opaque ids vs. natural keys

[Gustavo Niemeyer]

On Wed, May 29, 2013 at 2:15 AM, Tim Penhey <tim.penhey at canonical.com> wrote:
> I have been having a bit of an internal war (with myself) around
> document ids and business model keys.  This is something I want to bring
> up, and offer potential solutions.
>
> With the work going on around containers, it was suggested (and
> generally agreed upon) that we have machine ids that can be used to
> infer container type as well as parent child relationships.
>
> So machine ids:
>
>   "0" is a machine created by the environment provider
>   "0/lxc/0" is the first lxc container on machine "0"
>
>   "3/lxc/2" has a parent of "3" and a container type of "lxc"
>
>   The children of "3" are those whose machine IDs match "^3/\w+/\d+$"

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.


gustavo @ http://niemeyer.net