Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-29 Thread Thomas Spatzier
Hi all,

I have read thru all the good discussion around software orchestration and
what to share my view. I see that there are two threads - this one and [1]
- but I am just replying to the one with the more generic topic line.

So on the recent twist to have software components implemented as
resources, I see some pros and cons. I am not actually decided yet what I
like most, so just shedding some thoughts here.
The good thing it would bring is definitely that it would give us a lot of
the things that Lakshmi has asked for in [1] (e.g. feed in properties,
get_attr, state) for free, and it would keep the HOT language smaller.

One of the big differences between the way resources are used today, and
what components are meant to be is that components had semantics of being
declared once and potentially used in many places in a template. Whereas a
resource would result in one instance at runtime. I think this is a key
issue that needs to be addressed.

One possibility would be the "SoftwareComponent - Deployment - Server"
resource triple that Zane brought up on the other thread. Or the original
component concept ...

With the latter one, the other open issue is how the binding gets defined,
and there are some debates about it. In summary, I think the following
option have been outlined:

(1) a components section with the server
(2) a hosted_on link with the component
(3) some explicit binding object

(1) seems doable, but has state dependency impacts that Steve Baker lined
out in a recent post. (2) would solve the state dependency problem, but has
the problem that the re-usable thing (the component) points explicitly to
its host. (3) sounds like Zane's "SoftwareComponent - Deployment - Server"
idea.

At the moment I am inclined to (3) because it actually makes the
distinction between a component declaration and its use ("Deployment") very
clear. And I think this would have to be done in any case - whether
software components are resources or a new concept.
Originally, I actually brought up hosted_on in an own proposal because I am
coming from the TOSCA world where we have a HostedOn relationship type. The
difference, though, is that in TOSCA we have relationships as own objects
so we avoid "hardcoding" the host in the software component object but
having association objects instead. Again, this seems to go into the
direction of option (3).

BTW: +10 on Angus' request for big whiteboards at the summit!

[1]
http://lists.openstack.org/pipermail/openstack-dev/2013-October/017540.html

Regards,
Thomas

Angus Salkeld  wrote on 29.10.2013 02:22:22:
> From: Angus Salkeld 
> To: openstack-dev@lists.openstack.org,
> Date: 29.10.2013 02:25
> Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
>
> On 28/10/13 16:26 -0700, Clint Byrum wrote:
>
> [snip]
>
> >> >
> >> My components proposals had no hosted_on, but I've been thinking about
> >> the implications of implementing software configuration as resources,
> >> and one of the natural consequences might be that hosted_on is the
best
> >> way of establishing the relationship with compute and its
> >> configurations. Let me elaborate.
> >>
> >> Lets say that Heat has resource types for software configuration, with
> >> the following behaviours:
> >> * like other resources, a config resource goes into CREATE IN_PROGRESS
> >> as soon as its dependencies are satisfied (these dependencies may be
> >> values signalled from other config resources)
> >> * a config resource goes to state CREATE COMPLETE when it receives a
> >> signal that configuration on the compute resource is complete (by some
> >> mechanism; wait condition, marconi message, whatevs)
> >> * the relationship between config resources and compute resources are
> >> achieved with existing intrinsic functions (get_resource, get_attr)
> >>
> >> This lifecycle behaviour means that a configuration resource can only
> >> run on a single compute resource, and that relationship needs to be
> >> established somehow. Config resources will have a quirk in that they
> >> need to provide 2 sources of configuration data at different times:
> >> 1) cloud-init config-data (or other boot-only mechanism), which must
be
> >> available when the compute resource goes into CREATE IN_PROGRESS
> >> 2) the actual configuration data (oac metadata, puppet manifest, chef
> >> recipe) which the compute resource needs to be able to fetch and
execute
> >> whenever it becomes available.
> >>
> >> The data in 1) implies that the compute needs to depend on the config,
> >> but then all concurrency is lost (this won't matter for a
> >> cloud-init-only config reso

Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-28 Thread Angus Salkeld

On 28/10/13 16:26 -0700, Clint Byrum wrote:

[snip]


>
My components proposals had no hosted_on, but I've been thinking about
the implications of implementing software configuration as resources,
and one of the natural consequences might be that hosted_on is the best
way of establishing the relationship with compute and its
configurations. Let me elaborate.

Lets say that Heat has resource types for software configuration, with
the following behaviours:
* like other resources, a config resource goes into CREATE IN_PROGRESS
as soon as its dependencies are satisfied (these dependencies may be
values signalled from other config resources)
* a config resource goes to state CREATE COMPLETE when it receives a
signal that configuration on the compute resource is complete (by some
mechanism; wait condition, marconi message, whatevs)
* the relationship between config resources and compute resources are
achieved with existing intrinsic functions (get_resource, get_attr)

This lifecycle behaviour means that a configuration resource can only
run on a single compute resource, and that relationship needs to be
established somehow. Config resources will have a quirk in that they
need to provide 2 sources of configuration data at different times:
1) cloud-init config-data (or other boot-only mechanism), which must be
available when the compute resource goes into CREATE IN_PROGRESS
2) the actual configuration data (oac metadata, puppet manifest, chef
recipe) which the compute resource needs to be able to fetch and execute
whenever it becomes available.

The data in 1) implies that the compute needs to depend on the config,
but then all concurrency is lost (this won't matter for a
cloud-init-only config resource).  Either way, the data for 1) will need
to be available when the config resource is still in state INIT
COMPLETE, which may impose limitations on how that is defined (ie
get_resource, get_attr not allowed).

So, 2 concrete examples for handling config/compute dependencies:

hosted_on
-
resources:
  configA
type: Heat::ScriptConfig
properties:
   hosted_on:
 get_resource: the_server
   script: |
 #!/bin/bash
 logger "1. hello config A"
  configB
type: Heat::ScriptConfig
properties:
   hosted_on:
 get_resource: the_server
   script: |
 #!/bin/bash
 logger "1. hello config B"
  the_server:
type: OS::Nova::Server

Here, configA and configB go into CREATE IN_PROGRESS as soon as
the_server is CREATE COMPLETE. configA and configB go into CREATE
COMPLETE when heat-engine receives a signal that they are complete. This
signal may include values that other resources depend on to start their
creation.



My biggest objection to hosted_on is that if I want to reuse configA.. I
can't without an additional level of abstraction. This feels awkward,
and will be an awkward thing for users. In addition, it is very unclear
what what will actually be on "the_server" when looking at "the_server".

Nobody has answered my question where else this sort of pattern is used.


OS::Nova::Server config_resources
-
resources:
  configA
type: Heat::ScriptConfig
properties:
   script: |
 #!/bin/bash
 logger "1. hello config A"
  configB
type: Heat::ScriptConfig
properties:
   script: |
 #!/bin/bash
 logger "1. hello config B"
  the_server:
type: OS::Nova::Server
properties:
  config_resources:
- {get_resource: configA}
- {get_resource: configB}

Here there would need to be some bypassing of dependency calculation to
allow configA and configB to be created after the_server, maybe by:
* special treatment of config_resources to prevent dependencies being
created
* a get_resource variant which doesn't create a hard dependency
(get_resource_deferred?)



IMO no, these are not best expressed as resources in the same way that
python classes are not expressed as objects.

The template above reads more like code. If used as a component, configA
remains reusable throughout the rest of the template as it grows and
changes, and it is very obvious what is expected on "the_server". Each
server using configA gets its very own completion waitcondition for that
instantiation of the component.

This is why I liked the components concept, rather than have them as
resources. It seems clear to me that components are parse-time objects,
so if I refer to the same component 4 times, I really want 4 copies of
it. Resources, on the other hand, are real things that are instantiated.


Neither the hosted_on nor the config_resources behaviours are ideal, but
I'm leaning towards hosted_on at the moment since it doesn't require any
new soft-dependency mechanism.



IMO hosted_on is a new dependency mechanism, so avoiding the more clear
paradigm for the reason of not introducing dependency mechanism seems a
bit backwards too.


As for composability, what *actually* needs t

Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-28 Thread Clint Byrum
Excerpts from Steve Baker's message of 2013-10-28 15:43:02 -0700:
> On 10/26/2013 05:25 AM, Clint Byrum wrote:
> > Excerpts from Angus Salkeld's message of 2013-10-24 18:48:16 -0700:
> >> On 24/10/13 11:54 +0200, Patrick Petit wrote:
> >>> Hi Clint,
> >>> Thank you! I have few replies/questions in-line.
> >>> Cheers,
> >>> Patrick
> >>> On 10/23/13 8:36 PM, Clint Byrum wrote:
>  I think this fits into something that I want for optimizing
>  os-collect-config as well (our in-instance Heat-aware agent). That is
>  a way for us to wait for notification of changes to Metadata without
>  polling.
> >>> Interesting... If I understand correctly that's kinda replacement of 
> >>> cfn-hup... Do you have a blueprint pointer or something more 
> >>> specific? While I see the benefits of it, in-instance notifications 
> >>> is not really what we are looking for. We are looking for a 
> >>> notification service that exposes an API whereby listeners can 
> >>> register for Heat notifications. AWS Alarming / CloudFormation has 
> >>> that. Why not Ceilometer / Heat? That would be extremely valuable for 
> >>> those who build PaaS-like solutions above Heat. To say it bluntly, 
> >>> I'd like to suggest we explore ways to integrate Heat with Marconi.
> >> Yeah, I am trying to do a PoC of this now. I'll let you know how
> >> it goes.
> >>
> >> I am trying to implement the following:
> >>
> >> heat_template_version: 2013-05-23
> >> parameters:
> >>key_name:
> >>  type: String
> >>flavor:
> >>  type: String
> >>  default: m1.small
> >>image:
> >>  type: String
> >>  default: fedora-19-i386-heat-cfntools
> >> resources:
> >>config_server:
> >>  type: OS::Marconi::QueueServer
> >>  properties:
> >>image: {get_param: image}
> >>flavor: {get_param: flavor}
> >>key_name: {get_param: key_name}
> >>
> >>configA:
> >>  type: OS::Heat::OrderedConfig
> >>  properties:
> >>marconi_server: {get_attr: [config_server, url]}
> >>hosted_on: {get_resource: serv1}
> >>script: |
> >>  #!/bin/bash
> >>  logger "1. hello from marconi"
> >>
> >>configB:
> >>  type: OS::Heat::OrderedConfig
> >>  properties:
> >>marconi_server: {get_attr: [config_server, url]}
> >>hosted_on: {get_resource: serv1}
> >>depends_on: {get_resource: configA}
> >>script: |
> >>  #!/bin/bash
> >>  logger "2. hello from marconi"
> >>
> >>serv1:
> >>  type: OS::Nova::Server
> >>  properties:
> >>image: {get_param: image}
> >>flavor: {get_param: flavor}
> >>key_name: {get_param: key_name}
> >>user_data: |
> >>  #!/bin/sh
> >>  # poll /v1/queues/{hostname}/messages
> >>  # apply config
> >>  # post a response message with any outputs
> >>  # delete request message
> >>
> > If I may diverge this a bit, I'd like to consider the impact of
> > hosted_on on reusability in templates. hosted_on feels like an
> > anti-pattern, and I've never seen anything quite like it. It feels wrong
> > for a well contained component to then reach out and push itself onto
> > something else which has no mention of it.
> >
> > I'll rewrite your template as I envision it working:
> >
> > resources:
> >config_server:
> >  type: OS::Marconi::QueueServer
> >  properties:
> >image: {get_param: image}
> >flavor: {get_param: flavor}
> >key_name: {get_param: key_name}
> >
> >configA:
> >  type: OS::Heat::OrderedConfig
> >  properties:
> >marconi_server: {get_attr: [config_server, url]}
> >script: |
> >  #!/bin/bash
> >  logger "1. hello from marconi"
> >
> >configB:
> >  type: OS::Heat::OrderedConfig
> >  properties:
> >marconi_server: {get_attr: [config_server, url]}
> >depends_on: {get_resource: configA}
> >script: |
> >  #!/bin/bash
> >  logger "2. hello from marconi"
> >
> >serv1:
> >  type: OS::Nova::Server
> >  properties:
> >image: {get_param: image}
> >flavor: {get_param: flavor}
> >key_name: {get_param: key_name}
> >components:
> >  - configA
> >  - configB
> >user_data: |
> >  #!/bin/sh
> >  # poll /v1/queues/{hostname}/messages
> >  # apply config
> >  # post a response message with any outputs
> >  # delete request message
> >
> > This only becomes obvious why it is important when you want to do this:
> >
> > configC:
> >   type: OS::Heat::OrderedConfig
> >   properties:
> > script: |
> >   #!/bin/bash
> >   logger "?. I can race with A, no dependency needed"
> >
> > serv2:
> >   type: OS::Nova::Server
> >   properties:
> >   ...
> >   components:
> > - configA
> > - configC
> >
> > This is proper composition, where 

Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-28 Thread Keith Bray
In-line comments.

On 10/28/13 5:43 PM, "Steve Baker"  wrote:

>On 10/26/2013 05:25 AM, Clint Byrum wrote:
>> Excerpts from Angus Salkeld's message of 2013-10-24 18:48:16 -0700:
>>> On 24/10/13 11:54 +0200, Patrick Petit wrote:
 Hi Clint,
 Thank you! I have few replies/questions in-line.
 Cheers,
 Patrick
 On 10/23/13 8:36 PM, Clint Byrum wrote:
> I think this fits into something that I want for optimizing
> os-collect-config as well (our in-instance Heat-aware agent). That is
> a way for us to wait for notification of changes to Metadata without
> polling.
 Interesting... If I understand correctly that's kinda replacement of
 cfn-hup... Do you have a blueprint pointer or something more
 specific? While I see the benefits of it, in-instance notifications
 is not really what we are looking for. We are looking for a
 notification service that exposes an API whereby listeners can
 register for Heat notifications. AWS Alarming / CloudFormation has
 that. Why not Ceilometer / Heat? That would be extremely valuable for
 those who build PaaS-like solutions above Heat. To say it bluntly,
 I'd like to suggest we explore ways to integrate Heat with Marconi.
>>> Yeah, I am trying to do a PoC of this now. I'll let you know how
>>> it goes.
>>>
>>> I am trying to implement the following:
>>>
>>> heat_template_version: 2013-05-23
>>> parameters:
>>>key_name:
>>>  type: String
>>>flavor:
>>>  type: String
>>>  default: m1.small
>>>image:
>>>  type: String
>>>  default: fedora-19-i386-heat-cfntools
>>> resources:
>>>config_server:
>>>  type: OS::Marconi::QueueServer
>>>  properties:
>>>image: {get_param: image}
>>>flavor: {get_param: flavor}
>>>key_name: {get_param: key_name}
>>>
>>>configA:
>>>  type: OS::Heat::OrderedConfig
>>>  properties:
>>>marconi_server: {get_attr: [config_server, url]}
>>>hosted_on: {get_resource: serv1}
>>>script: |
>>>  #!/bin/bash
>>>  logger "1. hello from marconi"
>>>
>>>configB:
>>>  type: OS::Heat::OrderedConfig
>>>  properties:
>>>marconi_server: {get_attr: [config_server, url]}
>>>hosted_on: {get_resource: serv1}
>>>depends_on: {get_resource: configA}
>>>script: |
>>>  #!/bin/bash
>>>  logger "2. hello from marconi"
>>>
>>>serv1:
>>>  type: OS::Nova::Server
>>>  properties:
>>>image: {get_param: image}
>>>flavor: {get_param: flavor}
>>>key_name: {get_param: key_name}
>>>user_data: |
>>>  #!/bin/sh
>>>  # poll /v1/queues/{hostname}/messages
>>>  # apply config
>>>  # post a response message with any outputs
>>>  # delete request message
>>>
>> If I may diverge this a bit, I'd like to consider the impact of
>> hosted_on on reusability in templates. hosted_on feels like an
>> anti-pattern, and I've never seen anything quite like it. It feels wrong
>> for a well contained component to then reach out and push itself onto
>> something else which has no mention of it.
>>
>> I'll rewrite your template as I envision it working:
>>
>> resources:
>>config_server:
>>  type: OS::Marconi::QueueServer
>>  properties:
>>image: {get_param: image}
>>flavor: {get_param: flavor}
>>key_name: {get_param: key_name}
>>
>>configA:
>>  type: OS::Heat::OrderedConfig
>>  properties:
>>marconi_server: {get_attr: [config_server, url]}
>>script: |
>>  #!/bin/bash
>>  logger "1. hello from marconi"
>>
>>configB:
>>  type: OS::Heat::OrderedConfig
>>  properties:
>>marconi_server: {get_attr: [config_server, url]}
>>depends_on: {get_resource: configA}
>>script: |
>>  #!/bin/bash
>>  logger "2. hello from marconi"
>>
>>serv1:
>>  type: OS::Nova::Server
>>  properties:
>>image: {get_param: image}
>>flavor: {get_param: flavor}
>>key_name: {get_param: key_name}
>>components:
>>  - configA
>>  - configB
>>user_data: |
>>  #!/bin/sh
>>  # poll /v1/queues/{hostname}/messages
>>  # apply config
>>  # post a response message with any outputs
>>  # delete request message
>>
>> This only becomes obvious why it is important when you want to do this:
>>
>> configC:
>>   type: OS::Heat::OrderedConfig
>>   properties:
>> script: |
>>   #!/bin/bash
>>   logger "?. I can race with A, no dependency needed"
>>
>> serv2:
>>   type: OS::Nova::Server
>>   properties:
>>   ...
>>   components:
>> - configA
>> - configC
>>
>> This is proper composition, where the caller defines the components, not
>> the callee. Now you can re-use configA with a different component in the
>> same template. As we get smarter we 

Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-28 Thread Steve Baker
On 10/26/2013 05:25 AM, Clint Byrum wrote:
> Excerpts from Angus Salkeld's message of 2013-10-24 18:48:16 -0700:
>> On 24/10/13 11:54 +0200, Patrick Petit wrote:
>>> Hi Clint,
>>> Thank you! I have few replies/questions in-line.
>>> Cheers,
>>> Patrick
>>> On 10/23/13 8:36 PM, Clint Byrum wrote:
 I think this fits into something that I want for optimizing
 os-collect-config as well (our in-instance Heat-aware agent). That is
 a way for us to wait for notification of changes to Metadata without
 polling.
>>> Interesting... If I understand correctly that's kinda replacement of 
>>> cfn-hup... Do you have a blueprint pointer or something more 
>>> specific? While I see the benefits of it, in-instance notifications 
>>> is not really what we are looking for. We are looking for a 
>>> notification service that exposes an API whereby listeners can 
>>> register for Heat notifications. AWS Alarming / CloudFormation has 
>>> that. Why not Ceilometer / Heat? That would be extremely valuable for 
>>> those who build PaaS-like solutions above Heat. To say it bluntly, 
>>> I'd like to suggest we explore ways to integrate Heat with Marconi.
>> Yeah, I am trying to do a PoC of this now. I'll let you know how
>> it goes.
>>
>> I am trying to implement the following:
>>
>> heat_template_version: 2013-05-23
>> parameters:
>>key_name:
>>  type: String
>>flavor:
>>  type: String
>>  default: m1.small
>>image:
>>  type: String
>>  default: fedora-19-i386-heat-cfntools
>> resources:
>>config_server:
>>  type: OS::Marconi::QueueServer
>>  properties:
>>image: {get_param: image}
>>flavor: {get_param: flavor}
>>key_name: {get_param: key_name}
>>
>>configA:
>>  type: OS::Heat::OrderedConfig
>>  properties:
>>marconi_server: {get_attr: [config_server, url]}
>>hosted_on: {get_resource: serv1}
>>script: |
>>  #!/bin/bash
>>  logger "1. hello from marconi"
>>
>>configB:
>>  type: OS::Heat::OrderedConfig
>>  properties:
>>marconi_server: {get_attr: [config_server, url]}
>>hosted_on: {get_resource: serv1}
>>depends_on: {get_resource: configA}
>>script: |
>>  #!/bin/bash
>>  logger "2. hello from marconi"
>>
>>serv1:
>>  type: OS::Nova::Server
>>  properties:
>>image: {get_param: image}
>>flavor: {get_param: flavor}
>>key_name: {get_param: key_name}
>>user_data: |
>>  #!/bin/sh
>>  # poll /v1/queues/{hostname}/messages
>>  # apply config
>>  # post a response message with any outputs
>>  # delete request message
>>
> If I may diverge this a bit, I'd like to consider the impact of
> hosted_on on reusability in templates. hosted_on feels like an
> anti-pattern, and I've never seen anything quite like it. It feels wrong
> for a well contained component to then reach out and push itself onto
> something else which has no mention of it.
>
> I'll rewrite your template as I envision it working:
>
> resources:
>config_server:
>  type: OS::Marconi::QueueServer
>  properties:
>image: {get_param: image}
>flavor: {get_param: flavor}
>key_name: {get_param: key_name}
>
>configA:
>  type: OS::Heat::OrderedConfig
>  properties:
>marconi_server: {get_attr: [config_server, url]}
>script: |
>  #!/bin/bash
>  logger "1. hello from marconi"
>
>configB:
>  type: OS::Heat::OrderedConfig
>  properties:
>marconi_server: {get_attr: [config_server, url]}
>depends_on: {get_resource: configA}
>script: |
>  #!/bin/bash
>  logger "2. hello from marconi"
>
>serv1:
>  type: OS::Nova::Server
>  properties:
>image: {get_param: image}
>flavor: {get_param: flavor}
>key_name: {get_param: key_name}
>components:
>  - configA
>  - configB
>user_data: |
>  #!/bin/sh
>  # poll /v1/queues/{hostname}/messages
>  # apply config
>  # post a response message with any outputs
>  # delete request message
>
> This only becomes obvious why it is important when you want to do this:
>
> configC:
>   type: OS::Heat::OrderedConfig
>   properties:
> script: |
>   #!/bin/bash
>   logger "?. I can race with A, no dependency needed"
>
> serv2:
>   type: OS::Nova::Server
>   properties:
>   ...
>   components:
> - configA
> - configC
>
> This is proper composition, where the caller defines the components, not
> the callee. Now you can re-use configA with a different component in the
> same template. As we get smarter we can have these configs separate from
> the template and reusable across templates.
>
> Anyway, I'd like to see us stop talking about hosted_on, and if it has
> been implemented, that it be deprecated 

Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-25 Thread Angus Salkeld

