Open Stack

> On Dec 11, 2013, at 4:45 PM, "Clayton Coleman" <ccoleman at redhat.com> wrote:
> ----- Original Message -----
>> Devdatta,
>> 
>> On Dec 10, 2013, at 12:37 PM, devdatta kulkarni
>> <devdatta.kulkarni at rackspace.com> wrote:
>> 
>>> Hi Adrian,
>>> 
>>> Thanks for creating https://etherpad.openstack.org/p/solum-demystified
>>> 
>>> I am really excited to see the examples. Especially cool is how
>>> examples 2 and 3 demonstrate using a component ("solum_glance_id") created
>>> as part of example 1.
>>> 
>>> 
>>> Some questions/comments:
>>> 
>>> 1) Summarizing the sequence of events just to make sure I understand them
>>> correctly:
>>>  a) User selects a language pack and specifies its id in the plan file
>> 
>> They could put the language pack reference into a Plan file, or we could
>> generate a Plan file with a CLI command that feeds an auto-generated file to
>> the API for the user. That might reduce the user complexity a bit for the
>> general case.
> 
> It seems like the reasonable M1 and M2 scenarios are to get the bones of an integration working that allow a flexible Plan to exist (but not necessarily something an average user would edit).  

To be clear, are you suggesting that we ask users to place stock plan files in their code repos as a first step? This would certainly minimize work for us to get to milestone-1.

> M2 and M3 can focus on the support around making Plans that mere mortals can throw together (whether generated or precreated by an operator), and a lot of how that evolves depends on the other catalog work.  

This would mean revisiting the simplicity of the plan file, documenting lots of examples of them so the are well understood. At that point we could demonstrate ways to tweak them to accommodate a variety of workload types with Solum, not just deploy simple web apps fitting a single system architecture.

> You could argue the resistance from some quarters to the current PaaS model is that the "Plan" equivalent is hardcoded and non-flexible - what is being done differently here is to offer the concepts necessary to allow other types of plans and application models to coexist in a single system.

Agreed 100%. 

>>>  b) User creates repo with the plan file in it.
>> 
>> We could scan the repo for a Plan file to override the auto-generation step,
>> to allow a method for customization.
>> 
>>>  After this the flow could be:
>>>  c.1) User uses solum cli to 'create' an application by giving reference
>>>  to
>>>     the repo uri
>> 
>> I view this as the use of the cli "app create" command as the first step.
>> They can optionally specify a Plan file to use for either the build
>> sequence, or the app deployment sequence, or both (for a total of TWO Plan
>> files). We could also allow plan files to be placed in the Git repo, and
>> picked up there in the event that none are specified on the command line.
>> 
>> Note that they may also put a HOT file in their repo, and bypass HOT file
>> generation/catalog-lookup and cause Solum to use the supplied template. This
>> would be useful for power users who want the ability to further influence
>> the arrangement of the Heat stack.
>> 
>>>      c.1.1) Solum creates a plan resource
>>>      c.1.2) Solum model interpreter creates a Heat stack and does the rest
>>>      of the
>>>       things needed to create a assembly.
>>>      (The created plan resource does not play any part in assembly
>>>      creation as such.
>>>       Its only role is being a 'trackback' to track the plan from which
>>>       the assembly was created.)
>> 
>> It's also a way to find out what services the given requirements were mapped
>> to. In a Plan file, the services array contains ServiceSpecfications (see
>> the EX[1-3] YAML examples under the "services" node for an example of what
>> those look like. In a Plan resource, the services array includes a list of
>> service resources so you can see what Solum's model interpreter mapped your
>> requirements to.
>> 
>>>  or,
>>>  c.2) User uses solum cli to 'create/register' a plan by providing
>>>  reference to the repo uri.
>>>       c.2.1) Solum creates the plan resource.
>>>  c.2) User uses solum cli to 'create' an application by specifying the
>>>  created plan
>>>       resource uri
>>>       (In this flow, the plan is actively used).
>> 
>> Yes, this would be another option. I expect that this approach may be used by
>> users who want to create multitudes of Assemblies from a given Plan
>> resource.
>> 
>>> 2) Addition of new solum specific attributes in a plan specification is
>>> interesting.
>>>  I imagine those can be contributed back as "Solum" profile to CAMP spec?
>> 
>> If we want, that input would certainly be welcomed.
>> 
>>> 3) Model interpreter for generating Heat stack from a plan is a nice idea.
>>>  For all: Are there any recommended libraries for this?
>> 
>> Good question. There are a number of orchestration systems that we could look
>> at as case studies. Anything that has a declarative DSL is likely to have
>> implementations that are relevant to our need for a model interpreter. This
>> includes Heat.
>> 
>>> 4) Just to confirm, I assume that the api-spec-review etherpad
>>> (https://etherpad.openstack.org/p/solum-api-spec-review),
>>>  is for fyi purpose only. If someone wants to know what is the current
>>>  thinking about API, they should
>>>  just look at the solum-demystified etherpad
>>>  (https://etherpad.openstack.org/p/solum-demystified)
>> 
>> I just updated the solum-api-spec-review, as that's actually still WIP. I
>> labeled it as such.
>> 
>> Thanks,
>> 
>> Adrian