On Wed, Apr 19, 2017 at 2:29 AM, MONTEIRO, FELIPE C <[email protected]> wrote: > Hi all, > > > > I have a question regarding patrole and release management. Many projects > like heat or murano have a tempest plugin within their repos, so by > extension their tempest plugins have releases, as the projects change over > time. However, since patrole is just a tempest plugin, yet heavily reliant > on tempest, how should patrole do release management?
Hi Felipe, Release management depends on whether Patrole is planning the branchless model (i think it is) like Tempest or branch model., If branchless, then it does not fall under release management. It can adopt release model what Tempest has [1]. Branchless model gives many benefit like avoid backward incompatible changes, avoid maintaining multiple Patrole repo across releases etc. > Am I correct in > thinking that it should, in the first place? With nova-network and other > APIs slated for deprecation in Pike and beyond, Patrole will logically have > to continuously be maintained to keep up, meaning that older tests, just > like with Tempest, will have to be phased out. If Patrole, then, does not > have releases, then older release-dependent tests and functionality will > over time be lost. We have 3 cases here: 1. Functionality is deprecated/removed in new release. 2. Functionality newly added in new release. 3. Policy enforcement change. For case 1, Tempest keep testing deprecated functionality till it is marked deprecated across all supported stable branches. Once all stable branch has that functionality as deprecated marked, then we discuss of removing its testing from Tempest. With API Microversion model that is little bit different where functionality might be deprecated after specific version or it is deprecated from base version itself. For example, Nova proxy APIs deprecated after 2.36, Certificate APIs might be gone from base version (which is under discussion). This is more case by case and based on all stack holder point of view, we will decide their testing should be removed or stay till when. For case 2, Tempest introduced testing of new functionality with feature flag and those tests will be executed/skipped accordingly. Case 3 is something important to consider for Patrole. Usually policy changes will be done with backward compatible way where changes does not break upgrade. Any change in policy enforcement will be done at least with supporting old and new rules [2] or with old rules deprecation of period of 1 release cycle at least. And branchless model can detect any accidental changes which going to break upgrade. IMO, branchless model is good value for Patrole in all 3 cases consideration and feature flags to handle the new/old/policy-change functionality. Similarly release model can be same as Tempest has. > > > > Thank You, > > Felipe Monteiro ..1 https://wiki.openstack.org/wiki/QA/releases ..2 https://review.openstack.org/#/c/391113/13 -gmann > > > > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