On 25/10/13 09:25 -0700, Clint Byrum wrote:

Excerpts from Angus Salkeld's message of 2013-10-24 18:48:16 -0700:

On 24/10/13 11:54 +0200, Patrick Petit wrote:
>Hi Clint,
>Thank you! I have few replies/questions in-line.
>Cheers
>Patrick
>On 10/23/13 8:36 PM, Clint Byrum wrote:
>>I think this fits into something that I want for optimizing
>>os-collect-config as well (our in-instance Heat-aware agent). That is
>>a way for us to wait for notification of changes to Metadata without
>>polling.
>Interesting... If I understand correctly that's kinda replacement of
>cfn-hup... Do you have a blueprint pointer or something more
>specific? While I see the benefits of it, in-instance notifications
>is not really what we are looking for. We are looking for a
>notification service that exposes an API whereby listeners can
>register for Heat notifications. AWS Alarming / CloudFormation has
>that. Why not Ceilometer / Heat? That would be extremely valuable for
>those who build PaaS-like solutions above Heat. To say it bluntly,
>I'd like to suggest we explore ways to integrate Heat with Marconi.

Yeah, I am trying to do a PoC of this now. I'll let you know how
it goes.

I am trying to implement the following:

heat_template_version: 2013-05-23
parameters:
   key_name:
 type: String
   flavor:
 type: String
 default: m1.small
   image:
 type: String
 default: fedora-19-i386-heat-cfntools
resources:
   config_server:
 type: OS::Marconi::QueueServer
 properties:
   image: {get_param: image}
   flavor: {get_param: flavor}
   key_name: {get_param: key_name}

   configA:
 type: OS::Heat::OrderedConfig
 properties:
   marconi_server: {get_attr: [config_server, url]}
   hosted_on: {get_resource: serv1}
   script: |
 #!/bin/bash
 logger "1. hello from marconi"

   configB:
 type: OS::Heat::OrderedConfig
 properties:
   marconi_server: {get_attr: [config_server, url]}
   hosted_on: {get_resource: serv1}
   depends_on: {get_resource: configA}
   script: |
 #!/bin/bash
 logger "2. hello from marconi"

   serv1:
 type: OS::Nova::Server
 properties:
   image: {get_param: image}
   flavor: {get_param: flavor}
   key_name: {get_param: key_name}
   user_data: |
 #!/bin/sh
 # poll /v1/queues/{hostname}/messages
 # apply config
 # post a response message with any outputs
 # delete request message



If I may diverge this a bit, I'd like to consider the impact of
hosted_on on reusability in templates. hosted_on feels like an
anti-pattern, and I've never seen anything quite like it. It feels wrong
for a well contained component to then reach out and push itself onto
something else which has no mention of it.


Maybe I shouldn't have used hosted_on, it could be role_name/config_queue.



I'll rewrite your template as I envision it working:

resources:
  config_server:
type: OS::Marconi::QueueServer
properties:
  image: {get_param: image}
  flavor: {get_param: flavor}
  key_name: {get_param: key_name}

  configA:
type: OS::Heat::OrderedConfig
properties:
  marconi_server: {get_attr: [config_server, url]}
  script: |
#!/bin/bash
logger "1. hello from marconi"

  configB:
type: OS::Heat::OrderedConfig
properties:
  marconi_server: {get_attr: [config_server, url]}
  depends_on: {get_resource: configA}
  script: |
#!/bin/bash
logger "2. hello from marconi"

  serv1:
type: OS::Nova::Server
properties:
  image: {get_param: image}
  flavor: {get_param: flavor}
  key_name: {get_param: key_name}
  components:
- configA
- configB
  user_data: |
#!/bin/sh
# poll /v1/queues/{hostname}/messages
# apply config
# post a response message with any outputs
# delete request message

This only becomes obvious why it is important when you want to do this:

   configC:
 type: OS::Heat::OrderedConfig
 properties:
   script: |
 #!/bin/bash
 logger "?. I can race with A, no dependency needed"

Well if you put no dependency, it's like any other heat resource
they will be run in parallel (or at least either may go first)
there are lots of configs where this may not be important.


   serv2:
 type: OS::Nova::Server
 properties:
 ...
 components:
   - configA
   - configC

This is proper composition, where the caller defines the components, not
the callee. Now you can re-use configA with a different component in the
same template. As we get smarter we can have these configs separate from
the template and reusable across templates.

Anyway, I'd like to see us stop talking about hosted_on, and if it has
been implemented, that it be deprecated and eventually removed, as it is
just plain confusing.


There are pros and cons to both, I don't however think it is helpful
to shutdown

Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-25 Thread Clint Byrum
Excerpts from Angus Salkeld's message of 2013-10-24 18:48:16 -0700:
> On 24/10/13 11:54 +0200, Patrick Petit wrote:
> >Hi Clint,
> >Thank you! I have few replies/questions in-line.
> >Cheers,
> >Patrick
> >On 10/23/13 8:36 PM, Clint Byrum wrote:
> >>I think this fits into something that I want for optimizing
> >>os-collect-config as well (our in-instance Heat-aware agent). That is
> >>a way for us to wait for notification of changes to Metadata without
> >>polling.
> >Interesting... If I understand correctly that's kinda replacement of 
> >cfn-hup... Do you have a blueprint pointer or something more 
> >specific? While I see the benefits of it, in-instance notifications 
> >is not really what we are looking for. We are looking for a 
> >notification service that exposes an API whereby listeners can 
> >register for Heat notifications. AWS Alarming / CloudFormation has 
> >that. Why not Ceilometer / Heat? That would be extremely valuable for 
> >those who build PaaS-like solutions above Heat. To say it bluntly, 
> >I'd like to suggest we explore ways to integrate Heat with Marconi.
> 
> Yeah, I am trying to do a PoC of this now. I'll let you know how
> it goes.
> 
> I am trying to implement the following:
> 
> heat_template_version: 2013-05-23
> parameters:
>key_name:
>  type: String
>flavor:
>  type: String
>  default: m1.small
>image:
>  type: String
>  default: fedora-19-i386-heat-cfntools
> resources:
>config_server:
>  type: OS::Marconi::QueueServer
>  properties:
>image: {get_param: image}
>flavor: {get_param: flavor}
>key_name: {get_param: key_name}
> 
>configA:
>  type: OS::Heat::OrderedConfig
>  properties:
>marconi_server: {get_attr: [config_server, url]}
>hosted_on: {get_resource: serv1}
>script: |
>  #!/bin/bash
>  logger "1. hello from marconi"
> 
>configB:
>  type: OS::Heat::OrderedConfig
>  properties:
>marconi_server: {get_attr: [config_server, url]}
>hosted_on: {get_resource: serv1}
>depends_on: {get_resource: configA}
>script: |
>  #!/bin/bash
>  logger "2. hello from marconi"
> 
>serv1:
>  type: OS::Nova::Server
>  properties:
>image: {get_param: image}
>flavor: {get_param: flavor}
>key_name: {get_param: key_name}
>user_data: |
>  #!/bin/sh
>  # poll /v1/queues/{hostname}/messages
>  # apply config
>  # post a response message with any outputs
>  # delete request message
> 

If I may diverge this a bit, I'd like to consider the impact of
hosted_on on reusability in templates. hosted_on feels like an
anti-pattern, and I've never seen anything quite like it. It feels wrong
for a well contained component to then reach out and push itself onto
something else which has no mention of it.

I'll rewrite your template as I envision it working:

resources:
   config_server:
 type: OS::Marconi::QueueServer
 properties:
   image: {get_param: image}
   flavor: {get_param: flavor}
   key_name: {get_param: key_name}

   configA:
 type: OS::Heat::OrderedConfig
 properties:
   marconi_server: {get_attr: [config_server, url]}
   script: |
 #!/bin/bash
 logger "1. hello from marconi"

   configB:
 type: OS::Heat::OrderedConfig
 properties:
   marconi_server: {get_attr: [config_server, url]}
   depends_on: {get_resource: configA}
   script: |
 #!/bin/bash
 logger "2. hello from marconi"

   serv1:
 type: OS::Nova::Server
 properties:
   image: {get_param: image}
   flavor: {get_param: flavor}
   key_name: {get_param: key_name}
   components:
 - configA
 - configB
   user_data: |
 #!/bin/sh
 # poll /v1/queues/{hostname}/messages
 # apply config
 # post a response message with any outputs
 # delete request message

This only becomes obvious why it is important when you want to do this:

configC:
  type: OS::Heat::OrderedConfig
  properties:
script: |
  #!/bin/bash
  logger "?. I can race with A, no dependency needed"

serv2:
  type: OS::Nova::Server
  properties:
  ...
  components:
- configA
- configC

This is proper composition, where the caller defines the components, not
the callee. Now you can re-use configA with a different component in the
same template. As we get smarter we can have these configs separate from
the template and reusable across templates.

Anyway, I'd like to see us stop talking about hosted_on, and if it has
been implemented, that it be deprecated and eventually removed, as it is
just plain confusing.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-25 Thread Patrick Petit

I think this fits into something that I want for optimizing

os-collect-config as well (our in-instance Heat-aware agent). That is
a way for us to wait for notification of changes to Metadata without
polling.
Interesting... If I understand correctly that's kinda replacement of 
cfn-hup... Do you have a blueprint pointer or something more 
specific? While I see the benefits of it, in-instance notifications 
is not really what we are looking for. We are looking for a 
notification service that exposes an API whereby listeners can 
register for Heat notifications. AWS Alarming / CloudFormation has 
that. Why not Ceilometer / Heat? That would be extremely valuable for 
those who build PaaS-like solutions above Heat. To say it bluntly, 
I'd like to suggest we explore ways to integrate Heat with Marconi.


Yeah, I am trying to do a PoC of this now. I'll let you know how
it goes.

I am trying to implement the following:

heat_template_version: 2013-05-23
parameters:
  key_name:
type: String
  flavor:
type: String
default: m1.small
  image:
type: String
default: fedora-19-i386-heat-cfntools
resources:
  config_server:
type: OS::Marconi::QueueServer
properties:
  image: {get_param: image}
  flavor: {get_param: flavor}
  key_name: {get_param: key_name}

  configA:
type: OS::Heat::OrderedConfig
properties:
  marconi_server: {get_attr: [config_server, url]}
  hosted_on: {get_resource: serv1}
  script: |
#!/bin/bash
logger "1. hello from marconi"

  configB:
type: OS::Heat::OrderedConfig
properties:
  marconi_server: {get_attr: [config_server, url]}
  hosted_on: {get_resource: serv1}
  depends_on: {get_resource: configA}
  script: |
#!/bin/bash
logger "2. hello from marconi"

  serv1:
type: OS::Nova::Server
properties:
  image: {get_param: image}
  flavor: {get_param: flavor}
  key_name: {get_param: key_name}
  user_data: |
#!/bin/sh
# poll /v1/queues/{hostname}/messages
# apply config
# post a response message with any outputs
# delete request message

The idea here is that each "os::heat::orderedConfig" does the
following:
create the following marconi queues:
.{request,respones}
sends the config to the request queue
the vm then posts responses to the response queue

- each vm/server has a "config" queue (named based on "hosted_on")
- we can get attributes/outputs from the vm
- we can depend_on other config resources
- you can monitor progress externally via marconi
- you can have properties other than "script" (puppet/chef/..)
- you could/should have a marconi server running in you infrastructure
  (I am doing it in a vm for ease of testing).

Is this the kind of thing you are after?


No.
The king of thing I am taking about is that:

http://docs.aws.amazon.com/AWSCloudFormation/latest/UserGuide/aws-properties-as-notificationconfiguration.html
http://docs.aws.amazon.com/AutoScaling/latest/APIReference/API_DescribeAutoScalingNotificationTypes.html

Which I figured could be supported in Heat with the use Marconi's 
notifications.


Thanks
Patrick


-Angus



The second one would be to support a new type of AWS::IAM::User 
(perhaps

OS::IAM::User) resource whereby one could pass Keystone credentials to
be able to specify Ceilometer alarms based on application's specific
metrics (a.k.a KPIs).


It would likely be OS::Keystone::User, and AFAIK this is on the list of
de-AWS-ification things.
Great! As I said. It's a blocker for us and really would like to see 
it accepted for icehouse.


I hope this is making sense to you and can serve as a basis for 
further

discussions and refinements.


Really great feedback Patrick, thanks again for sharing!

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Patrick Petit
Cloud Computing Principal Architect, Innovative Products
Bull, Architect of an Open World TM
Tél : +33 (0)4 76 29 70 31
Mobile : +33 (0)6 85 22 06 39
http://www.bull.com


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



--
Patrick Petit
Cloud Computing Principal Architect, Innovative Products
Bull, Architect of an Open World TM
Tél : +33 (0)4 76 29 70 31
Mobile : +33 (0)6 85 22 06 39
http://www.bull.com


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-25 Thread Thomas Spatzier
Hi Keith,

thanks for sharing your opinion. That seems to make sense, and I know
Adrian was heavily involved in discussion at the Portland summit,. so seems
like the right contacts are hooked up.
Looking forward to the discussions at the summit.

Regards,
Thomas

Keith Bray  wrote on 25.10.2013 02:23:55:

> From: Keith Bray 
> To: OpenStack Development Mailing List
,
> Date: 25.10.2013 02:31
> Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
>
> Hi Thomas, here's my opinion:  Heat and Solum contributors will work
> closely together to figure out where specific feature implementations
> belong... But, in general, Solum is working at a level above Heat.  To
> write a Heat template, you have to know about infrastructure setup and
> configuration settings of infrastructure and API services.  I believe
> Solum intends to provide the ability to tweak and configure the amount of
> complexity that gets exposed or hidden so that it becomes easier for
cloud
> consumers to just deal with their application and not have to necessarily
> know or care about the underlying infrastructure and API services, but
> that level of detail can be exposed to them if necessary. Solum will know
> what infrastructure and services to set up to run applications, and it
> will leverage Heat and Heat templates for this.
>
> The Solum project has been very vocal about leveraging Heat under the
hood
> for the functionality and vision of orchestration that it intends to
> provide.  It seems, based on this thread (and +1 from me), enough people
> are interested in having Heat provide some level of software
> orchestration, even if it's just bootstrapping other CM tools and
> coordinating the "when are you done", and I haven't heard any Solum folks
> object to Heat implementing software orchestration capabilities... So,
I'm
> looking forward to great discussions on this topic for Heat at the
summit.
>  If you recall, Adrian Otto (who announced project Solum) was also the
one
> who was vocal at the Portland summit about the need for HOT syntax.  I
> think both projects are on a good path with a lot of fun collaboration
> time ahead.
>
> Kind regards,
> -Keith
>
> On 10/24/13 7:56 AM, "Thomas Spatzier" 
wrote:
>
> >Hi all,
> >
> >maybe a bit off track with respect to latest concrete discussions, but I
> >noticed the announcement of project "Solum" on openstack-dev.
> >Maybe this is playing on a different level, but I still see some
relation
> >to all the software orchestration we are having. What are your opinions
on
> >this?
> >
> >BTW, I just posted a similar short question in reply to the Solum
> >announcement mail, but some of us have mail filters an might read [Heat]
> >mail with higher prio, and I was interested in the Heat view.
> >
> >Cheers,
> >Thomas
> >
> >Patrick Petit  wrote on 24.10.2013 12:15:13:
> >> From: Patrick Petit 
> >> To: OpenStack Development Mailing List
> >,
> >> Date: 24.10.2013 12:18
> >> Subject: Re: [openstack-dev] [Heat] HOT Software configuration
proposal
> >>
> >> Sorry, I clicked the 'send' button too quickly.
> >>
> >> On 10/24/13 11:54 AM, Patrick Petit wrote:
> >> > Hi Clint,
> >> > Thank you! I have few replies/questions in-line.
> >> > Cheers,
> >> > Patrick
> >> > On 10/23/13 8:36 PM, Clint Byrum wrote:
> >> >> Excerpts from Patrick Petit's message of 2013-10-23 10:58:22 -0700:
> >> >>> Dear Steve and All,
> >> >>>
> >> >>> If I may add up on this already busy thread to share our
experience
> >> >>> with
> >> >>> using Heat in large and complex software deployments.
> >> >>>
> >> >> Thanks for sharing Patrick, I have a few replies in-line.
> >> >>
> >> >>> I work on a project which precisely provides additional value at
the
> >> >>> articulation point between resource orchestration automation and
> >> >>> configuration management. We rely on Heat and chef-solo
respectively
> >> >>> for
> >> >>> these base management functions. On top of this, we have developed
> >>an
> >> >>> event-driven workflow to manage the life-cycles of complex
software
> >> >>> stacks which primary purpose is to support middleware components
as
> >> >>> opposed to end-user apps. Our use cases are peculiar in the sense
> >that
> >> >>> software setup (install, config, contex

Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-24 Thread Angus Salkeld

On 24/10/13 11:54 +0200, Patrick Petit wrote:

Hi Clint,
Thank you! I have few replies/questions in-line.
Cheers,
Patrick
On 10/23/13 8:36 PM, Clint Byrum wrote:

Excerpts from Patrick Petit's message of 2013-10-23 10:58:22 -0700:

Dear Steve and All,

If I may add up on this already busy thread to share our experience with
using Heat in large and complex software deployments.


Thanks for sharing Patrick, I have a few replies in-line.


I work on a project which precisely provides additional value at the
articulation point between resource orchestration automation and
configuration management. We rely on Heat and chef-solo respectively for
these base management functions. On top of this, we have developed an
event-driven workflow to manage the life-cycles of complex software
stacks which primary purpose is to support middleware components as
opposed to end-user apps. Our use cases are peculiar in the sense that
software setup (install, config, contextualization) is not a one-time
operation issue but a continuous thing that can happen any time in
life-span of a stack. Users can deploy (and undeploy) apps long time
after the stack is created. Auto-scaling may also result in an
asynchronous apps deployment. More about this latter. The framework we
have designed works well for us. It clearly refers to a PaaS-like
environment which I understand is not the topic of the HOT software
configuration proposal(s) and that's absolutely fine with us. However,
the question for us is whether the separation of software config from
resources would make our life easier or not. I think the answer is
definitely yes but at the condition that the DSL extension preserves
almost everything from the expressiveness of the resource element. In
practice, I think that a strict separation between resource and
component will be hard to achieve because we'll always need a little bit
of application's specific in the resources. Take for example the case of
the SecurityGroups. The ports open in a SecurityGroup are application
specific.


Components can only be made up of the things that are common to all users
of said component. Also components would, if I understand the concept
correctly, just be for things that are at the sub-resource level.

That isn't cop

Security groups and open ports would be across multiple resources, and
thus would be separately specified from your app's component (though it
might be useful to allow components to export static values so that the
port list can be referred to along with the app component).


Then, designing a Chef or Puppet component type may be harder than it
looks at first glance. Speaking of our use cases we still need a little
bit of scripting in the instance's user-data block to setup a working
chef-solo environment. For example, we run librarian-chef prior to
starting chef-solo to resolve the cookbook dependencies. A cookbook can
present itself as a downloadable tarball but it's not always the case. A
chef component type would have to support getting a cookbook from a
public or private git repo (maybe subversion), handle situations where
there is one cookbook per repo or multiple cookbooks per repo, let the
user choose a particular branch or label, provide ssh keys if it's a
private repo, and so forth. We support all of this scenarios and so we
can provide more detailed requirements if needed.


Correct me if I'm wrong though, all of those scenarios are just variations
on standard inputs into chef. So the chef component really just has to
allow a way to feed data to chef.





I am not sure adding component relations like the 'depends-on' would
really help us since it is the job of config management to handle
software dependencies. Also, it doesn't address the issue of circular
dependencies. Circular dependencies occur in complex software stack
deployments. Example. When we setup a Slum virtual cluster, both the
head node and compute nodes depend on one another to complete their
configuration and so they would wait for each other indefinitely if we
were to rely on the 'depends-on'. In addition, I think it's critical to
distinguish between configuration parameters which are known ahead of
time, like a db name or user name and password, versus contextualization
parameters which are known after the fact generally when the instance is
created. Typically those contextualization parameters are IP addresses
but not only. The fact packages x,y,z have been properly installed and
services a,b,c successfully started is contextualization information
(a.k.a facts) which may be indicative that other components can move on
to the next setup stage.


The form of contextualization you mention above can be handled by a
slightly more capable wait condition mechanism than we have now. I've
been suggesting that this is the interface that workflow systems should
use.


The case of complex deployments with or without circular dependencies is
typically resolved by making the system converge toward the desirable
end-s

Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-24 Thread Keith Bray
Hi Thomas, here's my opinion:  Heat and Solum contributors will work
closely together to figure out where specific feature implementations
belong... But, in general, Solum is working at a level above Heat.  To
write a Heat template, you have to know about infrastructure setup and
configuration settings of infrastructure and API services.  I believe
Solum intends to provide the ability to tweak and configure the amount of
complexity that gets exposed or hidden so that it becomes easier for cloud
consumers to just deal with their application and not have to necessarily
know or care about the underlying infrastructure and API services, but
that level of detail can be exposed to them if necessary. Solum will know
what infrastructure and services to set up to run applications, and it
will leverage Heat and Heat templates for this.

The Solum project has been very vocal about leveraging Heat under the hood
for the functionality and vision of orchestration that it intends to
provide.  It seems, based on this thread (and +1 from me), enough people
are interested in having Heat provide some level of software
orchestration, even if it's just bootstrapping other CM tools and
coordinating the "when are you done", and I haven't heard any Solum folks
object to Heat implementing software orchestration capabilities... So, I'm
looking forward to great discussions on this topic for Heat at the summit.
 If you recall, Adrian Otto (who announced project Solum) was also the one
who was vocal at the Portland summit about the need for HOT syntax.  I
think both projects are on a good path with a lot of fun collaboration
time ahead.

Kind regards,
-Keith

