Re: [openstack-dev] [Magnum] Continuing with heat-coe-templates
On Sun, Jul 05, 2015 at 12:00:55AM +, Steven Dake (stdake) wrote: > Lars had a repo he maintains. Magnum had a repo it maintained. We > wanted one source of truth. The deal was we would merge all the > things into heat-coe-templates, delete larsks/heat-kubernetes and > delete the magnum templates. Then there would be one source of > truth. I apologize for being out of the loop for a bit; I was stuck out at a customer site for a while. I create the heat-coe-templates project at the request of sdake because it sounded as if (a) magnum wanted to make use of the templates and have them in a location where there was a better workflow for submitting and reviewing patches, and (b) magnum wanted to take the templates in a different direction (with support for other scheduling engines, etc). After creating it, there was no activity on it so I stopped paying attention for a while. If folks want to use it, we should set up some additional maintainers and go for it. I'm going to continue maintaining my own repository as a strictly-for-kubernetes tool. I had to make a number of changes to it recently in order to support a demo at the recent summit, and I am happy to contribute some of these upstream. In conclusion: I have very little skin in this game. I am happy for folks to make use of the templates if they are useful, and I am totally happy to let other folks manage the heat-coe-templates project and take it in a direction completely different from where things are now. I leave the decision about where things are going to someone who has a more vested interest in the resolution. Cheers, -- Lars Kellogg-Stedman | larsks @ {freenode,twitter,github} Cloud Engineering / OpenStack | http://blog.oddbit.com/ signature.asc Description: PGP signature __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Magnum] Continuing with heat-coe-templates
Team, Thanks everyone for your input on this thread. To make a decision, I’d like input form Lars. I have put this on our team meeting agenda for next Tuesday (2015-07-14 2200 UTC in #openstack-meeting-alt). I’ll reach out to him on IRC and ask if he can make time to attend. If Magnum feels comfortable supporting a fork of this code and keeping it within the Magnum tree, then it probably makes sense to delete the heat-coe-templates repo, and encourage Lars to continue any related work in the original repo [1], which it appears he is still doing. [1] https://github.com/larsks/heat-kubernetes Original heat-kubernetes repo Lars, you are also welcome to comment on this thread, or relay your thoughts directly to me by email, and I can share them with the team. Thanks, Adrian On Jul 4, 2015, at 5:00 PM, Steven Dake (stdake) mailto:std...@cisco.com>> wrote: Tom, Just to be clear on motive, it had nothing to do with reuse by others. Lars had a repo he maintains. Magnum had a repo it maintained. We wanted one source of truth. The deal was we would merge all the things into heat-coe-templates, delete larsks/heat-kubernetes and delete the magnum templates. Then there would be one source of truth. We haven’t really lived up to our end of the plan, so I am unclear is Lars is willing to delete his repo even if we were to make the repos consistent across all three. If we do proceed with placing heat-coe-templates in the attic, we should stop tracking larsks as an upstream repo and not bother submitting changes there either – since they will become independent works with independent paths. It is these tracking of the two repos to maintain consistency that lead to the creation of the heat-coe-templates repo in the first place (I.e. The lack of one source of truth). By abandoning the upstream relationship with larsks/heat-kubernetes we also solve the one source of truth problem which I think your proposal implies. Regards -steve From: Madhuri mailto:madhuri.ra...@gmail.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Monday, June 29, 2015 at 7:24 PM To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [Magnum] Continuing with heat-coe-templates 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 mailto:asalk...@mirantis.com>> wrote: On Tue, Jun 30, 2015 at 8:23 AM, Fox, Kevin M mailto:kevin@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...@huawei.com<mailto:hongbin...@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.camm...@hp.com<mailto:tom.camm...@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
Re: [openstack-dev] [Magnum] Continuing with heat-coe-templates
Tom, Just to be clear on motive, it had nothing to do with reuse by others. Lars had a repo he maintains. Magnum had a repo it maintained. We wanted one source of truth. The deal was we would merge all the things into heat-coe-templates, delete larsks/heat-kubernetes and delete the magnum templates. Then there would be one source of truth. We haven’t really lived up to our end of the plan, so I am unclear is Lars is willing to delete his repo even if we were to make the repos consistent across all three. If we do proceed with placing heat-coe-templates in the attic, we should stop tracking larsks as an upstream repo and not bother submitting changes there either – since they will become independent works with independent paths. It is these tracking of the two repos to maintain consistency that lead to the creation of the heat-coe-templates repo in the first place (I.e. The lack of one source of truth). By abandoning the upstream relationship with larsks/heat-kubernetes we also solve the one source of truth problem which I think your proposal implies. Regards -steve From: Madhuri mailto:madhuri.ra...@gmail.com>> Reply-To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Date: Monday, June 29, 2015 at 7:24 PM To: "OpenStack Development Mailing List (not for usage questions)" mailto:openstack-dev@lists.openstack.org>> Subject: Re: [openstack-dev] [Magnum] Continuing with heat-coe-templates 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 mailto:asalk...@mirantis.com>> wrote: On Tue, Jun 30, 2015 at 8:23 AM, Fox, Kevin M mailto:kevin@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...@huawei.com<mailto:hongbin...@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.camm...@hp.com<mailto:tom.camm...@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: #xx" feature of gerrit, but it is an additional overhead and wil
Re: [openstack-dev] [Magnum] Continuing with heat-coe-templates
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: wk...@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" To: "OpenStack Development Mailing List (not for usage questions)" 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 [asalk...@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 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...@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.camm...@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: #xx" 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 Mag
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 [asalk...@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 mailto:kevin@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...@huawei.com<mailto:hongbin...@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.camm...@hp.com<mailto:tom.camm...@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: #xx" 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/
Re: [openstack-dev] [Magnum] Continuing with heat-coe-templates
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 wrote: > On Tue, Jun 30, 2015 at 8:23 AM, Fox, Kevin M 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...@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.camm...@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: >> #xx" >> 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 th
Re: [openstack-dev] [Magnum] Continuing with heat-coe-templates
On Tue, Jun 30, 2015 at 8:23 AM, Fox, Kevin M 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...@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.camm...@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: > #xx" > 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 Developm
Re: [openstack-dev] [Magnum] Continuing with heat-coe-templates
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. Would it be reasonable to keep if conditionals worked? Thanks, Kevin From: Hongbin Lu [hongbin...@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.camm...@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: #xx" 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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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.camm...@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: #xx" 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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[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: #xx" 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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev