Re: [openstack-dev] [Heat] Comments on Steve Baker's Proposal on HOT Software Config
-Mike Spreitzer/Watson/IBM@IBMUS wrote: ->To: "OpenStack Development Mailing List \(not for usage questions\)">>From: Mike Spreitzer/Watson/IBM@IBMUS>Date: 10/30/2013 03:56PM>Subject: Re: [openstack-dev] [Heat] Comments on Steve Baker's>Proposal on HOT Software Config>>Lakshminaraya Renganarayana/Watson/IBM@IBMUS wrote on>10/30/2013 03:35:32 PM:>>>>> Zane Bitter wrote on 10/29/2013 08:46:21>AM:>>> ...>>> In this method >>> > (i.e. option (2) above) shouldn't we be building the dependency>graph in >>> > Heat rather than running through them sequentially as specified>by the >>> > user? In that case, we should use a dictionary not a list:>>> > >>> > app_server:>>> > type: OS::Nova::Server>>> > properties:>>> > components:>>> > install_user_profile:>>> > definition: InstallWasProfile>>> > params:>>> > user_id>>> > install_admin_profile:>>> > definition: InstallWasProfile>>> > params:>>> > admin_id>>> >>> I missed this implication of using a list! You are right, it should>be >>> a dictionary and Heat would be building the dependence graph. >>>>Using a dictionary instead of a list can work, but>I think we might be going overboard here. Do we expect the component>invocations on a given VM instance to run concurrently? I think that>has been dissed before. Chef users are happy to let a role be a list>of recipes, not a DAG. A list is simple; is there an actual problem>with it?Yes, there was some agreement on component invocations on a given VM instance being run sequentially. However, the issue here is slightly different. If, as a design principle, Heat analyzes dependences between component invocations,then it should do that irrespective of whether the component invocations are on the same VM or from different VMs. Given this, a list of component invocationswould imply an ordering which is in addition to the ordering induced by dependences.Whereas a dictionary would not impose any additional ordering.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] Comments on Steve Baker's Proposal on HOT Software Config
Zane Bitter wrote on 30.10.2013 22:33:31: > From: Zane Bitter > To: openstack-dev@lists.openstack.org, > Date: 30.10.2013 22:36 > Subject: Re: [openstack-dev] [Heat] Comments on Steve Baker's > Proposal on HOT Software Config > > On 30/10/13 20:35, Lakshminaraya Renganarayana wrote: > > >I'd like to see some more detail about how > > > inputs/outputs would be exposed in the configuration management systems > > > - or, more specifically, how the user can extend this to arbitrary > > > configuration management systems. > > > > The way inputs/outputs are exposed in a CM system > > would depend on its conventions. In our use with Chef, we expose these > > inputs and outputs as a Chef's node attributes, i.e., via the node[][] > > hash. I could imagine a similar scheme for Puppet. For a shell type of > > CM provider the inputs/outputs can be exposed as Shell environment > > variables. To avoid name conflicts, these inputs/outputs can be prefixed > > by a namespace, say Heat. > > Right, so who writes the code that exposes the inputs/outputs to the CM > system in that way? If it is the user, where does that code go and how > does it work? And if it's not the user, how would the user accommodate a > CM system that has not been envisioned by their provider? That's what > I'm trying to get at with this question. I think it is not the user who writes this binding code / glue code, but I envision a handful of component providers for the most common CM systems that implement the logic to (1) take data from Heat, (2) pass them to the CM system invocation, (3) wait for the CM system to report completion, (4) parse return data and pass it to Heat. So this is basically like an adapter, and for each such adapter it would have to be documented like the automation must be writen to work with it. E.g. in bash scripts the user can access all input as environment variables etc, or for Chef there mapping is like Lakshmi described it above. We have something like this implemented internally and I think such an implementation could be added to Heat. For any kind of custom CM system where we do not provide such an adapter, the user would have to write a plugin to handle the same logic. > > 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] Comments on Steve Baker's Proposal on HOT Software Config
On 30/10/13 20:35, Lakshminaraya Renganarayana wrote: >I'd like to see some more detail about how > inputs/outputs would be exposed in the configuration management systems > - or, more specifically, how the user can extend this to arbitrary > configuration management systems. The way inputs/outputs are exposed in a CM system would depend on its conventions. In our use with Chef, we expose these inputs and outputs as a Chef's node attributes, i.e., via the node[][] hash. I could imagine a similar scheme for Puppet. For a shell type of CM provider the inputs/outputs can be exposed as Shell environment variables. To avoid name conflicts, these inputs/outputs can be prefixed by a namespace, say Heat. Right, so who writes the code that exposes the inputs/outputs to the CM system in that way? If it is the user, where does that code go and how does it work? And if it's not the user, how would the user accommodate a CM system that has not been envisioned by their provider? That's what I'm trying to get at with this question. 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] Comments on Steve Baker's Proposal on HOT Software Config
Lakshminaraya Renganarayana/Watson/IBM@IBMUS wrote on 10/30/2013 03:35:32 PM: > Zane Bitter wrote on 10/29/2013 08:46:21 AM: > ... > In this method > > (i.e. option (2) above) shouldn't we be building the dependency graph in > > Heat rather than running through them sequentially as specified by the > > user? In that case, we should use a dictionary not a list: > > > >app_server: > > type: OS::Nova::Server > > properties: > >components: > > install_user_profile: > >definition: InstallWasProfile > >params: > > user_id > > install_admin_profile: > >definition: InstallWasProfile > >params: > > admin_id > > I missed this implication of using a list! You are right, it should be > a dictionary and Heat would be building the dependence graph. Using a dictionary instead of a list can work, but I think we might be going overboard here. Do we expect the component invocations on a given VM instance to run concurrently? I think that has been dissed before. Chef users are happy to let a role be a list of recipes, not a DAG. A list is simple; is there an actual problem with it? 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] Comments on Steve Baker's Proposal on HOT Software Config
Zane, thanks very much for the detailed feedback. I have added my comments inline. Zane Bitter wrote on 10/29/2013 08:46:21 AM: ... > As brief feedback on these suggestions: > E1: Probably +1 for inputs, but tentative -1 for attributes. I'm not > sure we can check anything useful with that other than internal > consistency of the template. The explicit specification of the attributes (or outputs) is aimed primarily at providing a name for the output so that they can be referred to in component invocations and also by software config providers (Chef or Puppet, etc.) to access them. The use of the attributes to check or validate is only a secondary aim and this could just be a consistency check with name matching. If we had more information such as types, constraints, about these attributes (similar to inputs of a template) we can validate more. But this is not the primary goal. >I'd like to see some more detail about how > inputs/outputs would be exposed in the configuration management systems > - or, more specifically, how the user can extend this to arbitrary > configuration management systems. The way inputs/outputs are exposed in a CM system would depend on its conventions. In our use with Chef, we expose these inputs and outputs as a Chef's node attributes, i.e., via the node[][] hash. I could imagine a similar scheme for Puppet. For a shell type of CM provider the inputs/outputs can be exposed as Shell environment variables. To avoid name conflicts, these inputs/outputs can be prefixed by a namespace, say Heat. > > E2: +1 for Opt1 > -1 for Opt2 (mixing namespaces is bad) > -1 for Opt3 Agreed -- we also prefer Opt1! > > E3: Sounds like a real issue (also, the solution for E2 has to take this > into account too); not sure about the implementation. Yes, agreed -- E2 has to understand which output from which invocation of a component is being used or referred to. With invocation_id's it should be possible to uniquely identify the component invocation. In this method > (i.e. option (2) above) shouldn't we be building the dependency graph in > Heat rather than running through them sequentially as specified by the > user? In that case, we should use a dictionary not a list: > >app_server: > type: OS::Nova::Server > properties: >components: > install_user_profile: >definition: InstallWasProfile >params: > user_id > install_admin_profile: >definition: InstallWasProfile >params: > admin_id I missed this implication of using a list! You are right, it should be a dictionary and Heat would be building the dependence graph. > E5: +1 but a question on where this is specified. In the component > definition itself, or in the particular invocation of it on a server? > Seems like it would have to be the latter. Good point. I think it could be specified on both places. It definitely could be specified on a particular invocation. I am not fully sure on this, but one can also imagine cases where a cross-component dependency is true for all invocations of a component, and hence might be specified as a part of the component definition as a dependency between two component types. 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] Comments on Steve Baker's Proposal on HOT Software Config
On Tue, Oct 29, 2013 at 01:50:59PM +0100, Zane Bitter wrote: > On 28/10/13 14:53, Steven Hardy wrote: > >On Sun, Oct 27, 2013 at 11:23:20PM -0400, Lakshminaraya Renganarayana wrote: > >>A few us at IBM studied Steve Baker's proposal on HOT Software > >>Configuration. Overall the proposed constructs and syntax are great -- we > >>really like the clean syntax and concise specification of components. We > >>would like to propose a few minor extensions that help with better > >>expression of dependencies among components and resources, and in-turn > >>enable cross-vm coordination. We have captured our thoughts on this on the > >>following Wiki page > >> > >>https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config-ibm-response > > > >Thanks for putting this together. I'll post inline below with cut/paste > >from the wiki followed by my response/question: > > > >>E2: Allow usage of component outputs (similar to resources): > >>There are fundamental differences between components and resources... > > > >So... lately I've been thinking this is not actually true, and that > >components are really just another type of resource. If we can implement > >the software-config functionality without inventing a new template > >abstraction, IMO a lot of the issues described in your wiki page no longer > >exist. > > > >Can anyone provide me with a clear argument for what the "fundamental > >differences" actually are? > > Here's an argument: Component deployments exist within a server > resource, so the dependencies don't work in the same way. The static > part of the configuration has to happen before the server is > created, but the actual runtime part is created after. So the > dependencies are inherently circular. So, good point, but I've been thinking about it from the other perspective: - Server gets created - SoftwareConfig is applied to server So the dependencies need not be circular, you have a SoftwareConfig resource, which references the Server and the SoftwareConfig definition. I guess this links back to stevebaker's previous comment tha the thing applying the software config would need a hosted_on property rather than OS::Nova::Server specifying a list of configs to apply. > >My opinion is we could do the following: > >- Implement software config "components" as ordinary resources, using the > > existing interfaces (perhaps with some enhancements to dependency > > declaration) > >- Give OS::Nova::Server a components property, which simply takes a list of > > resources which describe the software configuration(s) to be applied > > I think to overcome the problem described above, we would also need > to create a third type of resource. So we'd have a Configuration, a > Server and a Deployment. (In dependency terms, these are analogous > to WaitConditionHandle, Server and WaitCondition, or possibly EIP, > Server and EIPAssociation.) The deployment would reference the > server and the configuration, you could pass parameters into it get > attributes out of it, add explicit dependencies on it &c. Yep, so that's what I've been thinking too, Angus and I were chatting about ie earlier, and it seems like aligning with the existing pattern, used by EIP's and volumes would potentially solve the problem. However, you can cut out the "ConfigAttachment/ConfigApplier" resource, if you move to the hosted_on pattern suggested by Steve; > What I'm not clear on in this model is how much of the configuration > needs to be built to go onto the server (in the UserData?) before > the server is created, and how that would be represented in such a > way as to inherently create the correct dependency relationship > (i.e. get the _Server_ as well as the Deployment to depend on the > configuration). Yeah, so I think at some point, folks will have to make a choice about their preferred CM tool, and map things in their environment, such that the server gets built with the stuff required to e.g install the puppet agent into the instance, which then listens for the config from the config applier (which would know how to push the config to a puppet master I guess). So your environment could be: resource_registry: OS::Heat::Server: OS::Heat::PuppetSlaveServer OS::Heat::SoftwareConfig: OS::Heat::PuppetSoftwareConfig OS::Heat::PuppetSlaveServer could just be a provider resource, which creates a OS::Nova::Server and installs/configures the puppet client agents (or chef/salt/whatever). We could still maintain the status-quo by making the default to use heat-cfntools, where the initial UserData configures the things needed to make cfn-hup work, then cfn-hup polls for metadata updates which specify the config to be applied. The config you want to deploy could be defined via a (config tool agnositic) OS::Heat::SoftwareConfig resource, and the server it's applied to is either explicitly specified (via a parameter to the SoftwareConfig resource), or derived via allowing constraints to be specified for resources, si
Re: [openstack-dev] [Heat] Comments on Steve Baker's Proposal on HOT Software Config
Hi Steve, I am sorry for my confusing message. Just for clarification, I am against adding new abstracts to the HOT template. I just wanted to highlight that in Lakshminarayana proposal there are multiple steps which represent the same component in different stages. This might be confusing, because in you initial proposal you refer one component section for the whole component description, if I am not mistaken. Thanks Georgy On Tue, Oct 29, 2013 at 12:23 AM, Steven Hardy wrote: > On Mon, Oct 28, 2013 at 02:34:44PM -0700, Georgy Okrokvertskhov wrote: > > I believe we had a discussion about difference between declarative > approach > > and workflows. A component approach is consistent with declarative format > > as all actions\operations are hidden inside the service. If you want to > use > > actions and operations explicitly you will have to add a workflows > specific > > language to HOT format. You will need to have some conditions and other > > control structures. > > Please don't confuse the component/resource discussion further by adding > all these unrelated terms into the mix: > > - Resources are declarative, components aren't in any way more declarative > > - The resource/component discussion is unrelated to workflows, we're > discussing the template level interfaces. > > - Adding imperative control-flow interfaces to the template is the opposite > of a declarative approach > > > I also want to highlight that in most of examples on wiki pages there are > > actions instead of components. Just check names: install_mysql, > > configure_app. > > Having descriptions of the actions required to do configure an application > is not declarative. Having a resource define the properties of the > application is. > > > I think you revealed the major difference between resource and component. > > While the first has a fixed API and Heat already knows how to work with > it, > > A resource doesn't have a fixed API as such - it has flexible, > user-definable > interfaces (inputs/properties and outputs/attributes) > > > components are not determined and Heat does not know what this component > > actually does. > > Heat doesn't need to know what a resource or component actually does, it > needs to know what do do with the inputs/properties, and how to obtain the > outputs/attributes. > > > I remember the first draft for Software components and it > > had a specific examples for yum invocation for package installation. This > > is a good example of declarative component. When scripts and recipes > > appeared a component definition was blurred. > > This makes no sense, scripts defining platform specific installation > methods are the exact opposite of a declarative component. > > The blurred component definition you refer to is a very good reason not to > add a new abstraction IMO - we should focus on adding the functionality via > the existing, well understood interfaces. > > Steve > > ___ > 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] Comments on Steve Baker's Proposal on HOT Software Config
I am wondering on the execution semantics of these components or software config resources with respect to restart or re-execution. Coming from a iterative development and deployment angle, I would like these software config resources to be idempotent. What are your thoughts? Thanks, LN Steven Hardy wrote on 10/29/2013 03:23:14 AM: > From: Steven Hardy > To: "OpenStack Development Mailing List (not for usage questions)" > > Date: 10/29/2013 03:28 AM > Subject: Re: [openstack-dev] [Heat] Comments on Steve Baker's > Proposal on HOT Software Config > > On Mon, Oct 28, 2013 at 02:34:44PM -0700, Georgy Okrokvertskhov wrote: > > I believe we had a discussion about difference between declarative approach > > and workflows. A component approach is consistent with declarative format > > as all actions\operations are hidden inside the service. If you want to use > > actions and operations explicitly you will have to add a workflows specific > > language to HOT format. You will need to have some conditions and other > > control structures. > > Please don't confuse the component/resource discussion further by adding > all these unrelated terms into the mix: > > - Resources are declarative, components aren't in any way more declarative > > - The resource/component discussion is unrelated to workflows, we're > discussing the template level interfaces. > > - Adding imperative control-flow interfaces to the template is the opposite > of a declarative approach > > > I also want to highlight that in most of examples on wiki pages there are > > actions instead of components. Just check names: install_mysql, > > configure_app. > > Having descriptions of the actions required to do configure an application > is not declarative. Having a resource define the properties of the > application is. > > > I think you revealed the major difference between resource and component. > > While the first has a fixed API and Heat already knows how to work with it, > > A resource doesn't have a fixed API as such - it has flexible, user-definable > interfaces (inputs/properties and outputs/attributes) > > > components are not determined and Heat does not know what this component > > actually does. > > Heat doesn't need to know what a resource or component actually does, it > needs to know what do do with the inputs/properties, and how to obtain the > outputs/attributes. > > > I remember the first draft for Software components and it > > had a specific examples for yum invocation for package installation. This > > is a good example of declarative component. When scripts and recipes > > appeared a component definition was blurred. > > This makes no sense, scripts defining platform specific installation > methods are the exact opposite of a declarative component. > > The blurred component definition you refer to is a very good reason not to > add a new abstraction IMO - we should focus on adding the functionality via > the existing, well understood interfaces. > > Steve > > ___ > 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] Comments on Steve Baker's Proposal on HOT Software Config
On 28/10/13 14:53, Steven Hardy wrote: On Sun, Oct 27, 2013 at 11:23:20PM -0400, Lakshminaraya Renganarayana wrote: A few us at IBM studied Steve Baker's proposal on HOT Software Configuration. Overall the proposed constructs and syntax are great -- we really like the clean syntax and concise specification of components. We would like to propose a few minor extensions that help with better expression of dependencies among components and resources, and in-turn enable cross-vm coordination. We have captured our thoughts on this on the following Wiki page https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config-ibm-response Thanks for putting this together. I'll post inline below with cut/paste from the wiki followed by my response/question: E2: Allow usage of component outputs (similar to resources): There are fundamental differences between components and resources... So... lately I've been thinking this is not actually true, and that components are really just another type of resource. If we can implement the software-config functionality without inventing a new template abstraction, IMO a lot of the issues described in your wiki page no longer exist. Can anyone provide me with a clear argument for what the "fundamental differences" actually are? Here's an argument: Component deployments exist within a server resource, so the dependencies don't work in the same way. The static part of the configuration has to happen before the server is created, but the actual runtime part is created after. So the dependencies are inherently circular. My opinion is we could do the following: - Implement software config "components" as ordinary resources, using the existing interfaces (perhaps with some enhancements to dependency declaration) - Give OS::Nova::Server a components property, which simply takes a list of resources which describe the software configuration(s) to be applied I think to overcome the problem described above, we would also need to create a third type of resource. So we'd have a Configuration, a Server and a Deployment. (In dependency terms, these are analogous to WaitConditionHandle, Server and WaitCondition, or possibly EIP, Server and EIPAssociation.) The deployment would reference the server and the configuration, you could pass parameters into it get attributes out of it, add explicit dependencies on it &c. What I'm not clear on in this model is how much of the configuration needs to be built to go onto the server (in the UserData?) before the server is created, and how that would be represented in such a way as to inherently create the correct dependency relationship (i.e. get the _Server_ as well as the Deployment to depend on the configuration). This provides a lot of benefits: - Uniformity of interfaces (solves many of the interface-mapping issues you discuss in the wiki) - Can use provider resources and environments functionality unmodified - Conceptually simple, we don't have to confuse everyone with a new abstraction sub-type and related terminology - Resources describing software components will be stateful, as described in (E4), only the states would be the existing resource states, e.g CREATE, IN_PROGRESS == CONFIGURING, and CREATE, COMPLETE == CONFIG_COMPLETE +1 if we can do it. 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] Comments on Steve Baker's Proposal on HOT Software Config
On 28/10/13 04:23, Lakshminaraya Renganarayana wrote: Sorry, Re-posting this with [Heat] in the subject line, because many of us have filters based on [Heat] in the subject line. Hello, A few us at IBM studied Steve Baker's proposal on HOT Software Configuration. Overall the proposed constructs and syntax are great -- we really like the clean syntax and concise specification of components. We would like to propose a few minor extensions that help with better expression of dependencies among components and resources, and in-turn enable cross-vm coordination. We have captured our thoughts on this on the following Wiki page _ __https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config-ibm-response_ We would like to discuss these further ... please post your comments and suggestions. Thanks for posting this! It seems to me like there may be one basic idea behind many of the differences between this and Steve's proposal. I'm going to try to explain the dichotomy, and let me know if I haven't understood correctly, but if I have then this is probably the first question we want to answer. (Note that some of the suggestions are definitely applicable regardless.) So basically, the two options I see are: 1) Configurations represent entire software 'packages'; outputs are provided asynchronously as they become available and dependent packages can synchronise on them. Basically like WaitConditions now. (Steve B.) 2) Configurations represent individual steps in the deployment of a package; outputs are provided at the end of each configuration and dependent packages are synchronised purely on the graph of configs. (Lakshmi et. al.) (I wrote this before seeing Georgy's comments, but I believe he has picked up on the same thing.) I'm on the fence here. I lean toward the latter for implementation-related reasons, though the former seems like it would probably be tidier for users. I think getting a concrete idea of how outputs would be signalled within the config management system in the former system would allow us to compare it better to the latter system (which is described to a moderate level of detail already on this wiki page). As brief feedback on these suggestions: E1: Probably +1 for inputs, but tentative -1 for attributes. I'm not sure we can check anything useful with that other than internal consistency of the template. I'd like to see some more detail about how inputs/outputs would be exposed in the configuration management systems - or, more specifically, how the user can extend this to arbitrary configuration management systems. E2: +1 for Opt1 -1 for Opt2 (mixing namespaces is bad) -1 for Opt3 E3: Sounds like a real issue (also, the solution for E2 has to take this into account too); not sure about the implementation. In this method (i.e. option (2) above) shouldn't we be building the dependency graph in Heat rather than running through them sequentially as specified by the user? In that case, we should use a dictionary not a list: app_server: type: OS::Nova::Server properties: components: install_user_profile: definition: InstallWasProfile params: user_id install_admin_profile: definition: InstallWasProfile params: admin_id E4: +1 E5: +1 but a question on where this is specified. In the component definition itself, or in the particular invocation of it on a server? Seems like it would have to be the latter. 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] Comments on Steve Baker's Proposal on HOT Software Config
On Mon, Oct 28, 2013 at 02:34:44PM -0700, Georgy Okrokvertskhov wrote: > I believe we had a discussion about difference between declarative approach > and workflows. A component approach is consistent with declarative format > as all actions\operations are hidden inside the service. If you want to use > actions and operations explicitly you will have to add a workflows specific > language to HOT format. You will need to have some conditions and other > control structures. Please don't confuse the component/resource discussion further by adding all these unrelated terms into the mix: - Resources are declarative, components aren't in any way more declarative - The resource/component discussion is unrelated to workflows, we're discussing the template level interfaces. - Adding imperative control-flow interfaces to the template is the opposite of a declarative approach > I also want to highlight that in most of examples on wiki pages there are > actions instead of components. Just check names: install_mysql, > configure_app. Having descriptions of the actions required to do configure an application is not declarative. Having a resource define the properties of the application is. > I think you revealed the major difference between resource and component. > While the first has a fixed API and Heat already knows how to work with it, A resource doesn't have a fixed API as such - it has flexible, user-definable interfaces (inputs/properties and outputs/attributes) > components are not determined and Heat does not know what this component > actually does. Heat doesn't need to know what a resource or component actually does, it needs to know what do do with the inputs/properties, and how to obtain the outputs/attributes. > I remember the first draft for Software components and it > had a specific examples for yum invocation for package installation. This > is a good example of declarative component. When scripts and recipes > appeared a component definition was blurred. This makes no sense, scripts defining platform specific installation methods are the exact opposite of a declarative component. The blurred component definition you refer to is a very good reason not to add a new abstraction IMO - we should focus on adding the functionality via the existing, well understood interfaces. Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Comments on Steve Baker's Proposal on HOT Software Config
On Mon, Oct 28, 2013 at 04:48:45PM -0400, Mike Spreitzer wrote:
> Steve Baker wrote on 10/28/2013 04:24:30 PM:
>
> > On 10/29/2013 02:53 AM, Steven Hardy wrote:
> > > ...
> > > Can anyone provide me with a clear argument for what the "fundamental
> > > differences" actually are?
> > ...
> > Since writing those proposals my thinking has evolved too. I'm currently
> > thinking it would be best to implement software configuration resources
> > rather than create a new component construct.
>
> Please pardon the newbie question, but I do not understand. A resource
> type is implemented in OpenStack code --- a part of Heat that calls a
> fixed service API that expects Keystone credentials.
This is not true at all.
A resource is simply an abstraction, a container for data, possibly logic,
which has interfaces (inputs/properties, and outputs/attributes)
There a several ways to define a resource. One of them is to write a Heat
python plugin, which may, or may not talk to another OpenStack API, but
this is completely unrelated to the concept of a resource.
Another way to define a resource is via a Heat template ("Provider"
resources, combined with environments). This is a convenient way for users
to define their own resources, and to layer additional data, logic and
dependencies on top of existing Heat built-in resources.
> A component is
> implemented by a bit of user code (and/or other sorts of instructions)
> embedded in or referenced by a template, with no fixed API and not invoked
> with Keystone credentials. We desire the heat engine to invoke operations
> on resources; we do not desire the heat engine to invoke components (the
> VMs do that themselves, via whatever bootstrapping mechanism is used). So
> yes, I do see fundamental differences. What am I missing?
A component is simply some user-provided data, possibly combined with some
logic, which needs to be passed to some resource (or service, or
in-instance tool) which knows how to interpret it.
So the existing resource interface is a perfectly appropriate abstraction
to use to describe what folks have been calling components, IMO.
If we can avoid creating a new template abstraction, we avoid a whole pile
of complexity, as well as user confusion - it's much better to leverage what
we have, unless the abstraction turns out to be fundamentally incompatible
with the feature (my argument is that it's not).
Steve
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Comments on Steve Baker's Proposal on HOT Software Config
Georgy Okrokvertskhov wrote on 10/28/2013 02:18:42 PM: > > I believe the extensions you proposed will extend HOT software > components usability. In general I have only one concern related to > components naming. In your examples you have software components > like install_mysql (you got it from Steve's example) and configure_app. > I would say, that these components are not software components, but > some actions on software components. This is a small deviation from > declarative approach as in general declarative objects more or less > independent while actions are naturally have some sequence. For > example your configure_app should not be executed before install_app > and technically it is the same component on different stages. I > don't know what is inside puppet manifest in configure_app but it > might contain app installation phase or might not. > > From my perspective it will be better to add some concepts of > actions for components and have some predefined actions like > pre_install, install, post_install and probably some custom actions. > This will be more clear approach then declaring action as a software > component. This is quite typical approach in different PaaS solutions. I agree with you that the components in the proposal and our examples resemble more of actions. In fact, we actually find them similar to the concept of "automations" which is a generic term used to refer to any kind of script/recipes/etc. that does software install/configuration. So, I am open to a better name for them. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Comments on Steve Baker's Proposal on HOT Software Config
Robert Collins wrote on 10/28/2013 02:47:53 PM: > BTW I found it a little weird that you replied as a new > blueprint-scoped wiki page rather than an email, or as a discussion > page on Steve's page. It was a bit too long to directly post as an email text on the mailing list. Also, posting it as a wiki page allowed me to format it better. I did not know what is preferred and hence chose the separate page. I am perfectly fine with posting as a discussion on Steve's page. Let me know. > Your proposal for both delivering parameters to components and getting > output from components suffer from namespace confusion. For instance, > if I had a parameter called HOME, it would play havoc with the > behaviour of shell scripts. Likewise if I had an output call params > with your opt2 approach. > > As a general principle, separate namespaces are a good thing, so I > propose that parameters to things that will run in-instance should be > passed in in a dedicated namespace. I fully agree with you -- a separate dedicated namespace is best. > > This could be e.g. HEAT.param_name, or (better yet) not passed in at > all, and instead permit the component to query the metadata for the > parameters it needs from the machine metadata. This preserves > separation of concerns: Heat doesn't need to know how to invoke the > component, and the component has a well known interface for getting > it's parameters. Handling of multi-invocation components would then > become a scatter-gather approach: your WASP registration example would > invoke that component once and it would find some N profiles to > register when it queries it's metadata. Agree with you on the use of metadata service -- we also thought of the inputs and outputs of component invocations being stored and retrieved by the component providers from the Heat metadata service. > > (BTW, have a look at > http://git.openstack.org/cgit/openstack/os-collect-config and > http://git.openstack.org/cgit/openstack/os-apply-config for one > implementation of this strategy - it's what we're using in TripleO). Thanks for the pointers. I will look at them. > > For outputs, I think a similar strategy - having a well defined means > to upload metadata to heat - is all that's needed. Agreed. > -Rob > > > > > Hello, > > > > A few us at IBM studied Steve Baker's proposal on HOT Software > > Configuration. Overall the proposed constructs and syntax are great -- we > > really like the clean syntax and concise specification of components. We > > would like to propose a few minor extensions that help with better > > expression of dependencies among components and resources, and in-turn > > enable cross-vm coordination. We have captured our thoughts on this on the > > following Wiki page > > > > > -- > Robert Collins > Distinguished Technologist > HP Converged Cloud > > ___ > 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] Comments on Steve Baker's Proposal on HOT Software Config
>A component is implemented by a bit of user code (and/or other sorts of instructions) >embedded in or referenced by a template, with no fixed API and not invoked with Keystone >credentials. We desire the heat engine to invoke operations on resources; we do not desire >the heat engine to invoke components (the VMs do that themselves, via whatever >bootstrapping mechanism is used). I believe we had a discussion about difference between declarative approach and workflows. A component approach is consistent with declarative format as all actions\operations are hidden inside the service. If you want to use actions and operations explicitly you will have to add a workflows specific language to HOT format. You will need to have some conditions and other control structures. I also want to highlight that in most of examples on wiki pages there are actions instead of components. Just check names: install_mysql, configure_app. I think you revealed the major difference between resource and component. While the first has a fixed API and Heat already knows how to work with it, components are not determined and Heat does not know what this component actually does. I remember the first draft for Software components and it had a specific examples for yum invocation for package installation. This is a good example of declarative component. When scripts and recipes appeared a component definition was blurred. Thanks, Georgy On Mon, Oct 28, 2013 at 1:48 PM, Mike Spreitzer wrote: > Steve Baker wrote on 10/28/2013 04:24:30 PM: > > > > On 10/29/2013 02:53 AM, Steven Hardy wrote: > > > ... > > > > Can anyone provide me with a clear argument for what the "fundamental > > > differences" actually are? > > ... > > > Since writing those proposals my thinking has evolved too. I'm currently > > thinking it would be best to implement software configuration resources > > rather than create a new component construct. > > Please pardon the newbie question, but I do not understand. A resource > type is implemented in OpenStack code --- a part of Heat that calls a fixed > service API that expects Keystone credentials. A component is implemented > by a bit of user code (and/or other sorts of instructions) embedded in or > referenced by a template, with no fixed API and not invoked with Keystone > credentials. We desire the heat engine to invoke operations on resources; > we do not desire the heat engine to invoke components (the VMs do that > themselves, via whatever bootstrapping mechanism is used). So yes, I do > see fundamental differences. What am I missing? > > Thanks, > Mike > ___ > 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] Comments on Steve Baker's Proposal on HOT Software Config
Steve Baker wrote on 10/28/2013 04:24:30 PM: > On 10/29/2013 02:53 AM, Steven Hardy wrote: > > ... > > Can anyone provide me with a clear argument for what the "fundamental > > differences" actually are? > ... > Since writing those proposals my thinking has evolved too. I'm currently > thinking it would be best to implement software configuration resources > rather than create a new component construct. Please pardon the newbie question, but I do not understand. A resource type is implemented in OpenStack code --- a part of Heat that calls a fixed service API that expects Keystone credentials. A component is implemented by a bit of user code (and/or other sorts of instructions) embedded in or referenced by a template, with no fixed API and not invoked with Keystone credentials. We desire the heat engine to invoke operations on resources; we do not desire the heat engine to invoke components (the VMs do that themselves, via whatever bootstrapping mechanism is used). So yes, I do see fundamental differences. What am I missing? 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] Comments on Steve Baker's Proposal on HOT Software Config
On 10/29/2013 02:53 AM, Steven Hardy wrote: > On Sun, Oct 27, 2013 at 11:23:20PM -0400, Lakshminaraya Renganarayana wrote: >> A few us at IBM studied Steve Baker's proposal on HOT Software >> Configuration. Overall the proposed constructs and syntax are great -- we >> really like the clean syntax and concise specification of components. We >> would like to propose a few minor extensions that help with better >> expression of dependencies among components and resources, and in-turn >> enable cross-vm coordination. We have captured our thoughts on this on the >> following Wiki page >> >> https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config-ibm-response > Thanks for putting this together. I'll post inline below with cut/paste > from the wiki followed by my response/question: > >> E2: Allow usage of component outputs (similar to resources): >> There are fundamental differences between components and resources... > So... lately I've been thinking this is not actually true, and that > components are really just another type of resource. If we can implement > the software-config functionality without inventing a new template > abstraction, IMO a lot of the issues described in your wiki page no longer > exist. > > Can anyone provide me with a clear argument for what the "fundamental > differences" actually are? > > My opinion is we could do the following: > - Implement software config "components" as ordinary resources, using the > existing interfaces (perhaps with some enhancements to dependency > declaration) > - Give OS::Nova::Server a components property, which simply takes a list of > resources which describe the software configuration(s) to be applied > > This provides a lot of benefits: > - Uniformity of interfaces (solves many of the interface-mapping issues you > discuss in the wiki) > - Can use provider resources and environments functionality unmodified > - Conceptually simple, we don't have to confuse everyone with a new > abstraction sub-type and related terminology > - Resources describing software components will be stateful, as described > in (E4), only the states would be the existing resource states, e.g > CREATE, IN_PROGRESS == CONFIGURING, and CREATE, COMPLETE == > CONFIG_COMPLETE > > Thoughts? Since writing those proposals my thinking has evolved too. I'm currently thinking it would be best to implement software configuration resources rather than create a new component construct. To me, a natural consequence of configuration resources would be a hosted_on property rather than OS::Nova::Server components property, but I'll elaborate on that elsewhere. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Comments on Steve Baker's Proposal on HOT Software Config
On 28 October 2013 16:23, Lakshminaraya Renganarayana wrote: > Sorry, Re-posting this with [Heat] in the subject line, because many of us > have filters based on [Heat] in the subject line. Thanks. BTW I found it a little weird that you replied as a new blueprint-scoped wiki page rather than an email, or as a discussion page on Steve's page. Anyhow. Your proposal for both delivering parameters to components and getting output from components suffer from namespace confusion. For instance, if I had a parameter called HOME, it would play havoc with the behaviour of shell scripts. Likewise if I had an output call params with your opt2 approach. As a general principle, separate namespaces are a good thing, so I propose that parameters to things that will run in-instance should be passed in in a dedicated namespace. This could be e.g. HEAT.param_name, or (better yet) not passed in at all, and instead permit the component to query the metadata for the parameters it needs from the machine metadata. This preserves separation of concerns: Heat doesn't need to know how to invoke the component, and the component has a well known interface for getting it's parameters. Handling of multi-invocation components would then become a scatter-gather approach: your WASP registration example would invoke that component once and it would find some N profiles to register when it queries it's metadata. (BTW, have a look at http://git.openstack.org/cgit/openstack/os-collect-config and http://git.openstack.org/cgit/openstack/os-apply-config for one implementation of this strategy - it's what we're using in TripleO). For outputs, I think a similar strategy - having a well defined means to upload metadata to heat - is all that's needed. -Rob > > Hello, > > A few us at IBM studied Steve Baker's proposal on HOT Software > Configuration. Overall the proposed constructs and syntax are great -- we > really like the clean syntax and concise specification of components. We > would like to propose a few minor extensions that help with better > expression of dependencies among components and resources, and in-turn > enable cross-vm coordination. We have captured our thoughts on this on the > following Wiki page -- Robert Collins Distinguished Technologist HP Converged Cloud ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Comments on Steve Baker's Proposal on HOT Software Config
Hi Lakshminarayanan, I believe the extensions you proposed will extend HOT software components usability. In general I have only one concern related to components naming. In your examples you have software components like install_mysql (you got it from Steve's example) and configure_app. I would say, that these components are not software components, but some actions on software components. This is a small deviation from declarative approach as in general declarative objects more or less independent while actions are naturally have some sequence. For example your configure_app should not be executed before install_app and technically it is the same component on different stages. I don't know what is inside puppet manifest in configure_app but it might contain app installation phase or might not. >From my perspective it will be better to add some concepts of actions for components and have some predefined actions like pre_install, install, post_install and probably some custom actions. This will be more clear approach then declaring action as a software component. This is quite typical approach in different PaaS solutions. Thanks Georgy On Mon, Oct 28, 2013 at 8:08 AM, Randall Burt wrote: > > On Oct 28, 2013, at 9:49 AM, Steven Hardy wrote: > > > On Mon, Oct 28, 2013 at 02:33:40PM +, Randall Burt wrote: > >> > >> On Oct 28, 2013, at 8:53 AM, Steven Hardy > >> wrote: > >> > >>> On Sun, Oct 27, 2013 at 11:23:20PM -0400, Lakshminaraya Renganarayana > wrote: > A few us at IBM studied Steve Baker's proposal on HOT Software > Configuration. Overall the proposed constructs and syntax are great > -- we > really like the clean syntax and concise specification of components. > We > would like to propose a few minor extensions that help with better > expression of dependencies among components and resources, and in-turn > enable cross-vm coordination. We have captured our thoughts on this > on the > following Wiki page > > > https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config-ibm-response > >>> > >>> Thanks for putting this together. I'll post inline below with > cut/paste > >>> from the wiki followed by my response/question: > >>> > E2: Allow usage of component outputs (similar to resources): > There are fundamental differences between components and resources... > >>> > >>> So... lately I've been thinking this is not actually true, and that > >>> components are really just another type of resource. If we can > implement > >>> the software-config functionality without inventing a new template > >>> abstraction, IMO a lot of the issues described in your wiki page no > longer > >>> exist. > >>> > >>> Can anyone provide me with a clear argument for what the "fundamental > >>> differences" actually are? > >>> > >>> My opinion is we could do the following: > >>> - Implement software config "components" as ordinary resources, using > the > >>> existing interfaces (perhaps with some enhancements to dependency > >>> declaration) > >>> - Give OS::Nova::Server a components property, which simply takes a > list of > >>> resources which describe the software configuration(s) to be applied > >> > >> I see the appeal here, but I'm leaning toward having the components > define the resources they apply to rather than extending the interfaces of > every compute-related resource we have or may have in the future. True, > this may make things trickier in some respects with regard to bootstrapping > the compute resource, but then again, don't most configuration management > systems work on active compute instances? > > > > What "every" though? Don't we have exactly one compute resource, > > OS::Nova::Server? (I'm assuming this functionality won't be available > via > > AWS compatible Instance resource) > > Yes, I suppose it wouldn't do to go extending the AWS compatibility > interface with this functionality, so I withdraw my concern. > > > > > Steve > > > > ___ > > 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 > -- 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] Comments on Steve Baker's Proposal on HOT Software Config
On Oct 28, 2013, at 9:49 AM, Steven Hardy wrote: > On Mon, Oct 28, 2013 at 02:33:40PM +, Randall Burt wrote: >> >> On Oct 28, 2013, at 8:53 AM, Steven Hardy >> wrote: >> >>> On Sun, Oct 27, 2013 at 11:23:20PM -0400, Lakshminaraya Renganarayana wrote: A few us at IBM studied Steve Baker's proposal on HOT Software Configuration. Overall the proposed constructs and syntax are great -- we really like the clean syntax and concise specification of components. We would like to propose a few minor extensions that help with better expression of dependencies among components and resources, and in-turn enable cross-vm coordination. We have captured our thoughts on this on the following Wiki page https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config-ibm-response >>> >>> Thanks for putting this together. I'll post inline below with cut/paste >>> from the wiki followed by my response/question: >>> E2: Allow usage of component outputs (similar to resources): There are fundamental differences between components and resources... >>> >>> So... lately I've been thinking this is not actually true, and that >>> components are really just another type of resource. If we can implement >>> the software-config functionality without inventing a new template >>> abstraction, IMO a lot of the issues described in your wiki page no longer >>> exist. >>> >>> Can anyone provide me with a clear argument for what the "fundamental >>> differences" actually are? >>> >>> My opinion is we could do the following: >>> - Implement software config "components" as ordinary resources, using the >>> existing interfaces (perhaps with some enhancements to dependency >>> declaration) >>> - Give OS::Nova::Server a components property, which simply takes a list of >>> resources which describe the software configuration(s) to be applied >> >> I see the appeal here, but I'm leaning toward having the components define >> the resources they apply to rather than extending the interfaces of every >> compute-related resource we have or may have in the future. True, this may >> make things trickier in some respects with regard to bootstrapping the >> compute resource, but then again, don't most configuration management >> systems work on active compute instances? > > What "every" though? Don't we have exactly one compute resource, > OS::Nova::Server? (I'm assuming this functionality won't be available via > AWS compatible Instance resource) Yes, I suppose it wouldn't do to go extending the AWS compatibility interface with this functionality, so I withdraw my concern. > > Steve > > ___ > 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] Comments on Steve Baker's Proposal on HOT Software Config
On Mon, Oct 28, 2013 at 02:33:40PM +, Randall Burt wrote: > > On Oct 28, 2013, at 8:53 AM, Steven Hardy > wrote: > > > On Sun, Oct 27, 2013 at 11:23:20PM -0400, Lakshminaraya Renganarayana wrote: > >> A few us at IBM studied Steve Baker's proposal on HOT Software > >> Configuration. Overall the proposed constructs and syntax are great -- we > >> really like the clean syntax and concise specification of components. We > >> would like to propose a few minor extensions that help with better > >> expression of dependencies among components and resources, and in-turn > >> enable cross-vm coordination. We have captured our thoughts on this on the > >> following Wiki page > >> > >> https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config-ibm-response > > > > Thanks for putting this together. I'll post inline below with cut/paste > > from the wiki followed by my response/question: > > > >> E2: Allow usage of component outputs (similar to resources): > >> There are fundamental differences between components and resources... > > > > So... lately I've been thinking this is not actually true, and that > > components are really just another type of resource. If we can implement > > the software-config functionality without inventing a new template > > abstraction, IMO a lot of the issues described in your wiki page no longer > > exist. > > > > Can anyone provide me with a clear argument for what the "fundamental > > differences" actually are? > > > > My opinion is we could do the following: > > - Implement software config "components" as ordinary resources, using the > > existing interfaces (perhaps with some enhancements to dependency > > declaration) > > - Give OS::Nova::Server a components property, which simply takes a list of > > resources which describe the software configuration(s) to be applied > > I see the appeal here, but I'm leaning toward having the components define > the resources they apply to rather than extending the interfaces of every > compute-related resource we have or may have in the future. True, this may > make things trickier in some respects with regard to bootstrapping the > compute resource, but then again, don't most configuration management systems > work on active compute instances? What "every" though? Don't we have exactly one compute resource, OS::Nova::Server? (I'm assuming this functionality won't be available via AWS compatible Instance resource) Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Comments on Steve Baker's Proposal on HOT Software Config
On Oct 28, 2013, at 8:53 AM, Steven Hardy wrote: > On Sun, Oct 27, 2013 at 11:23:20PM -0400, Lakshminaraya Renganarayana wrote: >> A few us at IBM studied Steve Baker's proposal on HOT Software >> Configuration. Overall the proposed constructs and syntax are great -- we >> really like the clean syntax and concise specification of components. We >> would like to propose a few minor extensions that help with better >> expression of dependencies among components and resources, and in-turn >> enable cross-vm coordination. We have captured our thoughts on this on the >> following Wiki page >> >> https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config-ibm-response > > Thanks for putting this together. I'll post inline below with cut/paste > from the wiki followed by my response/question: > >> E2: Allow usage of component outputs (similar to resources): >> There are fundamental differences between components and resources... > > So... lately I've been thinking this is not actually true, and that > components are really just another type of resource. If we can implement > the software-config functionality without inventing a new template > abstraction, IMO a lot of the issues described in your wiki page no longer > exist. > > Can anyone provide me with a clear argument for what the "fundamental > differences" actually are? > > My opinion is we could do the following: > - Implement software config "components" as ordinary resources, using the > existing interfaces (perhaps with some enhancements to dependency > declaration) > - Give OS::Nova::Server a components property, which simply takes a list of > resources which describe the software configuration(s) to be applied I see the appeal here, but I'm leaning toward having the components define the resources they apply to rather than extending the interfaces of every compute-related resource we have or may have in the future. True, this may make things trickier in some respects with regard to bootstrapping the compute resource, but then again, don't most configuration management systems work on active compute instances? > > This provides a lot of benefits: > - Uniformity of interfaces (solves many of the interface-mapping issues you > discuss in the wiki) > - Can use provider resources and environments functionality unmodified > - Conceptually simple, we don't have to confuse everyone with a new > abstraction sub-type and related terminology > - Resources describing software components will be stateful, as described > in (E4), only the states would be the existing resource states, e.g > CREATE, IN_PROGRESS == CONFIGURING, and CREATE, COMPLETE == > CONFIG_COMPLETE > > Thoughts? Completely agree here. So far, I've not seen how components differ from resources save for some name and superficial syntax changes. Ordering component resources can likely be achieved with the existing "depends-on" functionality as well. > > Steve > > ___ > 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] Comments on Steve Baker's Proposal on HOT Software Config
On Sun, Oct 27, 2013 at 11:23:20PM -0400, Lakshminaraya Renganarayana wrote: > A few us at IBM studied Steve Baker's proposal on HOT Software > Configuration. Overall the proposed constructs and syntax are great -- we > really like the clean syntax and concise specification of components. We > would like to propose a few minor extensions that help with better > expression of dependencies among components and resources, and in-turn > enable cross-vm coordination. We have captured our thoughts on this on the > following Wiki page > > https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config-ibm-response Thanks for putting this together. I'll post inline below with cut/paste from the wiki followed by my response/question: > E2: Allow usage of component outputs (similar to resources): > There are fundamental differences between components and resources... So... lately I've been thinking this is not actually true, and that components are really just another type of resource. If we can implement the software-config functionality without inventing a new template abstraction, IMO a lot of the issues described in your wiki page no longer exist. Can anyone provide me with a clear argument for what the "fundamental differences" actually are? My opinion is we could do the following: - Implement software config "components" as ordinary resources, using the existing interfaces (perhaps with some enhancements to dependency declaration) - Give OS::Nova::Server a components property, which simply takes a list of resources which describe the software configuration(s) to be applied This provides a lot of benefits: - Uniformity of interfaces (solves many of the interface-mapping issues you discuss in the wiki) - Can use provider resources and environments functionality unmodified - Conceptually simple, we don't have to confuse everyone with a new abstraction sub-type and related terminology - Resources describing software components will be stateful, as described in (E4), only the states would be the existing resource states, e.g CREATE, IN_PROGRESS == CONFIGURING, and CREATE, COMPLETE == CONFIG_COMPLETE Thoughts? Steve ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Heat] Comments on Steve Baker's Proposal on HOT Software Config
Sorry, Re-posting this with [Heat] in the subject line, because many of us have filters based on [Heat] in the subject line. Hello, A few us at IBM studied Steve Baker's proposal on HOT Software Configuration. Overall the proposed constructs and syntax are great -- we really like the clean syntax and concise specification of components. We would like to propose a few minor extensions that help with better expression of dependencies among components and resources, and in-turn enable cross-vm coordination. We have captured our thoughts on this on the following Wiki page https://wiki.openstack.org/wiki/Heat/Blueprints/hot-software-config-ibm-response We would like to discuss these further ... please post your comments and suggestions. Thank you, LN _ Lakshminarayanan Renganarayana Research Staff Member IBM T.J. Watson Research Center___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
