opaque ids vs. natural keys

[Mark Shuttleworth]

On 05/31/2013 02:08 PM, Gustavo Niemeyer wrote:
> On Fri, May 31, 2013 at 3:43 AM, Ian Booth <ian.booth at canonical.com> wrote:
>>> My understanding of the sprint in Oakland is that we'd not tackle
>>> nesting at this point, which means in theory we'd just need a simple
>>> attribute saying "contained": "lxc" for the unit itself. This seems a
>>> few order of magnitudes simpler than changing primary keys like that,
>>> but I may be missing what this is all about.
>>>
>> Just as a heads up - we are not doing nesting now. We are ensuring the design
>> changes made now to support containers will also support nesting later on when
>> we do need to provide that feature.
> That's exactly what I was covering. I believe no design changes are
> at that level are necessary to support containers. A "container": "lxc"
> field in a unit is a trivial addition, and not a design change. It took
> quite a bit of debate to reach the conclusion that we don't need to
> care about nesting right now, and I wouldn't. This is not buying us
> anything from the list of critical features we have to add, or the list
> of critical things people want from us.
>
> I'm CCing Mark as I know he had strong opinions on that area, and was
> the proponent of nesting in the first place.

Yes & no!

We came to the agreement that we don't need to *deliver* nested
containers, but I did ask that we have a namespace which reflects
containers in a way that can accommodate nesting. So Tim's proposal
looks like a good start to me. It's unmodified from current
pre-container practice, and one can easily see how it would accommodate
both diverse container types and nesting.

What's not clear to me is whether the namespace in question should be
the service, or the machine.

It seems that what we're really describing is more like:

   machine:0/lxc/3

Mark