[TripleO] criteria for deprecating services
tony at bakeyournoodle.com
Mon Mar 4 00:01:41 UTC 2019
On Fri, Mar 01, 2019 at 03:43:18PM -0700, Alex Schultz wrote:
> On Fri, Mar 1, 2019 at 3:24 PM Dan Prince <dprince at redhat.com> wrote:
> > Recently we've been cleaning house in some of of the TripleO supported
> > services.
> > We removed MongoDB as RDO was also dropping it. I guess we needed to
> > follow suite as our CI is also based on the packages there.
> > For other services (Designate for example) if the RDO packages exist
> > and we already have support do we really need to deprecate them? Having
> > the ability to deploy some of the lesser used but still active
> > OpenStack projects with our deployment framework is nice for developers
> > and users alike. Especially when you want to try out a new services.
> It's the long term maintenance of them to ensure they continue to work
> (packaging/promotions/requirement syncing). If no one is watching them
> and making sure they still work, I'm not sure it's worth saying they
> are "supported". Much like the baremetal support that we had, when we
> drop any testing we might as well mark them deprecated since there is
> no way to know if they still "work" the next day. Adding and
> maintaining services is non-trivial so unless it's actively used, I
> don't think it's necessarily a bad thing to trim our "supported" list
> to a set of known good services.
> Just in the last two or three weeks I've had to go address packaging
> problems with Vitrage and Tacker because requirements changed in
> the project and the packages weren't kept up to date so the puppet
> module CI was broken. No one noticed this was broken until we went to
> go update some unrelated things and found out that they were broken.
> The same thing happens in TripleO too where a breakage in a less than
> supported service takes away time for more important work. The cost
> to keep these things working is > 0.
>  https://review.rdoproject.org/r/#/c/19006/
>  https://review.rdoproject.org/r/#/c/18830/
I don't really want to distract from the general topic on which I don't
have any strong oinions ... BUT ...
For this case is there a CI job what could have caught this failure? In
general on OpenSTack infrastructire we have the periodic pipeline so
that once a day we can check the generat health of a project. This
gives us a) an indication that things are broken and b) when (within
24hours) they broke?
Could we do something similar in RDO? Granted this doesn't mean people
will pay attention and fix things but it does help with backtracking?
Another thought I know we have some automatic jobs that rebuild RDO
packages when the requirements team bump things in u-c could we run
something similar that looks at the requirements of a service and check
that they're reflected in the .spec?
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 488 bytes
Desc: not available
More information about the openstack-discuss