Open Stack

https://review.openstack.org/#/c/245042
First patch https://review.openstack.org/#/c/221648

I proposed this spec, because the function is really needed, many customers of our company complained that they have to write/manage many templates to meet their business(the templates are similar, can they re-used?), 
also magnum guys asked me for this function too. I know there are several previous discussions such as https://review.openstack.org/#/c/84468/ and https://review.openstack.org/#/c/153771/ , but considering the user habits 
and compatibility with CFN templates, also the sample way is easy to implement based on our architecture, I proposed the same style as CFN.

If you agree with it, I will be happy to continue this work, thanks:)
   

-----邮件原件-----
发件人: Steven Hardy [mailto:shardy at redhat.com] 
发送时间: 2015年12月18日 19:08
收件人: OpenStack Development Mailing List (not for usage questions)
主题: Re: [openstack-dev] [Heat] Status of the Support Conditionals in Heat templates

On Wed, Dec 09, 2015 at 01:42:13PM +0300, Sergey Kraynev wrote:
>    Hi Heaters,
>    On the last IRC meeting we had a question about Support Conditionals spec
>    [1].
>    Previous attempt for this staff is here [2].
>    The example of first POC in Heat can be reviewed here [3]
>    As I understand we have not had any complete decision about this work.
>    So I'd like to clarify feelings of community about it. This clarification
>    may be done as answers for two simple questions:
>    Â - Why do we want to implement it?
>    Â - Why do NOT we want to implement it?
>    My personal feeling is:
>    - Why do we want to implement it?
>    Â  Â  * A lot of users wants to have similar staff.
>    Â  Â  * It's already presented in AWS, so will be good to have this
>    feature in Heat too.
>    Â - Why do NOT we want to implement it?
>    Â  Â  * it can be solved with Jinja [4] . However I don't think, that it's
>    really important reason for blocking this work.
>    Please share your idea about two questions above.
>    It should allows us to eventually decide, want we implement it or not.

This has been requested for a long time, and there have been several previous discussions, which all ended up in debating the implementation, rather than focussing on the simplest possible way to meet the user requirement.

I think this latest attempt provides a simple way to meet the requirement, improves out CFN compatibility, and is inspired by an interface which has been proven to work.

So I'm +1 on going ahead with this - the implementation looks pretty simple :)

We've debated Jinja and other solutions before and dismissed them as either unsafe to run inside the heat service, or potentially too complex - this proposed solution appears to resolve both those concerns.

Steve

__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev