Ignacio,
FWIW enabling this use case has so far cost us the following blurb (under security):
"Resources should be transparently authenticated such that they can use
OCCI for introspection (e.g. a virtual machine could connect to OCCI to
discover application configuration parameters, SSH authorized_keys,
etc.). Authentication must be transparent and could be based on MAC
address, IP address, interface, etc.
"
I don't really want to get down to the nitty gritty of charterlawyering but I think it could fall under the scope of "lifecycle management" where the resource itself is just another actor. Aside from the sysadmin/developer advantages, allowing machines to bind themselves to networks/loadbalancers is fairly important for failover scenarios and the like too.
We can discuss the details later.
Sam
Hi Meb,
While those APIs are highly interesting and required for service
portability (contextualization of VMs), they are out of the scope of
this WG.
Regards
--
Ignacio M. Llorente, Full Professor (Catedratico): http://dsa-research.org/doku.php?id=people:llorente
DSA Research Group: web http://dsa-research.org and blog http://blog.dsa-research.org
Globus GridWay Metascheduler: http://www.GridWay.org
OpenNebula Virtual Infrastructure Engine: http://www.OpenNebula.org
On 20/04/2009, at 12:45, Marc-Elian Bégin wrote:
> Hi,
>
> Please tell me if I'm out-of-scope and/or out-of-sync, as I haven't
> read all the email threads and docs the group has produced.
>
> Are we considering the API around the interactions taking place
> between a running instance and the cloud? I mean by that two types of
> interactions:
> 1- Hooks required at the end of the boot sequence to bootstrap the
> connection between a specific image instance and its cloud context.
> 2- The interface with the cloud environment to retrieve instance
> information such as hostname (private and public), instance specific
> user-data, etc.
>
> I realise that this is heavily influenced by my work using EC2. The
> goal would be to improve images interoperability between clouds,
> setting aside for the moment the virtualisation technology used (which
> also bring other issues...).
>
> Comments?
>
> Cheers,
>
> Meb
>
> _______________________________________________
> occi-wg mailing list
> occi-wg@ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg
_______________________________________________
occi-wg mailing list
occi-wg@ogf.org
http://www.ogf.org/mailman/listinfo/occi-wg