----- Original Message ----- > > > On Dec 11, 2013, at 4:45 PM, "Clayton Coleman" <ccole...@redhat.com> wrote: > > ----- Original Message ----- > >> Devdatta, > >> > >> On Dec 10, 2013, at 12:37 PM, devdatta kulkarni > >> <devdatta.kulka...@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 > OpenStackfirstname.lastname@example.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStackemail@example.com http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev