Re: [openstack-dev] [TripleO] Backwards compatibility policy for our projects
On 06/16/2014 10:06 PM, James Slagle wrote: On Mon, Jun 16, 2014 at 12:19 PM, Tomas Sedovic tsedo...@redhat.com wrote: If we do promise backwards compatibility, we should document it somewhere and if we don't we should probably make that more visible, too, so people know what to expect. I prefer the latter, because it will make the merge.py cleanup easier and every published bit of information I could find suggests that's our current stance anyway. Much of this is the reason why I pushed for the stable branches that we cut for icehouse. I'm not sure what downstreams that have shipped things are being referred to, but perhaps those needs could be served by the stable/icehouse branches that exist today? I know at least for the RDO downstream, the packages are being built off of releases done from the stable branches. So, honestly, I'm not that concerned about your proposed changes to rip stuff out without any deprecation from that point of view :). +1 on relying on the branches I personally don't see the backward compatibility much of an issue in TripleO (but I may miss some pieces though) ... more below That being said, just because TripleO has taken the stance that backwards compatibility is not guaranteed, I agree with some of the other sentiments in this thread: that we should at least try if there are easy things we can do. From a the 10.000 feet view, I can imagine people relying on a stable API for services like Cinder but I don't see how that applies to TripleO Why should one try to install an older version of OpenStack using some 'recent' version TripleO? The only scenario which comes up to my mind is the 'upgrade' process where undercloud and overcloud could get 'out of sync', yet this seems to have a pretty limited scope. A genuine question from a 'wannabe' TripleO contributor, do you see others? many others? -- Giulio Fidente GPG KEY: 08D733BA ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Backwards compatibility policy for our projects
On 19 June 2014 10:01, Giulio Fidente gfide...@redhat.com wrote: From a the 10.000 feet view, I can imagine people relying on a stable API for services like Cinder but I don't see how that applies to TripleO Why should one try to install an older version of OpenStack using some 'recent' version TripleO? The only scenario which comes up to my mind is the 'upgrade' process where undercloud and overcloud could get 'out of sync', yet this seems to have a pretty limited scope. A genuine question from a 'wannabe' TripleO contributor, do you see others? many others? There are companies (e.g. HP) who're trying to ship products based on TripleO. This means a) elements that are not upstreamed because they install proprietary / value-add code b) elements that are carrying changes that are not yet merged upstream because the velocity of upstream is very low. While I'm not suggesting you should bend over backwards to accommodate such users, some consideration is a reasonable expectation I think, particularly for (a). ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Backwards compatibility policy for our projects
On 16/06/14 18:51, Clint Byrum wrote: Excerpts from Tomas Sedovic's message of 2014-06-16 09:19:40 -0700: All, After having proposed some changes[1][2] to tripleo-heat-templates[3], reviewers suggested adding a deprecation period for the merge.py script. While TripleO is an official OpenStack program, none of the projects under its umbrella (including tripleo-heat-templates) have gone through incubation and integration nor have they been shipped with Icehouse. So there is no implicit compatibility guarantee and I have not found anything about maintaining backwards compatibility neither on the TripleO wiki page[4], tripleo-heat-template's readme[5] or tripleo-incubator's readme[6]. The Release Management wiki page[7] suggests that we follow Semantic Versioning[8], under which prior to 1.0.0 (t-h-t is ) anything goes. According to that wiki, we are using a stronger guarantee where we do promise to bump the minor version on incompatible changes -- but this again suggests that we do not promise to maintain backwards compatibility -- just that we document whenever we break it. I think there are no guarantees, and no promises. I also think that we've kept tripleo_heat_merge pretty narrow in surface area since making it into a module, so I'm not concerned that it will be incredibly difficult to keep those features alive for a while. According to Robert, there are now downstreams that have shipped things (with the implication that they don't expect things to change without a deprecation period) so there's clearly a disconnect here. I think it is more of a we will cause them extra work thing. If we can make a best effort and deprecate for a few releases (as in, a few releases of t-h-t, not OpenStack), they'll likely appreciate that. If we can't do it without a lot of effort, we shouldn't bother. Oh. I did assume we were talking about OpenStack releases, not t-h-t, sorry. I have nothing against making a new tht release that deprecates the features we're no longer using and dropping them for good in a later release. What do you suggest would be a reasonable waiting period? Say a month or so? I think it would be good if we could remove all the deprecated stuff before we start porting our templates to HOT. If we do promise backwards compatibility, we should document it somewhere and if we don't we should probably make that more visible, too, so people know what to expect. I prefer the latter, because it will make the merge.py cleanup easier and every published bit of information I could find suggests that's our current stance anyway. This is more about good will than promising. If it is easy enough to just keep the code around and have it complain to us if we accidentally resurrect a feature, that should be enough. We could even introduce a switch to the CLI like --strict that we can run in our gate and that won't allow us to keep using deprecated features. So I'd like to see us deprecate not because we have to, but because we can do it with only a small amount of effort. Right, that's fair enough. I've thought about adding a strict switch, too, but I'd like to start removing code from merge.py, not adding more :-). ___ 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] [TripleO] Backwards compatibility policy for our projects
Excerpts from Tomas Sedovic's message of 2014-06-17 04:56:24 -0700: On 16/06/14 18:51, Clint Byrum wrote: Excerpts from Tomas Sedovic's message of 2014-06-16 09:19:40 -0700: All, After having proposed some changes[1][2] to tripleo-heat-templates[3], reviewers suggested adding a deprecation period for the merge.py script. While TripleO is an official OpenStack program, none of the projects under its umbrella (including tripleo-heat-templates) have gone through incubation and integration nor have they been shipped with Icehouse. So there is no implicit compatibility guarantee and I have not found anything about maintaining backwards compatibility neither on the TripleO wiki page[4], tripleo-heat-template's readme[5] or tripleo-incubator's readme[6]. The Release Management wiki page[7] suggests that we follow Semantic Versioning[8], under which prior to 1.0.0 (t-h-t is ) anything goes. According to that wiki, we are using a stronger guarantee where we do promise to bump the minor version on incompatible changes -- but this again suggests that we do not promise to maintain backwards compatibility -- just that we document whenever we break it. I think there are no guarantees, and no promises. I also think that we've kept tripleo_heat_merge pretty narrow in surface area since making it into a module, so I'm not concerned that it will be incredibly difficult to keep those features alive for a while. According to Robert, there are now downstreams that have shipped things (with the implication that they don't expect things to change without a deprecation period) so there's clearly a disconnect here. I think it is more of a we will cause them extra work thing. If we can make a best effort and deprecate for a few releases (as in, a few releases of t-h-t, not OpenStack), they'll likely appreciate that. If we can't do it without a lot of effort, we shouldn't bother. Oh. I did assume we were talking about OpenStack releases, not t-h-t, sorry. I have nothing against making a new tht release that deprecates the features we're no longer using and dropping them for good in a later release. What do you suggest would be a reasonable waiting period? Say a month or so? I think it would be good if we could remove all the deprecated stuff before we start porting our templates to HOT. If we do promise backwards compatibility, we should document it somewhere and if we don't we should probably make that more visible, too, so people know what to expect. I prefer the latter, because it will make the merge.py cleanup easier and every published bit of information I could find suggests that's our current stance anyway. This is more about good will than promising. If it is easy enough to just keep the code around and have it complain to us if we accidentally resurrect a feature, that should be enough. We could even introduce a switch to the CLI like --strict that we can run in our gate and that won't allow us to keep using deprecated features. So I'd like to see us deprecate not because we have to, but because we can do it with only a small amount of effort. Right, that's fair enough. I've thought about adding a strict switch, too, but I'd like to start removing code from merge.py, not adding more :-). Let's just leave the capability forever. We're not adding things to merge.py or taking it in any new directions. Keeping the code does not cost us anything. Some day merge.py won't be used, and then it will be like we deleted the whole thing. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [TripleO] Backwards compatibility policy for our projects
All, After having proposed some changes[1][2] to tripleo-heat-templates[3], reviewers suggested adding a deprecation period for the merge.py script. While TripleO is an official OpenStack program, none of the projects under its umbrella (including tripleo-heat-templates) have gone through incubation and integration nor have they been shipped with Icehouse. So there is no implicit compatibility guarantee and I have not found anything about maintaining backwards compatibility neither on the TripleO wiki page[4], tripleo-heat-template's readme[5] or tripleo-incubator's readme[6]. The Release Management wiki page[7] suggests that we follow Semantic Versioning[8], under which prior to 1.0.0 (t-h-t is ) anything goes. According to that wiki, we are using a stronger guarantee where we do promise to bump the minor version on incompatible changes -- but this again suggests that we do not promise to maintain backwards compatibility -- just that we document whenever we break it. According to Robert, there are now downstreams that have shipped things (with the implication that they don't expect things to change without a deprecation period) so there's clearly a disconnect here. If we do promise backwards compatibility, we should document it somewhere and if we don't we should probably make that more visible, too, so people know what to expect. I prefer the latter, because it will make the merge.py cleanup easier and every published bit of information I could find suggests that's our current stance anyway. Tomas [1]: https://review.openstack.org/#/c/99384/ [2]: https://review.openstack.org/#/c/97939/ [3]: https://github.com/openstack/tripleo-heat-templates [4]: https://wiki.openstack.org/wiki/TripleO [5]: https://github.com/openstack/tripleo-heat-templates/blob/master/README.md [6]: https://github.com/openstack/tripleo-incubator/blob/master/README.rst [7]: https://wiki.openstack.org/wiki/TripleO/ReleaseManagement [8]: http://semver.org/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Backwards compatibility policy for our projects
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon 16 Jun 2014 10:19:40 AM MDT, Tomas Sedovic wrote: All, After having proposed some changes[1][2] to tripleo-heat-templates[3], reviewers suggested adding a deprecation period for the merge.py script. While TripleO is an official OpenStack program, none of the projects under its umbrella (including tripleo-heat-templates) have gone through incubation and integration nor have they been shipped with Icehouse. So there is no implicit compatibility guarantee and I have not found anything about maintaining backwards compatibility neither on the TripleO wiki page[4], tripleo-heat-template's readme[5] or tripleo-incubator's readme[6]. The Release Management wiki page[7] suggests that we follow Semantic Versioning[8], under which prior to 1.0.0 (t-h-t is ) anything goes. According to that wiki, we are using a stronger guarantee where we do promise to bump the minor version on incompatible changes -- but this again suggests that we do not promise to maintain backwards compatibility -- just that we document whenever we break it. According to Robert, there are now downstreams that have shipped things (with the implication that they don't expect things to change without a deprecation period) so there's clearly a disconnect here. If we do promise backwards compatibility, we should document it somewhere and if we don't we should probably make that more visible, too, so people know what to expect. I prefer the latter, because it will make the merge.py cleanup easier and every published bit of information I could find suggests that's our current stance anyway. Tomas [1]: https://review.openstack.org/#/c/99384/ [2]: https://review.openstack.org/#/c/97939/ [3]: https://github.com/openstack/tripleo-heat-templates [4]: https://wiki.openstack.org/wiki/TripleO [5]: https://github.com/openstack/tripleo-heat-templates/blob/master/README.md [6]: https://github.com/openstack/tripleo-incubator/blob/master/README.rst [7]: https://wiki.openstack.org/wiki/TripleO/ReleaseManagement [8]: http://semver.org/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I'm going to have to agree with Tomas here. There doesn't seem to be any reasonable expectation of backwards compatibility for the reasons he outlined, despite some downstream releases that may be impacted. - -J - -- Jason E. Rist Senior Software Engineer OpenStack Management UI Red Hat, Inc. openuc: +1.972.707.6408 mobile: +1.720.256.3933 Freenode: jrist github/identi.ca: knowncitizen - -- Jason E. Rist Senior Software Engineer OpenStack Management UI Red Hat, Inc. openuc: +1.972.707.6408 mobile: +1.720.256.3933 Freenode: jrist github/identi.ca: knowncitizen -BEGIN PGP SIGNATURE- Version: GnuPG v1 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQEcBAEBAgAGBQJTnxutAAoJEMqxYTi6t2f4Mh4H+gOF3aUZwIxY9FSEW/Hj1EjJ eDSDDPuOwWSlMn8VNmEq44ks7KNgGDU/qpjaDUjAJ8BCEm4cXi8JtS7zYsPJJeY3 t3z/cFPkyhWLgg0qQYOB03rbqYGX58G43xa8lFjvVi7GyfqCSKJ3AxauF2bDkx+b FoQztiaHvU09dw77JmvTxPJ2CpsvBHGaLkG3NneVIBNA8WtnBqKUQrT63ZnP8K++ G98SoMSNpXlztVEnElFMZoi+Lr7rO/37kP9CvqYtXBaDgL2Wbj6B+21Pn5OUVcXd MTy0CcvvpM/P08DNFW9+coHJcQOKJSeAYuDxn8z0+bpyJkAiSf9o4zlWOWtavfU= =qXmp -END PGP SIGNATURE- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Backwards compatibility policy for our projects
On 16 June 2014 17:30, Jason Rist jr...@redhat.com wrote: I'm going to have to agree with Tomas here. There doesn't seem to be any reasonable expectation of backwards compatibility for the reasons he outlined, despite some downstream releases that may be impacted. Backward compatibility is a hard habit to get into, and easy to put off. If you're not making any guarantees now, when are you going to start making them? How much breakage can users expect? Without wanting to look entirely like a troll, should TripleO be dropped as an official until it can start making such guarantees? I think every other official OpenStack project has a stable API policy of some kind, even if they don't entirely match... ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Backwards compatibility policy for our projects
Why is OOO being singled out for backwards compatibility? -Original Message- From: Duncan Thomas [mailto:duncan.tho...@gmail.com] Sent: Monday, June 16, 2014 11:42 AM To: jr...@redhat.com; OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [TripleO] Backwards compatibility policy for our projects On 16 June 2014 17:30, Jason Rist jr...@redhat.com wrote: I'm going to have to agree with Tomas here. There doesn't seem to be any reasonable expectation of backwards compatibility for the reasons he outlined, despite some downstream releases that may be impacted. Backward compatibility is a hard habit to get into, and easy to put off. If you're not making any guarantees now, when are you going to start making them? How much breakage can users expect? Without wanting to look entirely like a troll, should TripleO be dropped as an official until it can start making such guarantees? I think every other official OpenStack project has a stable API policy of some kind, even if they don't entirely match... ___ 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] [TripleO] Backwards compatibility policy for our projects
Excerpts from Tomas Sedovic's message of 2014-06-16 09:19:40 -0700: All, After having proposed some changes[1][2] to tripleo-heat-templates[3], reviewers suggested adding a deprecation period for the merge.py script. While TripleO is an official OpenStack program, none of the projects under its umbrella (including tripleo-heat-templates) have gone through incubation and integration nor have they been shipped with Icehouse. So there is no implicit compatibility guarantee and I have not found anything about maintaining backwards compatibility neither on the TripleO wiki page[4], tripleo-heat-template's readme[5] or tripleo-incubator's readme[6]. The Release Management wiki page[7] suggests that we follow Semantic Versioning[8], under which prior to 1.0.0 (t-h-t is ) anything goes. According to that wiki, we are using a stronger guarantee where we do promise to bump the minor version on incompatible changes -- but this again suggests that we do not promise to maintain backwards compatibility -- just that we document whenever we break it. I think there are no guarantees, and no promises. I also think that we've kept tripleo_heat_merge pretty narrow in surface area since making it into a module, so I'm not concerned that it will be incredibly difficult to keep those features alive for a while. According to Robert, there are now downstreams that have shipped things (with the implication that they don't expect things to change without a deprecation period) so there's clearly a disconnect here. I think it is more of a we will cause them extra work thing. If we can make a best effort and deprecate for a few releases (as in, a few releases of t-h-t, not OpenStack), they'll likely appreciate that. If we can't do it without a lot of effort, we shouldn't bother. If we do promise backwards compatibility, we should document it somewhere and if we don't we should probably make that more visible, too, so people know what to expect. I prefer the latter, because it will make the merge.py cleanup easier and every published bit of information I could find suggests that's our current stance anyway. This is more about good will than promising. If it is easy enough to just keep the code around and have it complain to us if we accidentally resurrect a feature, that should be enough. We could even introduce a switch to the CLI like --strict that we can run in our gate and that won't allow us to keep using deprecated features. So I'd like to see us deprecate not because we have to, but because we can do it with only a small amount of effort. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Backwards compatibility policy for our projects
Excerpts from Duncan Thomas's message of 2014-06-16 09:41:49 -0700: On 16 June 2014 17:30, Jason Rist jr...@redhat.com wrote: I'm going to have to agree with Tomas here. There doesn't seem to be any reasonable expectation of backwards compatibility for the reasons he outlined, despite some downstream releases that may be impacted. Backward compatibility is a hard habit to get into, and easy to put off. If you're not making any guarantees now, when are you going to start making them? How much breakage can users expect? Without wanting to look entirely like a troll, should TripleO be dropped as an official until it can start making such guarantees? I think every other official OpenStack project has a stable API policy of some kind, even if they don't entirely match... I actually agree with the sentiment of your statement, which is backward compatibility matters. However, there is one thing that is inaccurate in your statements: TripleO is not a project, it is a program. These tools are products of that program's mission which is to deploy OpenStack using itself as much as possible. Where there are holes, we fill them with existing tools or we write minimal tools such as the tripleo_heat_merge Heat template pre-processor. This particular tool is marked for death as soon as Heat grows the appropriate capabilities to allow that. This tool never wants to be integrated into the release. So it is a little hard to justify bending over backwards for BC. But I don't think that is what anybody is requesting. We're not looking for this tool to remain super agile and grow, thus making any existing code and interfaces a burden. So I think it is pretty easy to just start marking features as deprecated and raising deprecation warnings when they're used. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Backwards compatibility policy for our projects
Hi Clint This looks like a special pleading here - all OpenStack projects (or 'program' if you prefer - I'm honestly not seeing a difference) have bits that they've written quickly and would rather not have to maintain, but in order to allow people to make use of them downstream have to do that work. Ask the cinder team about how much I try to stay on top of any back-compat issues. If TripleO is not ready to take up that burden, then IMO it shouldn't be an official project. If the bits that make it up are too immature to actually be maintained with reasonable guarantees that they won't just pull the rug out from any consumers, then their use needs to be re-thought. Currently, tripleO enjoys huge benefits from its official status, but isn't delivering to that standard. No other project has a hope of coming in as an official deployment tool while tripleO holds that niche. Despite this, tripleO is barely usable, and doesn't seem to be maturing towards taking up the responsibilities that other projects have had forced upon them. If it isn't ready for that, should it go back to incubation and give some other team or technology a fair chance to step up to the plate? I don't want to look like I'm specifically beating on tripleO here, but it is the first openstack component I've worked with that seems to have this little concern for downstream users *and* no apparent plans to fix it. That's without going into all of the other difficulties myself and fellow developers have had trying to get involved with tripleO, which I'll go into at some other point. It is possible there are other places with similar problems, but this is the first I've run into - I'll call out any others I run into, since I think it is important, and discussing it publicly keeps everyone honest. If I've got the wrong expectations, I'd at least like to have the correction on record. Regards -- Duncan Thomas On 16 June 2014 17:58, Clint Byrum cl...@fewbar.com wrote: Excerpts from Duncan Thomas's message of 2014-06-16 09:41:49 -0700: On 16 June 2014 17:30, Jason Rist jr...@redhat.com wrote: I'm going to have to agree with Tomas here. There doesn't seem to be any reasonable expectation of backwards compatibility for the reasons he outlined, despite some downstream releases that may be impacted. Backward compatibility is a hard habit to get into, and easy to put off. If you're not making any guarantees now, when are you going to start making them? How much breakage can users expect? Without wanting to look entirely like a troll, should TripleO be dropped as an official until it can start making such guarantees? I think every other official OpenStack project has a stable API policy of some kind, even if they don't entirely match... I actually agree with the sentiment of your statement, which is backward compatibility matters. However, there is one thing that is inaccurate in your statements: TripleO is not a project, it is a program. These tools are products of that program's mission which is to deploy OpenStack using itself as much as possible. Where there are holes, we fill them with existing tools or we write minimal tools such as the tripleo_heat_merge Heat template pre-processor. This particular tool is marked for death as soon as Heat grows the appropriate capabilities to allow that. This tool never wants to be integrated into the release. So it is a little hard to justify bending over backwards for BC. But I don't think that is what anybody is requesting. We're not looking for this tool to remain super agile and grow, thus making any existing code and interfaces a burden. So I think it is pretty easy to just start marking features as deprecated and raising deprecation warnings when they're used. ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Duncan Thomas ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [TripleO] Backwards compatibility policy for our projects
Excerpts from Duncan Thomas's message of 2014-06-16 10:46:12 -0700: Hi Clint This looks like a special pleading here - all OpenStack projects (or 'program' if you prefer - I'm honestly not seeing a difference) have bits that they've written quickly and would rather not have to maintain, but in order to allow people to make use of them downstream have to do that work. Ask the cinder team about how much I try to stay on top of any back-compat issues. I don't just prefer program. It is an entirely different thing: https://wiki.openstack.org/wiki/Programs https://wiki.openstack.org/wiki/Governance/NewProjects If TripleO is not ready to take up that burden, then IMO it shouldn't be an official project. If the bits that make it up are too immature to actually be maintained with reasonable guarantees that they won't just pull the rug out from any consumers, then their use needs to be re-thought. Currently, tripleO enjoys huge benefits from its official status, but isn't delivering to that standard. No other project has a hope of coming in as an official deployment tool while tripleO holds that niche. Despite this, tripleO is barely usable, and doesn't seem to be maturing towards taking up the responsibilities that other projects have had forced upon them. If it isn't ready for that, should it go back to incubation and give some other team or technology a fair chance to step up to the plate? TripleO _isn't_ an official project. It is a program to make OpenStack deploy itself. This is the same as the infra program, which has a mission to support development. We're not calling for Zuul to be integrated into the release, we are just expecting it to keep supporting the goals of the infra program and OpenStack in general. What is the official deployment tool you mention? There isn't one. The tool we've been debating is something that enables OpenStack to be deployed using its own component, Heat, but that is sort of like oslo-incubator.. it is driving a proof of concept for inclusion into an official project. Ironic was spun out very early on because it was clear there was a need for an integrated project to manage baremetal. This is an example where pieces used for TripleO have been pushed into the integrated release. However, Heat already exists, and that is where the responsibility lies to orchestrate applications. We are driving quite a bit into Heat right now, with a massive refactor of the core to be more resilient to the types of challenges a datacenter environment will present. The features we get from the tripleo_heat_merge pre-processor that is in question will be the next thing to go into Heat. Expecting us to commit resources to both of those efforts doesn't make much sense. The program is driving its mission, and the tools will be incubated and integrated when that makes sense. Meanwhile, it turns out OpenStack _is not_ currently able to deploy itself. Users have to bolt things on, whether it is our tools, or salt/puppet/chef/ansible artifacts, users cannot use just what is in OpenStack to deploy OpenStack. But we need to be able to test from one end to the other while we get things landed in OpenStack.. and so, we use the pre-release model while we get to a releasable thing. I don't want to look like I'm specifically beating on tripleO here, but it is the first openstack component I've worked with that seems to have this little concern for downstream users *and* no apparent plans to fix it. Which component specifically are you referring to? Our plan, nay, our mission, is to fix it by pushing the necessary features into the relevant projects. Also, we actually take on a _higher_ burden of backward compatibility with some of our tools that we do want to release. They're not integrated, and we intend to keep them working with all releases of OpenStack because we intend to keep their interfaces stable for as long as those interfaces are relevant. diskimage-builder, os-apply-config, os-collect-config, os-refresh-config, are all stable, and don't need to be integrated into the OpenStack release because they're not even OpenStack specific. That's without going into all of the other difficulties myself and fellow developers have had trying to get involved with tripleO, which I'll go into at some other point. I would be quite interested in any feedback you can give us on how hard it might be to join the effort. It is a large effort, and I know new contributors can often get lost in a sea of possibilities if we, the long time contributors, aren't careful to get them bootstrapped. It is possible there are other places with similar problems, but this is the first I've run into - I'll call out any others I run into, since I think it is important, and discussing it publicly keeps everyone honest. If I've got the wrong expectations, I'd at least like to have the correction on record. I do think that there is a misunderstanding that TripleO is some kind of tool.
Re: [openstack-dev] [TripleO] Backwards compatibility policy for our projects
On Mon, Jun 16, 2014 at 12:19 PM, Tomas Sedovic tsedo...@redhat.com wrote: All, After having proposed some changes[1][2] to tripleo-heat-templates[3], reviewers suggested adding a deprecation period for the merge.py script. While TripleO is an official OpenStack program, none of the projects under its umbrella (including tripleo-heat-templates) have gone through incubation and integration nor have they been shipped with Icehouse. So there is no implicit compatibility guarantee and I have not found anything about maintaining backwards compatibility neither on the TripleO wiki page[4], tripleo-heat-template's readme[5] or tripleo-incubator's readme[6]. The Release Management wiki page[7] suggests that we follow Semantic Versioning[8], under which prior to 1.0.0 (t-h-t is ) anything goes. According to that wiki, we are using a stronger guarantee where we do promise to bump the minor version on incompatible changes -- but this again suggests that we do not promise to maintain backwards compatibility -- just that we document whenever we break it. According to Robert, there are now downstreams that have shipped things (with the implication that they don't expect things to change without a deprecation period) so there's clearly a disconnect here. If we do promise backwards compatibility, we should document it somewhere and if we don't we should probably make that more visible, too, so people know what to expect. I prefer the latter, because it will make the merge.py cleanup easier and every published bit of information I could find suggests that's our current stance anyway. Tomas [1]: https://review.openstack.org/#/c/99384/ [2]: https://review.openstack.org/#/c/97939/ [3]: https://github.com/openstack/tripleo-heat-templates [4]: https://wiki.openstack.org/wiki/TripleO [5]: https://github.com/openstack/tripleo-heat-templates/blob/master/README.md [6]: https://github.com/openstack/tripleo-incubator/blob/master/README.rst [7]: https://wiki.openstack.org/wiki/TripleO/ReleaseManagement [8]: http://semver.org/ ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev Hi Tomas, By and large, I think you are correct in your conclusions about the current state of backwards compatibility in TripleO. Much of this is the reason why I pushed for the stable branches that we cut for icehouse. I'm not sure what downstreams that have shipped things are being referred to, but perhaps those needs could be served by the stable/icehouse branches that exist today? I know at least for the RDO downstream, the packages are being built off of releases done from the stable branches. So, honestly, I'm not that concerned about your proposed changes to rip stuff out without any deprecation from that point of view :). That being said, just because TripleO has taken the stance that backwards compatibility is not guaranteed, I agree with some of the other sentiments in this thread: that we should at least try if there are easy things we can do. -- -- James Slagle -- ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