On 10/24/13 7:56 AM, "Thomas Spatzier"  wrote:

>Hi all,
>
>maybe a bit off track with respect to latest concrete discussions, but I
>noticed the announcement of project "Solum" on openstack-dev.
>Maybe this is playing on a different level, but I still see some relation
>to all the software orchestration we are having. What are your opinions on
>this?
>
>BTW, I just posted a similar short question in reply to the Solum
>announcement mail, but some of us have mail filters an might read [Heat]
>mail with higher prio, and I was interested in the Heat view.
>
>Cheers,
>Thomas
>
>Patrick Petit  wrote on 24.10.2013 12:15:13:
>> From: Patrick Petit 
>> To: OpenStack Development Mailing List
>,
>> Date: 24.10.2013 12:18
>> Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
>>
>> Sorry, I clicked the 'send' button too quickly.
>>
>> On 10/24/13 11:54 AM, Patrick Petit wrote:
>> > Hi Clint,
>> > Thank you! I have few replies/questions in-line.
>> > Cheers,
>> > Patrick
>> > On 10/23/13 8:36 PM, Clint Byrum wrote:
>> >> Excerpts from Patrick Petit's message of 2013-10-23 10:58:22 -0700:
>> >>> Dear Steve and All,
>> >>>
>> >>> If I may add up on this already busy thread to share our experience
>> >>> with
>> >>> using Heat in large and complex software deployments.
>> >>>
>> >> Thanks for sharing Patrick, I have a few replies in-line.
>> >>
>> >>> I work on a project which precisely provides additional value at the
>> >>> articulation point between resource orchestration automation and
>> >>> configuration management. We rely on Heat and chef-solo respectively
>> >>> for
>> >>> these base management functions. On top of this, we have developed
>>an
>> >>> event-driven workflow to manage the life-cycles of complex software
>> >>> stacks which primary purpose is to support middleware components as
>> >>> opposed to end-user apps. Our use cases are peculiar in the sense
>that
>> >>> software setup (install, config, contextualization) is not a
>>one-time
>> >>> operation issue but a continuous thing that can happen any time in
>> >>> life-span of a stack. Users can deploy (and undeploy) apps long time
>> >>> after the stack is created. Auto-scaling may also result in an
>> >>> asynchronous apps deployment. More about this latter. The framework
>we
>> >>> have designed works well for us. It clearly refers to a PaaS-like
>> >>> environment which I understand is not the topic of the HOT software
>> >>> configuration proposal(s) and that's absolutely fine with us.
>However,
>> >>> the question for us is whether the separation of software config
>>from
>> >>> resources would make our life easier or not. I think the answer is
>> >>> defin

Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-24 Thread Thomas Spatzier
Hi all,

maybe a bit off track with respect to latest concrete discussions, but I
noticed the announcement of project "Solum" on openstack-dev.
Maybe this is playing on a different level, but I still see some relation
to all the software orchestration we are having. What are your opinions on
this?

BTW, I just posted a similar short question in reply to the Solum
announcement mail, but some of us have mail filters an might read [Heat]
mail with higher prio, and I was interested in the Heat view.

Cheers,
Thomas

Patrick Petit  wrote on 24.10.2013 12:15:13:
> From: Patrick Petit 
> To: OpenStack Development Mailing List
,
> Date: 24.10.2013 12:18
> Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
>
> Sorry, I clicked the 'send' button too quickly.
>
> On 10/24/13 11:54 AM, Patrick Petit wrote:
> > Hi Clint,
> > Thank you! I have few replies/questions in-line.
> > Cheers,
> > Patrick
> > On 10/23/13 8:36 PM, Clint Byrum wrote:
> >> Excerpts from Patrick Petit's message of 2013-10-23 10:58:22 -0700:
> >>> Dear Steve and All,
> >>>
> >>> If I may add up on this already busy thread to share our experience
> >>> with
> >>> using Heat in large and complex software deployments.
> >>>
> >> Thanks for sharing Patrick, I have a few replies in-line.
> >>
> >>> I work on a project which precisely provides additional value at the
> >>> articulation point between resource orchestration automation and
> >>> configuration management. We rely on Heat and chef-solo respectively
> >>> for
> >>> these base management functions. On top of this, we have developed an
> >>> event-driven workflow to manage the life-cycles of complex software
> >>> stacks which primary purpose is to support middleware components as
> >>> opposed to end-user apps. Our use cases are peculiar in the sense
that
> >>> software setup (install, config, contextualization) is not a one-time
> >>> operation issue but a continuous thing that can happen any time in
> >>> life-span of a stack. Users can deploy (and undeploy) apps long time
> >>> after the stack is created. Auto-scaling may also result in an
> >>> asynchronous apps deployment. More about this latter. The framework
we
> >>> have designed works well for us. It clearly refers to a PaaS-like
> >>> environment which I understand is not the topic of the HOT software
> >>> configuration proposal(s) and that's absolutely fine with us.
However,
> >>> the question for us is whether the separation of software config from
> >>> resources would make our life easier or not. I think the answer is
> >>> definitely yes but at the condition that the DSL extension preserves
> >>> almost everything from the expressiveness of the resource element. In
> >>> practice, I think that a strict separation between resource and
> >>> component will be hard to achieve because we'll always need a little
> >>> bit
> >>> of application's specific in the resources. Take for example the
> >>> case of
> >>> the SecurityGroups. The ports open in a SecurityGroup are application
> >>> specific.
> >>>
> >> Components can only be made up of the things that are common to all
> >> users
> >> of said component. Also components would, if I understand the concept
> >> correctly, just be for things that are at the sub-resource level.
> >> Security groups and open ports would be across multiple resources, and
> >> thus would be separately specified from your app's component (though
it
> >> might be useful to allow components to export static values so that
the
> >> port list can be referred to along with the app component).
> Okay got it. If that's the case then that would work
> >>
> >>> Then, designing a Chef or Puppet component type may be harder than it
> >>> looks at first glance. Speaking of our use cases we still need a
little
> >>> bit of scripting in the instance's user-data block to setup a working
> >>> chef-solo environment. For example, we run librarian-chef prior to
> >>> starting chef-solo to resolve the cookbook dependencies. A cookbook
can
> >>> present itself as a downloadable tarball but it's not always the
> >>> case. A
> >>> chef component type would have to support getting a cookbook from a
> >>> public or private git repo (maybe subversion), handle situations

Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-24 Thread Patrick Petit

Sorry, I clicked the 'send' button too quickly.

On 10/24/13 11:54 AM, Patrick Petit wrote:

Hi Clint,
Thank you! I have few replies/questions in-line.
Cheers,
Patrick
On 10/23/13 8:36 PM, Clint Byrum wrote:

Excerpts from Patrick Petit's message of 2013-10-23 10:58:22 -0700:

Dear Steve and All,

If I may add up on this already busy thread to share our experience 
with

using Heat in large and complex software deployments.


Thanks for sharing Patrick, I have a few replies in-line.


I work on a project which precisely provides additional value at the
articulation point between resource orchestration automation and
configuration management. We rely on Heat and chef-solo respectively 
for

these base management functions. On top of this, we have developed an
event-driven workflow to manage the life-cycles of complex software
stacks which primary purpose is to support middleware components as
opposed to end-user apps. Our use cases are peculiar in the sense that
software setup (install, config, contextualization) is not a one-time
operation issue but a continuous thing that can happen any time in
life-span of a stack. Users can deploy (and undeploy) apps long time
after the stack is created. Auto-scaling may also result in an
asynchronous apps deployment. More about this latter. The framework we
have designed works well for us. It clearly refers to a PaaS-like
environment which I understand is not the topic of the HOT software
configuration proposal(s) and that's absolutely fine with us. However,
the question for us is whether the separation of software config from
resources would make our life easier or not. I think the answer is
definitely yes but at the condition that the DSL extension preserves
almost everything from the expressiveness of the resource element. In
practice, I think that a strict separation between resource and
component will be hard to achieve because we'll always need a little 
bit
of application's specific in the resources. Take for example the 
case of

the SecurityGroups. The ports open in a SecurityGroup are application
specific.

Components can only be made up of the things that are common to all 
users

of said component. Also components would, if I understand the concept
correctly, just be for things that are at the sub-resource level.
Security groups and open ports would be across multiple resources, and
thus would be separately specified from your app's component (though it
might be useful to allow components to export static values so that the
port list can be referred to along with the app component).

Okay got it. If that's the case then that would work



Then, designing a Chef or Puppet component type may be harder than it
looks at first glance. Speaking of our use cases we still need a little
bit of scripting in the instance's user-data block to setup a working
chef-solo environment. For example, we run librarian-chef prior to
starting chef-solo to resolve the cookbook dependencies. A cookbook can
present itself as a downloadable tarball but it's not always the 
case. A

chef component type would have to support getting a cookbook from a
public or private git repo (maybe subversion), handle situations where
there is one cookbook per repo or multiple cookbooks per repo, let the
user choose a particular branch or label, provide ssh keys if it's a
private repo, and so forth. We support all of this scenarios and so we
can provide more detailed requirements if needed.

Correct me if I'm wrong though, all of those scenarios are just 
variations

on standard inputs into chef. So the chef component really just has to
allow a way to feed data to chef.


That's correct. Boils down to specifying correctly all the constraints 
that apply to deploying a cookbook in an instance from it's component 
description.



I am not sure adding component relations like the 'depends-on' would
really help us since it is the job of config management to handle
software dependencies. Also, it doesn't address the issue of circular
dependencies. Circular dependencies occur in complex software stack
deployments. Example. When we setup a Slum virtual cluster, both the
head node and compute nodes depend on one another to complete their
configuration and so they would wait for each other indefinitely if we
were to rely on the 'depends-on'. In addition, I think it's critical to
distinguish between configuration parameters which are known ahead of
time, like a db name or user name and password, versus 
contextualization
parameters which are known after the fact generally when the 
instance is

created. Typically those contextualization parameters are IP addresses
but not only. The fact packages x,y,z have been properly installed and
services a,b,c successfully started is contextualization information
(a.k.a facts) which may be indicative that other components can move on
to the next setup stage.


The form of contextualization you mention above can be handled by a
slightly more capable wait condition me

Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-24 Thread Patrick Petit

Hi Clint,
Thank you! I have few replies/questions in-line.
Cheers,
Patrick
On 10/23/13 8:36 PM, Clint Byrum wrote:

Excerpts from Patrick Petit's message of 2013-10-23 10:58:22 -0700:

Dear Steve and All,

If I may add up on this already busy thread to share our experience with
using Heat in large and complex software deployments.


Thanks for sharing Patrick, I have a few replies in-line.


I work on a project which precisely provides additional value at the
articulation point between resource orchestration automation and
configuration management. We rely on Heat and chef-solo respectively for
these base management functions. On top of this, we have developed an
event-driven workflow to manage the life-cycles of complex software
stacks which primary purpose is to support middleware components as
opposed to end-user apps. Our use cases are peculiar in the sense that
software setup (install, config, contextualization) is not a one-time
operation issue but a continuous thing that can happen any time in
life-span of a stack. Users can deploy (and undeploy) apps long time
after the stack is created. Auto-scaling may also result in an
asynchronous apps deployment. More about this latter. The framework we
have designed works well for us. It clearly refers to a PaaS-like
environment which I understand is not the topic of the HOT software
configuration proposal(s) and that's absolutely fine with us. However,
the question for us is whether the separation of software config from
resources would make our life easier or not. I think the answer is
definitely yes but at the condition that the DSL extension preserves
almost everything from the expressiveness of the resource element. In
practice, I think that a strict separation between resource and
component will be hard to achieve because we'll always need a little bit
of application's specific in the resources. Take for example the case of
the SecurityGroups. The ports open in a SecurityGroup are application
specific.


Components can only be made up of the things that are common to all users
of said component. Also components would, if I understand the concept
correctly, just be for things that are at the sub-resource level.

That isn't cop

Security groups and open ports would be across multiple resources, and
thus would be separately specified from your app's component (though it
might be useful to allow components to export static values so that the
port list can be referred to along with the app component).


Then, designing a Chef or Puppet component type may be harder than it
looks at first glance. Speaking of our use cases we still need a little
bit of scripting in the instance's user-data block to setup a working
chef-solo environment. For example, we run librarian-chef prior to
starting chef-solo to resolve the cookbook dependencies. A cookbook can
present itself as a downloadable tarball but it's not always the case. A
chef component type would have to support getting a cookbook from a
public or private git repo (maybe subversion), handle situations where
there is one cookbook per repo or multiple cookbooks per repo, let the
user choose a particular branch or label, provide ssh keys if it's a
private repo, and so forth. We support all of this scenarios and so we
can provide more detailed requirements if needed.


Correct me if I'm wrong though, all of those scenarios are just variations
on standard inputs into chef. So the chef component really just has to
allow a way to feed data to chef.





I am not sure adding component relations like the 'depends-on' would
really help us since it is the job of config management to handle
software dependencies. Also, it doesn't address the issue of circular
dependencies. Circular dependencies occur in complex software stack
deployments. Example. When we setup a Slum virtual cluster, both the
head node and compute nodes depend on one another to complete their
configuration and so they would wait for each other indefinitely if we
were to rely on the 'depends-on'. In addition, I think it's critical to
distinguish between configuration parameters which are known ahead of
time, like a db name or user name and password, versus contextualization
parameters which are known after the fact generally when the instance is
created. Typically those contextualization parameters are IP addresses
but not only. The fact packages x,y,z have been properly installed and
services a,b,c successfully started is contextualization information
(a.k.a facts) which may be indicative that other components can move on
to the next setup stage.


The form of contextualization you mention above can be handled by a
slightly more capable wait condition mechanism than we have now. I've
been suggesting that this is the interface that workflow systems should
use.


The case of complex deployments with or without circular dependencies is
typically resolved by making the system converge toward the desirable
end-state through running idempotent recipes. This i

Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-24 Thread Patrick Petit

Hello Stan,
Please see comments inline.
Cheers,
Patrick
On 10/23/13 8:33 PM, Stan Lagun wrote:

Hi Patric,

Thank you for such great post! This is very close to the vision I've 
tried to propose earlier on software orchestration thread and I'm glad 
other people concern about the same issues. However the problem the 
problem with PaaS-like approached it that they currently on a little 
bit higher abstraction layer than Heat is intended to be. Typical Heat 
users are more of DevOps people rather than those who enjoy 
PaaS-related solutions. Going that direction would require some major 
paradigm shift for the Heat which I think is unnecessary.
Okay. But don't get me wrong. I am not militating for embarking 
PaaS-like capabilities into Heat. Far from it. There are two basic 
reasons for that. There are to many ways of approaching the PaaS 
endeavor and that would kill innovation for those who are trying to 
build value atop of OpenStack/Heat like ourselves. Even though we are 
DevOps the intent is that our users don't have to be since we provide 
them with built-in middleware stacks covering some verticals 
(high-performance computing related) that power users can leverage 
out-of-the-box to deploy their own apps. So, I guess what I intended to 
say is; let's try to keep it lean. Do not over engineer this thing with 
nuts and bolts allover the place because Heat is and will be 
increasingly used in completely unexpected ways.


I believe there is a place in OpenStack software-orchestration 
ecosystem for layers that would sin on top of Heat and provide more 
high-level services for software composition, dependency management. 
Heat is not aimed to be software-everything. I would suggest you to 
take a look at Murano project as it is very very close to what you 
want to achieve and as every open-source project it needs community 
contributions. And I believe that it is the place in OpenStack 
ecosystem where your expirience would be most valuable and appreciated 
as well as your contributions
Thank you for the invitation! We also welcome you to work with us on the 
XLcloud project which is also open-source Apache V2 project. Java-based 
though. Nobody is perfect ;-). More seriously we are thinking of moving 
the code to github and apply for incubation eventually making the 
OpenStack community become bigger and richer by joining in with the Java 
community :-)


The code
http://gitorious.ow2.org/xlcloud
A beginning of user documentation can be found here:
https://129.184.11.121:8443/display/XGM/XLcloud+Guides+and+Manuals+Home




On Wed, Oct 23, 2013 at 9:58 PM, Patrick Petit > wrote:


Dear Steve and All,

If I may add up on this already busy thread to share our
experience with using Heat in large and complex software deployments.

I work on a project which precisely provides additional value at
the articulation point between resource orchestration automation
and configuration management. We rely on Heat and chef-solo
respectively for these base management functions. On top of this,
we have developed an event-driven workflow to manage the
life-cycles of complex software stacks which primary purpose is to
support middleware components as opposed to end-user apps. Our use
cases are peculiar in the sense that software setup (install,
config, contextualization) is not a one-time operation issue but a
continuous thing that can happen any time in life-span of a stack.
Users can deploy (and undeploy) apps long time after the stack is
created. Auto-scaling may also result in an asynchronous apps
deployment. More about this latter. The framework we have designed
works well for us. It clearly refers to a PaaS-like environment
which I understand is not the topic of the HOT software
configuration proposal(s) and that's absolutely fine with us.
However, the question for us is whether the separation of software
config from resources would make our life easier or not. I think
the answer is definitely yes but at the condition that the DSL
extension preserves almost everything from the expressiveness of
the resource element. In practice, I think that a strict
separation between resource and component will be hard to achieve
because we'll always need a little bit of application's specific
in the resources. Take for example the case of the SecurityGroups.
The ports open in a SecurityGroup are application specific.

Then, designing a Chef or Puppet component type may be harder than
it looks at first glance. Speaking of our use cases we still need
a little bit of scripting in the instance's user-data block to
setup a working chef-solo environment. For example, we run
librarian-chef prior to starting chef-solo to resolve the cookbook
dependencies. A cookbook can present itself as a downloadable
tarball but it's not always the case. A chef component type would
 

Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-23 Thread Georgy Okrokvertskhov
Hi,

Looking through the thread I mentioned couple definitions of software
orchestration. I would like to summarize definitions before we go to deep
technical discussion about actual implementation.


There are two major areas and approaches covered by software orchestration:


*Software component installation* - aimed to install specific software
component to VM and configure it. This is a typical task for Heat. HOT
component is a best way to easily describe what component should be
installed and what are configuration parameter. Heat engine will figure out
by itself how to do this, probably with some hints from a user in terms of
dependencies and placement rules.


*Software service installation and life cycle management* - aimed to
provision a complex multi component software service over multiple VMs.
Also defines actions on specific events and manages software over the
entire environment life. This approach is closer to PaaS like solution and
relies on specific workflows sequences defined for different events and
situations. Instead of defining what should be installed, this approach
defines how to react on specific situation and what to do if some event has
been triggered. This workflow approach is what is covered by Mistral
project from the engine viewpoint. Mistral is going to orchestrate task
execution in distributed fashion on both VM and OpenStack levels and it has
events and schedule semantics. Actual workflow implementation for OpenStack
may be found in Murano project which already defines different workflows
for software installation and configuration depending on situation.


As I see, both approaches have their own user, and both approaches can
coexist in OpenStack ecosystem being complementary to each other. For
example workflow can generate HOT template to do some task which fits best
to Heat engine and in the same time HOT template can reference external
workflow to do the task which fits best to workflow approach.


Thanks
Georgy


On Wed, Oct 23, 2013 at 11:36 AM, Clint Byrum  wrote:
>
> Excerpts from Patrick Petit's message of 2013-10-23 10:58:22 -0700:
> > Dear Steve and All,
> >
> > If I may add up on this already busy thread to share our experience with
> > using Heat in large and complex software deployments.
> >
>
> Thanks for sharing Patrick, I have a few replies in-line.
>
> > I work on a project which precisely provides additional value at the
> > articulation point between resource orchestration automation and
> > configuration management. We rely on Heat and chef-solo respectively for
> > these base management functions. On top of this, we have developed an
> > event-driven workflow to manage the life-cycles of complex software
> > stacks which primary purpose is to support middleware components as
> > opposed to end-user apps. Our use cases are peculiar in the sense that
> > software setup (install, config, contextualization) is not a one-time
> > operation issue but a continuous thing that can happen any time in
> > life-span of a stack. Users can deploy (and undeploy) apps long time
> > after the stack is created. Auto-scaling may also result in an
> > asynchronous apps deployment. More about this latter. The framework we
> > have designed works well for us. It clearly refers to a PaaS-like
> > environment which I understand is not the topic of the HOT software
> > configuration proposal(s) and that's absolutely fine with us. However,
> > the question for us is whether the separation of software config from
> > resources would make our life easier or not. I think the answer is
> > definitely yes but at the condition that the DSL extension preserves
> > almost everything from the expressiveness of the resource element. In
> > practice, I think that a strict separation between resource and
> > component will be hard to achieve because we'll always need a little bit
> > of application's specific in the resources. Take for example the case of
> > the SecurityGroups. The ports open in a SecurityGroup are application
> > specific.
> >
>
> Components can only be made up of the things that are common to all users
> of said component. Also components would, if I understand the concept
> correctly, just be for things that are at the sub-resource level.
> Security groups and open ports would be across multiple resources, and
> thus would be separately specified from your app's component (though it
> might be useful to allow components to export static values so that the
> port list can be referred to along with the app component).
>
> > Then, designing a Chef or Puppet component type may be harder than it
> > looks at first glance. Speaking of our use cases we still need a little
> > bit of scripting in the instance's user-data block to setup a working
> > chef-solo environment. For example, we run librarian-chef prior to
> > starting chef-solo to resolve the cookbook dependencies. A cookbook can
> > present itself as a downloadable tarball but it's not always the case. A
> > chef c

Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-23 Thread Stan Lagun
Hi Patric,

Thank you for such great post! This is very close to the vision I've tried
to propose earlier on software orchestration thread and I'm glad other
people concern about the same issues. However the problem the problem with
PaaS-like approached it that they currently on a little bit higher
abstraction layer than Heat is intended to be. Typical Heat users are more
of DevOps people rather than those who enjoy PaaS-related solutions. Going
that direction would require some major paradigm shift for the Heat which I
think is unnecessary.

