[openstack-dev] [Magnum] Continuing with heat-coe-templates

Kai Qiang Wu wkqwu at cn.ibm.com
Wed Jul 1 03:38:59 UTC 2015


For @Tom's suggestion, I +1 about it, maintain a separate
heat-coe-templates is very inefficient.[As @HongBin's comments below]



Thanks


Best Wishes,
--------------------------------------------------------------------------------
Kai Qiang Wu (吴开强  Kennan)
IBM China System and Technology Lab, Beijing

E-mail: wkqwu at cn.ibm.com
Tel: 86-10-82451647
Address: Building 28(Ring Building), ZhongGuanCun Software Park,
         No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China
100193
--------------------------------------------------------------------------------
Follow your heart. You are miracle!



From:	"Fox, Kevin M" <Kevin.Fox at pnnl.gov>
To:	"OpenStack Development Mailing List (not for usage questions)"
            <openstack-dev at lists.openstack.org>
Date:	06/30/2015 11:40 PM
Subject:	Re: [openstack-dev] [Magnum] Continuing with heat-coe-templates



Whats the timeframe? I was really hoping for Liberty but its sounding like
thats unlikely? M then? The app catalog really needs conditionals for the
same reason. :/

Thanks,
Kevin

From: Angus Salkeld [asalkeld at mirantis.com]
Sent: Monday, June 29, 2015 6:56 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Magnum] Continuing with heat-coe-templates

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/20150701/6801dce6/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150701/6801dce6/attachment.gif>


More information about the OpenStack-dev mailing list