Re: [openstack-dev] [Heat] Some thoughts on the mapping section
> From: Zane Bitter > To: openstack-dev@lists.openstack.org > Date: 03/04/2014 22:09 > Subject: Re: [openstack-dev] [Heat] Some thoughts on the mapping section > > On 03/04/14 03:21, Thomas Herve wrote: > >> Speaking of offering options for selection, there is another proposal on > >> >adding conditional creation of resources [3], whose use case to enable > >> >or disable a resource creation (among others). My perception is that > >> >these are all relevant enhancements to the reusability of HOT templates, > >> >though I don't think we really need very sophisticated combinatory > >> >conditionals. > > I think that's interesting that you mentioned that, because Zane > talked about a "variables" section, which would encompass what > "conditions" and "mappings" mean. That's why we're discussing > extensively about those design points, to see where we can be a bit > more generic to handle more use cases. > > There was some discussion in the review[1] of having an if/then function > (equivalent of the ternary ?: operator in C) for calculating variable... > on reflection that is nothing more than a dumbed down version of > Fn::Select in CloudFormation (which we have no equivalent to in HOT) in > which the only possible index values are "true" and "false". > > The differences between Fn::Select and Fn::FindInMap are: > > 1) The bizarre double-indirect lookup, of course; and > 2) The actual mappings are defined once in a single place, rather than > everywhere you need to access them. > > I think we're all agreed that (1) is undesirable in itself. It occurs to > me that the existence of a variables section could render (2) moot also > (since you could calculate the result in one place, and just reference > it from there on). > > So if we had the variables section, we probably no longer need to > consider a mapping section and a replacement for Fn::FindInMap, just a > replacement for Fn::Select that could also cover the if/then use case. > > Thoughts? +1 for solving this in one place and coming up with such a solution that introduces just one new "thing" to solve problems that are addressed with two different things in CFN. Regards, Thomas > > cheers, > Zane. > > [1] https://review.openstack.org/84468 > > ___ > 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] Some thoughts on the mapping section
On 03/04/14 03:21, Thomas Herve wrote: Speaking of offering options for selection, there is another proposal on >adding conditional creation of resources [3], whose use case to enable >or disable a resource creation (among others). My perception is that >these are all relevant enhancements to the reusability of HOT templates, >though I don't think we really need very sophisticated combinatory >conditionals. I think that's interesting that you mentioned that, because Zane talked about a "variables" section, which would encompass what "conditions" and "mappings" mean. That's why we're discussing extensively about those design points, to see where we can be a bit more generic to handle more use cases. There was some discussion in the review[1] of having an if/then function (equivalent of the ternary ?: operator in C) for calculating variable... on reflection that is nothing more than a dumbed down version of Fn::Select in CloudFormation (which we have no equivalent to in HOT) in which the only possible index values are "true" and "false". The differences between Fn::Select and Fn::FindInMap are: 1) The bizarre double-indirect lookup, of course; and 2) The actual mappings are defined once in a single place, rather than everywhere you need to access them. I think we're all agreed that (1) is undesirable in itself. It occurs to me that the existence of a variables section could render (2) moot also (since you could calculate the result in one place, and just reference it from there on). So if we had the variables section, we probably no longer need to consider a mapping section and a replacement for Fn::FindInMap, just a replacement for Fn::Select that could also cover the if/then use case. Thoughts? cheers, Zane. [1] https://review.openstack.org/84468 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Heat] Some thoughts on the mapping section
Excerpts from Thomas Herve's message on 03/04/2014 09:21:05: > From: Thomas Herve > To: "OpenStack Development Mailing List (not for usage questions)" > > Date: 03/04/2014 09:21 > Subject: Re: [openstack-dev] [Heat] Some thoughts on the mapping section > > > > Speaking of offering options for selection, there is another proposal on > > adding conditional creation of resources [3], whose use case to enable > > or disable a resource creation (among others). My perception is that > > these are all relevant enhancements to the reusability of HOT templates, > > though I don't think we really need very sophisticated combinatory > > conditionals. > > I think that's interesting that you mentioned that, because Zane > talked about a "variables" section, which would encompass what > "conditions" and "mappings" mean. That's why we're discussing > extensively about those design points, to see where we can be a bit > more generic to handle more use cases. +1 on bringing those suggestions together. It seems to me like there is quite some overlap of what "mappings" and "variables" shall solve, so it would be nice to have one solution for it. As you mentioned earlier, the objection against "mappings" was not that CFN had it and we didn't want to have it, but because the use case did not sell well. If there are things that make sense, no objection, but maybe we can do it smarter in HOT ;-) Regards, Thomas > > Cheers, > > -- > Thomas > > ___ > 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] Some thoughts on the mapping section
> Hi, Hi Qiming > Regarding the discussion about the adding of a native 'mappings' section > to HOT [1], which has been abandoned, I have some different thoughts for > the team to consider. Maybe having that section added is not a bad > idea. > > I do think we need a 'mappings' kind of functionality in HOT, to allow > users to make a from available options. There are objections to adopt > this change: > > 1) Too similar to CFN... Which should not be the criteria for > excluding this. We can use other section names, if we really believe > that is an important factor to consider. I don't think that argument has been used. What Thomas said is that CFN having this feature is not a reason for having it in Heat. > 2) The functionality can be covered by 'environments'. That is > where the team really concerns about. > > My understanding to the item 2) is that people might have been somehow > misled by the existing sample templates or the examples used in > discussion (most of which were using imageId as an example). > > A 'mappings' section, IMO, provides the user an opportunity to make > selections from many options, period. Its usage is far beyond guest > image Id selection. Not all use cases are suitable to be expressed as > 'environments'. > > As the name suggests, 'environment' is a concept to decouple a > template from the cloud/host/guest where it is created. It helps > promote portability or reusability of the template. If you have > some settings that will change between clouds, or different guest > OS. 'environment' is the ideal place to put those variances. > > However, a 'mappings' section is about functionality, not usage > scenario. It can be treated as a subsection of 'parameters', to > make a template even more reusable when the stack can be used with > different resources (say, softwareconfigs, cloudconfigs, different > sources for get_file etc.). > > Say I have three DB backends to choose from, for my application [2]. > The DB backend is better treated as a component of the application, > instead of part of the environment. A 'mappings' section can be > used for a quick selection of OpenStack level options (such as > scaling policies, security groups, different templates for a nested > stack, different versions of external templates residing on a GIT > website...) or any application-level options (such as a different > SoftwareDeployment for the same SoftwareConfig), irrespective to which > cloud (the 'environments', my understanding) is hosting the stack. Environments are not just a way to customize depending on the target cloud. They allow you to define values which are going to be available during your template instantiation, even on the same cloud. I see more them as complex parameters. I think there was a push back on the review you mentioned because the use case is not super clear, and that using mapping for it clearly reduce reusability and portability. And the usecase you mentioned is *also* solved by environments. So currently you may understand where we're at. > Speaking of offering options for selection, there is another proposal on > adding conditional creation of resources [3], whose use case to enable > or disable a resource creation (among others). My perception is that > these are all relevant enhancements to the reusability of HOT templates, > though I don't think we really need very sophisticated combinatory > conditionals. I think that's interesting that you mentioned that, because Zane talked about a "variables" section, which would encompass what "conditions" and "mappings" mean. That's why we're discussing extensively about those design points, to see where we can be a bit more generic to handle more use cases. Cheers, -- Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Heat] Some thoughts on the mapping section
Hi, Regarding the discussion about the adding of a native 'mappings' section to HOT [1], which has been abandoned, I have some different thoughts for the team to consider. Maybe having that section added is not a bad idea. I do think we need a 'mappings' kind of functionality in HOT, to allow users to make a from available options. There are objections to adopt this change: 1) Too similar to CFN... Which should not be the criteria for excluding this. We can use other section names, if we really believe that is an important factor to consider. 2) The functionality can be covered by 'environments'. That is where the team really concerns about. My understanding to the item 2) is that people might have been somehow misled by the existing sample templates or the examples used in discussion (most of which were using imageId as an example). A 'mappings' section, IMO, provides the user an opportunity to make selections from many options, period. Its usage is far beyond guest image Id selection. Not all use cases are suitable to be expressed as 'environments'. As the name suggests, 'environment' is a concept to decouple a template from the cloud/host/guest where it is created. It helps promote portability or reusability of the template. If you have some settings that will change between clouds, or different guest OS. 'environment' is the ideal place to put those variances. However, a 'mappings' section is about functionality, not usage scenario. It can be treated as a subsection of 'parameters', to make a template even more reusable when the stack can be used with different resources (say, softwareconfigs, cloudconfigs, different sources for get_file etc.). Say I have three DB backends to choose from, for my application [2]. The DB backend is better treated as a component of the application, instead of part of the environment. A 'mappings' section can be used for a quick selection of OpenStack level options (such as scaling policies, security groups, different templates for a nested stack, different versions of external templates residing on a GIT website...) or any application-level options (such as a different SoftwareDeployment for the same SoftwareConfig), irrespective to which cloud (the 'environments', my understanding) is hosting the stack. Speaking of offering options for selection, there is another proposal on adding conditional creation of resources [3], whose use case to enable or disable a resource creation (among others). My perception is that these are all relevant enhancements to the reusability of HOT templates, though I don't think we really need very sophisticated combinatory conditionals. Regards, - Qiming [1] https://review.openstack.org/#/c/81918/ [2] http://lists.openstack.org/pipermail/openstack-dev/2014-April/031712.html [3] https://review.openstack.org/#/c/84468/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