I believe there is a place in OpenStack software-orchestration ecosystem
for layers that would sin on top of Heat and provide more high-level
services for software composition, dependency management. Heat is not aimed
to be software-everything. I would suggest you to take a look at Murano
project as it is very very close to what you want to achieve and as every
open-source project it needs community contributions. And I believe that it
is the place in OpenStack ecosystem where your expirience would be most
valuable and appreciated as well as your contributions


On Wed, Oct 23, 2013 at 9:58 PM, Patrick Petit wrote:

>  Dear Steve and All,
>
> If I may add up on this already busy thread to share our experience with
> using Heat in large and complex software deployments.
>
> I work on a project which precisely provides additional value at the
> articulation point between resource orchestration automation and
> configuration management. We rely on Heat and chef-solo respectively for
> these base management functions. On top of this, we have developed an
> event-driven workflow to manage the life-cycles of complex software stacks
> which primary purpose is to support middleware components as opposed to
> end-user apps. Our use cases are peculiar in the sense that software setup
> (install, config, contextualization) is not a one-time operation issue but
> a continuous thing that can happen any time in life-span of a stack. Users
> can deploy (and undeploy) apps long time after the stack is created.
> Auto-scaling may also result in an asynchronous apps deployment. More about
> this latter. The framework we have designed works well for us. It clearly
> refers to a PaaS-like environment which I understand is not the topic of
> the HOT software configuration proposal(s) and that's absolutely fine with
> us. However, the question for us is whether the separation of software
> config from resources would make our life easier or not. I think the answer
> is definitely yes but at the condition that the DSL extension preserves
> almost everything from the expressiveness of the resource element. In
> practice, I think that a strict separation between resource and component
> will be hard to achieve because we'll always need a little bit of
> application's specific in the resources. Take for example the case of the
> SecurityGroups. The ports open in a SecurityGroup are application specific.
>
> Then, designing a Chef or Puppet component type may be harder than it
> looks at first glance. Speaking of our use cases we still need a little bit
> of scripting in the instance's user-data block to setup a working chef-solo
> environment. For example, we run librarian-chef prior to starting chef-solo
> to resolve the cookbook dependencies. A cookbook can present itself as a
> downloadable tarball but it's not always the case. A chef component type
> would have to support getting a cookbook from a public or private git repo
> (maybe subversion), handle situations where there is one cookbook per repo
> or multiple cookbooks per repo, let the user choose a particular branch or
> label, provide ssh keys if it's a private repo, and so forth. We support
> all of this scenarios and so we can provide more detailed requirements if
> needed.
>
> I am not sure adding component relations like the 'depends-on' would
> really help us since it is the job of config management to handle software
> dependencies. Also, it doesn't address the issue of circular dependencies.
> Circular dependencies occur in complex software stack deployments. Example.
> When we setup a Slum virtual cluster, both the head node and compute nodes
> depend on one another to complete their configuration and so they would
> wait for each other indefinitely if we were to rely on the 'depends-on'. In
> addition, I think it's critical to distinguish between configuration
> parameters which are known ahead of time, like a db name or user name and
> password, versus contextualization parameters which are known after the
> fact generally when the instance is created. Typically those
> contextualization parameters are IP addresses but not only. The fact
> packages x,y,z have been properly installed and services a,b,c successfully
> started is contextualization information (a.k.a facts) which may be
> indicative that other components can move on to the next setup stage.
>
> The case of complex deployments with or without circular dependenc

Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-23 Thread Clint Byrum
Excerpts from Patrick Petit's message of 2013-10-23 10:58:22 -0700:
> Dear Steve and All,
> 
> If I may add up on this already busy thread to share our experience with 
> using Heat in large and complex software deployments.
> 

Thanks for sharing Patrick, I have a few replies in-line.

> I work on a project which precisely provides additional value at the 
> articulation point between resource orchestration automation and 
> configuration management. We rely on Heat and chef-solo respectively for 
> these base management functions. On top of this, we have developed an 
> event-driven workflow to manage the life-cycles of complex software 
> stacks which primary purpose is to support middleware components as 
> opposed to end-user apps. Our use cases are peculiar in the sense that 
> software setup (install, config, contextualization) is not a one-time 
> operation issue but a continuous thing that can happen any time in 
> life-span of a stack. Users can deploy (and undeploy) apps long time 
> after the stack is created. Auto-scaling may also result in an 
> asynchronous apps deployment. More about this latter. The framework we 
> have designed works well for us. It clearly refers to a PaaS-like 
> environment which I understand is not the topic of the HOT software 
> configuration proposal(s) and that's absolutely fine with us. However, 
> the question for us is whether the separation of software config from 
> resources would make our life easier or not. I think the answer is 
> definitely yes but at the condition that the DSL extension preserves 
> almost everything from the expressiveness of the resource element. In 
> practice, I think that a strict separation between resource and 
> component will be hard to achieve because we'll always need a little bit 
> of application's specific in the resources. Take for example the case of 
> the SecurityGroups. The ports open in a SecurityGroup are application 
> specific.
>

Components can only be made up of the things that are common to all users
of said component. Also components would, if I understand the concept
correctly, just be for things that are at the sub-resource level.
Security groups and open ports would be across multiple resources, and
thus would be separately specified from your app's component (though it
might be useful to allow components to export static values so that the
port list can be referred to along with the app component).

> Then, designing a Chef or Puppet component type may be harder than it 
> looks at first glance. Speaking of our use cases we still need a little 
> bit of scripting in the instance's user-data block to setup a working 
> chef-solo environment. For example, we run librarian-chef prior to 
> starting chef-solo to resolve the cookbook dependencies. A cookbook can 
> present itself as a downloadable tarball but it's not always the case. A 
> chef component type would have to support getting a cookbook from a 
> public or private git repo (maybe subversion), handle situations where 
> there is one cookbook per repo or multiple cookbooks per repo, let the 
> user choose a particular branch or label, provide ssh keys if it's a 
> private repo, and so forth. We support all of this scenarios and so we 
> can provide more detailed requirements if needed.
>

Correct me if I'm wrong though, all of those scenarios are just variations
on standard inputs into chef. So the chef component really just has to
allow a way to feed data to chef.

> I am not sure adding component relations like the 'depends-on' would 
> really help us since it is the job of config management to handle 
> software dependencies. Also, it doesn't address the issue of circular 
> dependencies. Circular dependencies occur in complex software stack 
> deployments. Example. When we setup a Slum virtual cluster, both the 
> head node and compute nodes depend on one another to complete their 
> configuration and so they would wait for each other indefinitely if we 
> were to rely on the 'depends-on'. In addition, I think it's critical to 
> distinguish between configuration parameters which are known ahead of 
> time, like a db name or user name and password, versus contextualization 
> parameters which are known after the fact generally when the instance is 
> created. Typically those contextualization parameters are IP addresses 
> but not only. The fact packages x,y,z have been properly installed and 
> services a,b,c successfully started is contextualization information 
> (a.k.a facts) which may be indicative that other components can move on 
> to the next setup stage.
> 

The form of contextualization you mention above can be handled by a
slightly more capable wait condition mechanism than we have now. I've
been suggesting that this is the interface that workflow systems should
use.

> The case of complex deployments with or without circular dependencies is 
> typically resolved by making the system converge toward the desirable 
> end-state through 

Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-23 Thread Patrick Petit

Dear Steve and All,

If I may add up on this already busy thread to share our experience with 
using Heat in large and complex software deployments.


I work on a project which precisely provides additional value at the 
articulation point between resource orchestration automation and 
configuration management. We rely on Heat and chef-solo respectively for 
these base management functions. On top of this, we have developed an 
event-driven workflow to manage the life-cycles of complex software 
stacks which primary purpose is to support middleware components as 
opposed to end-user apps. Our use cases are peculiar in the sense that 
software setup (install, config, contextualization) is not a one-time 
operation issue but a continuous thing that can happen any time in 
life-span of a stack. Users can deploy (and undeploy) apps long time 
after the stack is created. Auto-scaling may also result in an 
asynchronous apps deployment. More about this latter. The framework we 
have designed works well for us. It clearly refers to a PaaS-like 
environment which I understand is not the topic of the HOT software 
configuration proposal(s) and that's absolutely fine with us. However, 
the question for us is whether the separation of software config from 
resources would make our life easier or not. I think the answer is 
definitely yes but at the condition that the DSL extension preserves 
almost everything from the expressiveness of the resource element. In 
practice, I think that a strict separation between resource and 
component will be hard to achieve because we'll always need a little bit 
of application's specific in the resources. Take for example the case of 
the SecurityGroups. The ports open in a SecurityGroup are application 
specific.


Then, designing a Chef or Puppet component type may be harder than it 
looks at first glance. Speaking of our use cases we still need a little 
bit of scripting in the instance's user-data block to setup a working 
chef-solo environment. For example, we run librarian-chef prior to 
starting chef-solo to resolve the cookbook dependencies. A cookbook can 
present itself as a downloadable tarball but it's not always the case. A 
chef component type would have to support getting a cookbook from a 
public or private git repo (maybe subversion), handle situations where 
there is one cookbook per repo or multiple cookbooks per repo, let the 
user choose a particular branch or label, provide ssh keys if it's a 
private repo, and so forth. We support all of this scenarios and so we 
can provide more detailed requirements if needed.


I am not sure adding component relations like the 'depends-on' would 
really help us since it is the job of config management to handle 
software dependencies. Also, it doesn't address the issue of circular 
dependencies. Circular dependencies occur in complex software stack 
deployments. Example. When we setup a Slum virtual cluster, both the 
head node and compute nodes depend on one another to complete their 
configuration and so they would wait for each other indefinitely if we 
were to rely on the 'depends-on'. In addition, I think it's critical to 
distinguish between configuration parameters which are known ahead of 
time, like a db name or user name and password, versus contextualization 
parameters which are known after the fact generally when the instance is 
created. Typically those contextualization parameters are IP addresses 
but not only. The fact packages x,y,z have been properly installed and 
services a,b,c successfully started is contextualization information 
(a.k.a facts) which may be indicative that other components can move on 
to the next setup stage.


The case of complex deployments with or without circular dependencies is 
typically resolved by making the system converge toward the desirable 
end-state through running idempotent recipes. This is our approach. The 
first configuration phase handles parametrization which in general 
brings an instance to CREATE_COMPLETE state. A second phase follows to 
handle contextualization at the stack level. As a matter of fact, a new 
contextualization should be triggered every time an instance enters or 
leave the CREATE_COMPLETE state which may happen any time with 
auto-scaling. In that phase, circular dependencies can be resolved 
because all contextualization data can be compiled globally. Notice that 
Heat doesn't provide a purpose built resource or service like Chef's 
data-bag for the storage and retrieval of metadata. This a gap which IMO 
should be addressed in the proposal. Currently, we use a kludge that is 
to create a fake AWS::AutoScaling::LaunchConfiguration resource to store 
contextualization data in the metadata section of that resource.


Aside from the HOT software configuration proposal(s). There are two 
critical enhancements in Heat that would make software life-cycles 
management much easier. In fact, they are actual blockers for us.


The first one would be 

Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-23 Thread Clint Byrum
Excerpts from Thomas Spatzier's message of 2013-10-23 00:08:23 -0700:
> Clint Byrum  wrote on 23.10.2013 00:28:17:
> > From: Clint Byrum 
> > To: openstack-dev ,
> > Date: 23.10.2013 00:30
> > Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
> >
> > Excerpts from Georgy Okrokvertskhov's message of 2013-10-22 13:32:40
> -0700:
> > > Hi Thomas,
> > >
> > > I agree with you on semantics part. At the same time I see a potential
> > > question which might appear - if semantics is limited by few states
> visible
> > > for Heat engine, then who actually does software orchestration?
> > > Will it be reasonable then to have software orchestration as separate
> > > subproject for Heat as a part of "Orchestration" OpenStack program?
> Heat
> > > engine will then do dependency tracking and will use components as a
> > > reference for software orchestration engine which will perform actual
> > > deployment and high level software components coordination.
> > >
> > > This separated software orchestration engine may address all specific
> > > requirements proposed by different teams in this thread without
> affecting
> > > existing Heat engine.
> > >
> >
> > I'm not sure I know what "software orchestration" is, but I will take a
> > stab at a succinct definition:
> >
> > Coordination of software configuration across multiple hosts.
> >
> > If that is what you mean, then I believe what you actually want is
> > workflow. And for that, we have the Mistral project which was recently
> > announced [1].
> 
> My view of "software orchestration" in a sense of what Heat should be able
> to do is being able to bring up software installations (e.g. web server, a
> DBMS, a custom application) on-top of a bare compute resource by invoking a
> software config tool (e.g. Chef, Puppet ...) at the right point in time and
> let that tool do the actual work.
> Invoke does not necessarily mean to call an API of such a tool, but rather
> make sure it is bootstrapped and maybe gets a "go" signal to start.
> "software orchestration" could then further mean to give CM tools across
> hosts the "go" signal when the config on one host has completed. This be
> enabled by the signaling enhancements Steve Baker mentioned in one of his
> recent mails.
> 
> For such kind of stuff, I think we could live without workflows but do it
> purely declaratively. Of course, a workflow could be the underlying
> mechanism, but I would not want to express this in a template. If users
> have very complex problems to solve and cannot live with the simple
> software orchestration I outlined, then still a workflow could be used for
> everying on-top of the OS.
> 
> Anyway, that was just my view and others most probably have different views
> again, so seems like we really have to sort out terminology :-)
> 

Right, we can do a lot without any external workflow help. We may be
able to do basically everything without external workflow help, however
I want to make sure that users have a well defined method for solving
their problems before Heat has a way to declaratively solve them.

> >
> > Use that and you will simply need to define your desired workflow and
> > feed it into Mistral using a Mistral Heat resource. We can create a
> > nice bootstrapping resource for Heat instances that shims the mistral
> > workflow execution agent into machines (or lets us use one already there
> > via custom images).
> >
> > I can imagine it working something like this:
> >
> > resources:
> >   mistral_workflow_handle:
> > type: OS::Mistral::WorkflowHandle
> >   web_server:
> > type: OS::Nova::Server
> > components:
> >   mistral_agent:
> > component_type: mistral
> > params:
> >   workflow_: {ref: mistral_workflow_handle}
> >   mysql_server:
> > type: OS::Nova::Server
> > components:
> >   mistral_agent:
> > component_type: mistral
> > params:
> >   workflow_handle: {ref: mistral_workflow_handle}
> >   mistral_workflow:
> > type: OS::Mistral::Workflow
> > properties:
> >   handle: {ref: mistral_workflow_handle}
> >   workflow_reference: mysql_webapp_workflow
> >   params:
> > mysql_server: {ref: mysql_server}
> > webserver: {ref: web_server}
> >
> 
> While I can imagine that this works, I think for a big percentage of use
> cases I would be nice to avoid this

Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-23 Thread Thomas Spatzier
Clint Byrum  wrote on 23.10.2013 00:28:17:
> From: Clint Byrum 
> To: openstack-dev ,
> Date: 23.10.2013 00:30
> Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
>
> Excerpts from Georgy Okrokvertskhov's message of 2013-10-22 13:32:40
-0700:
> > Hi Thomas,
> >
> > I agree with you on semantics part. At the same time I see a potential
> > question which might appear - if semantics is limited by few states
visible
> > for Heat engine, then who actually does software orchestration?
> > Will it be reasonable then to have software orchestration as separate
> > subproject for Heat as a part of "Orchestration" OpenStack program?
Heat
> > engine will then do dependency tracking and will use components as a
> > reference for software orchestration engine which will perform actual
> > deployment and high level software components coordination.
> >
> > This separated software orchestration engine may address all specific
> > requirements proposed by different teams in this thread without
affecting
> > existing Heat engine.
> >
>
> I'm not sure I know what "software orchestration" is, but I will take a
> stab at a succinct definition:
>
> Coordination of software configuration across multiple hosts.
>
> If that is what you mean, then I believe what you actually want is
> workflow. And for that, we have the Mistral project which was recently
> announced [1].

My view of "software orchestration" in a sense of what Heat should be able
to do is being able to bring up software installations (e.g. web server, a
DBMS, a custom application) on-top of a bare compute resource by invoking a
software config tool (e.g. Chef, Puppet ...) at the right point in time and
let that tool do the actual work.
Invoke does not necessarily mean to call an API of such a tool, but rather
make sure it is bootstrapped and maybe gets a "go" signal to start.
"software orchestration" could then further mean to give CM tools across
hosts the "go" signal when the config on one host has completed. This be
enabled by the signaling enhancements Steve Baker mentioned in one of his
recent mails.

For such kind of stuff, I think we could live without workflows but do it
purely declaratively. Of course, a workflow could be the underlying
mechanism, but I would not want to express this in a template. If users
have very complex problems to solve and cannot live with the simple
software orchestration I outlined, then still a workflow could be used for
everying on-top of the OS.

Anyway, that was just my view and others most probably have different views
again, so seems like we really have to sort out terminology :-)

>
> Use that and you will simply need to define your desired workflow and
> feed it into Mistral using a Mistral Heat resource. We can create a
> nice bootstrapping resource for Heat instances that shims the mistral
> workflow execution agent into machines (or lets us use one already there
> via custom images).
>
> I can imagine it working something like this:
>
> resources:
>   mistral_workflow_handle:
> type: OS::Mistral::WorkflowHandle
>   web_server:
> type: OS::Nova::Server
> components:
>   mistral_agent:
> component_type: mistral
> params:
>   workflow_: {ref: mistral_workflow_handle}
>   mysql_server:
> type: OS::Nova::Server
> components:
>   mistral_agent:
> component_type: mistral
> params:
>   workflow_handle: {ref: mistral_workflow_handle}
>   mistral_workflow:
> type: OS::Mistral::Workflow
> properties:
>   handle: {ref: mistral_workflow_handle}
>   workflow_reference: mysql_webapp_workflow
>   params:
> mysql_server: {ref: mysql_server}
> webserver: {ref: web_server}
>

While I can imagine that this works, I think for a big percentage of use
cases I would be nice to avoid this inter-weaving of workflow constructs
with a HOT template. I think we could do a purely declarative approach (if
we scope software orchestration in context of Heat right), and not define
such handles and references.
We are trying to shield this from the users in other cases in HOT
(WaitConditionHandle and references), so why introduce it here ...

>
> And then the workflow is just defined outside of the Heat template (ok
> I'm sure somebody will want to embed it, but I prefer stronger
> separation). Something like this gets uploaded as
> "mysql_webapp_workflow":
>
> [ 'step1': 'install_stuff',
>   'step2': 'wait(step1)',
>   'step3': 'allocate_sql_user(server=%mysql_server%)'
>   'step4': 'credentials=w

Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-22 Thread Georgy Okrokvertskhov
Hi,

>I guess then heat is mainly doing top-level orchestration, and then
mistral does the workflow middle-level, and >taskflow is (hopefully) at the
lowest-level??

You drove the right picture. I can not say who is top-level and who is
low-level orchestration. This is all gear wheels which should work all
together well to achieve the result while Het is probably the driving wheel
among them who makes sure that everything  is working.

Thanks
Georgy


On Tue, Oct 22, 2013 at 5:14 PM, Joshua Harlow wrote:

>  Ah,
>
>  Seems like a reasonable approach then :-)
>
>  I guess then heat is mainly doing top-level orchestration, and then
> mistral does the workflow middle-level, and taskflow is (hopefully) at the
> lowest-level??
>
>  Thanks Georgy!
>
>   From: Georgy Okrokvertskhov 
> Reply-To: OpenStack Development Mailing List <
> openstack-dev@lists.openstack.org>
> Date: Tuesday, October 22, 2013 4:53 PM
>
> To: OpenStack Development Mailing List 
> Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
>
>   Hi Joshua,
>
>  >Sounds like taskflow could be that program (+1 from me, ha)?
>
> >Mistral to me is a nice authenticated REST api + other goodies ontop of
> >something that reliably executes workflows.
>
>  I would say that Mistral is a way to do this. My arguments are the
> following:
> 1. Mistral decouples code. Heat can use API calls to invoke a workflows
> execution instead of linking with taskflow library in the code. This is
> standard SOA approach which OpenStack uses a lot.
> 2. Mistral will expose DSL to define tasks while taskflow will require
> python code for task definition.
>
>  Mistral itself uses taskflow library to execute workflows but Mistral in
> addition does parsing and translation from DSL task definition to actual
> python code.
>
>  Heat can use taskflow for other purposes but workflows execution is not
> a good reason for that. Just because of nature of workflows for deployment,
> there is no knowledge about workflow until end user uploads it, so you can
> not use taskflow itself and code this workflow in python without
> preliminary knowledge about workflow.
>
>  If Heat uses just taskflow it should do all the work on workflow parsing
> and translation to a code that Heat team wants to avoid. At least this is
> my understanding.
>
>  Thanks
> Georgy
>
>
>
> On Tue, Oct 22, 2013 at 4:34 PM, Joshua Harlow wrote:
>
>> Sounds like taskflow could be that program (+1 from me, ha)?
>>
>> Mistral to me is a nice authenticated REST api + other goodies ontop of
>> something that reliably executes workflows.
>>
>> But then what I described is also the majority of what openstack does
>> (authenticated REST api + other goodies ontop of VM/volume/network/...
>> workflows).
>>
>> On 10/22/13 3:28 PM, "Clint Byrum"  wrote:
>>
>> >Excerpts from Georgy Okrokvertskhov's message of 2013-10-22 13:32:40
>> >-0700:
>> >> Hi Thomas,
>> >>
>> >> I agree with you on semantics part. At the same time I see a potential
>> >> question which might appear - if semantics is limited by few states
>> >>visible
>> >> for Heat engine, then who actually does software orchestration?
>> >> Will it be reasonable then to have software orchestration as separate
>> >> subproject for Heat as a part of "Orchestration" OpenStack program?
>> Heat
>> >> engine will then do dependency tracking and will use components as a
>> >> reference for software orchestration engine which will perform actual
>> >> deployment and high level software components coordination.
>> >>
>> >> This separated software orchestration engine may address all specific
>> >> requirements proposed by different teams in this thread without
>> >>affecting
>> >> existing Heat engine.
>> >>
>> >
>> >I'm not sure I know what "software orchestration" is, but I will take a
>> >stab at a succinct definition:
>> >
>> >Coordination of software configuration across multiple hosts.
>> >
>> >If that is what you mean, then I believe what you actually want is
>> >workflow. And for that, we have the Mistral project which was recently
>> >announced [1].
>> >
>> >Use that and you will simply need to define your desired workflow and
>> >feed it into Mistral using a Mistral Heat resource. We can create a
>> >nice bootstrapping resource for Heat instances that shims the mistral
>> >workflow execution agent into machines (or l

Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-22 Thread Joshua Harlow
Ah,

Seems like a reasonable approach then :-)

