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. > 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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
