stratos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nirmal Fernando <>
Subject Re: steps for supporting a new IaaS (e.g. cloudstack)?
Date Tue, 01 Apr 2014 03:44:27 GMT
Hi Chris,

I am sorry, I am yet to find some time to write a blog post on this. :-( (I
will write one before end of April :-)) Let me paste here and IRC chat log,
I had with Everett on adding a new IaaS support for Stratos (on providing
support for Rackspace IaaS in Apache Stratos).

And Everett has shared a summary on apache stratos dev list some time ago
too, AFAIR.

Chris, some of the method signatures might bit different now, but the
concepts are same. Hope you find this useful.

So, in a nutshell, you do not need to write a new
CloudControllerServiceImpl but an IaaSImpl in order to provide support for
a new IaaS. CloudControllerServiceImpl would delegate the operations to the
correct IaaSImpl based on the configurations you have provided.

<nirmal> let me brief what we do in Stratos..
<nirmal> in Stratos we are having a concept call Cartridges which will
mainly represent any application runtime
<nirmal> such as PHP, MySql, Tomcat etc.
<nirmal> you can think of those Cartridges as AMIs in the EC2 world
<nirmal> image in Openstack world
<nirmal> in Rackspace world it would be?
<nirmal> image?
<etoews1> right
<nirmal> cool
<nirmal> in Stratos we are capable of starting an instance from one of
those images in any given IaaS
<nirmal> we have a configuration file where you can define a Cartridge
<nirmal> and in that you can define a set of IaaSes where the Cartridge
instances can be started
<etoews1> FYI we have all of the major Linux distros and Windows
<nirmal> awesome..
<etoews1> do you need customized images?
<nirmal> Usually you can create a Cartridge using a base linux image
<etoews1> do you need to be able to create customized images for cartridges?
<nirmal> yes
<etoews1> right, you can create customized images in Rackspace but only
*per tenant*
<nirmal> you need to install Apache server, php and then you can call that
image a PHP Cartridge
<etoews1> i doubt that would be a problem for Stratos right?
<nirmal> what is a tenant in Rackspace context
<nirmal> is it like an EC2 a/c?
<etoews1> a customer.
<nirmal> can we made an image public?
<etoews1> what's an a/c?
<nirmal> sorry an account
<etoews1> the images can't be public.
<nirmal> ok..
<nirmal> is there any way to share images among tenants?
<etoews1> i don't think so but i could double check.
<nirmal> ok.. if not we might need to document Cartridge creation and ask
every tenant to create Cartridges for its own use
<nirmal> it's not an issue for Stratos, but will add some additional burden
on user.
<nirmal> in EC2 case, we make AMIs public
<etoews1> got it.
<nirmal> in Openstack case, we upload images to a public repository so that
users can import them
<etoews1> that makes sense.
<nirmal> cool
<nirmal> so as you might have already understand, for this type of
behaviour (that is supporting multiple IaaSes same time)
<nirmal> we need another abstraction layer
<nirmal> on top of jclouds
<nirmal> so that we can simply call that abstract API
<chipc> nirmal: +1
<nirmal> we do not need to depend on different behaviours of different
<nirmal> yes, it is the current interface
<nirmal> we could certainly improve, if there's a need :)
<nirmal> but so far this abstraction worked well for us
<nirmal> we successfully modeled EC2, Openstack, vCloud
<nirmal> into this
<nirmal> chipc, :) welcome to the conversation
<chipc> just got into the office...  ;-)
<nirmal> I see
<etoews1> hmmm...i see another potential stumbling block.
<etoews1> rackspace doesn't have floating/elastic IPs :(
<nirmal> ok...
<etoews1> how essential is it to implement associateAddress and
<nirmal> not necessary :)
<etoews1> ah. good!
<nirmal> so in Rackspace case, the instance starting call would be blocking
<nirmal> since we do not associate addresses before hand
<nirmal> i.e. we need auto assign ip to be enabled
<etoews1> ya. rax instances get assigned a public ip by default.
<nirmal> it's just a matter of specifying a property in Rackspace IaaS
configuration of Stratos
<etoews1> k
<nirmal> <!-- You can have 1..n cartridge elements. -->
<nirmal>   <cartridge type="php" host="" provider="carbon">
<nirmal>    <!-- cartridge element can have 0..n properties, and they'll be
overwritten by the properties
<nirmal>      specified under iaasProvider child elements of cartridge
element. -->
<nirmal>    <property name="ss" value="slsls"/>
<nirmal>    <property name="ss" value="slsls"/>
<nirmal>    <description>This is a php cartridge.</description>
<nirmal>    <deployment baseDir="xyz">
<nirmal>     <dir>abc</dir>
<nirmal>    </deployment>
<nirmal>    <!-- A cartridge element should add a reference to an existing
IaaS provider (specified
<nirmal>      in the above &lt;iaasProviders&gt; section) or it can create
a completely new IaaS
<nirmal>      Provider (which should have a unique "type" attribute. -->
<nirmal>    <iaasProvider type="openstack" >
<nirmal>     <imageId>nova/xxxxxxxxxx</imageId>
<nirmal>     <property name="keyPair" value="aa"/>
<nirmal>     <property name="instanceType" value="1"/>
<nirmal>     <property name="payload" value="resources/as.txt"/>
<nirmal>    </iaasProvider>
<nirmal>    <iaasProvider type="ec2" >
<nirmal>     <imageId>xxxxxxxxxx</imageId>
<nirmal>     <property name="keyPair" value="aa"/>
<nirmal>     <property name="securityGroups"
<nirmal>     <property name="instanceType" value="m1.large"/>
<nirmal>     <property name="payload" value="resources/as-ec2.txt"/>
<nirmal>    </iaasProvider>
<nirmal>   </cartridge>
<nirmal> this is a sample Cartridge definition
<nirmal> so another question would be, does Rackspace support key based
authentication ?
<etoews1> yes.
<nirmal> cool
<nirmal> what about passing a payload?
<etoews1> do you mean like a cloud-init style payload?
<nirmal> as in can I pass some dynamic information to the instance? user
data as of jclouds
<nirmal> why we need such mechanism is, Stratos dynamically generate some
cluster domain names, host names etc. upon a subscription to a Cartridge
<etoews1> that one will be more difficult.
<etoews1> we do have something like that. it's call "personality".
<etoews1> it's pretty limited though (255 bytes!) and not so easy to work
<nirmal> I see..
<nirmal> I faced the same issue with vCloud
<nirmal> even though there's a way to pass user data
<nirmal> there's no way to retrieve them within the instance
<etoews1> the personality file get "injected" into the image so it's
accessible. there's just a lot of limitations.
<nirmal> ya.. that's an issue...
<etoews1> if we have to bake an image anyway we could try to put something
a bit better in there.
<nirmal> in the sense?
<nirmal> in the personality file?
<nirmal> you meant to say that you can improve the limits of personality
<etoews1> something like assuming the personality file is a bash script and
putting something in the image that runs that bash script on boot.
<etoews1> a poor mans cloud-init.
<etoews1> the script could then download what it needs and execute that.
<etoews1> does sensitive information need to be passed into the instance?
credentials and such?
<nirmal> but this file can only have 255bytes right?
<etoews1> right.
<nirmal> no, just some dynamic data
<nirmal> AFAIR
<nirmal> but I'm not sure whether that can be fit into 255 bytes
<etoews1> we don't need to fit it in there.
<nirmal> I mean the dynamic data
<etoews1> the personality file just needs to contain enough information to
download the real data file
<etoews1> it could just contain a url.
<nirmal> hmm...
<etoews1> then the image that we bake takes that url, downloads it, and
does whatever is needed with it.
<nirmal> yes... but then there's should be a downloadable content :)
<etoews1> ya. this is all very hacky.
<nirmal> do you think any other way that we could tackle this kind of
<etoews1> i'm just trying to figure out if this is a show stopper or if
it's possible to work around it with a reasonable amount of effort.
<nirmal> or is this a limitation of Rackspace?
<etoews1> it's a limitation.
<nirmal> I don't think this is a show stopper
<nirmal> as I mentioned earlier I faced the same issue in vCloud
<etoews1> let's at least assume we can work around it and continue on to
see what else we run into :D
<nirmal> I tackled it like this..
<nirmal> in vCloud, we could pass a script to run on boot up
<nirmal> (well, I now wonder in Rackspace it is still the personality file?)
<nirmal> is there anyway that I can load scripts at boot up, other than via
personality file?
<etoews1> nope
<etoews1> :(
<nirmal> ok :(
<nirmal> now, then the only way is to hack it like you said...
<nirmal> for that we might need to do some trick at Cloud Controller
<nirmal> to make payload file downloadable
<etoews1> i was suggesting that the instance itself download the payload
<nirmal> yes.. exactly
<nirmal> but CC should host it
<nirmal> right?
<etoews1> ah. understood.
<nirmal> cool..
<etoews1> i thought the payload was just a file somewhere.
<etoews1> but it's served up by the CC. is that correct?
<nirmal> yes, it's a file resides in CC.
<etoews1> got it.
<nirmal> but currently it's not hosted
<nirmal> as in you can't download it directly..
<etoews1> i see.
<nirmal> well... nothing is impossible ... probably I see a way to make it
<nirmal> :)
<nirmal> we can write that file into registry and expose it via CC
<nirmal> registry == Carbon registry
<nirmal> ok .. say that we got it covered..
<nirmal> I think we are almost there..
<nirmal> so Everett, in order to add support for Rackspace, you just need
to implement a RackspaceIaas class
<nirmal> which extends Iaas abstract class
<nirmal> we usually keep Iaas implementations under
<etoews1> i'm reading through OpenstackNovaIass.
<nirmal> of course you need to create a Cartridge in order to test this.
<nirmal> ok.
<etoews1> is this doc pretty up to date?
<nirmal> I guess it is ...
<nirmal> team was working on the release..
<nirmal> and I remember they were updating docs..
<etoews1> i also see the scripts in the tools dir.
<nirmal> ya
<nirmal> those scripts are pretty static
<nirmal> if you see step 5
<nirmal> it is where we extract the payload
<nirmal> and grab the dynamic data
<etoews1> so does that script just export a bunch of env vars?
<nirmal> ya..
<nirmal> those dynamic data will be exported as env vars
<nirmal> so that the other scripts could utilize them
<etoews1> for use by the instance local stratos processes.
<nirmal> to be able to join with the ELB
<nirmal> etc.
<etoews1> i see.
<nirmal> I hope you have gained some sense on what to do now? :)
<etoews1> and after the cartridge is deployed and the user's code is
running, stratos takes over, and manages the scaling and whatnot?
<nirmal> yes... once the code is up and running  in the Cartridge
instance.. you need not to worry.
<nirmal> in Rackspace you have security groups right?
<etoews1> heh. " need not to worry." when it comes to computers, i
always worry. :P
<etoews1> nope. no security groups. :(
<nirmal> :D of course this is in theory :P
<nirmal> oh.. I see..
<etoews1> i saw in OpenstackNovaIaas that sec groups appeared to be
<nirmal> where you define ports that are opened to outside etc?
<etoews1> that stuff needs to be handled per instance by iptables.
<nirmal> yes... but in the Openstack, EC2 case, they always has a default
security group
<nirmal> have*
<etoews1> ya...i know. we haven't implemented sec groups on rax yet.
<nirmal> ok...
<etoews1> the ports are open by default.
<nirmal> but I guess, it's still fine.. as long as you specify correct
settings at the time of Cartridge creation
<nirmal> I see..
<nirmal> so we might want to close unnecessary ports...
<nirmal> if required...
<etoews1> right. jclouds can help with that (by running remote ssh
<etoews1> what ports does stratos need? where can i find the list?
<nirmal> let me give you the link
<etoews1> ah. very nice.
<etoews1> nirmal: anything else? can you see any other gotchas right now?
<nirmal> hmm...
<nirmal> not really... I think I asked most of the questions I can recall..
<nirmal> I think we could solve other issues, once you start to face them :)
<etoews1> ya. the devil is always in the details. that's why devs should
always multiple their estimates by 2.5. :D
<etoews1> s/multiple/multiply/
<nirmal> ya.. :D
<nirmal> In "associateAddress(IaasProvider, NodeMetadata)" method, please
return an empty String..
<nirmal> since you're not going to implement it..
<nirmal> and in "createKeyPairFromPublicKey" you can return false
<etoews1> sounds good to me.
<nirmal> great..

On Tue, Apr 1, 2014 at 3:46 AM, chris snow <> wrote:

> Looking through the diagrams, I can only see Create and Destroy instance
> methods performed on the IaaS.  However, [1] has a load of other methods,
> but I can't see Create/Destroy.  [2] on the other hand has create/terminate
> methods, but only one implementation - I was expecting to see an
> Implementation of CloudControllerService for each IaaS.
> Coming back to my original question, what is the minimal implementations I
> need to create as a starting point?  It would be good to establish some
> sort of connectivity from Stratos to Cloudstack without having to try and
> implement all the methods in IaaS (and maybe CloudControllerService)
> upfront.
> ---
> [1]
> [2]
> On Mon, Mar 31, 2014 at 7:55 AM, chris snow <> wrote:
>> Thanks everyone!
>> On Mon, Mar 31, 2014 at 6:45 AM, Mariangela Hills <>wrote:
>>> Lakmal, I will l look into this!
>>> Regards,
>>> Mariangela
>>> *--*
>>> Mariangela Hills
>>> Senior Technical Writer
>>> *WSO2, Inc. *lean.enterprise.middleware.
>>> m: +94 773 500185
>>> w:
>>>  <>
>>> On Mon, Mar 31, 2014 at 9:32 AM, Lakmal Warusawithana <>wrote:
>>>> Hi Chris,
>>>> Here I attached some sequence diagrams which I draw sometime back. I
>>>> hope still they are valid please verify. Also attached source.txt, so you
>>>> can easily modify.
>>>>  @mari, you may need these for update wiki.
>>>> thanks
>>>> On Mon, Mar 31, 2014 at 1:10 AM, chris snow <>wrote:
>>>>> Thanks for the info Lakmal.   I think I my conceptual understanding of
>>>>> cartridges is right, but it is now the detail that is lacking.  I.e.
>>>>> 'how' does Stratos interact with cartridges?  What is the API? What
>>>>> are the sequence of calls for different use cases of the cartridge
>>>>> API?
>>>>> On Sun, Mar 30, 2014 at 8:26 PM, Lakmal Warusawithana <>
>>>>> wrote:
>>>>> >
>>>>> >
>>>>> >
>>>>> > On Mon, Mar 31, 2014 at 12:25 AM, chris snow <>
>>>>> wrote:
>>>>> >>
>>>>> >> What are the steps that need to be performed to support a new
>>>>> >>
>>>>> >> Is an implementation of o.a.s.c.c.i.IaaS [1] required for each
>>>>> >>
>>>>> >> Is there any documentation (e.g. sequence diagram) that shows
>>>>> >> Stratos interacts with the IaaS implementation?
>>>>> >>
>>>>> >> Is there a minimal implementation (which methods) that I can
>>>>> initially
>>>>> >> perform to test some connectivity with the IaaS?
>>>>> >>
>>>>> >> Please note that I don't fully understand cartridges yet, so
it will
>>>>> >> probably be quite a while before I get anything working!
>>>>> >>
>>>>> >
>>>>> > Startos Cartridge run time is an instance. For example in EC2 its
>>>>> > instance. For OpenStacks its OpenStacks instance. For CloudStack
>>>>> > CloudStack instance.
>>>>> >
>>>>> > So what do we need to run an instance? For EC2 need AMI. For
>>>>> OpenStack , if
>>>>> > KVM then KVM image, if Docker then Docker image ..etc.
>>>>> >
>>>>> > I hope you are clear above. OK, then will take PHP Cartridge. To
>>>>> PHP, we
>>>>> > need webserver+PHP runtime - (eg. apache+php5 setup). So making
>>>>> > cartridge mean we need to install Apache+PHP top of some OS. (Ubuntu
>>>>> or
>>>>> > CentOS or ..etc). To make it Stratos aware we need to put Startos
>>>>> Cartridge
>>>>> > Agent. Then if you want to run this cartridge top of EC2, you need
>>>>> to create
>>>>> > AMI. For OpenStack, need KVM image or Docker image. Summery after
>>>>> setting up
>>>>> > all required software for relevant cartridge, need to create image
>>>>> and
>>>>> > register as a cartridge.
>>>>> >
>>>>> > PHP Cartridge = OS + Apache + PHP + Stratos Cartridge Agent.
>>>>> >
>>>>> > And for configuration easiness we are putting puppet agent and get
>>>>> all
>>>>> > config (eg setting up stratos cartridge agent with relevant MB,
>>>>> hosts
>>>>> > ..etc) from puppet master. therefore
>>>>> >
>>>>> > PHP Cartridge = (OS + Apache + PHP + Stratos Cartridge Agent +
>>>>> Puppet Agent)
>>>>> > image for relevant IaaS
>>>>> >
>>>>> >>
>>>>> >> Many thanks,
>>>>> >>
>>>>> >> Chris
>>>>> >> ---
>>>>> >> [1]
>>>>> >>
>>>>> >
>>>>> >
>>>>> >
>>>>> >
>>>>> > --
>>>>> > Lakmal Warusawithana
>>>>> > Software Architect; WSO2 Inc.
>>>>> > Mobile : +94714289692
>>>>> > Blog :
>>>>> >
>>>>> --
>>>>> Check out my professional profile and connect with me on LinkedIn.
>>>> --
>>>> Lakmal Warusawithana
>>>> Software Architect; WSO2 Inc.
>>>> Mobile : +94714289692
>>>> Blog :
>> --
>> Check out my professional profile and connect with me on LinkedIn.
> --
> Check out my professional profile and connect with me on LinkedIn.

Best Regards,

Nirmal Fernando.
PPMC Member & Committer of Apache Stratos,
Senior Software Engineer, WSO2 Inc.


View raw message