Open Stack

----- Original Message -----
> 
> > 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.

Possibly - or that plan generation is as absolutely simple as possible (we either take a plan as input in the client, or pregenerate one with 1-2 replacement variables).  

> 
> > 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
> 
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>