Re: [openstack-dev] [Heat] HOT Software configuration proposal
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 marconi url/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 marconi url/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.
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
Re: [openstack-dev] [Heat] HOT Software configuration proposal
In-line comments.
On 10/28/13 5:43 PM, Steve Baker sba...@redhat.com 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 marconi url/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 marconi url/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.
My components proposals had no hosted_on, but I've been thinking about
the implications of implementing
Re: [openstack-dev] [Heat] HOT Software configuration proposal
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 marconi url/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 marconi url/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
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 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 to be
Re: [openstack-dev] [Heat] HOT Software configuration proposal
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 keith.b...@rackspace.com wrote on 25.10.2013 02:23:55: From: Keith Bray keith.b...@rackspace.com To: OpenStack Development Mailing List openstack-dev@lists.openstack.org, 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 thomas.spatz...@de.ibm.com 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 patrick.pe...@bull.net wrote on 24.10.2013 12:15:13: From: Patrick Petit patrick.pe...@bull.net To: OpenStack Development Mailing List openstack-dev@lists.openstack.org, 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
Re: [openstack-dev] [Heat] HOT Software configuration proposal
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 marconi url/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 marconi url/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
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 marconi url/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 marconi url/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
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
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 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
Re: [openstack-dev] [Heat] HOT Software configuration proposal
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 patrick.pe...@bull.net wrote on 24.10.2013 12:15:13: From: Patrick Petit patrick.pe...@bull.net To: OpenStack Development Mailing List openstack-dev@lists.openstack.org, 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 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
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 thomas.spatz...@de.ibm.com 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 patrick.pe...@bull.net wrote on 24.10.2013 12:15:13: From: Patrick Petit patrick.pe...@bull.net To: OpenStack Development Mailing List openstack-dev@lists.openstack.org, 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
Re: [openstack-dev] [Heat] HOT Software configuration proposal
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
Re: [openstack-dev] [Heat] HOT Software configuration proposal
Clint Byrum cl...@fewbar.com wrote on 23.10.2013 00:28:17:
From: Clint Byrum cl...@fewbar.com
To: openstack-dev openstack-dev@lists.openstack.org,
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=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
Re: [openstack-dev] [Heat] HOT Software configuration proposal
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
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 running idempotent recipes. This is our approach. The first
Re: [openstack-dev] [Heat] HOT Software configuration proposal
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 patrick.pe...@bull.netwrote: 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
Re: [openstack-dev] [Heat] HOT Software configuration proposal
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 cl...@fewbar.com 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 component type would have to support getting a cookbook from a public
Re: [openstack-dev] [Heat] HOT Software configuration proposal
Steve Baker sba...@redhat.com wrote on 21.10.2013 23:02:47:
From: Steve Baker sba...@redhat.com
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 sba...@redhat.com 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 conditionhandle
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 zookeeper handles software configuration
dependencies this would result in the state of the stack being split
between two different co-ordination mechanisms.
I think that zookeeper could be an _optional_ backend for this, but using
the current mechanisms in Heat should probably be the primary or default
way of doing this.
We've put quite some effort into heat engine to co-ordinate
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 ;) 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
Zane Bitter zbit...@redhat.com 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
Zane Bitter zbit...@redhat.com wrote on 22.10.2013 15:24:28:
From: Zane Bitter zbit...@redhat.com
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
On 22/10/13 16:35, Thomas Spatzier wrote:
Zane Bitter zbit...@redhat.com wrote on 22.10.2013 15:24:28:
From: Zane Bitter zbit...@redhat.com
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
Zane Bitter zbit...@redhat.com wrote on 22.10.2013 17:23:52:
From: Zane Bitter zbit...@redhat.com
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 zbit...@redhat.com wrote on 22.10.2013 15:24:28:
From: Zane Bitter zbit...@redhat.com
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
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 zbit...@redhat.com wrote on 22.10.2013 17:23:52:
From: Zane Bitter zbit...@redhat.com
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 zbit...@redhat.com wrote on 22.10.2013 15:24:28:
From: Zane Bitter zbit...@redhat.com
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
--
Sincerely yours
Stanislav (Stan) Lagun
Senior Developer
Mirantis
35b/3, Vorontsovskaya St.
Moscow, Russia
Skype: stanlagun
www.mirantis.com
sla...@mirantis.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
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 sla...@mirantis.com 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 zbit...@redhat.com wrote on 22.10.2013 17:23:52:
From: Zane Bitter zbit...@redhat.com
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 zbit...@redhat.com wrote on 22.10.2013 15:24:28:
From: Zane Bitter zbit...@redhat.com
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
Re: [openstack-dev] [Heat] HOT Software configuration proposal
Stan Lagun sla...@mirantis.com wrote on 22.10.2013 19:02:38:
From: Stan Lagun sla...@mirantis.com
To: OpenStack Development Mailing List
openstack-dev@lists.openstack.org,
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
thomas.spatz...@de.ibm.com
wrote:
Zane Bitter zbit...@redhat.com wrote on 22.10.2013 17:23:52:
From: Zane Bitter zbit...@redhat.com
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 zbit...@redhat.com wrote on 22.10.2013 15:24:28:
From: Zane Bitter zbit...@redhat.com
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
Re: [openstack-dev] [Heat] HOT Software configuration proposal
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 gokrokvertsk...@mirantis.com wrote on 22.10.2013 20:01:19: From: Georgy Okrokvertskhov gokrokvertsk...@mirantis.com To: OpenStack Development Mailing List openstack-dev@lists.openstack.org, 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 sla...@mirantis.com 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 zbit...@redhat.com wrote on 22.10.2013 17:23:52: From: Zane Bitter zbit...@redhat.com 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 zbit...@redhat.com wrote on 22.10.2013 15:24:28: From: Zane Bitter zbit...@redhat.com 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
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].
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
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 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 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
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 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 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
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 harlo...@yahoo-inc.comwrote:
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 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 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
___
Re: [openstack-dev] [Heat] HOT Software configuration proposal
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
gokrokvertsk...@mirantis.commailto:gokrokvertsk...@mirantis.com
Reply-To: OpenStack Development Mailing List
openstack-dev@lists.openstack.orgmailto:openstack-dev@lists.openstack.org
Date: Tuesday, October 22, 2013 4:53 PM
To: OpenStack Development Mailing List
openstack-dev@lists.openstack.orgmailto: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
harlo...@yahoo-inc.commailto: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 cl...@fewbar.commailto: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 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
Re: [openstack-dev] [Heat] HOT Software configuration proposal
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 harlo...@yahoo-inc.comwrote:
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 gokrokvertsk...@mirantis.com
Reply-To: OpenStack Development Mailing List
openstack-dev@lists.openstack.org
Date: Tuesday, October 22, 2013 4:53 PM
To: OpenStack Development Mailing List 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 harlo...@yahoo-inc.comwrote:
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 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
Re: [openstack-dev] [Heat] HOT Software configuration proposal
Steve Baker sba...@redhat.com 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 conditionhandle 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
On 21/10/13 15:45 -0400, Mike Spreitzer wrote: Steve Baker sba...@redhat.com 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 conditionhandle 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
On 10/22/2013 08:45 AM, Mike Spreitzer wrote: Steve Baker sba...@redhat.com 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 conditionhandle 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
(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
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
On Tue, Oct 15, 2013 at 09:21:12PM -0400, Mike Spreitzer wrote: Steve Baker sba...@redhat.com wrote on 10/15/2013 06:48:53 PM: From: Steve Baker sba...@redhat.com 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
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
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
Steven Hardy sha...@redhat.com 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
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 sba...@redhat.com wrote on 16.10.2013 00:48:53: From: Steve Baker sba...@redhat.com To: openstack-dev@lists.openstack.org, Date:
Re: [openstack-dev] [Heat] HOT Software configuration proposal
On 16/10/13 15:58, Mike Spreitzer wrote: Zane Bitter zbit...@redhat.com 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
Zane Bitter zbit...@redhat.com 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
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
Clint Byrum cl...@fewbar.com 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
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
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_relationships_hosted_on.2C_depends_on.2C_connects_to.3F I'll paste the
Re: [openstack-dev] [Heat] HOT Software configuration proposal
Steve Baker sba...@redhat.com wrote on 10/15/2013 06:48:53 PM: From: Steve Baker sba...@redhat.com 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
Re: [openstack-dev] [Heat] HOT Software configuration proposal
On 10/16/2013 02:21 PM, Mike Spreitzer wrote: Steve Baker sba...@redhat.com wrote on 10/15/2013 06:48:53 PM: From: Steve Baker sba...@redhat.com 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
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 one
