Instance runtime API
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
Inline... <snip> Are we considering the API around the interactions taking place between a running instance and the cloud? [AE: ] we need to be wary here - when speaking of "cloud" contextualise it - in OCCI's case it's cloud infrastructure - bottom most layer. 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. [AE: ] The OVF format allows for this in its specification 2- The interface with the cloud environment to retrieve instance information such as hostname (private and public), instance specific user-data, etc. [AE: ] This is outside the remit of OCCI. It's an internal concern of the provider's network ops and IP address management. Retrieval of user data might be seen as a concern within the platform layer. 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 ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934 This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies.
Andy, Actually this is something I had provided for as I think it's some nice low hanging fruit that provides *significant* value. While wary of scope creep I'm also wary of people having to implement multiple APIs for basic funcitonality that we could/should provide - basic storage/network manipulation being an obvious example. 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. Does that adequately meet this requirement? Sam On Mon, Apr 20, 2009 at 12:51 PM, Edmonds, AndrewX < andrewx.edmonds@intel.com> wrote:
Inline...
<snip>
Are we considering the API around the interactions taking place between a running instance and the cloud?
[AE: ] we need to be wary here - when speaking of "cloud" contextualise it - in OCCI's case it's cloud infrastructure - bottom most layer.
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.
[AE: ] The OVF format allows for this in its specification
2- The interface with the cloud environment to retrieve instance information such as hostname (private and public), instance specific user-data, etc.
[AE: ] This is outside the remit of OCCI. It's an internal concern of the provider's network ops and IP address management. Retrieval of user data might be seen as a concern within the platform layer.
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 ------------------------------------------------------------- Intel Ireland Limited (Branch) Collinstown Industrial Park, Leixlip, County Kildare, Ireland Registered Number: E902934
This e-mail and any attachments may contain confidential material for the sole use of the intended recipient(s). Any review or distribution by others is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies. _______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
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@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@gogrid.com, (415) 939-8507 [mobile] BLOG: http://neotactics.com/blog, TWITTER: twitter.com/randybias
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@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@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@gogrid.com, (415) 939-8507 [mobile] BLOG: http://neotactics.com/blog, TWITTER: twitter.com/randybias
"Sam" == Sam Johnston <samj@samj.net> writes: Sam> Randy,
Sam> You may well be right, but this should be a concern for Sam> implementors rather than users - if I remember well there are Sam> virtualisation systems (UML?) that rely on PPP style links and Sam> therefore lack MAC addresses. The key point is that as a user I No, not UML. User-Mode-Linux certainly lets you create and user PPP links, but it has three different kinds of ethernet attachments, all of which permit the "hypervisor" to specify the mac address for each interface. Sam> I've done some work around having machines generate a public Sam> key pair during birth and then encrypting config info to them, Sam> but this is something that can be strapped on later in high Sam> security environments if it's deemed necessary - and in any Sam> case the machine being able to write its key pair into OCCI Sam> would be advantageous (and transparent with what is proposed). Yes, it would be very nice to be have support for being able to do this. -- ] Y'avait une poule de jammé dans l'muffler!!!!!!!!! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
Randy Bias <randyb@gogrid.com> writes:
Alternative is to say that machine-id¹ is always deposited in / or C:\ and has UUID.
This is straying away from API territory into mechanism, but it's quite interesting so... If you're doing hardware virtualisation, you can always pass the machine UUID in through the SMBIOS UUID without breaking the abstraction layers. This is what we do with Qemu/KVM, and Google suggests an identical option is available with VMware ESX. I don't know what the analogue is for Xen. It has the advantage that the guest doesn't need to have network interfaces attached to know its own identity. Another possibility is to use a DHCP option if you're happy with a guest needing networking to be able to find out about itself. However, fiddling with the filesystem of a guest as it boots is not so appealing in reality. Quite apart from the layering violation, it assumes: - the root filesystem is mounted by exactly one guest; - the host understands which filesystem is the root and can correctly unpick containers like LVM, RAID and encryption; - the host can correctly detect and understand the filesystem itself (Solaris ZFS on a Linux host? ADFS on anything modern?); - the filesystem is of a type that can be meaningfully be written to (CramFS root? NFS root for that matter?). For each of the above assumptions, I can think of at least one customer on our cluster who violates it. (I'd love to say we have at least one client running an OS without a notion of filesystem at all, but sadly that isn't true yet as far as I know.) Cheers, Chris.
"Randy" == Randy Bias <randyb@gogrid.com> writes: Randy> Will have to be MAC. URL example is fine. Passing MAC up Randy> from networking stack will be painful requiring a custom Randy> low-level listener. Implementation will be susceptible to Randy> hacking if providers do not enforce MAC addresses at Randy> switch/vswitch ports.
I partly agree. An intermediate hack of dubious security is to do it all over IPv6, using autoconfigured (fe80:: or other) addresses... they naturally have the MAC built-in, and you don't have to be so concerned about overlapping IPs in the different private parts of the cloud.... Now you just need a filter that checks layer-2 MAC == layer-3 source IP, and the application way up can just check layer-3. Randy> Alternative is to say that machine-id¹ is always deposited Randy> in / or C:\ and has UUID. That's even more problematic, I think. VMware's instances have these guest variables accessible via the VMware tools utilities, and you can stick a uuid in there (and vmware already does that). However, I'd like to see this part standardized, perhaps through either DMI or ACPI. There are other larger bits I'd like to be able to pass in that way, such as a kerberos ticket, or an IPsec private key that would permit a diskless host to NFSv4 mount it's /. -- ] Y'avait une poule de jammé dans l'muffler!!!!!!!!! | firewalls [ ] Michael Richardson, Sandelman Software Works, Ottawa, ON |net architect[ ] mcr@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[ ] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
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
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 On Mon, Apr 20, 2009 at 1:01 PM, Ignacio Martin Llorente < llorente@dacya.ucm.es> wrote:
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
Sam, In my opinion, we should concentrate (at least for the first draft) on the API for the remote management of VMs. I do not see that the WG should now discuss contextualization issues and APIs that could be used by the VMs to retrieve contextualization info. The specification should manage the VMs as black-boxes. Cheers, Ignacio -- 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 13:17, Sam Johnston wrote:
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
On Mon, Apr 20, 2009 at 1:01 PM, Ignacio Martin Llorente <llorente@dacya.ucm.es
wrote: 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
Hi, I agree with Ignacio. But do not forget, work for OCCI might not be done when we finish this draft @OGF27...Plenty more OGFs to come where we can talk and work on extensions/refinements :-) All the best, -Thijs On Mon, 2009-04-20 at 13:24 +0200, Ignacio Martin Llorente wrote:
Sam,
In my opinion, we should concentrate (at least for the first draft) on the API for the remote management of VMs. I do not see that the WG should now discuss contextualization issues and APIs that could be used by the VMs to retrieve contextualization info. The specification should manage the VMs as black-boxes.
Cheers,
Ignacio
-- 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 13:17, Sam Johnston wrote:
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
On Mon, Apr 20, 2009 at 1:01 PM, Ignacio Martin Llorente <llorente@dacya.ucm.es
wrote: 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
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds Software Engineer Grid Computing Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com
I understand your desire of resisting 'feature creep'... and I respect it! Here's my 5 cents on the longer term vision and where I come from... Several of the potential customer I speak to regarding cloud computing want what I call an 'inter cloud'! This means having their own 'inner cloud' (running on their own resources within their own infrastructure) which can off load to other clouds (e.g. commercial clouds) excess requests when their capacity is exceeded and/or when certain policy requirements are met (e.g. privacy issues, such as 'this machine can run outside of my infrastructure'). All this such that their cloud users continue to interact with an elastic service (we don't want 'queues' à la grid to creep back into the cloud interface semantic). For this vision to be realised, we need what this group is currently doing, but we also need to define our building blocks (i.e. machine images) such they are portable between clouds... unless we capture the composition of an image at a different level and compose the image on the fly as resources are committed! Again, I don't want this to be a distraction from the currently agreed scope, simply wanted to share a bit of longer term vision. Cheers, Meb On Apr 20, 2009, at 1:31 PM, Thijs Metsch wrote:
Hi,
I agree with Ignacio. But do not forget, work for OCCI might not be done when we finish this draft @OGF27...Plenty more OGFs to come where we can talk and work on extensions/refinements :-)
All the best,
-Thijs
On Mon, 2009-04-20 at 13:24 +0200, Ignacio Martin Llorente wrote:
Sam,
In my opinion, we should concentrate (at least for the first draft) on the API for the remote management of VMs. I do not see that the WG should now discuss contextualization issues and APIs that could be used by the VMs to retrieve contextualization info. The specification should manage the VMs as black-boxes.
Cheers,
Ignacio
-- 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 13:17, Sam Johnston wrote:
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
On Mon, Apr 20, 2009 at 1:01 PM, Ignacio Martin Llorente <llorente@dacya.ucm.es
wrote: 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
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds Software Engineer Grid Computing Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
Meb, That's a great longer term vision and one that you will find people here share. Meanwhile, what comments do you have on the OCCI work done so far? alexis On Mon, Apr 20, 2009 at 1:02 PM, Marc-Elian Bégin <meb@sixsq.com> wrote:
I understand your desire of resisting 'feature creep'... and I respect it!
Here's my 5 cents on the longer term vision and where I come from...
Several of the potential customer I speak to regarding cloud computing want what I call an 'inter cloud'! This means having their own 'inner cloud' (running on their own resources within their own infrastructure) which can off load to other clouds (e.g. commercial clouds) excess requests when their capacity is exceeded and/or when certain policy requirements are met (e.g. privacy issues, such as 'this machine can run outside of my infrastructure'). All this such that their cloud users continue to interact with an elastic service (we don't want 'queues' à la grid to creep back into the cloud interface semantic).
For this vision to be realised, we need what this group is currently doing, but we also need to define our building blocks (i.e. machine images) such they are portable between clouds... unless we capture the composition of an image at a different level and compose the image on the fly as resources are committed!
Again, I don't want this to be a distraction from the currently agreed scope, simply wanted to share a bit of longer term vision.
Cheers,
Meb
On Apr 20, 2009, at 1:31 PM, Thijs Metsch wrote:
Hi,
I agree with Ignacio. But do not forget, work for OCCI might not be done when we finish this draft @OGF27...Plenty more OGFs to come where we can talk and work on extensions/refinements :-)
All the best,
-Thijs
On Mon, 2009-04-20 at 13:24 +0200, Ignacio Martin Llorente wrote:
Sam,
In my opinion, we should concentrate (at least for the first draft) on the API for the remote management of VMs. I do not see that the WG should now discuss contextualization issues and APIs that could be used by the VMs to retrieve contextualization info. The specification should manage the VMs as black-boxes.
Cheers,
Ignacio
-- 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 13:17, Sam Johnston wrote:
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
On Mon, Apr 20, 2009 at 1:01 PM, Ignacio Martin Llorente <llorente@dacya.ucm.es
wrote: 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
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds Software Engineer Grid Computing Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com
_______________________________________________ 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
On Apr 20, 2009, at 2:10 PM, Alexis Richardson wrote:
Meb,
That's a great longer term vision and one that you will find people here share.
:-)
Meanwhile, what comments do you have on the OCCI work done so far?
I trust you!! And I'm not sure I could contribute at this stage, both from an expertise and time view-point. I'm a cloud user, building an in-cloud deployment framework and image factory... from that respect, I don't mind writing specific adaptors or connectors for the different cloud species our application will be interacting with... but I'd like to be able to reason in terms of 'mammals' or 'reptiles', instead of 'unicellular organisms' and 'energy life-forms'!! What I mean with this is that if we can create convergence such that cloud species look, smell and feel more or less the same... life will be a lot easier... I don't mind learning the language details ('cause I don't know how to speak 'unicellular' ;-) If the group can deliver quickly something that reaches general consensus (I'm not bother with total consensus) it would be refreshing. We could then move on the the next phase, while letting the more nitty gritty detail be worked on in parallel... if needed; as I'm not sure we actually need a spec for this type of work, at least not at this time... but this is only my personal opinion. Cheers, Meb
alexis
On Mon, Apr 20, 2009 at 1:02 PM, Marc-Elian Bégin <meb@sixsq.com> wrote:
I understand your desire of resisting 'feature creep'... and I respect it!
Here's my 5 cents on the longer term vision and where I come from...
Several of the potential customer I speak to regarding cloud computing want what I call an 'inter cloud'! This means having their own 'inner cloud' (running on their own resources within their own infrastructure) which can off load to other clouds (e.g. commercial clouds) excess requests when their capacity is exceeded and/or when certain policy requirements are met (e.g. privacy issues, such as 'this machine can run outside of my infrastructure'). All this such that their cloud users continue to interact with an elastic service (we don't want 'queues' à la grid to creep back into the cloud interface semantic).
For this vision to be realised, we need what this group is currently doing, but we also need to define our building blocks (i.e. machine images) such they are portable between clouds... unless we capture the composition of an image at a different level and compose the image on the fly as resources are committed!
Again, I don't want this to be a distraction from the currently agreed scope, simply wanted to share a bit of longer term vision.
Cheers,
Meb
On Apr 20, 2009, at 1:31 PM, Thijs Metsch wrote:
Hi,
I agree with Ignacio. But do not forget, work for OCCI might not be done when we finish this draft @OGF27...Plenty more OGFs to come where we can talk and work on extensions/refinements :-)
All the best,
-Thijs
On Mon, 2009-04-20 at 13:24 +0200, Ignacio Martin Llorente wrote:
Sam,
In my opinion, we should concentrate (at least for the first draft) on the API for the remote management of VMs. I do not see that the WG should now discuss contextualization issues and APIs that could be used by the VMs to retrieve contextualization info. The specification should manage the VMs as black-boxes.
Cheers,
Ignacio
-- 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 13:17, Sam Johnston wrote:
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
On Mon, Apr 20, 2009 at 1:01 PM, Ignacio Martin Llorente <llorente@dacya.ucm.es
wrote: 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
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds Software Engineer Grid Computing Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com
_______________________________________________ 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
Meb, Thank-you ... and yes we are setting our goals to 'achievable quickly'. It sounds like you might be able to contribute some use cases? alexis On Mon, Apr 20, 2009 at 1:47 PM, Marc-Elian Bégin <meb@sixsq.com> wrote:
On Apr 20, 2009, at 2:10 PM, Alexis Richardson wrote:
Meb,
That's a great longer term vision and one that you will find people here share.
:-)
Meanwhile, what comments do you have on the OCCI work done so far?
I trust you!! And I'm not sure I could contribute at this stage, both from an expertise and time view-point. I'm a cloud user, building an in-cloud deployment framework and image factory... from that respect, I don't mind writing specific adaptors or connectors for the different cloud species our application will be interacting with... but I'd like to be able to reason in terms of 'mammals' or 'reptiles', instead of 'unicellular organisms' and 'energy life-forms'!! What I mean with this is that if we can create convergence such that cloud species look, smell and feel more or less the same... life will be a lot easier... I don't mind learning the language details ('cause I don't know how to speak 'unicellular' ;-)
If the group can deliver quickly something that reaches general consensus (I'm not bother with total consensus) it would be refreshing. We could then move on the the next phase, while letting the more nitty gritty detail be worked on in parallel... if needed; as I'm not sure we actually need a spec for this type of work, at least not at this time... but this is only my personal opinion.
Cheers,
Meb
alexis
On Mon, Apr 20, 2009 at 1:02 PM, Marc-Elian Bégin <meb@sixsq.com> wrote:
I understand your desire of resisting 'feature creep'... and I respect it!
Here's my 5 cents on the longer term vision and where I come from...
Several of the potential customer I speak to regarding cloud computing want what I call an 'inter cloud'! This means having their own 'inner cloud' (running on their own resources within their own infrastructure) which can off load to other clouds (e.g. commercial clouds) excess requests when their capacity is exceeded and/or when certain policy requirements are met (e.g. privacy issues, such as 'this machine can run outside of my infrastructure'). All this such that their cloud users continue to interact with an elastic service (we don't want 'queues' à la grid to creep back into the cloud interface semantic).
For this vision to be realised, we need what this group is currently doing, but we also need to define our building blocks (i.e. machine images) such they are portable between clouds... unless we capture the composition of an image at a different level and compose the image on the fly as resources are committed!
Again, I don't want this to be a distraction from the currently agreed scope, simply wanted to share a bit of longer term vision.
Cheers,
Meb
On Apr 20, 2009, at 1:31 PM, Thijs Metsch wrote:
Hi,
I agree with Ignacio. But do not forget, work for OCCI might not be done when we finish this draft @OGF27...Plenty more OGFs to come where we can talk and work on extensions/refinements :-)
All the best,
-Thijs
On Mon, 2009-04-20 at 13:24 +0200, Ignacio Martin Llorente wrote:
Sam,
In my opinion, we should concentrate (at least for the first draft) on the API for the remote management of VMs. I do not see that the WG should now discuss contextualization issues and APIs that could be used by the VMs to retrieve contextualization info. The specification should manage the VMs as black-boxes.
Cheers,
Ignacio
-- 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 13:17, Sam Johnston wrote:
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
On Mon, Apr 20, 2009 at 1:01 PM, Ignacio Martin Llorente <llorente@dacya.ucm.es > > wrote:
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
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
-- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds Software Engineer Grid Computing Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com
_______________________________________________ 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
On Apr 20, 2009, at 2:52 PM, Alexis Richardson wrote:
Meb,
Thank-you ... and yes we are setting our goals to 'achievable quickly'.
It sounds like you might be able to contribute some use cases?
With pleasure. With Ignacio Llorente (and others) we've started StratusLab (www.stratuslab.org/wiki) to look into some of the issues I mentioned... so through that work we'd could definitely share usecases (Ignacio ?). From SixSq and our SlipStream work (that's the name of our in-cloud deployment app), we'd also be able to propose usecases, this more from a cloud user point-of-view. I'll monitor the group's mailing list for the next round... but feel free to poke me if and when needed. Cheers, Meb
alexis
On Mon, Apr 20, 2009 at 1:47 PM, Marc-Elian Bégin <meb@sixsq.com> wrote:
On Apr 20, 2009, at 2:10 PM, Alexis Richardson wrote:
Meb,
That's a great longer term vision and one that you will find people here share.
:-)
Meanwhile, what comments do you have on the OCCI work done so far?
I trust you!! And I'm not sure I could contribute at this stage, both from an expertise and time view-point. I'm a cloud user, building an in- cloud deployment framework and image factory... from that respect, I don't mind writing specific adaptors or connectors for the different cloud species our application will be interacting with... but I'd like to be able to reason in terms of 'mammals' or 'reptiles', instead of 'unicellular organisms' and 'energy life-forms'!! What I mean with this is that if we can create convergence such that cloud species look, smell and feel more or less the same... life will be a lot easier... I don't mind learning the language details ('cause I don't know how to speak 'unicellular' ;-)
If the group can deliver quickly something that reaches general consensus (I'm not bother with total consensus) it would be refreshing. We could then move on the the next phase, while letting the more nitty gritty detail be worked on in parallel... if needed; as I'm not sure we actually need a spec for this type of work, at least not at this time... but this is only my personal opinion.
Cheers,
Meb
alexis
On Mon, Apr 20, 2009 at 1:02 PM, Marc-Elian Bégin <meb@sixsq.com> wrote:
I understand your desire of resisting 'feature creep'... and I respect it!
Here's my 5 cents on the longer term vision and where I come from...
Several of the potential customer I speak to regarding cloud computing want what I call an 'inter cloud'! This means having their own 'inner cloud' (running on their own resources within their own infrastructure) which can off load to other clouds (e.g. commercial clouds) excess requests when their capacity is exceeded and/or when certain policy requirements are met (e.g. privacy issues, such as 'this machine can run outside of my infrastructure'). All this such that their cloud users continue to interact with an elastic service (we don't want 'queues' à la grid to creep back into the cloud interface semantic).
For this vision to be realised, we need what this group is currently doing, but we also need to define our building blocks (i.e. machine images) such they are portable between clouds... unless we capture the composition of an image at a different level and compose the image on the fly as resources are committed!
Again, I don't want this to be a distraction from the currently agreed scope, simply wanted to share a bit of longer term vision.
Cheers,
Meb
On Apr 20, 2009, at 1:31 PM, Thijs Metsch wrote:
Hi,
I agree with Ignacio. But do not forget, work for OCCI might not be done when we finish this draft @OGF27...Plenty more OGFs to come where we can talk and work on extensions/refinements :-)
All the best,
-Thijs
On Mon, 2009-04-20 at 13:24 +0200, Ignacio Martin Llorente wrote:
Sam,
In my opinion, we should concentrate (at least for the first draft) on the API for the remote management of VMs. I do not see that the WG should now discuss contextualization issues and APIs that could be used by the VMs to retrieve contextualization info. The specification should manage the VMs as black-boxes.
Cheers,
Ignacio
-- 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 13:17, Sam Johnston wrote:
> 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 > > On Mon, Apr 20, 2009 at 1:01 PM, Ignacio Martin Llorente > <llorente@dacya.ucm.es >> >> wrote: > > 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 >
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
-- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds Software Engineer Grid Computing Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com
_______________________________________________ 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
Meb, Sounds good! The occi-wg wiki has a place to describe your use cases, so feel free to stick some on there :-) alexis On Mon, Apr 20, 2009 at 2:08 PM, Marc-Elian Bégin <meb@sixsq.com> wrote:
On Apr 20, 2009, at 2:52 PM, Alexis Richardson wrote:
Meb,
Thank-you ... and yes we are setting our goals to 'achievable quickly'.
It sounds like you might be able to contribute some use cases?
With pleasure. With Ignacio Llorente (and others) we've started StratusLab (www.stratuslab.org/wiki) to look into some of the issues I mentioned... so through that work we'd could definitely share usecases (Ignacio ?). From SixSq and our SlipStream work (that's the name of our in-cloud deployment app), we'd also be able to propose usecases, this more from a cloud user point-of-view.
I'll monitor the group's mailing list for the next round... but feel free to poke me if and when needed.
Cheers,
Meb
alexis
On Mon, Apr 20, 2009 at 1:47 PM, Marc-Elian Bégin <meb@sixsq.com> wrote:
On Apr 20, 2009, at 2:10 PM, Alexis Richardson wrote:
Meb,
That's a great longer term vision and one that you will find people here share.
:-)
Meanwhile, what comments do you have on the OCCI work done so far?
I trust you!! And I'm not sure I could contribute at this stage, both from an expertise and time view-point. I'm a cloud user, building an in-cloud deployment framework and image factory... from that respect, I don't mind writing specific adaptors or connectors for the different cloud species our application will be interacting with... but I'd like to be able to reason in terms of 'mammals' or 'reptiles', instead of 'unicellular organisms' and 'energy life-forms'!! What I mean with this is that if we can create convergence such that cloud species look, smell and feel more or less the same... life will be a lot easier... I don't mind learning the language details ('cause I don't know how to speak 'unicellular' ;-)
If the group can deliver quickly something that reaches general consensus (I'm not bother with total consensus) it would be refreshing. We could then move on the the next phase, while letting the more nitty gritty detail be worked on in parallel... if needed; as I'm not sure we actually need a spec for this type of work, at least not at this time... but this is only my personal opinion.
Cheers,
Meb
alexis
On Mon, Apr 20, 2009 at 1:02 PM, Marc-Elian Bégin <meb@sixsq.com> wrote:
I understand your desire of resisting 'feature creep'... and I respect it!
Here's my 5 cents on the longer term vision and where I come from...
Several of the potential customer I speak to regarding cloud computing want what I call an 'inter cloud'! This means having their own 'inner cloud' (running on their own resources within their own infrastructure) which can off load to other clouds (e.g. commercial clouds) excess requests when their capacity is exceeded and/or when certain policy requirements are met (e.g. privacy issues, such as 'this machine can run outside of my infrastructure'). All this such that their cloud users continue to interact with an elastic service (we don't want 'queues' à la grid to creep back into the cloud interface semantic).
For this vision to be realised, we need what this group is currently doing, but we also need to define our building blocks (i.e. machine images) such they are portable between clouds... unless we capture the composition of an image at a different level and compose the image on the fly as resources are committed!
Again, I don't want this to be a distraction from the currently agreed scope, simply wanted to share a bit of longer term vision.
Cheers,
Meb
On Apr 20, 2009, at 1:31 PM, Thijs Metsch wrote:
Hi,
I agree with Ignacio. But do not forget, work for OCCI might not be done when we finish this draft @OGF27...Plenty more OGFs to come where we can talk and work on extensions/refinements :-)
All the best,
-Thijs
On Mon, 2009-04-20 at 13:24 +0200, Ignacio Martin Llorente wrote: > > Sam, > > In my opinion, we should concentrate (at least for the first draft) > on the API for the remote management of VMs. I do not see that the WG > should now discuss contextualization issues and APIs that could be > used by the VMs to retrieve contextualization info. The specification > should manage the VMs as black-boxes. > > Cheers, > > Ignacio > > -- > 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 13:17, Sam Johnston wrote: > >> 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 >> >> On Mon, Apr 20, 2009 at 1:01 PM, Ignacio Martin Llorente >> <llorente@dacya.ucm.es >>> >>> wrote: >> >> 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 >> > > _______________________________________________ > occi-wg mailing list > occi-wg@ogf.org > http://www.ogf.org/mailman/listinfo/occi-wg
-- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds Software Engineer Grid Computing Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com
_______________________________________________ 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
Hi Meb, Thanks again for your feedback. Yes, I understand the problem (you know that is exactly the aim of OpenNebula, to build those "hybrid clouds") an in fact that is something that must be done to allow interoperation. I fully agree we need it. Cheers, -- 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 14:02, Marc-Elian Bégin wrote:
I understand your desire of resisting 'feature creep'... and I respect it!
Here's my 5 cents on the longer term vision and where I come from...
Several of the potential customer I speak to regarding cloud computing want what I call an 'inter cloud'! This means having their own 'inner cloud' (running on their own resources within their own infrastructure) which can off load to other clouds (e.g. commercial clouds) excess requests when their capacity is exceeded and/or when certain policy requirements are met (e.g. privacy issues, such as 'this machine can run outside of my infrastructure'). All this such that their cloud users continue to interact with an elastic service (we don't want 'queues' à la grid to creep back into the cloud interface semantic).
For this vision to be realised, we need what this group is currently doing, but we also need to define our building blocks (i.e. machine images) such they are portable between clouds... unless we capture the composition of an image at a different level and compose the image on the fly as resources are committed!
Again, I don't want this to be a distraction from the currently agreed scope, simply wanted to share a bit of longer term vision.
Cheers,
Meb
On Apr 20, 2009, at 1:31 PM, Thijs Metsch wrote:
Hi,
I agree with Ignacio. But do not forget, work for OCCI might not be done when we finish this draft @OGF27...Plenty more OGFs to come where we can talk and work on extensions/refinements :-)
All the best,
-Thijs
On Mon, 2009-04-20 at 13:24 +0200, Ignacio Martin Llorente wrote:
Sam,
In my opinion, we should concentrate (at least for the first draft) on the API for the remote management of VMs. I do not see that the WG should now discuss contextualization issues and APIs that could be used by the VMs to retrieve contextualization info. The specification should manage the VMs as black-boxes.
Cheers,
Ignacio
-- 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 13:17, Sam Johnston wrote:
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
On Mon, Apr 20, 2009 at 1:01 PM, Ignacio Martin Llorente <llorente@dacya.ucm.es
wrote: 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
_______________________________________________ occi-wg mailing list occi-wg@ogf.org http://www.ogf.org/mailman/listinfo/occi-wg -- Thijs Metsch Tel: +49 (0)941 3075-122 (x60122) http://blogs.sun.com/intheclouds Software Engineer Grid Computing Sun Microsystems GmbH Dr.-Leo-Ritter-Str. 7 mailto:thijs.metsch@sun.com D-93049 Regensburg http://www.sun.com
_______________________________________________ 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
+1 On 4/20/09 4:24 AM, "Ignacio Martin Llorente" <llorente@dacya.ucm.es> wrote:
In my opinion, we should concentrate (at least for the first draft) on the API for the remote management of VMs.
-- Randy Bias, VP Technology Strategy, GoGrid randyb@gogrid.com, (415) 939-8507 [mobile] BLOG: http://neotactics.com/blog, TWITTER: twitter.com/randybias
participants (9)
-
Alexis Richardson -
Chris Webb -
Edmonds, AndrewX -
Ignacio Martin Llorente -
Marc-Elian Bégin -
Michael Richardson -
Randy Bias -
Sam Johnston -
Thijs Metsch