Re: [openstack-dev] [Ironic] maintaining backwards compatibility within a cycle
I think it depends totally on if you want trunk to be a distribution mechanism or not. If you encourage people to 'just use trunk' for deployment, then you better not break out of tree drivers on people. If you have a stable release branch, that you tell people to use, there is plenty of forewarning for out of tree drivers to update when the new stable is about to be released. Thanks, Kevin From: Lucas Alvares Gomes [lucasago...@gmail.com] Sent: Thursday, November 20, 2014 8:28 AM To: OpenStack Development Mailing List (not for usage questions) Subject: Re: [openstack-dev] [Ironic] maintaining backwards compatibility within a cycle Hi Ruby, Thank you for putting this up. I'm one of the ones think we should try hard (even really hard) to maintain the compatibility on every commit. I understand that it may sound naive because I'm sure that sometimes we will break things, but that doesn't means we shouldn't try. There may be people running Ironic in a continuous deployment environment, those are the users of the project and therefor the most important part of Ironic. Doesn't matter how well written Ironic code may be if nobody is using it. If we break that user workflow and he's unhappy that's the ultimate failure. I also understand that in the project POV we want to have fast interactions and shiny new features as quick as possible and trying to be backward compatibility all the time - on every commit - might slow that down. But in the user POV I believe that he doesn't care much about all the new features, he would mostly care about the things that used to work to continue to work for him. Also the backwards approach between releases and not commits might work fine in the non-opensource world where the code is kept indoors until the software is release, but in the opensource world where the code is out to people to use it all the time it doesn't seem to work that well. That's my 2 cents. Lucas On Thu, Nov 20, 2014 at 3:38 PM, Ruby Loo wrote: > Hi, we had an interesting discussion on IRC about whether or not we should > be maintaining backwards compatibility within a release cycle. In this > particular case, we introduced a new decorator in this kilo cycle, and were > discussing the renaming of it, and whether it needed to be backwards > compatible to not break any out-of-tree driver using master. > > Some of us (ok, me or I) think it doesn't make sense to make sure that > everything we do is backwards compatible. Others disagree and think we > should, or at least strive for 'must be' backwards compatible with the > caveat that there will be cases where this isn't feasible/possible/whatever. > (I hope I captured that correctly.) > > Although I can see the merit (well, sort of) of trying our best, trying > doesn't mean 'must', and if it is 'must', who decides what can be exempted > from this, and how will we communicate what is exempted, etc? > > Thoughts? > > --ruby > > ___ > 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 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] maintaining backwards compatibility within a cycle
Let's get concrete for a moment, because it makes a difference which API we're talking about. We have to guarantee a fairly high degree of backwards compatibility within the REST API. Adding new capabilities, and exposing them in a discoverable way, is fine; a backwards-incompatible breaking change to the REST API is definitely not OK without a version bump. We should (and do) make a strong effort not to land any REST API change without appreciable thought and testing of its impact. Changes here have an immediate effect on anyone following trunk. The RPC API is another area of compatibility, and perhaps the one most clearly versioned today. We must continue supporting running disparate versions of the RPC client and server (that is, rpcapi.py and manager.py) so that operators can upgrade the API and Conductor services asymmetrically. Changes to the RPC API are done in such a way that each service can be upgraded independently of other services. The driver API is the only purely-python API we support -- and we know that there are downstream consumers of that API. OnMetal is one such; many other spoke up at the recent summit. While the impact of a breaking change here is less than in the REST API, it is not to be overlooked. There is a cost associated with maintaining an out-of-tree driver and we should make a best-effort to minimize that cost for folks who (for what ever reason) are in that boat. -Devananda On Thu Nov 20 2014 at 8:28:56 AM Lucas Alvares Gomes wrote: > Hi Ruby, > > Thank you for putting this up. > > I'm one of the ones think we should try hard (even really hard) to > maintain the compatibility on every commit. I understand that it may > sound naive because I'm sure that sometimes we will break things, but > that doesn't means we shouldn't try. > > There may be people running Ironic in a continuous deployment > environment, those are the users of the project and therefor the most > important part of Ironic. Doesn't matter how well written Ironic code > may be if nobody is using it. If we break that user workflow and he's > unhappy that's the ultimate failure. > > I also understand that in the project POV we want to have fast > interactions and shiny new features as quick as possible and trying to > be backward compatibility all the time - on every commit - might slow > that down. But in the user POV I believe that he doesn't care much > about all the new features, he would mostly care about the things that > used to work to continue to work for him. > > Also the backwards approach between releases and not commits might > work fine in the non-opensource world where the code is kept indoors > until the software is release, but in the opensource world where the > code is out to people to use it all the time it doesn't seem to work > that well. > > That's my 2 cents. > > Lucas > > On Thu, Nov 20, 2014 at 3:38 PM, Ruby Loo wrote: > > Hi, we had an interesting discussion on IRC about whether or not we > should > > be maintaining backwards compatibility within a release cycle. In this > > particular case, we introduced a new decorator in this kilo cycle, and > were > > discussing the renaming of it, and whether it needed to be backwards > > compatible to not break any out-of-tree driver using master. > > > > Some of us (ok, me or I) think it doesn't make sense to make sure that > > everything we do is backwards compatible. Others disagree and think we > > should, or at least strive for 'must be' backwards compatible with the > > caveat that there will be cases where this isn't > feasible/possible/whatever. > > (I hope I captured that correctly.) > > > > Although I can see the merit (well, sort of) of trying our best, trying > > doesn't mean 'must', and if it is 'must', who decides what can be > exempted > > from this, and how will we communicate what is exempted, etc? > > > > Thoughts? > > > > --ruby > > > > ___ > > 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 > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] maintaining backwards compatibility within a cycle
On 11/20/2014 04:38 PM, Ruby Loo wrote: Hi, we had an interesting discussion on IRC about whether or not we should be maintaining backwards compatibility within a release cycle. In this particular case, we introduced a new decorator in this kilo cycle, and were discussing the renaming of it, and whether it needed to be backwards compatible to not break any out-of-tree driver using master. Some of us (ok, me or I) think it doesn't make sense to make sure that everything we do is backwards compatible. Others disagree and think we should, or at least strive for 'must be' backwards compatible with the caveat that there will be cases where this isn't feasible/possible/whatever. (I hope I captured that correctly.) Although I can see the merit (well, sort of) of trying our best, trying doesn't mean 'must', and if it is 'must', who decides what can be exempted from this, and how will we communicate what is exempted, etc? It make sense to try to preserve compatibility, especially for things that landed some time ago. For newly invented things, like the decorator it makes no sense to me, however. People consuming master have to be prepared. That does not mean that we should break them every week obviously, but still. That's why we have releases: to promise stability to people. By consuming master you agree that things might break rarely. Thoughts? --ruby ___ 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] [Ironic] maintaining backwards compatibility within a cycle
Thank you for this Ruby, I agree with what Lucas stated in his reply, Though I thought I would toss my two cents in to the pool as well. I also feel that we should (and have been) strive (ing) to maintain compatibility. Though I feel this is more important on a release to release basis, more so then on an inter cycle basis. I feel this way because with in a cycle a new feature may be introduced that has an unforeseen impact on the current code that needs to be addressed with in that cycle. As a Operator I would refer to this a "leading edge" vs "bleeding edge". This is also one of the reasons we cut stable releases, so that folks who what to have stability in the code they run in production are not having to deal the day to day upkeep of what landed trunk (master branch) last night that broke my production environment. Trunk is almost by default not a stable playground, If we add a new shinny and then find out that it has an unforeseen impact, changing the way the new feature is implemented is not such a bad thing, as long as it is still with in the cycle it was introduced and an official release has not been cut, I am excluding RC releases as they are Release "Candidates" and finding such impacts is there "job". As this is only my option, actual cash value is less then .02 cents. Chris Krelle NobodyCam On Thu, Nov 20, 2014 at 8:28 AM, Lucas Alvares Gomes wrote: > Hi Ruby, > > Thank you for putting this up. > > I'm one of the ones think we should try hard (even really hard) to > maintain the compatibility on every commit. I understand that it may > sound naive because I'm sure that sometimes we will break things, but > that doesn't means we shouldn't try. > > There may be people running Ironic in a continuous deployment > environment, those are the users of the project and therefor the most > important part of Ironic. Doesn't matter how well written Ironic code > may be if nobody is using it. If we break that user workflow and he's > unhappy that's the ultimate failure. > > I also understand that in the project POV we want to have fast > interactions and shiny new features as quick as possible and trying to > be backward compatibility all the time - on every commit - might slow > that down. But in the user POV I believe that he doesn't care much > about all the new features, he would mostly care about the things that > used to work to continue to work for him. > > Also the backwards approach between releases and not commits might > work fine in the non-opensource world where the code is kept indoors > until the software is release, but in the opensource world where the > code is out to people to use it all the time it doesn't seem to work > that well. > > That's my 2 cents. > > Lucas > > On Thu, Nov 20, 2014 at 3:38 PM, Ruby Loo wrote: > > Hi, we had an interesting discussion on IRC about whether or not we > should > > be maintaining backwards compatibility within a release cycle. In this > > particular case, we introduced a new decorator in this kilo cycle, and > were > > discussing the renaming of it, and whether it needed to be backwards > > compatible to not break any out-of-tree driver using master. > > > > Some of us (ok, me or I) think it doesn't make sense to make sure that > > everything we do is backwards compatible. Others disagree and think we > > should, or at least strive for 'must be' backwards compatible with the > > caveat that there will be cases where this isn't > feasible/possible/whatever. > > (I hope I captured that correctly.) > > > > Although I can see the merit (well, sort of) of trying our best, trying > > doesn't mean 'must', and if it is 'must', who decides what can be > exempted > > from this, and how will we communicate what is exempted, etc? > > > > Thoughts? > > > > --ruby > > > > ___ > > 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 > ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Ironic] maintaining backwards compatibility within a cycle
Hi Ruby, Thank you for putting this up. I'm one of the ones think we should try hard (even really hard) to maintain the compatibility on every commit. I understand that it may sound naive because I'm sure that sometimes we will break things, but that doesn't means we shouldn't try. There may be people running Ironic in a continuous deployment environment, those are the users of the project and therefor the most important part of Ironic. Doesn't matter how well written Ironic code may be if nobody is using it. If we break that user workflow and he's unhappy that's the ultimate failure. I also understand that in the project POV we want to have fast interactions and shiny new features as quick as possible and trying to be backward compatibility all the time - on every commit - might slow that down. But in the user POV I believe that he doesn't care much about all the new features, he would mostly care about the things that used to work to continue to work for him. Also the backwards approach between releases and not commits might work fine in the non-opensource world where the code is kept indoors until the software is release, but in the opensource world where the code is out to people to use it all the time it doesn't seem to work that well. That's my 2 cents. Lucas On Thu, Nov 20, 2014 at 3:38 PM, Ruby Loo wrote: > Hi, we had an interesting discussion on IRC about whether or not we should > be maintaining backwards compatibility within a release cycle. In this > particular case, we introduced a new decorator in this kilo cycle, and were > discussing the renaming of it, and whether it needed to be backwards > compatible to not break any out-of-tree driver using master. > > Some of us (ok, me or I) think it doesn't make sense to make sure that > everything we do is backwards compatible. Others disagree and think we > should, or at least strive for 'must be' backwards compatible with the > caveat that there will be cases where this isn't feasible/possible/whatever. > (I hope I captured that correctly.) > > Although I can see the merit (well, sort of) of trying our best, trying > doesn't mean 'must', and if it is 'must', who decides what can be exempted > from this, and how will we communicate what is exempted, etc? > > Thoughts? > > --ruby > > ___ > 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