I guess then heat is mainly doing top-level orchestration, and then mistral 
does the workflow middle-level, and taskflow is (hopefully) at the 
lowest-level??

Thanks Georgy!

From: Georgy Okrokvertskhov 
mailto:gokrokvertsk...@mirantis.com>>
Reply-To: OpenStack Development Mailing List 
mailto:openstack-dev@lists.openstack.org>>
Date: Tuesday, October 22, 2013 4:53 PM
To: OpenStack Development Mailing List 
mailto:openstack-dev@lists.openstack.org>>
Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal

Hi Joshua,

>Sounds like taskflow could be that program (+1 from me, ha)?

>Mistral to me is a nice authenticated REST api + other goodies ontop of
>something that reliably executes workflows.

I would say that Mistral is a way to do this. My arguments are the following:
1. Mistral decouples code. Heat can use API calls to invoke a workflows 
execution instead of linking with taskflow library in the code. This is 
standard SOA approach which OpenStack uses a lot.
2. Mistral will expose DSL to define tasks while taskflow will require python 
code for task definition.

Mistral itself uses taskflow library to execute workflows but Mistral in 
addition does parsing and translation from DSL task definition to actual python 
code.

Heat can use taskflow for other purposes but workflows execution is not a good 
reason for that. Just because of nature of workflows for deployment, there is 
no knowledge about workflow until end user uploads it, so you can not use 
taskflow itself and code this workflow in python without preliminary knowledge 
about workflow.

If Heat uses just taskflow it should do all the work on workflow parsing and 
translation to a code that Heat team wants to avoid. At least this is my 
understanding.

Thanks
Georgy



On Tue, Oct 22, 2013 at 4:34 PM, Joshua Harlow 
mailto:harlo...@yahoo-inc.com>> wrote:
Sounds like taskflow could be that program (+1 from me, ha)?

Mistral to me is a nice authenticated REST api + other goodies ontop of
something that reliably executes workflows.

But then what I described is also the majority of what openstack does
(authenticated REST api + other goodies ontop of VM/volume/network/...
workflows).

On 10/22/13 3:28 PM, "Clint Byrum" mailto:cl...@fewbar.com>> 
wrote:

>Excerpts from Georgy Okrokvertskhov's message of 2013-10-22 13:32:40
>-0700:
>> Hi Thomas,
>>
>> I agree with you on semantics part. At the same time I see a potential
>> question which might appear - if semantics is limited by few states
>>visible
>> for Heat engine, then who actually does software orchestration?
>> Will it be reasonable then to have software orchestration as separate
>> subproject for Heat as a part of "Orchestration" OpenStack program? Heat
>> engine will then do dependency tracking and will use components as a
>> reference for software orchestration engine which will perform actual
>> deployment and high level software components coordination.
>>
>> This separated software orchestration engine may address all specific
>> requirements proposed by different teams in this thread without
>>affecting
>> existing Heat engine.
>>
>
>I'm not sure I know what "software orchestration" is, but I will take a
>stab at a succinct definition:
>
>Coordination of software configuration across multiple hosts.
>
>If that is what you mean, then I believe what you actually want is
>workflow. And for that, we have the Mistral project which was recently
>announced [1].
>
>Use that and you will simply need to define your desired workflow and
>feed it into Mistral using a Mistral Heat resource. We can create a
>nice bootstrapping resource for Heat instances that shims the mistral
>workflow execution agent into machines (or lets us use one already there
>via custom images).
>
>I can imagine it working something like this:
>
>resources:
>  mistral_workflow_handle:
>type: OS::Mistral::WorkflowHandle
>  web_server:
>type: OS::Nova::Server
>components:
>  mistral_agent:
>component_type: mistral
>params:
>  workflow_: {ref: mistral_workflow_handle}
>  mysql_server:
>type: OS::Nova::Server
>components:
>  mistral_agent:
>component_type: mistral
>params:
>  workflow_handle: {ref: mistral_workflow_handle}
>  mistral_workflow:
>type: OS::Mistral::Workflow
>properties:
>  handle: {ref: mistral_workflow_handle}
>  workflow_reference: mysql_webapp_workflow
>  params:
>mysql_server: {ref: mysql_server}
>webserver: {ref: web_server}
>
>
>And then the workflow is just defined outside of the Heat template (ok
>I'm 

Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-22 Thread Georgy Okrokvertskhov
Hi Joshua,

>Sounds like taskflow could be that program (+1 from me, ha)?

>Mistral to me is a nice authenticated REST api + other goodies ontop of
>something that reliably executes workflows.

I would say that Mistral is a way to do this. My arguments are the
following:
1. Mistral decouples code. Heat can use API calls to invoke a workflows
execution instead of linking with taskflow library in the code. This is
standard SOA approach which OpenStack uses a lot.
2. Mistral will expose DSL to define tasks while taskflow will require
python code for task definition.

Mistral itself uses taskflow library to execute workflows but Mistral in
addition does parsing and translation from DSL task definition to actual
python code.

Heat can use taskflow for other purposes but workflows execution is not a
good reason for that. Just because of nature of workflows for deployment,
there is no knowledge about workflow until end user uploads it, so you can
not use taskflow itself and code this workflow in python without
preliminary knowledge about workflow.

If Heat uses just taskflow it should do all the work on workflow parsing
and translation to a code that Heat team wants to avoid. At least this is
my understanding.

Thanks
Georgy



On Tue, Oct 22, 2013 at 4:34 PM, Joshua Harlow wrote:

> Sounds like taskflow could be that program (+1 from me, ha)?
>
> Mistral to me is a nice authenticated REST api + other goodies ontop of
> something that reliably executes workflows.
>
> But then what I described is also the majority of what openstack does
> (authenticated REST api + other goodies ontop of VM/volume/network/...
> workflows).
>
> On 10/22/13 3:28 PM, "Clint Byrum"  wrote:
>
> >Excerpts from Georgy Okrokvertskhov's message of 2013-10-22 13:32:40
> >-0700:
> >> Hi Thomas,
> >>
> >> I agree with you on semantics part. At the same time I see a potential
> >> question which might appear - if semantics is limited by few states
> >>visible
> >> for Heat engine, then who actually does software orchestration?
> >> Will it be reasonable then to have software orchestration as separate
> >> subproject for Heat as a part of "Orchestration" OpenStack program? Heat
> >> engine will then do dependency tracking and will use components as a
> >> reference for software orchestration engine which will perform actual
> >> deployment and high level software components coordination.
> >>
> >> This separated software orchestration engine may address all specific
> >> requirements proposed by different teams in this thread without
> >>affecting
> >> existing Heat engine.
> >>
> >
> >I'm not sure I know what "software orchestration" is, but I will take a
> >stab at a succinct definition:
> >
> >Coordination of software configuration across multiple hosts.
> >
> >If that is what you mean, then I believe what you actually want is
> >workflow. And for that, we have the Mistral project which was recently
> >announced [1].
> >
> >Use that and you will simply need to define your desired workflow and
> >feed it into Mistral using a Mistral Heat resource. We can create a
> >nice bootstrapping resource for Heat instances that shims the mistral
> >workflow execution agent into machines (or lets us use one already there
> >via custom images).
> >
> >I can imagine it working something like this:
> >
> >resources:
> >  mistral_workflow_handle:
> >type: OS::Mistral::WorkflowHandle
> >  web_server:
> >type: OS::Nova::Server
> >components:
> >  mistral_agent:
> >component_type: mistral
> >params:
> >  workflow_: {ref: mistral_workflow_handle}
> >  mysql_server:
> >type: OS::Nova::Server
> >components:
> >  mistral_agent:
> >component_type: mistral
> >params:
> >  workflow_handle: {ref: mistral_workflow_handle}
> >  mistral_workflow:
> >type: OS::Mistral::Workflow
> >properties:
> >  handle: {ref: mistral_workflow_handle}
> >  workflow_reference: mysql_webapp_workflow
> >  params:
> >mysql_server: {ref: mysql_server}
> >webserver: {ref: web_server}
> >
> >
> >And then the workflow is just defined outside of the Heat template (ok
> >I'm sure somebody will want to embed it, but I prefer stronger
> >separation). Something like this gets uploaded as
> >"mysql_webapp_workflow":
> >
> >[ 'step1': 'install_stuff',
> >  'step2': 'wait(step1)',
> >  'step3': 'allocate_sql_user(server=%mysql_server%)'
> >  'step4': 'credentials=wait_and_read(step3)'
> >  'step5': 'write_config_file(server=%webserver%)' ]
> >
> >Or maybe it is declared as a graph, or whatever, but it is not Heat's
> >problem how to do workflows, it just feeds the necessary data from
> >orchestration into the workflow engine. This also means you can use a
> >non OpenStack workflow engine without any problems.
> >
> >I think after having talked about this, we should have workflow live in
> >its own program.. we can always combine them if we want to, but having a
> >clear line would mean keeping t

Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-22 Thread Georgy Okrokvertskhov
Hi Clint,

Thank you for the detailed analysis.

>I'm not sure I know what "software orchestration" is, but I will take a
>stab at a succinct definition:

>Coordination of software configuration across multiple hosts.

Having this definition of "software orchestration" what will Heat
software orchestration component BP cover? I just trying to clarify for
myself what is Heat position and view on software orchestration based on
components and Heat view on workflows.

Right now it is not clear where is the separation line between component
and workflow. I think this blurred line introduced a lot of confusion in
this thread as some guys had a workflows based approach in mind and some
had component based view.

Thanks
Georgy



On Tue, Oct 22, 2013 at 3:28 PM, Clint Byrum  wrote:

> Excerpts from Georgy Okrokvertskhov's message of 2013-10-22 13:32:40 -0700:
> > Hi Thomas,
> >
> > I agree with you on semantics part. At the same time I see a potential
> > question which might appear - if semantics is limited by few states
> visible
> > for Heat engine, then who actually does software orchestration?
> > Will it be reasonable then to have software orchestration as separate
> > subproject for Heat as a part of "Orchestration" OpenStack program? Heat
> > engine will then do dependency tracking and will use components as a
> > reference for software orchestration engine which will perform actual
> > deployment and high level software components coordination.
> >
> > This separated software orchestration engine may address all specific
> > requirements proposed by different teams in this thread without affecting
> > existing Heat engine.
> >
>
> I'm not sure I know what "software orchestration" is, but I will take a
> stab at a succinct definition:
>
> Coordination of software configuration across multiple hosts.
>
> If that is what you mean, then I believe what you actually want is
> workflow. And for that, we have the Mistral project which was recently
> announced [1].
>
> Use that and you will simply need to define your desired workflow and
> feed it into Mistral using a Mistral Heat resource. We can create a
> nice bootstrapping resource for Heat instances that shims the mistral
> workflow execution agent into machines (or lets us use one already there
> via custom images).
>
> I can imagine it working something like this:
>
> resources:
>   mistral_workflow_handle:
> type: OS::Mistral::WorkflowHandle
>   web_server:
> type: OS::Nova::Server
> components:
>   mistral_agent:
> component_type: mistral
> params:
>   workflow_: {ref: mistral_workflow_handle}
>   mysql_server:
> type: OS::Nova::Server
> components:
>   mistral_agent:
> component_type: mistral
> params:
>   workflow_handle: {ref: mistral_workflow_handle}
>   mistral_workflow:
> type: OS::Mistral::Workflow
> properties:
>   handle: {ref: mistral_workflow_handle}
>   workflow_reference: mysql_webapp_workflow
>   params:
> mysql_server: {ref: mysql_server}
> webserver: {ref: web_server}
>
>
> And then the workflow is just defined outside of the Heat template (ok
> I'm sure somebody will want to embed it, but I prefer stronger
> separation). Something like this gets uploaded as
> "mysql_webapp_workflow":
>
> [ 'step1': 'install_stuff',
>   'step2': 'wait(step1)',
>   'step3': 'allocate_sql_user(server=%mysql_server%)'
>   'step4': 'credentials=wait_and_read(step3)'
>   'step5': 'write_config_file(server=%webserver%)' ]
>
> Or maybe it is declared as a graph, or whatever, but it is not Heat's
> problem how to do workflows, it just feeds the necessary data from
> orchestration into the workflow engine. This also means you can use a
> non OpenStack workflow engine without any problems.
>
> I think after having talked about this, we should have workflow live in
> its own program.. we can always combine them if we want to, but having a
> clear line would mean keeping the interfaces clean.
>
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2013-October/016605.html
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>



-- 
Georgy Okrokvertskhov
Technical Program Manager,
Cloud and Infrastructure Services,
Mirantis
http://www.mirantis.com
Tel. +1 650 963 9828
Mob. +1 650 996 3284
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-22 Thread Joshua Harlow
Sounds like taskflow could be that program (+1 from me, ha)?

Mistral to me is a nice authenticated REST api + other goodies ontop of
something that reliably executes workflows.

But then what I described is also the majority of what openstack does
(authenticated REST api + other goodies ontop of VM/volume/network/...
workflows).

On 10/22/13 3:28 PM, "Clint Byrum"  wrote:

>Excerpts from Georgy Okrokvertskhov's message of 2013-10-22 13:32:40
>-0700:
>> Hi Thomas,
>> 
>> I agree with you on semantics part. At the same time I see a potential
>> question which might appear - if semantics is limited by few states
>>visible
>> for Heat engine, then who actually does software orchestration?
>> Will it be reasonable then to have software orchestration as separate
>> subproject for Heat as a part of "Orchestration" OpenStack program? Heat
>> engine will then do dependency tracking and will use components as a
>> reference for software orchestration engine which will perform actual
>> deployment and high level software components coordination.
>> 
>> This separated software orchestration engine may address all specific
>> requirements proposed by different teams in this thread without
>>affecting
>> existing Heat engine.
>> 
>
>I'm not sure I know what "software orchestration" is, but I will take a
>stab at a succinct definition:
>
>Coordination of software configuration across multiple hosts.
>
>If that is what you mean, then I believe what you actually want is
>workflow. And for that, we have the Mistral project which was recently
>announced [1].
>
>Use that and you will simply need to define your desired workflow and
>feed it into Mistral using a Mistral Heat resource. We can create a
>nice bootstrapping resource for Heat instances that shims the mistral
>workflow execution agent into machines (or lets us use one already there
>via custom images).
>
>I can imagine it working something like this:
>
>resources:
>  mistral_workflow_handle:
>type: OS::Mistral::WorkflowHandle
>  web_server:
>type: OS::Nova::Server
>components:
>  mistral_agent:
>component_type: mistral
>params:
>  workflow_: {ref: mistral_workflow_handle}
>  mysql_server:
>type: OS::Nova::Server
>components:
>  mistral_agent:
>component_type: mistral
>params:
>  workflow_handle: {ref: mistral_workflow_handle}
>  mistral_workflow:
>type: OS::Mistral::Workflow
>properties:
>  handle: {ref: mistral_workflow_handle}
>  workflow_reference: mysql_webapp_workflow
>  params:
>mysql_server: {ref: mysql_server}
>webserver: {ref: web_server}
>
>
>And then the workflow is just defined outside of the Heat template (ok
>I'm sure somebody will want to embed it, but I prefer stronger
>separation). Something like this gets uploaded as
>"mysql_webapp_workflow":
>
>[ 'step1': 'install_stuff',
>  'step2': 'wait(step1)',
>  'step3': 'allocate_sql_user(server=%mysql_server%)'
>  'step4': 'credentials=wait_and_read(step3)'
>  'step5': 'write_config_file(server=%webserver%)' ]
>
>Or maybe it is declared as a graph, or whatever, but it is not Heat's
>problem how to do workflows, it just feeds the necessary data from
>orchestration into the workflow engine. This also means you can use a
>non OpenStack workflow engine without any problems.
>
>I think after having talked about this, we should have workflow live in
>its own program.. we can always combine them if we want to, but having a
>clear line would mean keeping the interfaces clean.
>
>[1] 
>http://lists.openstack.org/pipermail/openstack-dev/2013-October/016605.htm
>l
>
>___
>OpenStack-dev mailing list
>OpenStack-dev@lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-22 Thread Clint Byrum
Excerpts from Georgy Okrokvertskhov's message of 2013-10-22 13:32:40 -0700:
> Hi Thomas,
> 
> I agree with you on semantics part. At the same time I see a potential
> question which might appear - if semantics is limited by few states visible
> for Heat engine, then who actually does software orchestration?
> Will it be reasonable then to have software orchestration as separate
> subproject for Heat as a part of "Orchestration" OpenStack program? Heat
> engine will then do dependency tracking and will use components as a
> reference for software orchestration engine which will perform actual
> deployment and high level software components coordination.
> 
> This separated software orchestration engine may address all specific
> requirements proposed by different teams in this thread without affecting
> existing Heat engine.
> 

I'm not sure I know what "software orchestration" is, but I will take a
stab at a succinct definition:

Coordination of software configuration across multiple hosts.

If that is what you mean, then I believe what you actually want is
workflow. And for that, we have the Mistral project which was recently
announced [1].

Use that and you will simply need to define your desired workflow and
feed it into Mistral using a Mistral Heat resource. We can create a
nice bootstrapping resource for Heat instances that shims the mistral
workflow execution agent into machines (or lets us use one already there
via custom images).

I can imagine it working something like this:

resources:
  mistral_workflow_handle:
type: OS::Mistral::WorkflowHandle
  web_server:
type: OS::Nova::Server
components:
  mistral_agent:
component_type: mistral
params:
  workflow_: {ref: mistral_workflow_handle}
  mysql_server:
type: OS::Nova::Server
components:
  mistral_agent:
component_type: mistral
params:
  workflow_handle: {ref: mistral_workflow_handle}
  mistral_workflow:
type: OS::Mistral::Workflow
properties:
  handle: {ref: mistral_workflow_handle}
  workflow_reference: mysql_webapp_workflow
  params:
mysql_server: {ref: mysql_server}
webserver: {ref: web_server}


And then the workflow is just defined outside of the Heat template (ok
I'm sure somebody will want to embed it, but I prefer stronger
separation). Something like this gets uploaded as
"mysql_webapp_workflow":

[ 'step1': 'install_stuff',
  'step2': 'wait(step1)',
  'step3': 'allocate_sql_user(server=%mysql_server%)'
  'step4': 'credentials=wait_and_read(step3)'
  'step5': 'write_config_file(server=%webserver%)' ]

Or maybe it is declared as a graph, or whatever, but it is not Heat's
problem how to do workflows, it just feeds the necessary data from
orchestration into the workflow engine. This also means you can use a
non OpenStack workflow engine without any problems.

I think after having talked about this, we should have workflow live in
its own program.. we can always combine them if we want to, but having a
clear line would mean keeping the interfaces clean.

[1] http://lists.openstack.org/pipermail/openstack-dev/2013-October/016605.html

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-22 Thread Georgy Okrokvertskhov
Hi Thomas,

I agree with you on semantics part. At the same time I see a potential
question which might appear - if semantics is limited by few states visible
for Heat engine, then who actually does software orchestration?
Will it be reasonable then to have software orchestration as separate
subproject for Heat as a part of "Orchestration" OpenStack program? Heat
engine will then do dependency tracking and will use components as a
reference for software orchestration engine which will perform actual
deployment and high level software components coordination.

This separated software orchestration engine may address all specific
requirements proposed by different teams in this thread without affecting
existing Heat engine.

Thanks
Georgy


On Tue, Oct 22, 2013 at 12:06 PM, Thomas Spatzier <
thomas.spatz...@de.ibm.com> wrote:

> Georgy Okrokvertskhov  wrote on 22.10.2013
> 20:01:19:
> > From: Georgy Okrokvertskhov 
> > To: OpenStack Development Mailing List
> ,
> > Date: 22.10.2013 20:05
> > Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
> >
> > Hi,
> >
> > I would agree with Stan that we need to discuss definitions before
> > going deeply to the implementation.
> >
> > The first example on the https://wiki.openstack.org/wiki/Heat/
> > Blueprints/hot-software-config shows components like install_mysql
> > and install_wordpress.
>
> Good point. I also think that at least the examples currently used are more
> of an "automation step" than a "component".
> IMO component should represent some kind of software installation (e.g. a
> web server, a DBMS, etc.), where automation is used under the covers to
> install and configure that piece of software.
> From an orchestration point of view, a reasonable semantics would be that
> when a component is in state CREATE_COMPLETE it is ready to use, e.g. a web
> server is ready to serve applications. With respect to the automation that
> was used to bring up the component, it would return successful (and this
> would be signaled to Heat) when the component setup is done.
>
> For example, the following could represent an Apache web server component,
> installed using Chef:
>
> components:
>   apache:
> type: OS::Heat::SoftwareConfig_Chef
> cookbook: http://www.example.com/my_apache_cookbook.zip
> properties:
>   http_port: 8080
>
> 'apache' is just a name here that indicates of course what you get. The
> type indicates that a component provide able to invoke Chef automation is
> used. The cookbook attribute points to the cookbook to use, which will
> install and configure apache. By setting the http_port property to 8080,
> you provide input to the Chef cookbook. The SoftwareConfig_Chef component
> provider will implement the logic to pass properties to the Chef invocation
> in the right syntax.
>
> > I would say that this is a bit confusing because I expected to see
> > component definitions instead of software deployment definition
> > process. I think this is a quite dangerous path here because this
> > example shows us that we can use components as installation steps
> > definition instead of real component definition.
> > If one continue to do this approach and defines more and more
> > granular steps as a components they will come to workflow definition
> > composed in terms of components. This approach does not add either
> > simplicity or clarity in the HOT template.
> >
> > Thanks
> > Georgy
> >
> >
>
> > On Tue, Oct 22, 2013 at 10:02 AM, Stan Lagun 
> wrote:
> > Hello,
>
> > I've been reading through the thread and the wiki pages and I'm
> > still confused by the terms. Is there a clear definition of what do
> > we understand by component from user's and developer's point of
> > view. If I write "component, type:MySQL" what is behind that
> > definition? I mean how does the system know what exactly MySQL is
> > and how to install it? What MySQL version is it gonna be? Will it be
> > x86 or x64? How does the system understand that I need MySQL for
> > Windows on Windows VM rather then Linux MySQL? What do I as a
> > developer need to do so that it would be possible to have "type:
> > MyCoolComponentType"?
> >
>
> > On Tue, Oct 22, 2013 at 8:35 PM, Thomas Spatzier
>  > > wrote:
> > Zane Bitter  wrote on 22.10.2013 17:23:52:
> > > From: Zane Bitter 
> > > To: openstack-dev@lists.openstack.org,
> > > Date: 22.10.2013 17:26
> > > Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
> > >
> > > On 22/10

Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-22 Thread Thomas Spatzier
Georgy Okrokvertskhov  wrote on 22.10.2013
20:01:19:
> From: Georgy Okrokvertskhov 
> To: OpenStack Development Mailing List
,
> Date: 22.10.2013 20:05
> Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
>
> Hi,
>
> I would agree with Stan that we need to discuss definitions before
> going deeply to the implementation.
>
> The first example on the https://wiki.openstack.org/wiki/Heat/
> Blueprints/hot-software-config shows components like install_mysql
> and install_wordpress.

Good point. I also think that at least the examples currently used are more
of an "automation step" than a "component".
IMO component should represent some kind of software installation (e.g. a
web server, a DBMS, etc.), where automation is used under the covers to
install and configure that piece of software.
>From an orchestration point of view, a reasonable semantics would be that
when a component is in state CREATE_COMPLETE it is ready to use, e.g. a web
server is ready to serve applications. With respect to the automation that
was used to bring up the component, it would return successful (and this
would be signaled to Heat) when the component setup is done.

For example, the following could represent an Apache web server component,
installed using Chef:

components:
  apache:
type: OS::Heat::SoftwareConfig_Chef
cookbook: http://www.example.com/my_apache_cookbook.zip
properties:
  http_port: 8080

'apache' is just a name here that indicates of course what you get. The
type indicates that a component provide able to invoke Chef automation is
used. The cookbook attribute points to the cookbook to use, which will
install and configure apache. By setting the http_port property to 8080,
you provide input to the Chef cookbook. The SoftwareConfig_Chef component
provider will implement the logic to pass properties to the Chef invocation
in the right syntax.

> I would say that this is a bit confusing because I expected to see
> component definitions instead of software deployment definition
> process. I think this is a quite dangerous path here because this
> example shows us that we can use components as installation steps
> definition instead of real component definition.
> If one continue to do this approach and defines more and more
> granular steps as a components they will come to workflow definition
> composed in terms of components. This approach does not add either
> simplicity or clarity in the HOT template.
>
> Thanks
> Georgy
>
>

> On Tue, Oct 22, 2013 at 10:02 AM, Stan Lagun  wrote:
> Hello,

> I've been reading through the thread and the wiki pages and I'm
> still confused by the terms. Is there a clear definition of what do
> we understand by component from user's and developer's point of
> view. If I write "component, type:MySQL" what is behind that
> definition? I mean how does the system know what exactly MySQL is
> and how to install it? What MySQL version is it gonna be? Will it be
> x86 or x64? How does the system understand that I need MySQL for
> Windows on Windows VM rather then Linux MySQL? What do I as a
> developer need to do so that it would be possible to have "type:
> MyCoolComponentType"?
>

> On Tue, Oct 22, 2013 at 8:35 PM, Thomas Spatzier
 > wrote:
> Zane Bitter  wrote on 22.10.2013 17:23:52:
> > From: Zane Bitter 
> > To: openstack-dev@lists.openstack.org,
> > Date: 22.10.2013 17:26
> > Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
> >
> > On 22/10/13 16:35, Thomas Spatzier wrote:
> > > Zane Bitter  wrote on 22.10.2013 15:24:28:
> > >> From: Zane Bitter 
> > >> To: openstack-dev@lists.openstack.org,
> > >> Date: 22.10.2013 15:27
> > >> Subject: Re: [openstack-dev] [Heat] HOT Software configuration
> proposal
> > >>
> > >> On 22/10/13 09:15, Thomas Spatzier wrote:
> > >>> BTW, the convention of properties being input and attributes being
> > > output,
> > >>> i.e. that subtle distinction between properties and attributes is
not
> > >>> really intuitive, at least not to me as non-native speaker, because
I
> > > used
> > >>> to use both words as synonyms.
> > >>
> > >> As a native speaker, I can confidently state that it's not intuitive
> to
> > >> anyone ;)
> > >
> > > Phew, good to read that ;-)
> > >
> > >>
> > >> We unfortunately inherited these names from the Properties section
and
> > >> the Fn::GetAtt function in cfn templates. It's even worse than that,
> > >> because there's a whole category of... uh... thin

Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-22 Thread Thomas Spatzier
Stan Lagun  wrote on 22.10.2013 19:02:38:
> From: Stan Lagun 
> To: OpenStack Development Mailing List
,
> Date: 22.10.2013 19:06
> Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
>
> Hello,

> I've been reading through the thread and the wiki pages and I'm
> still confused by the terms. Is there a clear definition of what do
> we understand by component from user's and developer's point of
> view. If I write "component, type:MySQL" what is behind that
> definition? I mean how does the system know what exactly MySQL is

I think the current proposal is not that Heat would support very specific
component types (like MySQL, Apache, Tomcat etc.) but component is more of
a generic construct to represent a piece of software. The type attribute of
a component then just calls out the config management tool (e.g. Chef) to
install and configure that piece of software. By pointing a component to,
say, a Chef cookbook for setting up MySQL the runtime type would be MySQL.
That is at least my view on this.

I agree, however, that it needs to be straightened out how the term
"component" is really used.

> and how to install it? What MySQL version is it gonna be? Will it be
> x86 or x64? How does the system understand that I need MySQL for
> Windows on Windows VM rather then Linux MySQL? What do I as a
> developer need to do so that it would be possible to have "type:
> MyCoolComponentType"?
>

> On Tue, Oct 22, 2013 at 8:35 PM, Thomas Spatzier
 > wrote:
> Zane Bitter  wrote on 22.10.2013 17:23:52:
> > From: Zane Bitter 
> > To: openstack-dev@lists.openstack.org,
> > Date: 22.10.2013 17:26
> > Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
> >
> > On 22/10/13 16:35, Thomas Spatzier wrote:
> > > Zane Bitter  wrote on 22.10.2013 15:24:28:
> > >> From: Zane Bitter 
> > >> To: openstack-dev@lists.openstack.org,
> > >> Date: 22.10.2013 15:27
> > >> Subject: Re: [openstack-dev] [Heat] HOT Software configuration
> proposal
> > >>
> > >> On 22/10/13 09:15, Thomas Spatzier wrote:
> > >>> BTW, the convention of properties being input and attributes being
> > > output,
> > >>> i.e. that subtle distinction between properties and attributes is
not
> > >>> really intuitive, at least not to me as non-native speaker, because
I
> > > used
> > >>> to use both words as synonyms.
> > >>
> > >> As a native speaker, I can confidently state that it's not intuitive
> to
> > >> anyone ;)
> > >
> > > Phew, good to read that ;-)
> > >
> > >>
> > >> We unfortunately inherited these names from the Properties section
and
> > >> the Fn::GetAtt function in cfn templates. It's even worse than that,
> > >> because there's a whole category of... uh... things (DependsOn,
> > >> DeletionPolicy, &c.) that don't even have a name - I always have to
> > >> resist the urge to call them 'attributes' too.
> > >
> > > So is this something we should try to get straight in HOT while we
> still
> > > have the flexibility?
> >
> > Y-yes. Provided that we can do it without making things *more*
> > confusing, +1. That's hard though, because there are a number of places
> > we have to refer to them, all with different audiences:
> >   - HOT users
> >   - cfn users
> >   - Existing developers
> >   - New developers
> >   - Plugin developers
> >
> > and using different names for the same thing can cause problems. My
test
> > for this is: if you were helping a user on IRC debug an issue, is there
> > a high chance you would spend 15 minutes talking past each other
because
> > they misunderstand the terminology?

> Hm, good point. Seems like it would really cause more confusion than it
> helps. So back away from the general idea of renaming things that exist
> both in cfn and HOT.
> What we should try of course is to give new concepts that will only exist
> in HOT intuitive names.
>
> >
> > > Regarding properties/attributes for example, to me I would call both
> just
> > > properties of a resource or component, and then I can write them or
> read
> > > them like:
> > >
> > > components:
> > >    my_component:
> > >      type: ...
> > >      properties:
> > >        my_prop: { get_property: [ other_component,
> other_component_prop ] }
> > >
> > >    other_component:
> > >      # ...
> > >
>

Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-22 Thread Georgy Okrokvertskhov
Hi,

I would agree with Stan that we need to discuss definitions before going
deeply to the implementation.

The first example on the
https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config shows
components like install_mysql and install_wordpress.
I would say that this is a bit confusing because I expected to see
component definitions instead of software deployment definition process. I
think this is a quite dangerous path here because this example shows us
that we can use components as installation steps definition instead of real
component definition.
If one continue to do this approach and defines more and more granular
steps as a components they will come to workflow definition composed in
terms of components. This approach does not add either simplicity or
clarity in the HOT template.

Thanks
Georgy



On Tue, Oct 22, 2013 at 10:02 AM, Stan Lagun  wrote:

> Hello,
>
> I've been reading through the thread and the wiki pages and I'm still
> confused by the terms. Is there a clear definition of what do we understand
> by component from user's and developer's point of view. If I write
> "component, type:MySQL" what is behind that definition? I mean how does the
> system know what exactly MySQL is and how to install it? What MySQL version
> is it gonna be? Will it be x86 or x64? How does the system understand that
> I need MySQL for Windows on Windows VM rather then Linux MySQL? What do I
> as a developer need to do so that it would be possible to have "type:
> MyCoolComponentType"?
>
>
> On Tue, Oct 22, 2013 at 8:35 PM, Thomas Spatzier <
> thomas.spatz...@de.ibm.com> wrote:
>
>> Zane Bitter  wrote on 22.10.2013 17:23:52:
>> > From: Zane Bitter 
>> > To: openstack-dev@lists.openstack.org,
>> > Date: 22.10.2013 17:26
>> > Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
>> >
>> > On 22/10/13 16:35, Thomas Spatzier wrote:
>> > > Zane Bitter  wrote on 22.10.2013 15:24:28:
>> > >> From: Zane Bitter 
>> > >> To: openstack-dev@lists.openstack.org,
>> > >> Date: 22.10.2013 15:27
>> > >> Subject: Re: [openstack-dev] [Heat] HOT Software configuration
>> proposal
>> > >>
>> > >> On 22/10/13 09:15, Thomas Spatzier wrote:
>> > >>> BTW, the convention of properties being input and attributes being
>> > > output,
>> > >>> i.e. that subtle distinction between properties and attributes is
>> not
>> > >>> really intuitive, at least not to me as non-native speaker, because
>> I
>> > > used
>> > >>> to use both words as synonyms.
>> > >>
>> > >> As a native speaker, I can confidently state that it's not intuitive
>> to
>> > >> anyone ;)
>> > >
>> > > Phew, good to read that ;-)
>> > >
>> > >>
>> > >> We unfortunately inherited these names from the Properties section
>> and
>> > >> the Fn::GetAtt function in cfn templates. It's even worse than that,
>> > >> because there's a whole category of... uh... things (DependsOn,
>> > >> DeletionPolicy, &c.) that don't even have a name - I always have to
>> > >> resist the urge to call them 'attributes' too.
>> > >
>> > > So is this something we should try to get straight in HOT while we
>> still
>> > > have the flexibility?
>> >
>> > Y-yes. Provided that we can do it without making things *more*
>> > confusing, +1. That's hard though, because there are a number of places
>> > we have to refer to them, all with different audiences:
>> >   - HOT users
>> >   - cfn users
>> >   - Existing developers
>> >   - New developers
>> >   - Plugin developers
>> >
>> > and using different names for the same thing can cause problems. My test
>> > for this is: if you were helping a user on IRC debug an issue, is there
>> > a high chance you would spend 15 minutes talking past each other because
>> > they misunderstand the terminology?
>>
>> Hm, good point. Seems like it would really cause more confusion than it
>> helps. So back away from the general idea of renaming things that exist
>> both in cfn and HOT.
>> What we should try of course is to give new concepts that will only exist
>> in HOT intuitive names.
>>
>> >
>> > > Regarding properties/attributes for example, to me I would call both
>> just
>> > > properties of a resource or c

Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-22 Thread Stan Lagun
Hello,

I've been reading through the thread and the wiki pages and I'm still
confused by the terms. Is there a clear definition of what do we understand
by component from user's and developer's point of view. If I write
"component, type:MySQL" what is behind that definition? I mean how does the
system know what exactly MySQL is and how to install it? What MySQL version
is it gonna be? Will it be x86 or x64? How does the system understand that
I need MySQL for Windows on Windows VM rather then Linux MySQL? What do I
as a developer need to do so that it would be possible to have "type:
MyCoolComponentType"?


On Tue, Oct 22, 2013 at 8:35 PM, Thomas Spatzier  wrote:

> Zane Bitter  wrote on 22.10.2013 17:23:52:
> > From: Zane Bitter 
> > To: openstack-dev@lists.openstack.org,
> > Date: 22.10.2013 17:26
> > Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
> >
> > On 22/10/13 16:35, Thomas Spatzier wrote:
> > > Zane Bitter  wrote on 22.10.2013 15:24:28:
> > >> From: Zane Bitter 
> > >> To: openstack-dev@lists.openstack.org,
> > >> Date: 22.10.2013 15:27
> > >> Subject: Re: [openstack-dev] [Heat] HOT Software configuration
> proposal
> > >>
> > >> On 22/10/13 09:15, Thomas Spatzier wrote:
> > >>> BTW, the convention of properties being input and attributes being
> > > output,
> > >>> i.e. that subtle distinction between properties and attributes is not
> > >>> really intuitive, at least not to me as non-native speaker, because I
> > > used
> > >>> to use both words as synonyms.
> > >>
> > >> As a native speaker, I can confidently state that it's not intuitive
> to
> > >> anyone ;)
> > >
> > > Phew, good to read that ;-)
> > >
> > >>
> > >> We unfortunately inherited these names from the Properties section and
> > >> the Fn::GetAtt function in cfn templates. It's even worse than that,
> > >> because there's a whole category of... uh... things (DependsOn,
> > >> DeletionPolicy, &c.) that don't even have a name - I always have to
> > >> resist the urge to call them 'attributes' too.
> > >
> > > So is this something we should try to get straight in HOT while we
> still
> > > have the flexibility?
> >
> > Y-yes. Provided that we can do it without making things *more*
> > confusing, +1. That's hard though, because there are a number of places
> > we have to refer to them, all with different audiences:
> >   - HOT users
> >   - cfn users
> >   - Existing developers
> >   - New developers
> >   - Plugin developers
> >
> > and using different names for the same thing can cause problems. My test
> > for this is: if you were helping a user on IRC debug an issue, is there
> > a high chance you would spend 15 minutes talking past each other because
> > they misunderstand the terminology?
>
> Hm, good point. Seems like it would really cause more confusion than it
> helps. So back away from the general idea of renaming things that exist
> both in cfn and HOT.
> What we should try of course is to give new concepts that will only exist
> in HOT intuitive names.
>
> >
> > > Regarding properties/attributes for example, to me I would call both
> just
> > > properties of a resource or component, and then I can write them or
> read
> > > them like:
> > >
> > > components:
> > >my_component:
> > >  type: ...
> > >  properties:
> > >my_prop: { get_property: [ other_component,
> other_component_prop ] }
> > >
> > >other_component:
> > >  # ...
> > >
> > > I.e. you write property 'my_prop' of 'my_component' in its properties
> > > section, and you read property 'other_component_prop' of
> 'other_component'
> > > using the get_property function.
> > > ... we can also call them attributes, but use one name, not two
> different
> > > names for the same thing.
> >
> > IMO inputs (Properties) and outputs (Fn::GetAtt) are different things
> > (and they exist in different namespaces), so -1 for giving them the same
> > name.
> >
> > In an ideal world I'd like HOT to use something like get_output_data (or
> > maybe just get_data), but OTOH we have e.g. FnGetAtt() and
> > attributes_schema baked in to the plugin API that we can't really
> > change, so it se

Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-22 Thread Thomas Spatzier
Zane Bitter  wrote on 22.10.2013 17:23:52:
> From: Zane Bitter 
> To: openstack-dev@lists.openstack.org,
> Date: 22.10.2013 17:26
> Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
>
> On 22/10/13 16:35, Thomas Spatzier wrote:
> > Zane Bitter  wrote on 22.10.2013 15:24:28:
> >> From: Zane Bitter 
> >> To: openstack-dev@lists.openstack.org,
> >> Date: 22.10.2013 15:27
> >> Subject: Re: [openstack-dev] [Heat] HOT Software configuration
proposal
> >>
> >> On 22/10/13 09:15, Thomas Spatzier wrote:
> >>> BTW, the convention of properties being input and attributes being
> > output,
> >>> i.e. that subtle distinction between properties and attributes is not
> >>> really intuitive, at least not to me as non-native speaker, because I
> > used
> >>> to use both words as synonyms.
> >>
> >> As a native speaker, I can confidently state that it's not intuitive
to
> >> anyone ;)
> >
> > Phew, good to read that ;-)
> >
> >>
> >> We unfortunately inherited these names from the Properties section and
> >> the Fn::GetAtt function in cfn templates. It's even worse than that,
> >> because there's a whole category of... uh... things (DependsOn,
> >> DeletionPolicy, &c.) that don't even have a name - I always have to
> >> resist the urge to call them 'attributes' too.
> >
> > So is this something we should try to get straight in HOT while we
still
> > have the flexibility?
>
> Y-yes. Provided that we can do it without making things *more*
> confusing, +1. That's hard though, because there are a number of places
> we have to refer to them, all with different audiences:
>   - HOT users
>   - cfn users
>   - Existing developers
>   - New developers
>   - Plugin developers
>
> and using different names for the same thing can cause problems. My test
> for this is: if you were helping a user on IRC debug an issue, is there
> a high chance you would spend 15 minutes talking past each other because
> they misunderstand the terminology?

Hm, good point. Seems like it would really cause more confusion than it
helps. So back away from the general idea of renaming things that exist
both in cfn and HOT.
What we should try of course is to give new concepts that will only exist
in HOT intuitive names.

>
> > Regarding properties/attributes for example, to me I would call both
just
> > properties of a resource or component, and then I can write them or
read
> > them like:
> >
> > components:
> >my_component:
> >  type: ...
> >  properties:
> >my_prop: { get_property: [ other_component,
other_component_prop ] }
> >
> >other_component:
> >  # ...
> >
> > I.e. you write property 'my_prop' of 'my_component' in its properties
> > section, and you read property 'other_component_prop' of
'other_component'
> > using the get_property function.
> > ... we can also call them attributes, but use one name, not two
different
> > names for the same thing.
>
> IMO inputs (Properties) and outputs (Fn::GetAtt) are different things
> (and they exist in different namespaces), so -1 for giving them the same
> name.
>
> In an ideal world I'd like HOT to use something like get_output_data (or
> maybe just get_data), but OTOH we have e.g. FnGetAtt() and
> attributes_schema baked in to the plugin API that we can't really
> change, so it seems likely to lead to developers and users adopting
> different terminology, or making things very difficult for new
> developers, or both :(
>
> cheers,
> Zane.
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-22 Thread Zane Bitter

On 22/10/13 16:35, Thomas Spatzier wrote:

Zane Bitter  wrote on 22.10.2013 15:24:28:

From: Zane Bitter 
To: openstack-dev@lists.openstack.org,
Date: 22.10.2013 15:27
Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal

On 22/10/13 09:15, Thomas Spatzier wrote:

BTW, the convention of properties being input and attributes being

output,

i.e. that subtle distinction between properties and attributes is not
really intuitive, at least not to me as non-native speaker, because I

used

to use both words as synonyms.


As a native speaker, I can confidently state that it's not intuitive to
anyone ;)


Phew, good to read that ;-)



We unfortunately inherited these names from the Properties section and
the Fn::GetAtt function in cfn templates. It's even worse than that,
because there's a whole category of... uh... things (DependsOn,
DeletionPolicy, &c.) that don't even have a name - I always have to
resist the urge to call them 'attributes' too.


So is this something we should try to get straight in HOT while we still
have the flexibility?


Y-yes. Provided that we can do it without making things *more* 
confusing, +1. That's hard though, because there are a number of places 
we have to refer to them, all with different audiences:

 - HOT users
 - cfn users
 - Existing developers
 - New developers
 - Plugin developers

and using different names for the same thing can cause problems. My test 
for this is: if you were helping a user on IRC debug an issue, is there 
a high chance you would spend 15 minutes talking past each other because 
they misunderstand the terminology?



Regarding properties/attributes for example, to me I would call both just
properties of a resource or component, and then I can write them or read
them like:

components:
   my_component:
 type: ...
 properties:
   my_prop: { get_property: [ other_component, other_component_prop ] }

   other_component:
 # ...

I.e. you write property 'my_prop' of 'my_component' in its properties
section, and you read property 'other_component_prop' of 'other_component'
using the get_property function.
... we can also call them attributes, but use one name, not two different
names for the same thing.


IMO inputs (Properties) and outputs (Fn::GetAtt) are different things 
(and they exist in different namespaces), so -1 for giving them the same 
name.


