Alex/All +1 to phasing this and starting with core proposal that is deliverable in Q1.
Best Duncan On 8 January 2013 14:34, Alex Heneveld <alex.henev...@cloudsoftcorp.com>wrote: > > Thanks for all the comments and support so far! Great to have so much > interest and especially so many volunteers. > > Some of the main points in my mind, on the discussion so far: > > *"A new unit of deployment"* is a perfect description of this, Chris. And > +1 to once it is deployed mapping it on to "projects" -- seems like a good > fit to me, although I'm no projects expert. Thoughts? > > *The description format* is crucial to this feature's success, I think. > For me priorities are to make it simple to use and simple to understand, > and to align / be compatible with standards where feasible. But there are > multiple choices as people have noted. The logical architecture to me > would be a core description format which is an extensible standard, with > some easy-to-use formats available on top of these. > *As a core native format*, what do people think of Oasis TOSCA's XML > vocabulary [1] ? I've worked with it for a while, and it has the right > general concepts I think we'd need, done well, and in a way which won't > bite us down the line. (Alex Huang, in answer to your question, I strongly > suspect that re-using cloudformation or vapp/OVF as _native_ will end up > being too restrictive.) It's not very user friendly, however, so we'd > definitely want... > * Easy-to-use description formats* layered on top of this: AWS > CloudFormation is an obvious desire; OVA/OVF/vApp could be useful; and > personally I'd like to see a lightweight YAML dialect based on > Cloudstack-specific concepts (to make it super-simple to create blueprints). > Disclaimer: I'm just suggesting this for discussion. I'm not at all > sure what is "right"; I'm just sure it's important to get it close to right! > > *The API *portion I think is straightforward. It's REST, you can list > 'em, upload new ones, delete, and get info (on templates). Perhaps in time > you could extend. For deployed instances, it's just the Projects REST API. > DMTF CIMI model & REST draft [2] (thanks for the pointer Chris) is a > good guide to functionality/concepts but I think not as far as API goes? > Wouldn't people want the API to be consistent with the rest of cloudstack > API? (But a CIMI skin, e.g. deltaclouds, mapping on to the blueprints API > in cloudstack, that I like.) > > *The GUI* is something that hasn't been discussed much. What should this > look like? A searchable library (like for VMs) seems the obvious choice, > as a separate module in the CS GUI, populated by uploading description > files as noted above? All using the REST API of course. (And in time > there might be "designer" features where you can build/extend blueprints in > the GUI.) Once deployed things they appear as projects, perhaps extending > that GUI+API to support additional info for things which come from > blueprints. Is that what people were thinking? > > *On the topic of in-guest automation,* +1 to calling this out as a > separate _task_, but is it by itself a feature? I see it as a code library > -- which this blueprints feature obviously needs, and which should be > modular, and which would be useful for other features (e.g. possibly having > GUI hooks where a user can right click on a VM and invoke in-guest > automation, assuming password hasn't changed). But the use case of > defining a VM with files installed and a command invoked would be handled > by a simple blueprint. So I think add such a use case, and make sure this > library is modular, but not sure it should be a separate feature. (Unless > there is a precedent for "developer features" ?) > > *As for PaaS* total agreement here that PaaS-enablement is just a use case > -- an important one -- but the feature itself is independent of PaaS and > useful in non PaaS. > > *For planning, more generally, *(and again answering Alex Huang's other > question) once we have some support and consensus (which we're starting to > get) I think we definitely need to phase in the features, and break those > in to smaller tasks. There is a lot here. Ideally I'd like to identify > some core where we could get something indicative pretty quickly (a couple > months) then adjust this in response to feedback, and build upon it for > additional features. (This bit at least isn't controversial, is it?!) > > Thanks folks and please keep it coming. > > --A > > [1] > http://docs.oasis-open.org/**tosca/TOSCA/v1.0/TOSCA-v1.0.**html<http://docs.oasis-open.org/tosca/TOSCA/v1.0/TOSCA-v1.0.html> > [2] http://dmtf.org/sites/default/**files/standards/documents/** > DSP0263_1.0.0a.pdf<http://dmtf.org/sites/default/files/standards/documents/DSP0263_1.0.0a.pdf> > > > > On 08/01/2013 07:50, Mohammad Nour El-Din wrote: > >> Big +1 >> >> I would also take the chance mentioning that I would like to help coding >> wise and planning also if/when possible >> >> Allow me to take this thread one step further and say that I can see at >> least an initial consensus if not a good enough one to start taking it >> into >> a one or more separate threads where we can discuss more planning and >> technical details >> >> Thoughts ? >> >> On Tue, Jan 8, 2013 at 7:25 AM, Koushik Das <koushik....@citrix.com> >> wrote: >> >> +1 to the feature. >>> This will definitely help in doing initial application prototype and >>> testing on a test cloud and once everything is tuned up properly the >>> application can be exported as a package and imported to a production >>> cloud >>> and with minimal configuration changes should be up and running. >>> >>> -Koushik >>> >>> -----Original Message----- >>>> From: Alex Heneveld >>>> [mailto:alex.heneveld@**cloudsoftcorp.com<alex.henev...@cloudsoftcorp.com> >>>> ] >>>> Sent: Saturday, January 05, 2013 3:34 AM >>>> To: >>>> cloudstack-dev@incubator.**apache.org<cloudstack-dev@incubator.apache.org> >>>> Subject: [DISCUSS] PaaS Enablement: Composite Application Blueprints >>>> (#576) >>>> >>>> >>>> Hi All, >>>> >>>> At the CCC, and in jira [1] late last year, we started discussing this >>>> >>> feature >>> >>>> request, but going foward we'd like to get broader feedback. A couple >>>> >>> folks >>> >>>> have suggested we bring it back to the mailing list to get this. >>>> >>>> In brief, we're responding to a desire for high-level composite >>>> >>> blueprints on >>> >>>> top of Cloudstack. For instance: >>>> >>>> (a) An app team wants to have a single entity in Cloudstack which >>>> represents their application, >>>> consisting of a load-balancer, a scalable appserver tier, and >>>> a >>>> >>> SQL >>> >>>> database >>>> >>>> (b) A middleware team wants to have a mechanism for describing a >>>> >>> PaaS >>> >>>> which they can >>>> deploy, manage (e.g. scale out, back), track costs, and >>>> destroy >>>> >>> as a unit >>> >>>> in Cloudstack >>>> >>>> These get mapped on to Cloudstack components (IaaS and services), but >>>> what distinguishes them from Projects is that they are reusable portable >>>> definitions. This is similar to what VMware have in vApp and AWS in >>>> CloudFormation; but there is (so far) a preference to base these around >>>> CloudStack concepts and have them accessible in the GUI. >>>> >>>> Cloudsoft (me and others here) want to work on this, together with like- >>>> minded folks. >>>> >>>> Here are some feature ideas for starters: >>>> >>>> * IaaS mapping >>>> - ability to refer to specific templates and offerings (eg id="1234") >>>> - ability to refer to portable descriptions of templates and offerings >>>> >>> (eg >>> >>>> os("ubuntu"), userdata("myappsrv"), minram("2gb")) >>>> - ability to define subnets, DNS, public IP and firewall rules >>>> >>>> * Wiring >>>> - ability to write files to VM's with permissions, mode, etc >>>> - ability to embed references to other blueprint entities (ie other VM >>>> IP's/hostnames) in such files >>>> - ability to execute commands on VM's, with order constraints >>>> - ability to use puppet/chef/bash/juju/**cartridges/brooklyn (e.g. via >>>> the >>>> above capabilities) >>>> >>>> * Management >>>> - ability to access blueprints and deployments via REST and via GUI >>>> - ability to define clusters and groups of entities (which could be >>>> >>> scaled) >>> >>>> - ability to deploy policies (eg elasticity, HA/DR logic) to various >>>> >>> management >>> >>>> systems >>>> >>>> What would you like to see? Would you be able to help? >>>> >>>> Many thanks, >>>> Alex >>>> >>>> [1] >>>> https://issues.apache.org/**jira/browse/CLOUDSTACK-576<https://issues.apache.org/jira/browse/CLOUDSTACK-576> >>>> >>> >>> >> > -- Duncan Johnston-Watt CEO | Cloudsoft Corporation Twitter | @duncanjw Mobile | +44 777 190 2653 Skype | duncan_johnstonwatt Linkedin | www.linkedin.com/in/duncanjohnstonwatt Cloudsoft Corporation Limited, Registered in Scotland No: SC349230. Registered Office: 13 Dryden Place, Edinburgh, EH9 1RP This e-mail message is confidential and for use by the addressee only. If the message is received by anyone other than the addressee, please return the message to the sender by replying to it and then delete the message from your computer. Internet e-mails are not necessarily secure. Cloudsoft Corporation Limited does not accept responsibility for changes made to this message after it was sent. Whilst all reasonable care has been taken to avoid the transmission of viruses, it is the responsibility of the recipient to ensure that the onward transmission, opening or use of this message and any attachments will not adversely affect its systems or data. No responsibility is accepted by Cloudsoft Corporation Limited in this regard and the recipient should carry out such virus and other checks as it considers appropriate.
