[occi-wg] Instance runtime API

[Sam Johnston]

Randy,

You may well be right, but this should be a concern for implementors rather
than users - if I remember well there are virtualisation systems (UML?) that
rely on PPP style links and therefore lack MAC addresses. The key point is
that as a user I want to know that any attributes I set via the client
interface can only be seen by the machine as details like database
credentials are likely to be sensitive. For this there should be no need to
discover any credentials, rather just connect and ask away.

I've done some work around having machines generate a public key pair during
birth and then encrypting config info to them, but this is something that
can be strapped on later in high security environments if it's deemed
necessary - and in any case the machine being able to write its key pair
into OCCI would be advantageous (and transparent with what is proposed).

Sam

On Tue, Apr 21, 2009 at 7:55 AM, Randy Bias <randyb at gogrid.com> wrote:

>  Will have to be MAC.  URL example is fine.  Passing MAC up from
> networking stack will be painful requiring a custom low-level listener.
>  Implementation will be susceptible to hacking if providers do not enforce
> MAC addresses at switch/vswitch ports.
>
> Alternative is to say that ‘machine-id’ is always deposited in / or C:\ and
> has UUID.
>
>
> --Randy
>
>
> On 4/20/09 4:01 AM, "Sam Johnston" <samj at samj.net> wrote:
>
> My proposed solution for this is that the cloud provider simply allow the
> workload to transparently authenticate to OCCI via its IP/MAC address and/or
> [virtual] interface. We could use a well known alias like "self" so as the
> machine can just pull down *http://example.com/self* (without needing to
> know its own UUID) and extract from that any
> state/configuration/introspection/other information it needs.
>
>
>
> --
> Randy Bias, VP Technology Strategy, GoGrid
> randyb at gogrid.com, (415) 939-8507 [mobile]
> BLOG: http://neotactics.com/blog, TWITTER: twitter.com/randybias
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.ogf.org/pipermail/occi-wg/attachments/20090421/92a9203e/attachment.html