In an ideal world I'd like HOT to use something like get_output_data (or 
maybe just get_data), but OTOH we have e.g. FnGetAtt() and 
attributes_schema baked in to the plugin API that we can't really 
change, so it seems likely to lead to developers and users adopting 
different terminology, or making things very difficult for new 
developers, or both :(


cheers,
Zane.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-22 Thread Thomas Spatzier
Zane Bitter  wrote on 22.10.2013 15:24:28:
> From: Zane Bitter 
> To: openstack-dev@lists.openstack.org,
> Date: 22.10.2013 15:27
> Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
>
> On 22/10/13 09:15, Thomas Spatzier wrote:
> > BTW, the convention of properties being input and attributes being
output,
> > i.e. that subtle distinction between properties and attributes is not
> > really intuitive, at least not to me as non-native speaker, because I
used
> > to use both words as synonyms.
>
> As a native speaker, I can confidently state that it's not intuitive to
> anyone ;)

Phew, good to read that ;-)

>
> We unfortunately inherited these names from the Properties section and
> the Fn::GetAtt function in cfn templates. It's even worse than that,
> because there's a whole category of... uh... things (DependsOn,
> DeletionPolicy, &c.) that don't even have a name - I always have to
> resist the urge to call them 'attributes' too.

So is this something we should try to get straight in HOT while we still
have the flexibility?
Regarding properties/attributes for example, to me I would call both just
properties of a resource or component, and then I can write them or read
them like:

components:
  my_component:
type: ...
properties:
  my_prop: { get_property: [ other_component, other_component_prop ] }

  other_component:
# ...

I.e. you write property 'my_prop' of 'my_component' in its properties
section, and you read property 'other_component_prop' of 'other_component'
using the get_property function.
... we can also call them attributes, but use one name, not two different
names for the same thing.

>
> - ZB
>
> ___
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>


___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-22 Thread Lakshminaraya Renganarayana
Zane Bitter  wrote on 10/22/2013 09:24:28 AM:

>
> On 22/10/13 09:15, Thomas Spatzier wrote:
> > BTW, the convention of properties being input and attributes being
output,
> > i.e. that subtle distinction between properties and attributes is not
> > really intuitive, at least not to me as non-native speaker, because I
used
> > to use both words as synonyms.
>
> As a native speaker, I can confidently state that it's not intuitive to
> anyone ;)
>
> We unfortunately inherited these names from the Properties section and
> the Fn::GetAtt function in cfn templates. It's even worse than that,
> because there's a whole category of... uh... things (DependsOn,
> DeletionPolicy, &c.) that don't even have a name - I always have to
> resist the urge to call them 'attributes' too.

At least for the components construct being proposed (by Steve Baker),
shall we adopt a more explicit convention and require component definitions
to explicitly name their inputs and outputs?

Thanks,
LN___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-22 Thread Zane Bitter

On 22/10/13 09:15, Thomas Spatzier wrote:

BTW, the convention of properties being input and attributes being output,
i.e. that subtle distinction between properties and attributes is not
really intuitive, at least not to me as non-native speaker, because I used
to use both words as synonyms.


As a native speaker, I can confidently state that it's not intuitive to 
anyone ;)


We unfortunately inherited these names from the Properties section and 
the Fn::GetAtt function in cfn templates. It's even worse than that, 
because there's a whole category of... uh... things (DependsOn, 
DeletionPolicy, &c.) that don't even have a name - I always have to 
resist the urge to call them 'attributes' too.


- ZB

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-22 Thread Thomas Spatzier
> Steve Baker  wrote on 21.10.2013 23:02:47:
> From: Steve Baker 
> To: openstack-dev@lists.openstack.org,
> Date: 21.10.2013 23:06
> Subject: Re: [openstack-dev] [Heat] HOT Software configuration proposal
>
>> On 10/22/2013 08:45 AM, Mike Spreitzer wrote:
>> Steve Baker  wrote on 10/15/2013 06:48:53 PM:
>>
>> > I've just written some proposals to address Heat's HOT software
>> > configuration needs, and I'd like to use this thread to get some
feedback:
>> > https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config
>> > https://wiki.openstack.org/wiki/Heat/Blueprints/native-tools-
>> bootstrap-config
>> >
>> > Please read the proposals and reply to the list with any comments or
>> > suggestions.
>>
>> Can you confirm whether I have got the big picture right?  I think
>> some of my earlier remarks were mistaken.
>>
>> You propose to introduce the concept of component and recognize
>> software configuration as a matter of invoking components --- with a
>> DAG of data dependencies among the component invocations.  While
>> this is similar to what today's heat engine does for resources, you
>> do NOT propose that the heat engine will get in the business of
>> invoking components.  Rather: each VM will run a series of component
>> invocations, and in-VM mechanisms will handle the cross-component
>> synchronization and data communication.
> This is basically correct, except that in-VM mechanisms won't know
> much about cross-component synchronization and data communication.
> They will just execute whatever components are available to be
> executed, and report back values to heat-engine by signalling to
> waitconditions.
>>  You propose to add a bit of sugaring for the wait condition&handle
>> mechanism, and the heat engine will do the de-sugaring.
> Yes, I think improvements can be made on what I proposed, such as
> every component signalling when it is complete, and optionally
> including a return value in that signal.

Being able to handle completion of single components inside a VM and being
able to pass outputs of those components seems important to me. I think
that should mostly address the requirements for declaring data dependencies
between components that have been discussed before in this thread. If
wait-conditions are the underlying mechanism, fine, as longs as we can hid
it from the template syntax.

For example, something like this should be possible:

components:
  comp_a:
type: OS::Heat::SomeCMProvider
properties:
  prop1: { get_param: param1 }
  prop2: ...
  comp_b:
type: OS::Heat::SomeCMProvider
properties:
  propA: { get_attr: [ comp_a, some_attr ] }

resources:
  serverA:
type: OS::Nova::Server
# ...
components:
  - comp_a
  serverB:
type: OS::Nova::Server
# ...
components:
  - comp_b

I.e. there are two components comp_a and comp_b on two different servers.
comp_a has a data dependency on an attribute of comp_b. If we treat
'properties' as input to components and 'attributes' as output (the way it
is currently done for resources), that should be doable.
BTW, the convention of properties being input and attributes being output,
i.e. that subtle distinction between properties and attributes is not
really intuitive, at least not to me as non-native speaker, because I used
to use both words as synonyms.
Anyway it seems like the current proposal is a starting point with
enhancements on the roadmap, right?

>>  Each component is written in one of a few supported configuration
>> management (CM) frameworks, and essentially all component
>> invocations on a given VM invoke components of the same CM framework
>> (with possible exceptions for one or two really basic ones).
> Rather than being limited to a few supported CM tools, I like the
> idea of some kind of provider mechanism so that users or heat admins
> can add support for new CM tools. This implies that it needs to be
> possible to add a component type without requiring custom python
> that runs on heat engine.
>> The heat engine gains the additional responsibility of making sure
>> that the appropriate CM framework(s) is(are) bootstrapped in each VM.
> Maybe. Or it might be up to the user to invoke images that already
> have the CM tools installed, or the user can provide a custom
> component provider which installs the tool in the way that they want.
>
> As for the cross-component synchronization and data communication
> question, at this stage I'm not comfortable with bringing something
> like zookeeper into the mix for a general solution for inter-
> component communication.  If heat engine handles resource
> dependencies and zook

Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-21 Thread Steve Baker
On 10/22/2013 08:45 AM, Mike Spreitzer wrote:
> Steve Baker  wrote on 10/15/2013 06:48:53 PM:
>
> > I've just written some proposals to address Heat's HOT software
> > configuration needs, and I'd like to use this thread to get some
> feedback:
> > https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config
> >
> https://wiki.openstack.org/wiki/Heat/Blueprints/native-tools-bootstrap-config
> >
> > Please read the proposals and reply to the list with any comments or
> > suggestions.
>
> Can you confirm whether I have got the big picture right?  I think
> some of my earlier remarks were mistaken.
>
> You propose to introduce the concept of component and recognize
> software configuration as a matter of invoking components --- with a
> DAG of data dependencies among the component invocations.  While this
> is similar to what today's heat engine does for resources, you do NOT
> propose that the heat engine will get in the business of invoking
> components.  Rather: each VM will run a series of component
> invocations, and in-VM mechanisms will handle the cross-component
> synchronization and data communication. 
This is basically correct, except that in-VM mechanisms won't know much
about cross-component synchronization and data communication. They will
just execute whatever components are available to be executed, and
report back values to heat-engine by signalling to waitconditions.
>  You propose to add a bit of sugaring for the wait condition&handle
> mechanism, and the heat engine will do the de-sugaring. 
Yes, I think improvements can be made on what I proposed, such as every
component signalling when it is complete, and optionally including a
return value in that signal.
>  Each component is written in one of a few supported configuration
> management (CM) frameworks, and essentially all component invocations
> on a given VM invoke components of the same CM framework (with
> possible exceptions for one or two really basic ones).
Rather than being limited to a few supported CM tools, I like the idea
of some kind of provider mechanism so that users or heat admins can add
support for new CM tools. This implies that it needs to be possible to
add a component type without requiring custom python that runs on heat
engine.
> The heat engine gains the additional responsibility of making sure
> that the appropriate CM framework(s) is(are) bootstrapped in each VM.
Maybe. Or it might be up to the user to invoke images that already have
the CM tools installed, or the user can provide a custom component
provider which installs the tool in the way that they want.

As for the cross-component synchronization and data communication
question, at this stage I'm not comfortable with bringing something like
zookeeper into the mix for a general solution for inter-component
communication.  If heat engine handles resource dependencies and
zookeeper handles software configuration dependencies this would result
in the state of the stack being split between two different
co-ordination mechanisms.

We've put quite some effort into heat engine to co-ordinate resource
dependencies. Wait conditions are currently cumbersome to use, but by
exposing software configuration state in terms of resource dependencies
they do enable heat engine to be central source of state for the entire
stack, including progress of software config.

If wait conditions can become palatable to use (or completely
transparent) then to me that addresses the main concerns about using
them in the short term. Longer term I'd consider something like Marconi
to replace metadata polling and wait condition signalling but it is too
early to be having that conversation.
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-21 Thread Angus Salkeld

On 21/10/13 15:45 -0400, Mike Spreitzer wrote:

Steve Baker  wrote on 10/15/2013 06:48:53 PM:


I've just written some proposals to address Heat's HOT software
configuration needs, and I'd like to use this thread to get some

feedback:

https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config


https://wiki.openstack.org/wiki/Heat/Blueprints/native-tools-bootstrap-config



Please read the proposals and reply to the list with any comments or
suggestions.


Can you confirm whether I have got the big picture right?  I think some of
my earlier remarks were mistaken.

You propose to introduce the concept of component and recognize software
configuration as a matter of invoking components --- with a DAG of data
dependencies among the component invocations.  While this is similar to
what today's heat engine does for resources, you do NOT propose that the
heat engine will get in the business of invoking components.  Rather: each
VM will run a series of component invocations, and in-VM mechanisms will
handle the cross-component synchronization and data communication.  You
propose to add a bit of sugaring for the wait condition&handle mechanism,
and the heat engine will do the de-sugaring.  Each component is written in
one of a few supported configuration management (CM) frameworks, and
essentially all component invocations on a given VM invoke components of
the same CM framework (with possible exceptions for one or two really
basic ones).  The heat engine gains the additional responsibility of
making sure that the appropriate CM framework(s) is(are) bootstrapped in
each VM.  The heat engine gains no additional responsibilities.

Have I got that right?


I hope so, I don't want Heat to get into the business of two different
dependency systems.

-Angus



Thanks,
Mike



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev



___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-21 Thread Mike Spreitzer
Steve Baker  wrote on 10/15/2013 06:48:53 PM:

> I've just written some proposals to address Heat's HOT software 
> configuration needs, and I'd like to use this thread to get some 
feedback:
> https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config
> 
https://wiki.openstack.org/wiki/Heat/Blueprints/native-tools-bootstrap-config

> 
> Please read the proposals and reply to the list with any comments or
> suggestions.

Can you confirm whether I have got the big picture right?  I think some of 
my earlier remarks were mistaken.

You propose to introduce the concept of component and recognize software 
configuration as a matter of invoking components --- with a DAG of data 
dependencies among the component invocations.  While this is similar to 
what today's heat engine does for resources, you do NOT propose that the 
heat engine will get in the business of invoking components.  Rather: each 
VM will run a series of component invocations, and in-VM mechanisms will 
handle the cross-component synchronization and data communication.  You 
propose to add a bit of sugaring for the wait condition&handle mechanism, 
and the heat engine will do the de-sugaring.  Each component is written in 
one of a few supported configuration management (CM) frameworks, and 
essentially all component invocations on a given VM invoke components of 
the same CM framework (with possible exceptions for one or two really 
basic ones).  The heat engine gains the additional responsibility of 
making sure that the appropriate CM framework(s) is(are) bootstrapped in 
each VM.  The heat engine gains no additional responsibilities.

Have I got that right?

Thanks,
Mike___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-19 Thread Mike Spreitzer
(I really do not understand how the archive is ordered.  In the by-thread 
view, in which all messages with this subject are equally indented, the 
last message listed is not the chronologically last.)

I see that components have parameters.  In some uses (invocations) of 
components, parameters are given actual values.  I find it surprising that 
in the component definitions there are no declarations of parameters. 
Wouldn't that be helpful or needed?

Thanks,
Mike___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-17 Thread Zane Bitter

On 16/10/13 21:02, Clint Byrum wrote:

Excerpts from Zane Bitter's message of 2013-10-16 06:16:33 -0700:

>I'd love to be able to put this control in the user's hands by just
>using provider templates - i.e. you designate PuppetServer.yaml as the
>provider for an OS::Nova::Server in your template and it knows how to
>configure Puppet and handle the various components. We could make
>available a library of such provider templates, but users wouldn't be
>limited to only using those.
>

This I don't think I understand well enough to pass judgement on. My
understanding of providers is that they are meant to make templates more
portable between clouds that have different capabilities.


That's certainly one use, and the main one we've been concentrating on. 
One of the cool things about providers IMHO is that it's a completely 
generic feature, not tied to one particular use case, so it's 
potentially very powerful, possibly in ways that we haven't even thought 
of yet.


So the idea here would be that you have a 
[Puppet|Chef|Salt|Ansible|CFEngine]Server provider template that 
contains an OS::Nova::Server resource with the UserData filled in to 
configure the CM system to start and e.g. grab the component configs 
from the metadata. You then use this template as the provider for one or 
more of your servers, link the components somehow and off you go.



Mapping that
onto different CM systems feels like a stretch and presents a few
questions for me. How do I have two OS::Nova::Server's using different
CM systems when I decide to deploy something that uses salt instead of
chef?


You can specify a provider for an individual resource, you don't have to 
map a whole resource type to it in the environment (although you can). 
Even if you did, you could just make up your own resource types (say, 
OS::Custom::ChefServer and OS::Custom::SaltServer).



As long as components can be composed of other components, then it seems
to me that you would just want the CM system to be a component. If you
find yourself including the same set of components constantly.. just
make a bigger component out of them.


This is a good point, and may well be the way to go. I was thinking that 
the CM system had to be effectively one step higher in the chain than 
the components that run under it, but maybe that's really only true of 
cloud-init.


(BTW I agree with Steve B here, addressing the problem is much more 
important to me than any particular solution.)


cheers,
Zane.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-16 Thread Steve Baker
On 10/17/2013 03:11 AM, Thomas Spatzier wrote:
> Hi Steve,
>
> thanks a lot taking the effort to write all this down. I had a look at both
> wiki pages and have some comments below. This is really from the top of my
> head, and I guess I have to spend some more time thinking about it, but I
> wanted to provide some feedback anyway.
>
> On "components vs. resources":
> So the proposal says clearly that the resource concept is only used for
> things that get accessed and managed via their APIs, i.e. services provided
> by something external to Heat (nova, cinder, etc), while software is
> different and therefore modeled as components, which is basically fine (and
> I also suggested this in my initial proposal .. but was never quite sure).
> Anyway, I think we also need some APIs to access software components (not
> the actual installed software, but the provider managing it), so we can get
> the state of a component, and probably also manage the state to do
> meaningful orchestration. That would bring it close to the resource concept
> again, or components (the providers) would have to provide some means for
> getting access to state etc.
As I've mentioned, messaging/sync is out of scope for these blueprints
but it would be good to start exploring the options now.
> Why no processing of intrinsic functions in config block?
> ... that was actually a question that came up when I read this first, but
> maybe is resolved by some text further down in the wiki. But I wanted to
> ask for clarification. I thought having intrinsic function could be helpful
> for passing parameters around, and also implying dependencies. A bit
> further down some concept for parameter passing to the config providers is
> introduced, and for filling the parameters, intrinsic functions can be
> used. So do I get it right that this would enable the dependency building
> and data passing?
Some reasons for not allowing intrinsic functions in components:
- it allows component config to be purely represented in the syntax of
the CM tool without any reference to Heat constructs
- it allows the CM's native variable handling to be used instead of
bypassing it by doing config substitutions
- it simplifies the implementation of components in heat engine - no
resource or component dependencies, no function evaluation
> Regarding pointer from a server's components section to components vs. a
> hosted_on relationship:
> The current proposal is in fact (or probably) isomorphic to the hosted_on
> links from my earlier proposal. However, having pointers from the lower
> layer (servers) to the upper layers (software) seems a bit odd to me. It
> would be really nice to get clean decoupling of software and infrastructure
> and not just the ability to copy and paste the components and then having
> to define server resources specifically to point to components. The
> ultimate goal would be to have app layer models and infrastructure models
> (e.g. using the environments concept and provider resources) and some way
> of binding app components to one or multiple servers per deployment (single
> server in test, clustered in production).
> Maybe some layer in between is necessary, because neither my earlier
> "hosted_on" proposal nor the current proposal does that.
https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config#Composability

To me, this addresses the separation of architecture from application
configuration. Components don't make any reference to the architecture
of the stack. Server resources only refer to components by name. I would
say that specifying what pieces of configuration run where is in the
domain of architecture. You could even choose component names which make
no reference to the specific application - making the OS::Nova::Server
resource definitions a more pure representation of architecture.
> Why no depends_on (or just dependency) between components?
> Ordering in components is ok, but I think it should be possible to express
> dependencies between components across servers. Whether or not a
> "depends_on" relationship is the right things to express this, or just a
> more simple dependency notation can be discussed, but I think we need
> something. In my approach I tried to come up with one section
> ("relationship") that is the place for specifying all sorts of linke,
> dependency being one, just to come up with one extensible way of expressing
> things.
> Anyway, having the ability to manage dependencies by Heat seems necessary.
> And I would not pass the ball completely to the other tools outside of
> Heat. First of all, doing things in those other tools also gets complicated
> (e.g. while chef is good on one server, doing synchronization across
> servers can get ugly). And Heat has the ultimate knowledge about what
> servers it created, their IP addresses etc, so it should lead
> orchestration.
See the second depends_on bullet point here
https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config#Why_not_relat

Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-16 Thread Steve Baker
On 10/17/2013 02:16 AM, Zane Bitter wrote:
> On 16/10/13 00:48, Steve Baker wrote:
>> I've just written some proposals to address Heat's HOT software
>> configuration needs, and I'd like to use this thread to get some
>> feedback:
>> https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config
>> https://wiki.openstack.org/wiki/Heat/Blueprints/native-tools-bootstrap-config
>>
>
> Wow, nice job, thanks for writing all of this up :)
>
>> Please read the proposals and reply to the list with any comments or
>> suggestions.
>
> For me the crucial question is, how do we define the interface for
> synchronising and passing data from and to arbitrary applications
> running under an arbitrary configuration management system?
>
Agreed, but I wanted to remove that from the scope of these blueprints,
with the hope that what is done here will be an enabler for a new
sync/messaging mechanism - or at least not make it harder.

>
> I'm not a big fan of having Heat::Puppet, Heat::CloudInit,
> Heat::Ansible &c. component types insofar as they require your cloud
> provider to support your preferred configuration management system
> before you can use it. (In contrast, it's much easier to teach your
> configuration management system about Heat because you control it
> yourself, and configuration management systems are already designed
> for plugging in arbitrary applications.)
>
> I'd love to be able to put this control in the user's hands by just
> using provider templates - i.e. you designate PuppetServer.yaml as the
> provider for an OS::Nova::Server in your template and it knows how to
> configure Puppet and handle the various components. We could make
> available a library of such provider templates, but users wouldn't be
> limited to only using those.
>

I agree you've identified a problem worth solving. The only thing a
component type does in heat-engine is build cloud-init chunks. I'll have
a think about how this can be implemented as something resembling
component providers.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-16 Thread Lakshminaraya Renganarayana


Clint Byrum  wrote on 10/16/2013 03:02:13 PM:

>
> Excerpts from Zane Bitter's message of 2013-10-16 06:16:33 -0700:

> >
> > For me the crucial question is, how do we define the interface for
> > synchronising and passing data from and to arbitrary applications
> > running under an arbitrary configuration management system?
> >
> > Compared to this, defining the actual format in which software
> > applications are specified in HOT seems like a Simple Matter of
> > Bikeshedding ;)
> >
>
> Agreed. This is one area where juju excels (making cross-node message
> passing simple). So perhaps we should take a look at what works from the
> juju model and copy it.

Actually, this exactly the point

"how do we define the interface for  synchronising and passing data
from and to arbitrary applications running under an arbitrary
configuration management system?"

I was addressing in my message/proposal a couple of days back on the
mailing list :-) Glad to see that echoed again. I am proposing that
Heat should have a higher (than current wait-conditions/signals) level
abstraction for synchronization and data exchange. I do not mind it
being message passing as in JuJu. Based on our experience I am proposing
a zookeeper style global data space with blocking-reads, and non-blocking
writes.


Thanks,
LN
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-16 Thread Clint Byrum
Excerpts from Zane Bitter's message of 2013-10-16 06:16:33 -0700:
> On 16/10/13 00:48, Steve Baker wrote:
> > I've just written some proposals to address Heat's HOT software
> > configuration needs, and I'd like to use this thread to get some feedback:
> > https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config
> > https://wiki.openstack.org/wiki/Heat/Blueprints/native-tools-bootstrap-config
> 
> Wow, nice job, thanks for writing all of this up :)
> 
> > Please read the proposals and reply to the list with any comments or
> > suggestions.
> 
> For me the crucial question is, how do we define the interface for 
> synchronising and passing data from and to arbitrary applications 
> running under an arbitrary configuration management system?
> 
> Compared to this, defining the actual format in which software 
> applications are specified in HOT seems like a Simple Matter of 
> Bikeshedding ;)
> 

