Re: [openstack-dev] [Solum] Plan files and resources
- Original Message -
>
> > On Dec 11, 2013, at 4:45 PM, "Clayton Coleman" wrote:
> > - Original Message -
> >> Devdatta,
> >>
> >> On Dec 10, 2013, at 12:37 PM, devdatta kulkarni
> >> 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
Re: [openstack-dev] [Solum] Plan files and resources
> On Dec 11, 2013, at 4:45 PM, "Clayton Coleman" wrote:
> - Original Message -
>> Devdatta,
>>
>> On Dec 10, 2013, at 12:37 PM, devdatta kulkarni
>> 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
>> implementat
Re: [openstack-dev] [Solum] Plan files and resources
- Original Message -
> Devdatta,
>
> On Dec 10, 2013, at 12:37 PM, devdatta kulkarni
> 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). 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. 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.
>
> > 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
> _
Re: [openstack-dev] [Solum] Plan files and resources
Devdatta,
On Dec 10, 2013, at 12:37 PM, devdatta kulkarni
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
