[occi-wg] Send shell commands to new hosts started with OCCI

Mon Dec 5 12:05:12 CST 2011

I think we are simp;ly being asked for a mechanism to pass an instruction at boot time to launch a startup script.

Let's stay away from the architectural niceties for the moment!

Florian points out that such startup scripts can be pre-packaged with a machine image in OVF.  If so, this is a nice feature and we just need to communicate with OVF sufficiently to (a) discover and (b) trigger such scripts upon startup.  Perhaps the only sophistication that would be needed would be to provide a choice of startup hooks among many that may be present.

Whatever is put together should be limited in scope to be able to achieve the desired effect, and not be over-designed, and should work with all operating systems.

Alan

On Dec 5, 2011, at 11:57 AM, Gary Mazz wrote:

> 
> This is a very old topic and discussed several times... I just recently 
> pinged Andy with a suggestion of bypassing PaaS and moving OCCI straight 
> to SaaS.
> 
> Michael brings up good points.
> 
> Depending on model, there can be strong similarities between IaaS PaaS 
> and SaaS. In a fully abstracted model, the CPU portion of IaaS OCCI can 
> be translated to "data processing" which can represent an application in 
> SaaS as well as the execution environment of PaaS. Data Processing is 
> supported by perimeter services ie networking, storage and memory.
> 
> This model would allow IaaS OCCI to be repurposed and support the full 
> complement of data processing environments.
> 
> The exact implementation for the SaaS (application) could be achieve via 
> mixins, as Alan suggests.  Ultimately, there needs to be SaaS and PaaS 
> data processing classes defined as part of the OCCI standard.
> 
>   However, there are some additional complexities to the SaaS and the 
> PaaS models.  SaaS data storage may be nondescript endpoint(s), where 
> only the capabilities are specified.  The type of alteration is true for 
> networking, the endpoint(s) may only be defined by URI and port number.  
> Although I thought that case was already addressed..
> 
> The model PaaS is a more complicated than SaaS.. PaaS exposes a litany 
> of internal (logical) services, including single/multiple execution 
> platforms, web servers, load balancers, databases, networking and 
> storage. This complexity warrants better differentiation of PaaS. The 
> exact profiles are open for discussion.  I have some opinions on topic.
> 
> cheers,
> gary
> 
> 
> 
> 
> On 12/5/2011 8:24 AM, Alan Sill wrote:
>> Could this be handled via the mix-in mechanism?  The difficulty may be differences in how start-up scripts are invoked in various operating systems, for which it is hard to have a solution built into the standard.  Having mechanisms that can work via a mix-in for various popular OS'es may, however, be possible.
>> 
>> Alan
>> 
>> On Dec 5, 2011, at 3:33 AM, Jamie Marshall wrote:
>> 
>>> Hello,
>>> 
>>> my 2 cents worth may be worth a read.
>>> 
>>> Here in France in the CompatibleOne project we are faced with much the same issue.
>>> 
>>> Our aim is the provision of a fully automated brokering and provisioning platform for the satisfaction of complex and hetrogeneous cloud provisioning requests.  We have also identified this difficulty as bein one of the aspects for which we will need to find or provide a satisfactory solution for ALL cloud provider platforms. We have been working on this subject and have already a basic architectural model allowing us to perform automatic provisioning with configuration for open stack and open nebual platforms. We demonstrated this 19 days ago at the OW2 Conference at Orange Labs here in Paris.
>>> Of course there is much more work to be done and we welcome ideas and thoughts on this very important subject.
>>> 
>>> Sincerely
>>> Jamie Marshall
>>> Expertise Manager
>>> Prologue
>>> Architect
>>> CompatibleOne
>>> 
>>> 
>>> 
>>> system
>>> 
>>> Date: Mon, 5 Dec 2011 09:57:03 +0100
>>> From: otacorp at gmail.com
>>> To: michael.behrens at r2ad.com
>>> CC: occi-wg at ogf.org
>>> Subject: Re: [occi-wg] Send shell commands to new hosts started with OCCI
>>> 
>>> Cheers and thanks for your answer.
>>> 
>>> Well, It looks like a no so I'll use some other way to achieve my goal.
>>> 
>>> Have a nice day
>>> 
>>> On 05/12/11 0.04, Michael Behrens wrote:
>>> 2-cents: It's an interesting request to consider.  As part of cloud automation, being able to kick off a configuration script is important.
>>> 
>>> I think some sort of startup script or agent would be needed to be staged in the guest VM first - not sure how one would otherwise communicate with a new machine securely.  Then once the SSH keys are generated, that generic script could then invoke a configuration server to proceed with the next steps.
>>> 
>>> This reminds me that we need to start considering the PaaS specifications soon.  As part of PaaS, being able scale new machines up and configure them is important.
>>> 
>>>  --
>>> Michael B.
>>> 
>>> Stefano Ghio wrote:
>>> Greetings,
>>> 
>>> I was wondering if it was possible to send shell commands to new hosts started with OCCI. I would like to do launche some java -jar after the host has started, preferably without using a script on the host.
>>> 
>>> I couldn't find anything anywhere about it (OCCI Core, OCCI HTTP Rendering, OCCI Infrastructure).
>>> 
>>> Thank you, regards
>>> -- 
>>> Dr. Stefano Ghio - ENG Engineering Italy
>>> 
>>> Website: http://groglogs.blogspot.com/
>>> 
>>> If you received this message but you are not its recipient, please ignore it and warn me, thank you.
>>> 
>>> 
>>> _______________________________________________
>>> occi-wg mailing list
>>> 
>>> occi-wg at ogf.org
>>> http://www.ogf.org/mailman/listinfo/occi-wg
>>> 
>>> 
>>> 
>>> -- 
>>> Dr. Stefano Ghio - Italy
>>> 
>>> Website: http://groglogs.blogspot.com/
>>> 
>>> If you received this message but you are not its recipient, please ignore it and warn me, thank you.
>>> 
>>> _______________________________________________ occi-wg mailing list occi-wg at ogf.org http://www.ogf.org/mailman/listinfo/occi-wg
>>> _______________________________________________
>>> occi-wg mailing list
>>> occi-wg at ogf.org
>>> http://www.ogf.org/mailman/listinfo/occi-wg
>> _______________________________________________
>> occi-wg mailing list
>> occi-wg at ogf.org
>> http://www.ogf.org/mailman/listinfo/occi-wg
> 
> _______________________________________________
> occi-wg mailing list
> occi-wg at ogf.org
> http://www.ogf.org/mailman/listinfo/occi-wg