Agreed. This is one area where juju excels (making cross-node message
passing simple). So perhaps we should take a look at what works from the
juju model and copy it.

> (BTW +1 for not having the relationships, hosted_on always reminded me 
> uncomfortably of INTERCAL[1]. We already have DependsOn for resources 
> though, and might well need it here too.)
>

Also agreed. The way the new proposal has it, it feels more like
composing a workflow.

> I'm not a big fan of having Heat::Puppet, Heat::CloudInit, Heat::Ansible 
> &c. component types insofar as they require your cloud provider to 
> support your preferred configuration management system before you can 
> use it. (In contrast, it's much easier to teach your configuration 
> management system about Heat because you control it yourself, and 
> configuration management systems are already designed for plugging in 
> arbitrary applications.)
> 

Also agree. Having Heat know too much about anything that has many
implementations is a bit of a layer violation. Heat has an interface,
and we should make it really easy for the popular tools to consume
said interface. I could see us having a separate set of shims, like
heat-puppet, and heat-salt, that are helpers for those systems to consume
data from Heat more smoothly.

> I'd love to be able to put this control in the user's hands by just 
> using provider templates - i.e. you designate PuppetServer.yaml as the 
> provider for an OS::Nova::Server in your template and it knows how to 
> configure Puppet and handle the various components. We could make 
> available a library of such provider templates, but users wouldn't be 
> limited to only using those.
> 

This I don't think I understand well enough to pass judgement on. My
understanding of providers is that they are meant to make templates more
portable between clouds that have different capabilities. Mapping that
onto different CM systems feels like a stretch and presents a few
questions for me. How do I have two OS::Nova::Server's using different
CM systems when I decide to deploy something that uses salt instead of
chef?

As long as components can be composed of other components, then it seems
to me that you would just want the CM system to be a component. If you
find yourself including the same set of components constantly.. just
make a bigger component out of them.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-16 Thread Mike Spreitzer
Zane Bitter  wrote on 10/16/2013 10:30:44 AM:

> On 16/10/13 15:58, Mike Spreitzer wrote:
> ...
> > Thanks for a great short sharp answer.  In that light, I see a 
concern.
> >   Once a workflow has been generated, the system has lost the ability 
to
> > adapt to changes in either model.  In a highly concurrent and dynamic
> > environment, that could be problematic.
> 
> I think you're referring to the fact if reality diverges from the model 
> we have no way to bring it back in line (and even when doing an update, 
> things can and usually will go wrong if Heat's idea of the existing 
> template does not reflect reality any more). If so, then I agree that we 

> are weak in this area. You're obviously aware of 
> http://summit.openstack.org/cfp/details/95 so it is definitely on the 
radar.

Actually, I am thinking of both of the two models you mentioned.  We are 
only in the midst of implementing an even newer design (heat based), but 
for my group's old code we have a revised design in which the 
infrastructure orchestrator can react to being overtaken by later updates 
to the model we call "target state" (origin source is client) as well as 
concurrent updates to the model we call "observed state" (origin source is 
hardware/hypervisor).  I haven't yet decided what to recommend to the heat 
community, so I'm just mentioning the issue as a possible concern.

Thanks,
Mike___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-16 Thread Zane Bitter

On 16/10/13 15:58, Mike Spreitzer wrote:

Zane Bitter  wrote on 10/16/2013 08:25:38 AM:

 > To answer your question, the key thing that Heat does is take in two
 > declarative models and generate a workflow to transform one into the
 > other. (The general case of this is a stack update, where the two models
 > are defined in the previous and new templates. Stack create and delete
 > are special cases where one or the other of the models is empty.)
 >
 > Workflows don't belong in HOT because they are a one-off thing. You need
 > a different one for every situation, and this is exactly why Heat exists
 > - to infer the correct workflow to reify a model in any given situation.

Thanks for a great short sharp answer.  In that light, I see a concern.
  Once a workflow has been generated, the system has lost the ability to
adapt to changes in either model.  In a highly concurrent and dynamic
environment, that could be problematic.


I think you're referring to the fact if reality diverges from the model 
we have no way to bring it back in line (and even when doing an update, 
things can and usually will go wrong if Heat's idea of the existing 
template does not reflect reality any more). If so, then I agree that we 
are weak in this area. You're obviously aware of 
http://summit.openstack.org/cfp/details/95 so it is definitely on the radar.


cheers,
Zane.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-16 Thread Thomas Spatzier
Hi Steve,

thanks a lot taking the effort to write all this down. I had a look at both
wiki pages and have some comments below. This is really from the top of my
head, and I guess I have to spend some more time thinking about it, but I
wanted to provide some feedback anyway.

On "components vs. resources":
So the proposal says clearly that the resource concept is only used for
things that get accessed and managed via their APIs, i.e. services provided
by something external to Heat (nova, cinder, etc), while software is
different and therefore modeled as components, which is basically fine (and
I also suggested this in my initial proposal .. but was never quite sure).
Anyway, I think we also need some APIs to access software components (not
the actual installed software, but the provider managing it), so we can get
the state of a component, and probably also manage the state to do
meaningful orchestration. That would bring it close to the resource concept
again, or components (the providers) would have to provide some means for
getting access to state etc.

Why no processing of intrinsic functions in config block?
... that was actually a question that came up when I read this first, but
maybe is resolved by some text further down in the wiki. But I wanted to
ask for clarification. I thought having intrinsic function could be helpful
for passing parameters around, and also implying dependencies. A bit
further down some concept for parameter passing to the config providers is
introduced, and for filling the parameters, intrinsic functions can be
used. So do I get it right that this would enable the dependency building
and data passing?

Regarding pointer from a server's components section to components vs. a
hosted_on relationship:
The current proposal is in fact (or probably) isomorphic to the hosted_on
links from my earlier proposal. However, having pointers from the lower
layer (servers) to the upper layers (software) seems a bit odd to me. It
would be really nice to get clean decoupling of software and infrastructure
and not just the ability to copy and paste the components and then having
to define server resources specifically to point to components. The
ultimate goal would be to have app layer models and infrastructure models
(e.g. using the environments concept and provider resources) and some way
of binding app components to one or multiple servers per deployment (single
server in test, clustered in production).
Maybe some layer in between is necessary, because neither my earlier
"hosted_on" proposal nor the current proposal does that.

Why no depends_on (or just dependency) between components?
Ordering in components is ok, but I think it should be possible to express
dependencies between components across servers. Whether or not a
"depends_on" relationship is the right things to express this, or just a
more simple dependency notation can be discussed, but I think we need
something. In my approach I tried to come up with one section
("relationship") that is the place for specifying all sorts of linke,
dependency being one, just to come up with one extensible way of expressing
things.
Anyway, having the ability to manage dependencies by Heat seems necessary.
And I would not pass the ball completely to the other tools outside of
Heat. First of all, doing things in those other tools also gets complicated
(e.g. while chef is good on one server, doing synchronization across
servers can get ugly). And Heat has the ultimate knowledge about what
servers it created, their IP addresses etc, so it should lead
orchestration.

Regarding "component_execution: async"
Is this necessary? I think in any case, it should be possible to create
infrastructure resources (servers) in parallel. Then only the component
startup should be synchronized once the servers are up, and this should be
the default behavior. I think this actually related to the dependency topic
above. BTW, even component startup inside servers can be done in parallel
unless components have dependencies on each other, so doing a component
startup in the strict order as given in a list in the template is probably
not necessary.

Regarding the wait condition example:
I get the idea and it surely would work, but I think it is still
un-intuitive and we should about a more abstract declarative way for
expressing such use cases.

Regarding the native tool bootstrap config proposal:
I agree with other comments already made on this thread that the sheer
number of different config components seems to much. I guess for users it
will be hard to understand, which one to use when, what combination makes
sense, in which order they have to be combined etc. Especially, when things
are getting combined, my gut feeling is that the likelyhood of templates
breaking whenever some of the underlying implementation changes will
increase.

Steve Baker  wrote on 16.10.2013 00:48:53:
> From: Steve Baker 
> To: openstack-dev@lists.openstack.org,
> Date: 16.10.2013 00:51
> Subject: 

Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-16 Thread Mike Spreitzer
Zane Bitter  wrote on 10/16/2013 08:25:38 AM:

> To answer your question, the key thing that Heat does is take in two 
> declarative models and generate a workflow to transform one into the 
> other. (The general case of this is a stack update, where the two models 

> are defined in the previous and new templates. Stack create and delete 
> are special cases where one or the other of the models is empty.)
> 
> Workflows don't belong in HOT because they are a one-off thing. You need 

> a different one for every situation, and this is exactly why Heat exists 

> - to infer the correct workflow to reify a model in any given situation.

Thanks for a great short sharp answer.  In that light, I see a concern. 
Once a workflow has been generated, the system has lost the ability to 
adapt to changes in either model.  In a highly concurrent and dynamic 
environment, that could be problematic.

Thanks,
Mike___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-16 Thread Mike Spreitzer
Steven Hardy  wrote on 10/16/2013 04:11:40 AM:
> ...
> IMO we should be abstracting the software configuration complexity 
behind a
> Heat resource interface, not pushing it up to a pre-processor (which
> implies some horribly complex interfaces at the heat template level)

I am not sure I follow.  Can you please elaborate on the horrible 
implication?

Thanks,
Mike___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-16 Thread Zane Bitter

On 16/10/13 00:48, Steve Baker wrote:

I've just written some proposals to address Heat's HOT software
configuration needs, and I'd like to use this thread to get some feedback:
https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config
https://wiki.openstack.org/wiki/Heat/Blueprints/native-tools-bootstrap-config


Wow, nice job, thanks for writing all of this up :)


Please read the proposals and reply to the list with any comments or
suggestions.


For me the crucial question is, how do we define the interface for 
synchronising and passing data from and to arbitrary applications 
running under an arbitrary configuration management system?


Compared to this, defining the actual format in which software 
applications are specified in HOT seems like a Simple Matter of 
Bikeshedding ;)


(BTW +1 for not having the relationships, hosted_on always reminded me 
uncomfortably of INTERCAL[1]. We already have DependsOn for resources 
though, and might well need it here too.)


I'm not a big fan of having Heat::Puppet, Heat::CloudInit, Heat::Ansible 
&c. component types insofar as they require your cloud provider to 
support your preferred configuration management system before you can 
use it. (In contrast, it's much easier to teach your configuration 
management system about Heat because you control it yourself, and 
configuration management systems are already designed for plugging in 
arbitrary applications.)


I'd love to be able to put this control in the user's hands by just 
using provider templates - i.e. you designate PuppetServer.yaml as the 
provider for an OS::Nova::Server in your template and it knows how to 
configure Puppet and handle the various components. We could make 
available a library of such provider templates, but users wouldn't be 
limited to only using those.


cheers,
Zane.


[1] https://en.wikipedia.org/wiki/COMEFROM

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-16 Thread Zane Bitter

On 16/10/13 06:56, Mike Spreitzer wrote:

What is the difference between what today's heat engine does and a
workflow?  I am interested to hear what you experts think, I hope it
will be clarifying.  I presume the answers will touch on things like
error handling, state tracking, and updates.


(Disclaimer: I'm not an expert, I just work on this stuff ;)

First off, to be clear, it was my understanding from this thread that 
the original proposal to add workflow syntax to HOT is effectively dead. 
(If I'm mistaken, add a giant -1 from me.) Mirantis have since 
announced, I assume not coincidentally, that they will start 
implementing a workflow service (Mistral, based on the original 
Convection proposal from Keith Bray at the Havana summit) for OpenStack, 
backed by the taskflow library. So bringing workflows back in to this 
discussion is confusing the issue.


(FWIW I think that having a workflow service will be a great thing for 
other reasons, but I also hope that all of Stan's original example will 
be possible in Heat *without* resorting to requiring users to define an 
explicit workflow.)


It must be acknowledged that the Heat engine does run a workflow. The 
workflow part can in principle, and probably should, be delegated to the 
taskflow library, and I would be surprised if we did not eventually end 
up doing this (though I'm not looking forward to actually implementing it).


To answer your question, the key thing that Heat does is take in two 
declarative models and generate a workflow to transform one into the 
other. (The general case of this is a stack update, where the two models 
are defined in the previous and new templates. Stack create and delete 
are special cases where one or the other of the models is empty.)


Workflows don't belong in HOT because they are a one-off thing. You need 
a different one for every situation, and this is exactly why Heat exists 
- to infer the correct workflow to reify a model in any given situation.


cheers,
Zane.

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-16 Thread Steven Hardy
On Tue, Oct 15, 2013 at 09:21:12PM -0400, Mike Spreitzer wrote:
> Steve Baker  wrote on 10/15/2013 06:48:53 PM:
> 
> > From: Steve Baker 
> > To: openstack-dev@lists.openstack.org, 
> > Date: 10/15/2013 06:51 PM
> > Subject: [openstack-dev] [Heat] HOT Software configuration proposal
> > 
> > I've just written some proposals to address Heat's HOT software 
> > configuration needs, and I'd like to use this thread to get some 
> feedback:
> > https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config
> 
> In that proposal, each component can use a different configuration 
> management tool.
> 
> > 
> https://wiki.openstack.org/wiki/Heat/Blueprints/native-tools-bootstrap-config
> 
> 
> In this proposal, I get the idea that it is intended that each Compute 
> instance run only one configuration management tool.  At least, most of 
> the text discusses the support (e.g., the idea that each CM tool supplies 
> userdata to bootstrap itself) in terms appropriate for a single CM tool 
> per instance; also, there is no discussion of combining userdata from 
> several CM tools.

IMO it makes no sense to use more than one CM tool on a particular
instance, apart from the case already mentioned by stevebaker where
cloud-init is used to bootstrap some other tool.

>From my discussions with folks so far, they want:
- Something simple and declarative at the template interface
- A way to reuse data and knowledge from existing CM tools
  (Puppet/Chef/...) in a clean an non-complex way

> I agree with the separation of concerns issues that have been raised.  I 
> think all this software config stuff can be handled by a pre-processor 
> that takes an extended template in and outputs a plain template that can 
> be consumed by today's heat engine (no extension to the heat engine 
> necessary).

I think this is the exact opposite of the direction we should be headed.

IMO we should be abstracting the software configuration complexity behind a
Heat resource interface, not pushing it up to a pre-processor (which
implies some horribly complex interfaces at the heat template level)

Steve

___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-15 Thread Mike Spreitzer
The threading in the archive includes this discussion under the "HOT 
Software orchestration proposal for workflows" heading, and the overall 
ordering in the archive looks very mixed up to me.  I am going to reply 
here, hoping that the new subject line will be subject to less strange 
ordering in the archive; this is really a continuation of the overall 
discussion, not just Steve Baker's proposal.

What is the difference between what today's heat engine does and a 
workflow?  I am interested to hear what you experts think, I hope it will 
be clarifying.  I presume the answers will touch on things like error 
handling, state tracking, and updates.

I see the essence of Steve Baker's proposal to be that of doing the 
minimal mods necessary to enable the heat engine to orchestrate software 
components.  The observation is that not much has to change, since the 
heat engine is already in the business of calling out to things and 
passing values around.  I see a little bit of a difference, maybe because 
I am too new to already know why it is not an issue.  In today's heat 
engine, the calls are made to fixed services to do CRUD operations on 
virtual resources in the cloud, using credentials managed implicitly; the 
services have fixed endpoints, even as the virtual resources come and go. 
Software components have no fixed service endpoints; the service endpoints 
come and go as the host Compute instances come and go; I did not notice a 
story about authorization for the software component calls.

Interestingly, Steve Baker's proposal reminds me a lot of Chef.  If you 
just rename Steve's "component" to "recipe", the alignment gets real 
obvious; I am sure it is no accident.  I am not saying it is isomorphic 
--- clearly Steve Baker's proposal has more going on, with its cross-VM 
data dependencies and synchronization.  But let me emphasize that we can 
start to see a different way of thinking here.  Rather than focusing on a 
centrally-run workflow, think of each VM as independently running its own 
series of recipes --- with the recipes invocations now able to communicate 
and synchronize between VMs as well as within VMs.

Steve Baker's proposal uses two forms of communication and synchronization 
between VMs: (1) get_attr and (2) wait conditions and handles (sugar 
coated or not).  The implementation of (1) is part of the way the heat 
engine invokes components, the implementation of (2) is independent of the 
heat engine.

Using the heat engine for orchestration is limited to the kinds of logic 
that the heat engine can run.  This may be one reason people are 
suggesting using a general workflow engine.  However, the recipes 
(components) running in the VMs can do general computation; if we allow 
general cross-VM communication and synchronization as part of those 
general computations, we clearly have a more expressive system than the 
heat engine.

Of course, a general distributed computation can get itself into trouble 
(e.g., deadlock, livelock).  If we structure that computation as a set of 
components (recipe invocations) with a DAG of dependencies then we avoid 
those troubles.  And the kind of orchestration that the heat engine does 
is sufficient to invoke such components.

Structuring software orchestration as a DAG of components also gives us a 
leg up on UPDATE.  Rather than asking the user to write a workflow for 
each different update, or a general meta-workflow that does introspection 
to decide what work needs to be done, we ask the thing that invokes the 
components to run through the components in the way that today's heat 
engine runs through resources for an UPDATE.

Lakshmi has been working on a software orchestration technique that is 
also centered on the idea of a DAG of components.  It was created before 
we got real interested in Heat.  It is implemented as a pre-processor that 
runs upstream of where today's heat engine goes, emitting fairly minimal 
userdata needed for bootstrapping.  The dependencies between recipe 
invocations are handled very smoothly in the recipes, which are written in 
Chef.  No hackery is needed in the recipe text at all (thanks to Ruby 
metaprogramming); what is needed is only an additional declaration of what 
are the cross-VM inputs and outputs of each recipe.  The propagation of 
data and synchronization between VMs is handled, under the covers, via 
simple usage of ZooKeeper (other implementations are reasonable too).  But 
the idea of heat-independent propagation of data and synchronization among 
a DAG of components is not limited to chef-based components, and can 
appear fairly smooth in any recipe language.

A value of making software orchestration independent of today's heat 
engine is that it enables the four-stage pipeline that I have sketched at 
https://docs.google.com/drawings/d/1Y_yyIpql5_cdC8116XrBHzn6GfP_g0NHTTG_W4o0R9U 
and whose ordering of functionality has been experimentally vetted with 
some non-trivial examples.  The first big

Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-15 Thread Steve Baker
On 10/16/2013 02:21 PM, Mike Spreitzer wrote:
> Steve Baker  wrote on 10/15/2013 06:48:53 PM:
>
> > From: Steve Baker 
> > To: openstack-dev@lists.openstack.org,
> > Date: 10/15/2013 06:51 PM
> > Subject: [openstack-dev] [Heat] HOT Software configuration proposal
> >
> > I've just written some proposals to address Heat's HOT software
> > configuration needs, and I'd like to use this thread to get some
> feedback:
> > https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config
>
> In that proposal, each component can use a different configuration
> management tool.
>
> >
> https://wiki.openstack.org/wiki/Heat/Blueprints/native-tools-bootstrap-config
>
> In this proposal, I get the idea that it is intended that each Compute
> instance run only one configuration management tool.  At least, most
> of the text discusses the support (e.g., the idea that each CM tool
> supplies userdata to bootstrap itself) in terms appropriate for a
> single CM tool per instance; also, there is no discussion of combining
> userdata from several CM tools.
>
I think users should be told that it is possible but foolhardy to mix CM
tools in a single server. The exception to this *might* be allowing one
Heat::CloudInit (or Heat::SoftwareConfig) component to install the other
CM tool on a pristine image before running the other components that use
that tool.

Initially I thought that each component type should be able to ensure
that its CM tool is installed before invoking that tool. The realities
of doing this the right way all the time are difficult though[1] so I've
backed away from this for now. It can always be added as an enhancement
later. In the meantime users are free to build images that have all
required prerequisites, or install them with a Heat::CloudInit (or
Heat::SoftwareConfig) component on boot.

> I agree with the separation of concerns issues that have been raised.
>  I think all this software config stuff can be handled by a
> pre-processor that takes an extended template in and outputs a plain
> template that can be consumed by today's heat engine (no extension to
> the heat engine necessary).
>
A stated goal of the heat template format is that it be fit-for-use by
humans. Pre-processing is a perfectly valid technique for other services
that use heat and we encourage that. However if the pre-processing is to
work around usability issues in the template format I would rather focus
on fixing those issues.

[1] Currently the most reliable way of installing heat-cfntools on any
arbitrary pristine image is in a venv
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev


Re: [openstack-dev] [Heat] HOT Software configuration proposal

2013-10-15 Thread Mike Spreitzer
Steve Baker  wrote on 10/15/2013 06:48:53 PM:

> From: Steve Baker 
> To: openstack-dev@lists.openstack.org, 
> Date: 10/15/2013 06:51 PM
> Subject: [openstack-dev] [Heat] HOT Software configuration proposal
> 
> I've just written some proposals to address Heat's HOT software 
> configuration needs, and I'd like to use this thread to get some 
feedback:
> https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config

In that proposal, each component can use a different configuration 
management tool.

> 
https://wiki.openstack.org/wiki/Heat/Blueprints/native-tools-bootstrap-config


In this proposal, I get the idea that it is intended that each Compute 
instance run only one configuration management tool.  At least, most of 
the text discusses the support (e.g., the idea that each CM tool supplies 
userdata to bootstrap itself) in terms appropriate for a single CM tool 
per instance; also, there is no discussion of combining userdata from 
several CM tools.

I agree with the separation of concerns issues that have been raised.  I 
think all this software config stuff can be handled by a pre-processor 
that takes an extended template in and outputs a plain template that can 
be consumed by today's heat engine (no extension to the heat engine 
necessary).

Regards,
Mike
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev