Hi All.
Would people consider an addition to the instance creation part of deltacloud API to allow the injection of files/content to specified paths? (an extra optional field(s) on the POST)?
(this is the sort of thing that we need to have in some kind of semi-formal RFC wiki setup for people to point at and shout).
+1 -Adrian Jclouds
On Dec 7, 2009 4:47 PM, "Michael Neale" michael.neale@gmail.com wrote:
Hi All.
Would people consider an addition to the instance creation part of deltacloud API to allow the injection of files/content to specified paths? (an extra optional field(s) on the POST)?
(this is the sort of thing that we need to have in some kind of semi-formal RFC wiki setup for people to point at and shout).
-- Michael D Neale home: www.michaelneale.net blog: michaelneale.blogspot.com _______________________________________________ deltacloud-devel mailing list deltacloud-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/deltacloud-devel
I'm currently working on getting file injection into the RimuHosting API. After that I will work on some patches for the deltacloud api to add this functionality in.
-Ivan
On Tue, Dec 8, 2009 at 1:46 PM, Michael Neale michael.neale@gmail.com wrote:
Hi All.
Would people consider an addition to the instance creation part of deltacloud API to allow the injection of files/content to specified paths? (an extra optional field(s) on the POST)?
(this is the sort of thing that we need to have in some kind of semi-formal RFC wiki setup for people to point at and shout).
-- Michael D Neale home: www.michaelneale.net blog: michaelneale.blogspot.com _______________________________________________ deltacloud-devel mailing list deltacloud-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/deltacloud-devel
On Tue, Dec 08, 2009 at 03:43:49PM +1300, Ivan Meredith wrote:
I'm currently working on getting file injection into the RimuHosting API. After that I will work on some patches for the deltacloud api to add this functionality in.
-Ivan
On Tue, Dec 8, 2009 at 1:46 PM, Michael Neale michael.neale@gmail.com wrote:
Hi All.
Would people consider an addition to the instance creation part of deltacloud API to allow the injection of files/content to specified paths? (an extra optional field(s) on the POST)?
(this is the sort of thing that we need to have in some kind of semi-formal RFC wiki setup for people to point at and shout).
-- Michael D Neale home: www.michaelneale.net blog: michaelneale.blogspot.com
Certainly we will need something like that, I'd welcome an RFC patch.
BTW Ivan if you don't mind, please don't top-post -- makes the conversation hard to follow.
Thanks, --Hugh
On Tue, 2009-12-08 at 15:43 +1300, Ivan Meredith wrote:
I'm currently working on getting file injection into the RimuHosting API. After that I will work on some patches for the deltacloud api to add this functionality in.
Is this truly file injection (i.e., I can say 'replace /etc/hosts with this' when I start an instance) rather than EC2's user-data mechanism ?
David
On Wed, Dec 16, 2009 at 1:34 PM, David Lutterkort lutter@redhat.com wrote:
On Tue, 2009-12-08 at 15:43 +1300, Ivan Meredith wrote:
I'm currently working on getting file injection into the RimuHosting API. After that I will work on some patches for the deltacloud api to add this functionality in.
Is this truly file injection (i.e., I can say 'replace /etc/hosts with this' when I start an instance) rather than EC2's user-data mechanism ?
Yes you would be able to do that
So, EC2 doesn't allow (this week) the specific injection of files into instances.
It does allow placement of up to 16k into a location that can be fetched by instance upon boot.
With EC2, we could 'fake' file injection, by only having the driver inject it into the instance boot metadata.
It'd be up to the image to actually do the pull at boot time.
I think this would allow supporting this functionality, and not being limited by what EC2 can (or can't) do.
A 20-line bash init.d script could be provided for people using EC2 to enable pulling from the metadata at boottime and injecting the file(s) locally.
Ultimately, "injection" is only partially defined to mean "push as far as possible for this provider". And I think that's fine.
-Bob
On Dec 7, 2009, at 7:46 PM, Michael Neale wrote:
Hi All.
Would people consider an addition to the instance creation part of deltacloud API to allow the injection of files/content to specified paths? (an extra optional field(s) on the POST)?
(this is the sort of thing that we need to have in some kind of semi-formal RFC wiki setup for people to point at and shout).
-- Michael D Neale home: www.michaelneale.net blog: michaelneale.blogspot.com _______________________________________________ deltacloud-devel mailing list deltacloud-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/deltacloud-devel
On Tue, Dec 8, 2009 at 10:06 AM, Bob McWhirter bmcwhirt@redhat.com wrote:
So, EC2 doesn't allow (this week) the specific injection of files into instances.
It does allow placement of up to 16k into a location that can be fetched by instance upon boot.
With EC2, we could 'fake' file injection, by only having the driver inject it into the instance boot metadata.
It'd be up to the image to actually do the pull at boot time.
I think this would allow supporting this functionality, and not being limited by what EC2 can (or can't) do.
A 20-line bash init.d script could be provided for people using EC2 to enable pulling from the metadata at boottime and injecting the file(s) locally.
Ultimately, "injection" is only partially defined to mean "push as far as possible for this provider". And I think that's fine.
-Bob
On Dec 7, 2009, at 7:46 PM, Michael Neale wrote:
Hi All.
Would people consider an addition to the instance creation part of deltacloud API to allow the injection of files/content to specified paths? (an extra optional field(s) on the POST)?
(this is the sort of thing that we need to have in some kind of semi-formal RFC wiki setup for people to point at and shout).
-- Michael D Neale home: www.michaelneale.net blog: michaelneale.blogspot.com _______________________________________________ deltacloud-devel mailing list deltacloud-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/deltacloud-devel
deltacloud-devel mailing list deltacloud-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/deltacloud-devel
What about using ace/puppet or something similar for this kind of configuration? Then we don't have to depend on the provider of the cloud, just that we have some basic components installed on our instance(s). Rightscale has a similar concept to this with their server templates and 'rightScripts', and we did the same thing in the oVirt project to configure/setup an 'appliance' server.
Good point, Thorsten. I think the 'bootstrap script' is the highest value add. Not a replacement for puppet/etc, but these services need to be installed before they can be used. Having an injection/exec feature allows you to overlay an embryo image with whatever you want to finish the job, albeit chef, puppet, apt-get whatever.
FWIW, jclouds is exposing this so that we don't depend so heavily on specific cloud support and images. If the vendor doesn't support injection, we simply ssh in, push the file, and exec it. Outside windows, accomplishing this cross-cloud isn't rocket science for most cases.
my 2p. -Adrian
On Tue, Dec 8, 2009 at 8:03 AM, Thorsten von Eicken tve@rightscale.comwrote:
For EC2 you might consider supporting http://alestic.com/2009/06/ec2-user-data-scriptshttp://alestic.com/2009/06/ec2-user-data-scripts, which is a nice way to go. Thorsten
Bob McWhirter wrote:
So, EC2 doesn't allow (this week) the specific injection of files into instances.
It does allow placement of up to 16k into a location that can be fetched by instance upon boot.
With EC2, we could 'fake' file injection, by only having the driver inject it into the instance boot metadata.
It'd be up to the image to actually do the pull at boot time.
I think this would allow supporting this functionality, and not being limited by what EC2 can (or can't) do.
A 20-line bash init.d script could be provided for people using EC2 to enable pulling from the metadata at boottime and injecting the file(s) locally.
Ultimately, "injection" is only partially defined to mean "push as far as possible for this provider". And I think that's fine.
-Bob
On Dec 7, 2009, at 7:46 PM, Michael Neale wrote:
Hi All.
Would people consider an addition to the instance creation part of deltacloud API to allow the injection of files/content to specified paths? (an extra optional field(s) on the POST)?
(this is the sort of thing that we need to have in some kind of semi-formal RFC wiki setup for people to point at and shout).
-- Michael D Neale home: www.michaelneale.net blog: michaelneale.blogspot.com _______________________________________________ deltacloud-devel mailing listdeltacloud-devel@lists.fedorahosted.orghttps://fedorahosted.org/mailman/listinfo/deltacloud-devel
deltacloud-devel mailing listdeltacloud-devel@lists.fedorahosted.orghttps://fedorahosted.org/mailman/listinfo/deltacloud-devel
deltacloud-devel mailing list deltacloud-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/deltacloud-devel
On Wed, Dec 9, 2009 at 7:12 AM, Adrian Cole adrian@jclouds.org wrote:
Good point, Thorsten. I think the 'bootstrap script' is the highest value add. Not a replacement for puppet/etc, but these services need to be installed before they can be used. Having an injection/exec feature allows you to overlay an embryo image with whatever you want to finish the job, albeit chef, puppet, apt-get whatever.
FWIW, jclouds is exposing this so that we don't depend so heavily on specific cloud support and images. If the vendor doesn't support injection, we simply ssh in, push the file, and exec it. Outside windows, accomplishing this cross-cloud isn't rocket science for most cases.
my 2p. -Adrian
I guess it depends on what people are happy having deltacloud do/be. Is it acceptable to require features that are not (yet) available be "emulated" via other means ?
I think Thorsten's comments make sense: you need some way to give the server enough identity to boot strap from there, that is often what it comes down to, so perhaps it isn't about arbitrary file injection but about identity/security so it can then run bootstrap scripts etc.
On Tue, Dec 8, 2009 at 8:03 AM, Thorsten von Eicken tve@rightscale.com wrote:
For EC2 you might consider supporting http://alestic.com/2009/06/ec2-user-data-scripts, which is a nice way to go. Thorsten
Bob McWhirter wrote:
So, EC2 doesn't allow (this week) the specific injection of files into instances.
It does allow placement of up to 16k into a location that can be fetched by instance upon boot.
With EC2, we could 'fake' file injection, by only having the driver inject it into the instance boot metadata.
It'd be up to the image to actually do the pull at boot time.
I think this would allow supporting this functionality, and not being limited by what EC2 can (or can't) do.
A 20-line bash init.d script could be provided for people using EC2 to enable pulling from the metadata at boottime and injecting the file(s) locally.
Ultimately, "injection" is only partially defined to mean "push as far as possible for this provider". And I think that's fine.
-Bob
On Dec 7, 2009, at 7:46 PM, Michael Neale wrote:
Hi All.
Would people consider an addition to the instance creation part of deltacloud API to allow the injection of files/content to specified paths? (an extra optional field(s) on the POST)?
(this is the sort of thing that we need to have in some kind of semi-formal RFC wiki setup for people to point at and shout).
-- Michael D Neale home: www.michaelneale.net blog: michaelneale.blogspot.com _______________________________________________ deltacloud-devel mailing list deltacloud-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/deltacloud-devel
deltacloud-devel mailing list deltacloud-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/deltacloud-devel
deltacloud-devel mailing list deltacloud-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/deltacloud-devel
deltacloud-devel mailing list deltacloud-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/deltacloud-devel
2009/12/9 Michael Neale michael.neale@gmail.com:
On Wed, Dec 9, 2009 at 7:12 AM, Adrian Cole adrian@jclouds.org wrote:
Good point, Thorsten. I think the 'bootstrap script' is the highest value add. Not a replacement for puppet/etc, but these services need to be installed before they can be used. Having an injection/exec feature allows you to overlay an embryo image with whatever you want to finish the job, albeit chef, puppet, apt-get whatever.
FWIW, jclouds is exposing this so that we don't depend so heavily on specific cloud support and images. If the vendor doesn't support injection, we simply ssh in, push the file, and exec it. Outside windows, accomplishing this cross-cloud isn't rocket science for most cases.
my 2p. -Adrian
I guess it depends on what people are happy having deltacloud do/be. Is it acceptable to require features that are not (yet) available be "emulated" via other means ?
I think Thorsten's comments make sense: you need some way to give the server enough identity to boot strap from there, that is often what it comes down to, so perhaps it isn't about arbitrary file injection but about identity/security so it can then run bootstrap scripts etc.
Hello,
I'm developing an application which can benefit from using a deltacloud API. It appeared very difficult to configure instances in practive. I've blogged on the subject here: http://it-result.me/configuring-cloud-nodes-with-deltacloud/
My personal opinion is that full-scale file injection via deltacloud API is likely not necessary. It is sufficient to be able to pass a single file to the instance on start. If instance needs to be heavily customized it is better to customize the image or use some kind of configuration management system.
A solution which worked fine for me was instance model class modification to contain additional "client_data" property used to pass the configuration data to the instance (the patch attached below). A driver is supposed to pass the value to the instance in provider-dependent manner. E.g. it can inject the configuration information into a file with a well-known name on the instance filesystem. Or, for EC2, it can pass it via user-data so that instance can fetch the data from a fixed URL as described in EC2 developers guide.
The patch does not attempt to establish any standard location for the client_data information on the instance filesystem. It is probably unnecessary because it is platform-dependent and because not all providers (e.g. EC2) support file injection anyway.
The deltacloud API patch can be found here: http://it-result.me/wp-content/uploads/2010/01/client-data.patch.txt
Hope it can be of any use.
Thank you, Roman
On Thu, 2010-01-14 at 13:15 +0300, Roman wrote:
I'm developing an application which can benefit from using a deltacloud API. It appeared very difficult to configure instances in practive. I've blogged on the subject here: http://it-result.me/configuring-cloud-nodes-with-deltacloud/
Nice, I see you even have a patch for supporting user data on that post. Before committing that, I'd like to see if we can expand that mechanism to other clouds than just EC2.
My personal opinion is that full-scale file injection via deltacloud API is likely not necessary. It is sufficient to be able to pass a single file to the instance on start. If instance needs to be heavily customized it is better to customize the image or use some kind of configuration management system.
I agree with that - I believe people are in general better off if they use some central cloud-independent service for configuring their instances. Of course, we still need to provide them with enough of a hook to bootstrap that process.
A solution which worked fine for me was instance model class modification to contain additional "client_data" property used to pass the configuration data to the instance (the patch attached below).
Not attached, but I saw it on your blog ;)
The patch does not attempt to establish any standard location for the client_data information on the instance filesystem. It is probably unnecessary because it is platform-dependent and because not all providers (e.g. EC2) support file injection anyway.
I think longer term, we'd also want some sort of cloud-compat package that people can install inside their instances so that you can get user data through the exact same mechanism, regardless of cloud.
The deltacloud API patch can be found here: http://it-result.me/wp-content/uploads/2010/01/client-data.patch.txt
I want to get some clarity on how we can simulate that in other clouds, but I think your patch will be the way to go as a generic mechanism.
David
On Thu, Jan 14, 2010 at 9:15 PM, Roman roman.maillist@gmail.com wrote:
Hello,
I'm developing an application which can benefit from using a deltacloud API. It appeared very difficult to configure instances in practive. I've blogged on the subject here: http://it-result.me/configuring-cloud-nodes-with-deltacloud/
Nice - that blog sums up why this is needed perfectly in deltacloud. I agree - only needs to be minimal injection.
FWIW, rackspace offers injection by passing a file path and a Base64 encoding of file data (only up to 10kb though). I know others offer similar things (such as rimu, or will shortly). So at least on the rackspace side, the driver could accomodate it by injecting it into the server create request "message".
If there is a minimal single file injection we can agree on (is a single file enough?) - then I think this really should be in deltacloud, as it makes it workable for many many cases. I think its reasonable to expect cloud providers to have this (as I think they all pretty much do) without having to emulate it with a post-startup script (which would be what people do now I guess).
On Sun, 2010-01-17 at 09:14 +1100, Michael Neale wrote:
FWIW, rackspace offers injection by passing a file path and a Base64 encoding of file data (only up to 10kb though). I know others offer similar things (such as rimu, or will shortly). So at least on the rackspace side, the driver could accomodate it by injecting it into the server create request "message".
If there is a minimal single file injection we can agree on (is a single file enough?) - then I think this really should be in deltacloud, as it makes it workable for many many cases. I think its reasonable to expect cloud providers to have this (as I think they all pretty much do) without having to emulate it with a post-startup script (which would be what people do now I guess).
From an API POV, we should support both, and let people discover what
mechanism the backend cloud supports. Anything else, for example, simulating EC2's user-data mechanism on rackspace by injecting a fixed file will lead to a lowest-common denominator API.
What I am thinking is that we indicate such variations in the toplevel api.xml. For example, instead of just saying
<link href="http://localhost:3000/api/instances" rel="instances"/>
for EC2 we'd say
<link href="http://localhost:3000/api/instances" rel="instances"> <operation name="create"> <user-data> <maxsize unit="kB">16</maxsize> </user-data> </operation> </link>
and for Rack we'd say
<link href="http://localhost:3000/api/instances" rel="instances"> <operation name="create"> <user-files max="5"> <maxsize="10" unit="kB">10</maxsize> <path-length unit="byte">255</path-length> </user-files> </operation> </link>
That way, applications can discover which mechanism for file injection the cloud supports, and act accordingly.
David
On Wed, Jan 20, 2010 at 11:01 AM, David Lutterkort lutter@redhat.comwrote:
From an API POV, we should support both, and let people discover what
mechanism the backend cloud supports. Anything else, for example, simulating EC2's user-data mechanism on rackspace by injecting a fixed file will lead to a lowest-common denominator API.
Yes, it will - which is ok if lowest common denominator is useful (ie at
this stage of cloud providers, there is lots of innovation going on - surely it won't continue like this for ever !).
....
That way, applications can discover which mechanism for file injection the cloud supports, and act accordingly.
David
So this turns deltacloud into a "discovery" API - is that the direction that deltacloud needs to go? At the moment it is an API that you can use to do something more or less directly. Introducing a discovery component means that to use this api, you need to discover capabilities, and then make a decision in your client code how to use/not use them (which is kind of pushing it up a layer to the clients) - doesn't that make it harder for people to write clients that can work across clouds?
On 01/19/2010 09:20 PM, Michael Neale wrote:
So this turns deltacloud into a "discovery" API - is that the direction that deltacloud needs to go? At the moment it is an API that you can use to do something more or less directly. Introducing a discovery component means that to use this api, you need to discover capabilities, and then make a decision in your client code how to use/not use them (which is kind of pushing it up a layer to the clients) - doesn't that make it harder for people to write clients that can work across clouds?
Masking irrelevant differences is a key goal for the API, enabling developers to write once and interact with many clouds. At the same time, exposing differentiating behaviour, or methods which cannot be masked via capability discovery is also important. File injection is perhaps somewhere in the middle.
b
On Wed, Jan 20, 2010 at 1:38 PM, Brian Stevens bstevens@redhat.com wrote:
Masking irrelevant differences is a key goal for the API, enabling developers to write once and interact with many clouds. At the same time, exposing differentiating behaviour, or methods which cannot be masked via capability discovery is also important. File injection is perhaps somewhere in the middle.
b
Right - so "masking" - how far do we go to mask something my emulating it in some driver code etc?
Would be nice is one day be able to go to aws.amazon.com/deltacloud and rackspacecloud.com/deltacloud and rimuhosting.com/deltacloud etc and see (modulo api version) enough to get going with. In that case using the discovery stuff would be nice. But in the case of me (as a user) running deltacloud impl locally to provide me with interop - I would be happier to let it emulate for me (perhaps... just thinking aloud of the different ways people will use this).
On Wed, 2010-01-20 at 13:20 +1100, Michael Neale wrote:
So this turns deltacloud into a "discovery" API - is that the direction that deltacloud needs to go? At the moment it is an API that you can use to do something more or less directly. Introducing a discovery component means that to use this api, you need to discover capabilities, and then make a decision in your client code how to use/not use them (which is kind of pushing it up a layer to the clients) - doesn't that make it harder for people to write clients that can work across clouds?
I think you're disappointed with the messenger ;)
To stick with file/user-data injection: today, only EC2 and Rackspace give you some capability to do that as far as I can tell. EC2 does the user-data thing that you can access via HTTP inside the image, Rackspace lets you write up to five small files anywhere in the file system. The only way in which we could make that difference disappear is to simulate EC2's user-data on Rackspace by putting user-data into a fixed file in the filesystem - that's unsatisfactory for people who want to use deltacloud only for Rackspace, since we've removed a feature.
Both mechanisms are reasonable, and I would hope that other cloud providers will follow one of these instead of inventing yet another one. That in itself means that you can port applications from one cloud to another as long as they support the same injection mechanism - deltacloud will take care of minor differences of how exactly you inject that data. If you don't want to bother with discovery, ensure in some other way that all the clouds you're targeting support the features you need, e.g. restrict yourself to a subset of drivers.
To get portability to a wider range of clouds, an application needs to be aware to some extent of the differences between clouds - there's no way we can pretend in deltacloud that GoGrid (or most other clouds) support any sort of data injection. To help those, more complex, applications, deltacloud should tell them about features that only some of the drivers support.
So, I see adding capabilities metadata and allowing discovery not as a restriction of what people can do, but a help for people who want or need to do more complicated things.
David
On Wed, Jan 20, 2010 at 2:09 PM, David Lutterkort lutter@redhat.com wrote:
I think you're disappointed with the messenger ;)
Oh no - not disappointed ;) just more thinking as how *I* would like to use it - as Roman pointed out in his blog, to make it useful this minimal injection was needed. But what was interesting was that with that minimal injection, he was able to do something useful. I would think if someone is happily sticking with rackspace they would use the nice rackspace api directly (should they want features that it offers over deltacloud) - the few clouds I know about have something that would map to this or else come very close without a lot of work at all.
I agree that portability is far more than this, but this inches us a bit closer (keep in mind I am thinking portability of applications - not so much in taking an entire image and moving it intact). ie avoiding any overt lock-in to a specific cloud in terms of my application.
Perhaps file injection (as Brian mentioned in a separate thread) is one of the "inbetween" things that really should be in a version of the API, but perhaps with additional features on top of that discoverable. The discoverable stuff would need to make sure it covers enough of what other clouds offer, otherwise people may as well go direct.
To stick with file/user-data injection: today, only EC2 and Rackspace give you some capability to do that as far as I can tell. EC2 does the user-data thing that you can access via HTTP inside the image, Rackspace lets you write up to five small files anywhere in the file system. The only way in which we could make that difference disappear is to simulate EC2's user-data on Rackspace by putting user-data into a fixed file in the filesystem - that's unsatisfactory for people who want to use deltacloud only for Rackspace, since we've removed a feature.
Both mechanisms are reasonable, and I would hope that other cloud providers will follow one of these instead of inventing yet another one. That in itself means that you can port applications from one cloud to another as long as they support the same injection mechanism - deltacloud will take care of minor differences of how exactly you inject that data. If you don't want to bother with discovery, ensure in some other way that all the clouds you're targeting support the features you need, e.g. restrict yourself to a subset of drivers.
To get portability to a wider range of clouds, an application needs to be aware to some extent of the differences between clouds - there's no way we can pretend in deltacloud that GoGrid (or most other clouds) support any sort of data injection. To help those, more complex, applications, deltacloud should tell them about features that only some of the drivers support.
So, I see adding capabilities metadata and allowing discovery not as a restriction of what people can do, but a help for people who want or need to do more complicated things.
David
I beleive there is a consensus over the fact that the data injection feature is a must (or at least very useful) for deltacloud. Please correct me if I'm wrong.
These are my comments.
2010/1/20 David Lutterkort lutter@redhat.com:
From an API POV, we should support both, and let people discover what mechanism the backend cloud supports. Anything else, for example, simulating EC2's user-data mechanism on rackspace by injecting a fixed file will lead to a lowest-common denominator API.
Deltacloud is a provider-independent API. if somebody chooses it, he will expect it to be closer to a lowest-common denominator API. Not all features of underlying providers will be supported. In exchange there is no need to make multiple cloud management implementations.
If deltacloud API comes with optional extension features, which are not supported across all providers, such features should be clearly marked in API and documentation as an extension so that developers can avoid using them if they want to stay provider-independent.
I think that the data injection feature discussed in this thread is a basic one thus it should not be implemented as a kind of discoverable extension (if possible). In worst case, make the data injection feature an extension, but do not offer different ways of injecting data in deltacloud API.
--------------------------------------------- 2010/1/15 David Lutterkort lutter@redhat.com:
I think longer term, we'd also want some sort of cloud-compat package that people can install inside their instances so that you can get user data through the exact same mechanism, regardless of cloud.
I think this would be a good way to go.
Wonder if there any other way for deltacloud API to stay cloud provider-independent?
--------------------------------------------- 2010/1/17 Michael Neale michael.neale@gmail.com:
If there is a minimal single file injection we can agree on (is a single file enough?)
I think that single file enough, and the rackspace way of injecting multiple files looks equally good. Indeed, some developers will probably prefer a richer-style rackspace way of injecting multiple files.
In API, can we agree that the additional instance model field (named client_data in my patch) should contain an array of File objects? Each file can have name and content properties. Let's put no any hard limits on the number of files. Let's put limits on a total file size.
I think that it would be better for implementation to pass a single file to the instance and let the cloud-compat package to expand it on first instance startup into multiple files specified in deltacloud create instance API call.
Would this way be sufficiently good to go?
Probably it worth to start from trivial single-file injection and then extend it to injecting multiple files mixed with bootstrap scripts, etc.
---------------------------------------------
2010/1/20 David Lutterkort lutter@redhat.com:
To stick with file/user-data injection: today, only EC2 and Rackspace give you some capability to do that as far as I can tell.
I agree that for other providers it might be missing, still it is a useful feature.
To get portability to a wider range of clouds, an application needs to be aware to some extent of the differences between clouds - there's no way we can pretend in deltacloud that GoGrid (or most other clouds) support any sort of data injection. To help those, more complex, applications, deltacloud should tell them about features that only some of the drivers support.
It will make a sense. If my application needs data injection and it is supported only by a subset of drivers, I will limit it to the subset of drivers, and that would be absolutely OK for me.
I can think about some, a kind of last resort, workaround ways for achieving data injection for providers which do not support data injection.
E.g., something along EC2-style. In certain conditions it is possible to set up a service for distributing injected data to the instances. Upon instance boot the deltacloud-compat will contact the service over the internet and the service will retrieve the injected data from deltacloud based on instance IP address and push it to the instance. Downsides are security issues and the need to set up a corresponding network infrastructure.
On Wed, 2010-01-20 at 14:46 +0300, Roman wrote:
I beleive there is a consensus over the fact that the data injection feature is a must (or at least very useful) for deltacloud. Please correct me if I'm wrong.
I completely agree - I see data injection as a very important feature.
2010/1/20 David Lutterkort lutter@redhat.com:
From an API POV, we should support both, and let people discover what mechanism the backend cloud supports. Anything else, for example, simulating EC2's user-data mechanism on rackspace by injecting a fixed file will lead to a lowest-common denominator API.
Deltacloud is a provider-independent API. if somebody chooses it, he will expect it to be closer to a lowest-common denominator API. Not all features of underlying providers will be supported. In exchange there is no need to make multiple cloud management implementations.
For data injection, that lcd today is no data injection - as long as there are clouds that do not support it, we can't offer it in deltacloud. If somebody starts an instance on GoGrid and passes user-data, we have to return an error, since GoGrid doesn't support that.
The discovery mechanism I suggested still lets you use deltacloud as a lcd API: simply ignore advertisements of optional features.
If deltacloud API comes with optional extension features, which are not supported across all providers, such features should be clearly marked in API and documentation as an extension so that developers can avoid using them if they want to stay provider-independent.
That's exactly the intent behind discovery. In addition, you should never have to make decisions based on the name of the provider - you should always be able to make them based on metadata you get from the concrete driver. IOW, if you want to know if you can inject user data, don't check whether you're talking to EC2, check for well-known metadata in the API description.
I think that the data injection feature discussed in this thread is a basic one thus it should not be implemented as a kind of discoverable extension (if possible). In worst case, make the data injection feature an extension, but do not offer different ways of injecting data in deltacloud API.
But no matter what we do, it _will_ be different, since the two clouds that offer it use different mechanisms. The choices we have are 1. stick with the lcd and do nothing 2. advertise only a user-data feature, and inject that as a file on rack 3. advertise EC2's user-data and Rack's file injection differently
Clearly, I prefer (3) since it does not hinder people who only use Rack (or any cloud that will add file injection in the future)
2010/1/15 David Lutterkort lutter@redhat.com:
I think longer term, we'd also want some sort of cloud-compat package that people can install inside their instances so that you can get user data through the exact same mechanism, regardless of cloud.
I think this would be a good way to go.
Wonder if there any other way for deltacloud API to stay cloud provider-independent?
Just to be clear: I don't want to make using dcloud API dependent on any special sauce installed in the image. Rather, such a compat package should make creating cloud-independent images easier.
I'd be open to having an API variant that is geared towards images with a dcloud-compat installed, but that can't be the primary API.
In API, can we agree that the additional instance model field (named client_data in my patch) should contain an array of File objects? Each file can have name and content properties. Let's put no any hard limits on the number of files. Let's put limits on a total file size.
What do you do when somebody tries to inject files into a GoGrid instance ? Or an EC2 instance ? What when they try to inject 7 files into a Rack instance ? Silent failure is not an option ;)
I think that it would be better for implementation to pass a single file to the instance and let the cloud-compat package to expand it on first instance startup into multiple files specified in deltacloud create instance API call.
Would this way be sufficiently good to go?
No, since it would remove a feature that people are already using. It's only an option for images where we know that dcloud-compat has been installed.
E.g., something along EC2-style. In certain conditions it is possible to set up a service for distributing injected data to the instances. Upon instance boot the deltacloud-compat will contact the service over the internet and the service will retrieve the injected data from deltacloud based on instance IP address and push it to the instance. Downsides are security issues and the need to set up a corresponding network infrastructure.
Hmm .. that sounds very involved to me - I am pretty confident that sooner or later all clouds will offer some sort of data injection. If people already have code for something like this, it would be nice to include it in some generally available project.
David
On Thu, Jan 21, 2010 at 5:45 AM, David Lutterkort lutter@redhat.com wrote:
That's exactly the intent behind discovery. In addition, you should never have to make decisions based on the name of the provider - you should always be able to make them based on metadata you get from the concrete driver. IOW, if you want to know if you can inject user data, don't check whether you're talking to EC2, check for well-known metadata in the API description.
Right, so perhaps I was getting things confused in my mind. So what you are suggesting is that some file injection feature is part of the api - but in an optional section. And the api would provide a way to query what in the optional section is available?
What would be nice would be to pick either the Rackspace or the EC2 way of injection, and make that the "normal" way - and emulate it if really needed (in the driver if necessary) for the other (I think that would be possible to do the EC2 way in Rackspace without too much trouble). In time cloud providers would possibly provide it anyway.
If its discovering 2 different ways to do file injection, I don't think I would like that (unless 1 type is a super set of the other type - if you follow what I mean).
On Thu, 2010-01-21 at 15:54 +1100, Michael Neale wrote:
Right, so perhaps I was getting things confused in my mind. So what you are suggesting is that some file injection feature is part of the api - but in an optional section. And the api would provide a way to query what in the optional section is available?
Yes, exactly - it has to be optional, since not all clouds support it. If/when that feature settles down in clouds we can think about a new rev of the API that offers it for all clouds - but that's some way out.
What would be nice would be to pick either the Rackspace or the EC2 way of injection, and make that the "normal" way - and emulate it if really needed (in the driver if necessary) for the other (I think that would be possible to do the EC2 way in Rackspace without too much trouble). In time cloud providers would possibly provide it anyway.
The question is: which way to do it will "win" ? If we emulate user-data with file injection on Rack, and every other cloud starts offering file injection[1], we'd have restricted the API unnecessarily.
If its discovering 2 different ways to do file injection, I don't think I would like that (unless 1 type is a super set of the other type - if you follow what I mean).
I think, for now, we should stick more closely to what different clouds offer, simply because we can't tell yet what will become the prevalent mechanism. Client-side, it's a fairly simple check - assuming 'api' holds a DOM for the toplevel api entry point, your client would do something like
if xpath(api, "/api/link[rel='instances']/feature[@name='user-data']) params.add("user-data", user_data) else if xpath(api, "/api/link[rel='instances']/feature[@name='user-files']) file = { :path => "/var/lib/misc/user-data.txt", :data => user_data } params.add("user-files", file) else lose end create_instance(params)
You could probably add another 10 lines or so to do some sanity checking, but it's really not a crazy amount of code.
David
[1] I don't see that happening, since file injection is _much_ more problematic than EC2's user-data. Just bear with me for the sake of argument.
On Fri, Jan 22, 2010 at 5:28 AM, David Lutterkort lutter@redhat.com wrote:
Yes, exactly - it has to be optional, since not all clouds support it. If/when that feature settles down in clouds we can think about a new rev of the API that offers it for all clouds - but that's some way out.
Adrian Cole pointed out the jclouds way of doing this:
http://code.google.com/p/jclouds/wiki/ComputeGuide#Adding_a_post-boot_script This is a single file injection of a script. If not supported, fallback to SSH will be required so it can do it.
On Fri, 2010-01-22 at 09:33 +1100, Michael Neale wrote:
On Fri, Jan 22, 2010 at 5:28 AM, David Lutterkort lutter@redhat.com wrote:
Yes, exactly - it has to be optional, since not all clouds support it. If/when that feature settles down in clouds we can think about a new rev of the API that offers it for all clouds - but that's some way out.
Adrian Cole pointed out the jclouds way of doing this:
http://code.google.com/p/jclouds/wiki/ComputeGuide#Adding_a_post-boot_script This is a single file injection of a script. If not supported, fallback to SSH will be required so it can do it.
There are many ways how you can simulate one with the other, _if_ you are willing to instrument your images, e.g. through ssh. If the image is not instrumented, your whole API call falls flat on its face.
Deltacloud is a general-purpose cloud API, and as such can't assume that images are instrumented in any particular way. The situation is very different with jclouds which can make all kinds of assumptions about what's in the image.
David
hmm, well, it could make sense to move the runscript option into the Template.
We are currently guarding all changes to the template based on discoverable, or statically coded features of the cloud. With the runscript inside the template, we can check support on the image so that the API call doesn't fall flat on its face in an unsupported scenario ;)
anyway, this is more fodder for the jclouds-dev group than deltacloud. I'll leave you to it.
thanks for the feedback, David. Cheers, -Adrian
On Thu, Jan 21, 2010 at 3:46 PM, David Lutterkort lutter@redhat.com wrote:
On Fri, 2010-01-22 at 09:33 +1100, Michael Neale wrote:
On Fri, Jan 22, 2010 at 5:28 AM, David Lutterkort lutter@redhat.com wrote:
Yes, exactly - it has to be optional, since not all clouds support it. If/when that feature settles down in clouds we can think about a new rev of the API that offers it for all clouds - but that's some way out.
Adrian Cole pointed out the jclouds way of doing this:
http://code.google.com/p/jclouds/wiki/ComputeGuide#Adding_a_post-boot_script
This is a single file injection of a script. If not supported, fallback to SSH will be required so it can do it.
There are many ways how you can simulate one with the other, _if_ you are willing to instrument your images, e.g. through ssh. If the image is not instrumented, your whole API call falls flat on its face.
Deltacloud is a general-purpose cloud API, and as such can't assume that images are instrumented in any particular way. The situation is very different with jclouds which can make all kinds of assumptions about what's in the image.
David
deltacloud-devel mailing list deltacloud-devel@lists.fedorahosted.org https://fedorahosted.org/mailman/listinfo/deltacloud-devel
There are many ways how you can simulate one with the other, _if_ you are willing to instrument your images, e.g. through ssh. If the image is not instrumented, your whole API call falls flat on its face.
Deltacloud is a general-purpose cloud API, and as such can't assume that images are instrumented in any particular way. The situation is very different with jclouds which can make all kinds of assumptions about what's in the image.
What can i do with new vm's in a cloud without discover them and get more configuration to the vm. If we install a new system from a template we need to do always some steps like install something else to bring up services or put puppet there to bring up services later. With one injection like firstboot or postcommand, everything is possible then. Put, for example "firstboot" has always a dependencies to a guest operating system, in which style firstboot is running. On the other hand, the most cloud providers have the "same/a" range of supported operating systems.
Thomas
It's nice to see discussion switches back to a simplier, more realistic way of doing things.
Feature discovery is cool and not a problem itself.
I affraid only that keeping both user-data and rackspace file-injection in API can lead to issues. These are essentially the same feature, it is just implemented by providers in different ways. Currently there are two different providers offering data injection, and they offer it in different ways. I just think, there are can be multiple other ways for other providers to choose. E.g. bootstrap scripts are often used. And who have said it is not possible to do data injection via provisioning systems? E.g. pass data via kickstart file sections. What about configuration systems? E.g. passing data as a puppet node definition. There can be other ways or variations as well.
If every way of doing the same thing will be a separate extension to the API it will risk to become bloated with provider-specific features. Thus applications (and application developers) will still struggle heavily from provider dependencies and have to implement multiple ways of dong the same thing.
I agree with Michael that viable options are a single feature or have a superset feature included in impl. 1) a single feature (data-injection) to be an extension. Or 2) EC2 to offer data-injection and user-data features + Rackspace to offer data-injection and file-injection features. Or 3) EC2 to offer data-injection + Rackspace to offer data-injection and file-injection features.
To repeat myself, I strongly believe that deltacloud should offer a provider-independent way of doing things as a highest priority. There is nothing wrong with support for provider-specific ways, but, as long as they are backed with provider-independent ones.
Roman blog: http://it-result.me
On Wed, Jan 20, 2010 at 10:46 PM, Roman roman.maillist@gmail.com wrote:
I think that the data injection feature discussed in this thread is a basic one thus it should not be implemented as a kind of discoverable extension (if possible). In worst case, make the data injection feature an extension, but do not offer different ways of injecting data in deltacloud API.
I agree exactly - really one way.
I think that it would be better for implementation to pass a single file to the instance and let the cloud-compat package to expand it on first instance startup into multiple files specified in deltacloud create instance API call.
Would this way be sufficiently good to go?
I think so - injecting something is often enough to start with. Or put it
this way, if we are to inject N things, that doesn't necessarily bring us closer to absolute portability then injecting 1 file, but 1 file makes it very useful to start with I think.
On Tue, 2009-12-08 at 11:46 +1100, Michael Neale wrote:
Would people consider an addition to the instance creation part of deltacloud API to allow the injection of files/content to specified paths? (an extra optional field(s) on the POST)?
(this is the sort of thing that we need to have in some kind of semi-formal RFC wiki setup for people to point at and shout).
What I am having trouble with for this is that it's not clear to me how to express that in a cross-cloud way.
For clouds that do not support file injection (e.g., EC2), we'd need to make sure that the image is built in a certain way; should we carry additional image metadata to tell us which images have been prepped with a 'file injector' for EC2 ? Or should we assume that file injection will eventually be available on any cloud ? That heavily influences how we would express file injection on the API level.
David
What I am having trouble with for this is that it's not clear to me how to express that in a cross-cloud way.
For clouds that do not support file injection (e.g., EC2), we'd need to make sure that the image is built in a certain way; should we carry additional image metadata to tell us which images have been prepped with a 'file injector' for EC2 ? Or should we assume that file injection will eventually be available on any cloud ? That heavily influences how we would express file injection on the API level.
David
And this is the pointy end of things with deltacloud. Say I was building a *tool* which allowed me to work across clouds, then in that case I would do what I needed to plug the gaps for clouds which did not support what I considered an essential service. I guess in device driver terms it is "emulated"? (or perhaps they use more colorful language for that kind of hacking ;).
However, is deltacloud aiming to be, in the end, a common API specification with a supporting reference implementation and some core drivers? or is it an integration layer which specifies and API and also how to emulate missing features for a cloud to participate in it? If the latter, then the "drivers" provide low level common access to the clouds, and then the upper layers emulate missing features on top of that if needed. If the former, then it means we have different levels of API 'compliance' etc...
Optimistically speaking, the excellent participation in deltacloud means that it is likely that "missing" features won't be missing for long in various cloud providers - but does that mean in the meantime we want to emulate things by whatever means necessary?
deltacloud-devel@lists.fedorahosted.org