Open Stack

I agree with Tom's comment for not maintaining separate repo for
heat-templates when it can't be reused by others.

Regards,
Madhuri

On Tue, Jun 30, 2015 at 10:56 AM, Angus Salkeld <asalkeld at mirantis.com>
wrote:

> On Tue, Jun 30, 2015 at 8:23 AM, Fox, Kevin M <Kevin.Fox at pnnl.gov> wrote:
>
>> Needing to fork templates to tweak things is a very common problem.
>>
>> Adding conditionals to Heat was discussed at the Summit. (
>> https://etherpad.openstack.org/p/YVR-heat-liberty-template-format). I
>> want to say, someone was going to prototype it using YAQL, but I don't
>> remember who.
>>
>
> I was going to do that, but I would not expect that ready in a very short
> time frame. It needs
> some investigation and agreement from others. I'd suggest making you
> decision based
> on what we have now.
>
> -Angus
>
>
>>
>> Would it be reasonable to keep if conditionals worked?
>>
>> Thanks,
>> Kevin
>> ________________________________________
>> From: Hongbin Lu [hongbin.lu at huawei.com]
>> Sent: Monday, June 29, 2015 3:01 PM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: Re: [openstack-dev] [Magnum] Continuing with heat-coe-templates
>>
>> Agree. The motivation of pulling templates out of Magnum tree is hoping
>> these templates can be leveraged by a larger community and get more
>> feedback. However, it is unlikely to be the case in practise, because
>> different people has their own version of templates for addressing
>> different use cases. It is proven to be hard to consolidate different
>> templates even if these templates share a large amount of duplicated code
>> (recall that we have to copy-and-paste the original template to add support
>> for Ironic and CoreOS). So, +1 for stopping usage of heat-coe-templates.
>>
>> Best regards,
>> Hongbin
>>
>> -----Original Message-----
>> From: Tom Cammann [mailto:tom.cammann at hp.com]
>> Sent: June-29-15 11:16 AM
>> To: openstack Development Mailing List (not for usage questions)
>> Subject: [openstack-dev] [Magnum] Continuing with heat-coe-templates
>>
>> Hello team,
>>
>> I've been doing work in Magnum recently to align our templates with the
>> "upstream" templates from larsks/heat-kubernetes[1]. I've also been porting
>> these changes to the stackforge/heat-coe-templates[2] repo.
>>
>> I'm currently not convinced that maintaining a separate repo for Magnum
>> templates (stackforge/heat-coe-templates) is beneficial for Magnum or the
>> community.
>>
>> Firstly it is very difficult to draw a line on what should be allowed
>> into the heat-coe-templates. We are currently taking out changes[3] that
>> introduced "useful" autoscaling capabilities in the templates but that
>> didn't fit the Magnum plan. If we are going to treat the heat-coe-templates
>> in that way then this extra repo will not allow organic development of new
>> and old container engine templates that are not tied into Magnum.
>> Another recent change[4] in development is smart autoscaling of bays
>> which introduces parameters that don't make a lot of sense outside of
>> Magnum.
>>
>> There are also difficult interdependency problems between the templates
>> and the Magnum project such as the parameter fields. If a required
>> parameter is added into the template the Magnum code must be also updated
>> in the same commit to avoid functional test failures. This can be avoided
>> using "Depends-On:
>> #xxxxxx"
>> feature of gerrit, but it is an additional overhead and will require some
>> CI setup.
>>
>> Additionally we would have to version the templates, which I assume would
>> be necessary to allow for packaging. This brings with it is own problems.
>>
>> As far as I am aware there are no other people using the
>> heat-coe-templates beyond the Magnum team, if we want independent growth of
>> this repo it will need to be adopted by other people rather than Magnum
>> commiters.
>>
>> I don't see the heat templates as a dependency of Magnum, I see them as a
>> truly fundamental part of Magnum which is going to be very difficult to cut
>> out and make reusable without compromising Magnum's development process.
>>
>> I would propose to delete/deprecate the usage of heat-coe-templates and
>> continue with the usage of the templates in the Magnum repo. How does the
>> team feel about that?
>>
>> If we do continue with the large effort required to try and pull out the
>> templates as a dependency then we will need increase the visibility of repo
>> and greatly increase the reviews/commits on the repo. We also have a fairly
>> significant backlog of work to align the heat-coe-templates with the
>> templates in heat-coe-templates.
>>
>> Thanks,
>> Tom
>>
>> [1] https://github.com/larsks/heat-kubernetes
>> [2] https://github.com/stackforge/heat-coe-templates
>> [3] https://review.openstack.org/#/c/184687/
>> [4] https://review.openstack.org/#/c/196505/
>>
>> __________________________________________________________________________
>> 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
>>
>> __________________________________________________________________________
>> 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
>>
>> __________________________________________________________________________
>> 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
>>
>
>
> __________________________________________________________________________
> 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
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150630/e72b8faf/attachment.html>