Return-Path: X-Original-To: apmail-stratos-dev-archive@minotaur.apache.org Delivered-To: apmail-stratos-dev-archive@minotaur.apache.org Received: from mail.apache.org (hermes.apache.org [140.211.11.3]) by minotaur.apache.org (Postfix) with SMTP id 728581012B for ; Thu, 13 Mar 2014 01:16:23 +0000 (UTC) Received: (qmail 27382 invoked by uid 500); 13 Mar 2014 01:16:22 -0000 Delivered-To: apmail-stratos-dev-archive@stratos.apache.org Received: (qmail 27345 invoked by uid 500); 13 Mar 2014 01:16:22 -0000 Mailing-List: contact dev-help@stratos.incubator.apache.org; run by ezmlm Precedence: bulk List-Help: List-Unsubscribe: List-Post: List-Id: Reply-To: dev@stratos.incubator.apache.org Delivered-To: mailing list dev@stratos.incubator.apache.org Received: (qmail 27338 invoked by uid 99); 13 Mar 2014 01:16:22 -0000 Received: from athena.apache.org (HELO athena.apache.org) (140.211.11.136) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 13 Mar 2014 01:16:22 +0000 X-ASF-Spam-Status: No, hits=1.8 required=5.0 tests=FREEMAIL_ENVFROM_END_DIGIT,HTML_MESSAGE,LOTS_OF_MONEY,RCVD_IN_DNSWL_LOW,SPF_PASS X-Spam-Check-By: apache.org Received-SPF: pass (athena.apache.org: domain of damitha23@gmail.com designates 209.85.220.50 as permitted sender) Received: from [209.85.220.50] (HELO mail-pa0-f50.google.com) (209.85.220.50) by apache.org (qpsmtpd/0.29) with ESMTP; Thu, 13 Mar 2014 01:16:18 +0000 Received: by mail-pa0-f50.google.com with SMTP id kq14so331378pab.37 for ; Wed, 12 Mar 2014 18:15:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type; bh=Ytwkrr7X5iXOj2qSmnlX0uwu0oIgkJs0ZuPIuB4GsaA=; b=tG97QLpKHYuNxSqmxwPAegEHQMdbiZd2fLFsin/xrpTW0gzUDtimkFq/W4u42eE38k w1hv9LevmePFBhJfpdlObW7HI/RPPuFYHAMm8JiZ5+nyqnrA3rK3ng/HMJYE69g8c7J1 fgccWCxOHISQzMiruu0nLfN7egbvrXLfQL1KydJkmTd2M9Ya1MNDrKXU9WkC6ZhtX2AS nQkC7FUsEh57ryFd+INgJ91ps17Q6lJCWhlRWu/FnuhBDZCnXRkF/jbSS/AVoCn5jdla 11CM/e3k72WgiRdqS+oeCXBidHX7T6j++YjubYqUHbh3adxy3jO3wiaz8nChJlcxrn2n z7rQ== MIME-Version: 1.0 X-Received: by 10.68.228.138 with SMTP id si10mr750820pbc.13.1394673357924; Wed, 12 Mar 2014 18:15:57 -0700 (PDT) Received: by 10.68.236.133 with HTTP; Wed, 12 Mar 2014 18:15:57 -0700 (PDT) In-Reply-To: References: Date: Thu, 13 Mar 2014 06:45:57 +0530 Message-ID: Subject: Re: Passing Payload to VMware vCloud VMs From: damitha kumarage To: dev@stratos.incubator.apache.org Content-Type: multipart/alternative; boundary=047d7b2e54ce13aebd04f472b271 X-Virus-Checked: Checked by ClamAV on apache.org --047d7b2e54ce13aebd04f472b271 Content-Type: text/plain; charset=ISO-8859-1 Hi, In EC2 and Openstack IaaS when we pass user data through jclouds api it is stored in a storage called metadata server. In vCouds where user data get stored? Now in Openstack and EC2 "cloud ready" Ubuntu images has some internal scripts to get that user data from metadata server and store it somewhere when instance bootup. In certain OS's where "cloud ready" images are not provided(Openstack/Docker images, suse images sometime back), we need to write our own init scripts to retrieve user data from metadata server when instance boot up. So cartridge agent has to handle this depending on the IaaS and/or OS, by one of following ways. - In "cloud ready" images where user data already retrieved, copy them to Stratos specific location from the originally retrieved location - In "not so cloud ready images", but where metadata server is available retrieve data from metadata server and store in Stratos specific location(Docker, old Suse) - In other cases retrieve data from whatever server it is stored and copy them to Stratos specific location. I suggest in Stratos agent, isolate code which depend on IaaS, OS(like in this userdata case). Damitha On Wed, Mar 12, 2014 at 11:56 PM, Isuru Perera wrote: > Hi Paul, > > Thanks for your suggestion. > > The cartridges in Amazon EC2 and OpenStack are configured using Puppet. > > We pass the puppet master IP to those cartridges and the agent will be > executed by the init script. > > We need to do the same with vCloud. > > So, I'm thinking whether we can write user data to some file via the > customization script and then read that from the init script. > > I think in summary, the requirement is same as you mentioned. > > Thanks! > > Best regards, > > -- > Sent from my mobile > On Mar 12, 2014 11:39 PM, "Paul Fremantle" wrote: > >> Looks like you should put a secure HTTP get request into the >> customization script that then pulls the real config from a server. >> >> Paul >> >> >> On 12 March 2014 18:00, Isuru Perera wrote: >> >>> Hi, >>> >>> I have been looking for way to do $subject. >>> >>> It seems there is no way of passing user-data (payload) to VMs in vCloud >>> similar to Amazon EC2 and OpenStack. >>> >>> Udara has also looked in to this and he has asked the same question on >>> StackOverflow [1] >>> >>> Looks like we need to use a custom script [2] and pass user-data. >>> >>> The script depends on the target Cartridge OS. >>> >>> So we need to think of way to achieve this requirement. >>> >>> I will look into this further and update this thread. >>> >>> Thanks! >>> >>> Best Regards, >>> >>> [1] >>> http://stackoverflow.com/questions/19628362/passing-payloads-to-vcloud-vms >>> [2] >>> http://pubs.vmware.com/vcloud-director-1-5/wwhelp/wwhimpl/js/html/wwhelp.htm#href=user/GUID-724EB7B5-5C97-4A2F-897F-B27F1D4226C7.html >>> >>> -- >>> Isuru Perera >>> Senior Software Engineer | WSO2, Inc. | http://wso2.com/ >>> Lean . Enterprise . Middleware >>> >>> about.me/chrishantha >>> >> >> >> >> -- >> Paul Fremantle >> CTO and Co-Founder, WSO2 >> OASIS WS-RX TC Co-chair, Apache Member >> >> UK: +44 207 096 0336 >> US: +1 646 595 7614 >> >> blog: http://pzf.fremantle.org >> twitter.com/pzfreo >> paul@wso2.com >> >> wso2.com Lean Enterprise Middleware >> >> Disclaimer: This communication may contain privileged or other >> confidential information and is intended exclusively for the addressee/s. >> If you are not the intended recipient/s, or believe that you may have >> received this communication in error, please reply to the sender indicating >> that fact and delete the copy you received and in addition, you should not >> print, copy, retransmit, disseminate, or otherwise use the information >> contained in this communication. Internet communications cannot be >> guaranteed to be timely, secure, error or virus-free. The sender does not >> accept liability for any errors or omissions. >> > -- __________________________________________________________________ Damitha Kumarage http://people.apache.org/ __________________________________________________________________ --047d7b2e54ce13aebd04f472b271 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable
Hi,
In EC= 2 and Openstack IaaS when we pass user data through jclouds api it is store= d in a storage called metadata server. In vCouds where user data get stored= ?

Now in Openstack and EC2 "cloud ready" Ubuntu images ha= s some internal scripts to get that user data from metadata server and stor= e it somewhere when instance bootup. In certain OS's where "cloud = ready" images are not provided(Openstack/Docker images, suse images so= metime back), we need to write our own init scripts to retrieve user data f= rom metadata server when instance boot up.

So cartridge agent has to handle this depending on the IaaS and/o= r OS, by one of following ways.
- In "cloud ready" image= s where user data already retrieved, copy them to Stratos specific location= from the originally retrieved location

- In "not so cloud ready images", but where metadata se= rver is available retrieve data from metadata server and store in Stratos s= pecific location(Docker, old Suse)

- In other cases retrieve d= ata from whatever server it is stored and copy them to Stratos specific loc= ation.

I suggest in Stratos agent, isolate code which depend on IaaS, OS= (like in this userdata case).

Damitha


On Wed, Mar 12, 2014 at 11:= 56 PM, Isuru Perera <isurup@wso2.com> wrote:

Hi Paul,

Thanks for your suggestion.

The cartridges in Amazon EC2 and OpenStack are configured us= ing Puppet.

We pass the puppet master IP to those cartridges and the age= nt will be executed by the init script.

We need to do the same with vCloud.

So, I'm thinking whether we can write user data to some = file via the customization script and then read that from the init script.<= /p>

I think in summary, the requirement is same as you mentioned= .

Thanks!

Best regards,

--
Sent from my mobile



On 12 March 2014 18:00, Isuru Perera <isurup@wso2.com> wrote:<= br>
Hi,

I have been looking for way to do $su= bject.

It seems there is no way of passing user-data (payload) to V= Ms in vCloud similar to Amazon EC2 and OpenStack.

Udara has al= so looked in to this and he has asked the same question on StackOverflow [1= ]

Looks like we need to use a custom script [2] and pass user-= data.

The script depends on the target Cartridge OS.

<= div>So we need to think of way to achieve this requirement.

I will look into this further and update this thread.

Thanks!
Best Regards,



--
Paul Fremantle
CTO and Co-Founder, WSO2
OASIS WS-RX TC Co-chair,= Apache Member

UK: +44 207 096 0336
US: +1 646 595 7614

blog: http://pzf= .fremantle.org
twitter.com/pzfreo
paul@wso2.com

wso2.com L= ean Enterprise Middleware

Disclaimer: This communication may contain= privileged or other confidential information and is intended exclusively f= or the addressee/s. If you are not the intended recipient/s, or believe tha= t you may have received this communication in error, please reply to the se= nder indicating that fact and delete the copy you received and in addition,= you should not print, copy, retransmit, disseminate, or otherwise use the = information contained in this communication. Internet communications cannot= be guaranteed to be timely, secure, error or virus-free. The sender does n= ot accept liability for any errors or omissions.



--
___________= _______________________________________________________
Damitha Kumarage=
http://people.apache.org/
__________________________________________________________________ --047d7b2e54ce13aebd04f472b271--