Open Stack

On Mon, Oct 16, 2017 at 7:33 AM, Steven Dake (stdake) <stdake at cisco.com> wrote:
> Emilien,
>
> I generally thought the stable policy seemed reasonable enough for lifecycle management tools.  I’m not sure what specific problems you had in TripleO although I did read your review.  Kolla was just tagged with the stable policy, and TMK, we haven’t run into trouble yet, although the Kolla project is stable and has been following the stable policy for about 18 months.  If the requirements are watered down, the tag could potentially be meaningless.  We haven’t experienced this specific tag enough to know if it needs some refinement for the specific use case of lifecycle management tools.  That said, the follows release policy was created to handle the special case of lifecycle management tool’s upstream sources not being ready for lifecycle management tools to release at one coordinated release time.
>
> Kollians?  Any problems thus far with the stable policy?
>
> Cheers
> -steve
>

I'm not a Kolla person, but from the Puppet OpenStack stand point we
haven't been able to follow stable because we can't guarantee complete
configuration coverage for all the services. So while we don't
backport breaking changes (ie removing parameters from resources), we
do have to backport additions (adding params to resources/etc) as
folks start trying to use the upstream services. Since people are not
necessarily following master in their deployments, for example there's
a significant lag from operators who start trying to upgrade to Newton
about the time we're releasing Pike, etc etc.  These types of
additions could be seen as features because we didn't know we had to
add additional code to support the use case in the previous cycle.
Generally we're supporting our basic scenarios (which are pretty
extensive), but there are end user cases we don't test on a regular
basis which pop up from time to time where being able to say we
support a 'stable-policy' but will backport non-breaking changes if
necessary.

Thanks,
-Alex

>
> On 10/16/17, 4:27 AM, "Thierry Carrez" <thierry at openstack.org> wrote:
>
>     Emilien Macchi wrote:
>     > [...]
>     > ## Proposal
>     >
>     > Proposal 1: create a new policy that fits for projects like installers.
>     > I kicked-off something here: https://review.openstack.org/#/c/511968/
>     > (open for feedback).
>     > Content can be read here:
>     > http://docs-draft.openstack.org/68/511968/1/check/gate-project-team-guide-docs-ubuntu-xenial/1a5b40e//doc/build/html/stable-branches.html#support-phases
>     > Tag created here: https://review.openstack.org/#/c/511969/ (same,
>     > please review).
>     >
>     > The idea is really to not touch the current stable policy and create a
>     > new one, more "relax" that suits well for projects like installers.
>     >
>     > Proposal 2: change the current policy and be more relax for projects
>     > like installers.
>     > I haven't worked on this proposal while it was something I was
>     > considering doing first, because I realized it could bring confusion
>     > in which projects actually follow the real stable policy and the ones
>     > who have exceptions.
>     > That's why I thought having a dedicated tag would help to separate them.
>     >
>     > Proposal 3: no change anywhere, projects like installer can't claim
>     > stability etiquette (not my best option in my opinion).
>     >
>     > Anyway, feedback is welcome, I'm now listening. If you work on Kolla,
>     > TripleO, OpenStack-Ansible, PuppetOpenStack (or any project who has
>     > this need), please get involved in the review process.
>
>     My preference goes to proposal 1, however rather than call it "relaxed"
>     I would make it specific to deployment/lifecycle or cycle-trailing
>     projects.
>
>     Ideally this policy could get adopted by any such project. The
>     discussion started on the review and it's going well, so let's see where
>     it goes :)
>
>     --
>     Thierry Carrez (ttx)
>
>     __________________________________________________________________________
>     OpenStack Development Mailing List (not for usage questions)
>     Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>     http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev