Thanks a lot for your clarifications, Alex. Regarding language, personally I am not in favor of YAML, although YAML gets rid of curly braces and quotes, correct indentation required by YAML is also annoying to users.
-min On 1/9/13 4:39 PM, "Alex Heneveld" <alex.henev...@cloudsoftcorp.com> wrote: > >Hi Min, Jie, > >Min, nice questions. I've given my answers in-line. > >Jie, my answers also respond to some of your points, re TOSCA and >YAML/JSON. > > >On 08/01/2013 17:50, Min Chen wrote: >> +1 on this feature to extend CloudStack from pure IaaS to PaaS or SaaS >> area. Some questions in my mind: >> >> 1) Does your proposed blueprint only contain functional component >> description or contain both functional and deployment aspects? For >> example, for a 3-tier app containing three functional components like >>web >> tier, server, and DB, users can define different deployment models for >>the >> same functional components, like small deployment (co-hosting all >> components on one VM), or medium or large deployment. >Great use case. Introduces a _lot_ of complexity: > >(1) allow parameters to be passed to the blueprint (e.g. "size") >(2) separate the components that are to be created from the >customizations performed > (so you could define customizations for webserver, appserver, >and data, then either > apply the customizations either to a single VM (small), >distinct VM's (medium), > or distinct VM groups (large)) >(3) allow blueprints to refer to other blueprints > (so the "webserver customization" lives as its own reusable >module) >(4) allow conditional branching based on parameters > (e.g. if user selects "size=small" then run all customisations >on single VM) > >I'd be inclined to DEFER them as features, until phase 2 or 3, but we >should consider how the description might support them as I'd like to >see some of this functionality eventually. > >What do other people think? This is obvious functionality to want, >what's the right way to support it but without making the description >language complicated? > >(BTW one of the reasons I think TOSCA could be a good choice is that it >has considered many of these. You can define properties (1 above), >arbitrary nodes (2), and references to other definitions (3). It also >has the concepts of requirements / capabilities, relationships, >policies, and plans -- some of which could be used to support (4) >eventually.) > >> 2) Have you thought of creating Service offerings from your defined >> blueprints? This may allow CloudStack to provide some SaaS >>functionalities. >I like this idea, although it might break assumptions made elsewhere >about service offerings so we should look at it carefully. > >> 3) As for blueprint description language, easy-to-read and easy-to-edit >>by >> human being should be necessary if we don't provide any visual GUI tools >> to create/edit a blueprint. I have seen some JSON format before in BMC >> Cloud LifeCycle product 2.0. >Wow JSON seems popular so far. And yet YAML is more concise and >expressive. Designed to be easy for people to read and write >configuration just like this. Whereas JSON is designed for serializing >objects, in a way that isn't too hard for people. YAML seems the right >language for this purpose to me -- and my experience has been that it is >easier to read and to write, without the litter of curly braces and >quotes. > >But I don't want to be a language bigot! I can go with JSON if that's >what people want. :) > >> 4) For a multi-tier application, blueprint should not only describe >> different components, but also connections among those components, like >> open port, LB and FW rules among them. I assume that your blueprint is >> also taking that into consideration, and your backend orchestration >>layer >> can provide enough flexibility to provision any such app, seems not an >> easy task to me since I am new to CS. >Yeah, this is where it gets interesting. A common trick I've seen is to >use hostnames for a lot of the connection configuration, and have a few >hard-coded patterns in there (e.g. for groups, load-balancers). But >that only gets you so far, and then you hit a wall (or spin up a >different orchestrator). > >Using requirements/capabilities and typed relationships gives a much >more an elegant solution. (Not necessarily TOSCA, but these concepts >are well developed there!) > >In any case let's make sure the use cases include interesting situations >like this, and we can compare approaches. This absolutely DOES need to >be in phase 1 I think. > >> 5) From a normal user perspective, I would really love to see a GUI tool >> developed around this to allow user to visually create/edit a multi-tier >> app blueprint instead of using a TextEditor. >Nice to hear. Me too. The description, API, and backend come first, >with an initial set of features, but I'd love to see the GUI in phase 2. > >> Thanks >> -min >Keep it coming please. > >--Alex >
