WIP: Namespace package

[dmcgowan]

Creates a namespace package and namespace tool. The interface to the namespace package is primarily focused on managing sets of namespace entries which can be used to resolve a name into entries and initialize a registry client.

[vbatts]

Think we could move this main() to the top, so it's the first thing after imports?

[dmcgowan]

agreed, should be on top

[vbatts]

what is lacking to get this merged?

[dmcgowan]

Instead of passing in a base set of Entries and a Discoverer, a Discoverer should be able to be composed of multiple discoverers. The base entries should be able to be converted to a discoverer from a static set of entries and composed with any other methods.

[dmcgowan]

@vbatts

There are still a few more changes I want to make before removing the WIP flag

• Add composable discoverer, move resolution logic to this discoverer
• Remove base entries from creating resolver, just use discoverer (add static discoverer which takes in entries)
• Remove need to import from distribution base package to allow namespace package to stand on its own
  • Remove repository client factory
  • Update resolution interface to only return Endpoint objects (this is all the client needs from Namespace)

[dmcgowan]

Made the updates from my previous comment. I need to do one more pass at code cleanup and unit tests then I will remove the WIP tag. I am happy with the current interface although if someone can offer a better name for Entry I would be grateful. I also still think RemoteEndpoint seems off but I am torn because I would prefer the entry argument parsing remain inside the namespace package. Opinions welcome.

[dmcgowan]

This struct only exists to ensure the underlying entry array is sorted. This keeps inserts and lookups fast. We could get rid of this struct and use functions which mutate and return the Entry slice, but we will lose that guarantee. This entries slice is never actually sorted since inserts are in order.

[miminar]

I've tried to identify gaps between desired feature set and currently proposed state of namespace stuff. The result can be found here.
@dmcgowan, @ncdc, @stevvooe: I'd appreciate if any of you could take a look and comment (probably here). There are few open questions and you may have the answers.

[dmcgowan]

@stevvooe I think I agree that from the namespace resolver perspective, entries should have a scope, action, and arguments. The only entry which would attempt to be resolved is the "namespace" action and only by a particular resolver such as the MultiResolver or a RecursiveResolver.

This is relevant to the http resolver contribution from @minimnar

[stevvooe]

@miminar I took a peak at the suggested changes. I'm confused as to why you'd add a block command when you can capture and blackhole the namespace:

some.company/      namespace
fully.configured/      namespace
fully.configured/      push ...
fully.configured/      pull ...

In the above example, "some.company/" is has no configuration so it cannot be pushed or pulled. Following from that, I find blocking the entire "endpoint" to be odd when you can simply not include it in the configuration.

These details may not be clear in the specification.

While the confirmation feature seems like a dubious feature, it would probably be better expressed as a modifier for namespace directive:

some.company/      namespace  confirm
some.company/      push  ...

Albeit, it seems odd to express UI behavior at this level. It might be better to have the concept of namespace-less targets, which could be used to push/pull (note the lack of a namespace declaration):

production        push ...
production        pull ...

Then, such and endpoint would require an explicit call out for push:

$ docker push production mysensitivieimage

[miminar]

@stevvooe You're right about the blocking feature. It wasn't clear enough to me while I wrote those notes.

I like the idea of namespace-less targets. I'll try to come up with more elaborated proposal based on it later.

[stevvooe]

@miminar Sounds good. We probably need to make these use cases clear in the namespace package docs.

[stevvooe]

We are reevaluating the approach here. Closing this for now.