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 <[email protected]>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 <iaasProviders> 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 <[email protected]> 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 <[email protected]> wrote: >> >>> Thanks everyone! >>> >>> >>> On Mon, Mar 31, 2014 at 6:45 AM, Mariangela Hills >>> <[email protected]>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 >>>> <[email protected]>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 <[email protected]>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 < >>>>>> [email protected]> wrote: >>>>>> > >>>>>> > >>>>>> > >>>>>> > On Mon, Mar 31, 2014 at 12:25 AM, chris snow <[email protected]> >>>>>> 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/
