stratos-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Nirmal Fernando <nirmal070...@gmail.com>
Subject Re: steps for supporting a new IaaS (e.g. cloudstack)?
Date Tue, 08 Apr 2014 22:29:08 GMT
Hi All,

I've just written a wiki page on this
https://cwiki.apache.org/confluence/display/STRATOS/4.0.0+Adding+support+for+a+new+IaaS+provider

Will keep filling gaps there.


On Tue, Apr 1, 2014 at 9:14 AM, Nirmal Fernando <nirmal070125@gmail.com>wrote:

> 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.
> <etoews1> https://cwiki.apache.org/confluence/display/STRATOS/Cartridges
> <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
> <etoews1> org.apache.stratos.cloud.
> controller.interfaces.Iaas
> <nirmal> we do not need to depend on different behaviours of different
> IaaSes
> <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
> releaseAddress?
> <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="abc.com" 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"
> value="manager,cep,mb,default"/>
> <nirmal>     <property name="instanceType" value="m1.large"/>
> <nirmal>     <property name="payload" value="resources/as-ec2.txt"/>
> <nirmal>    </iaasProvider>
> <nirmal>
> <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>
> http://docs.rackspace.com/servers/api/v2/cs-devguide/content/ServersKeyPairs-d1e2545.html
> <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>
> http://docs.rackspace.com/servers/api/v2/cs-devguide/content/Server_Personality-d1e2543.html
> <etoews1> it's pretty limited though (255 bytes!) and not so easy to work
> with.
> <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
> file..
> <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
> requirement?
> <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
> level...
> <nirmal> to make payload file downloadable
> <etoews1> i was suggesting that the instance itself download the payload
> file.
> <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 downloadable
> <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
> org.apache.stratos.cloud.controller.iaases
> <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?
> <etoews1>
> https://cwiki.apache.org/confluence/display/STRATOS/Creating+a+Cartridge
> <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. "...you 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
> optional.
> <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
> commands).
> <etoews1> what ports does stratos need? where can i find the list?
> <nirmal> let me give you the link
> <nirmal>
> https://cwiki.apache.org/confluence/display/STRATOS/Common+IaaS+Configurations
> <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 <chsnow123@gmail.com> 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]
>> https://github.com/apache/incubator-stratos/blob/master/components/org.apache.stratos.cloud.controller/src/main/java/org/apache/stratos/cloud/controller/interfaces/Iaas.java
>>
>> [2]
>> https://github.com/apache/incubator-stratos/blob/master/components/org.apache.stratos.cloud.controller/src/main/java/org/apache/stratos/cloud/controller/interfaces/CloudControllerService.java
>>
>>
>>
>> On Mon, Mar 31, 2014 at 7:55 AM, chris snow <chsnow123@gmail.com> wrote:
>>
>>> Thanks everyone!
>>>
>>>
>>> On Mon, Mar 31, 2014 at 6:45 AM, Mariangela Hills <mariangela@wso2.com>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: http://wso2.com
>>>>  <http://wso2.com/events/>
>>>>
>>>>
>>>> On Mon, Mar 31, 2014 at 9:32 AM, Lakmal Warusawithana <lakmal@wso2.com>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 <chsnow123@gmail.com>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 <
>>>>>> lakmal@wso2.com> wrote:
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > On Mon, Mar 31, 2014 at 12:25 AM, chris snow <chsnow123@gmail.com>
>>>>>> wrote:
>>>>>> >>
>>>>>> >> What are the steps that need to be performed to support
a new IaaS?
>>>>>> >>
>>>>>> >> Is an implementation of o.a.s.c.c.i.IaaS [1] required for
each
>>>>>> IaaS?
>>>>>> >>
>>>>>> >> Is there any documentation (e.g. sequence diagram) that
shows how
>>>>>> >> 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
>>>>>> EC2
>>>>>> > instance. For OpenStacks its OpenStacks instance. For CloudStack
its
>>>>>> > 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
>>>>>> run PHP, we
>>>>>> > need webserver+PHP runtime - (eg. apache+php5 setup). So making
PHP
>>>>>> > 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, CEP
>>>>>> hosts
>>>>>> > ..etc) from puppet master. therefore
>>>>>> >
>>>>>> > PHP Cartridge = (OS + Apache + PHP + Stratos Cartridge Agent
+
>>>>>> Puppet Agent)
>>>>>> > image for relevant IaaS
>>>>>> >
>>>>>> >>
>>>>>> >> Many thanks,
>>>>>> >>
>>>>>> >> Chris
>>>>>> >> ---
>>>>>> >> [1]
>>>>>> >>
>>>>>> https://github.com/apache/incubator-stratos/blob/master/components/org.apache.stratos.cloud.controller/src/main/java/org/apache/stratos/cloud/controller/interfaces/Iaas.java
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> >
>>>>>> > --
>>>>>> > Lakmal Warusawithana
>>>>>> > Software Architect; WSO2 Inc.
>>>>>> > Mobile : +94714289692
>>>>>> > Blog : http://lakmalsview.blogspot.com/
>>>>>> >
>>>>>>
>>>>>>
>>>>>>
>>>>>> --
>>>>>> Check out my professional profile and connect with me on LinkedIn.
>>>>>> http://lnkd.in/cw5k69
>>>>>>
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Lakmal Warusawithana
>>>>> Software Architect; WSO2 Inc.
>>>>> Mobile : +94714289692
>>>>> Blog : http://lakmalsview.blogspot.com/
>>>>>
>>>>>
>>>>
>>>
>>>
>>> --
>>> Check out my professional profile and connect with me on LinkedIn.
>>> http://lnkd.in/cw5k69
>>>
>>
>>
>>
>> --
>> Check out my professional profile and connect with me on LinkedIn.
>> http://lnkd.in/cw5k69
>>
>
>
>
> --
> Best Regards,
> Nirmal
>
> Nirmal Fernando.
> PPMC Member & Committer of Apache Stratos,
> Senior Software Engineer, WSO2 Inc.
>
> Blog: http://nirmalfdo.blogspot.com/
>



-- 
Best Regards,
Nirmal

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

Blog: http://nirmalfdo.blogspot.com/

Mime
View raw message