Open Stack

On Sun, Mar 3, 2019 at 7:22 PM Emilien Macchi <emilien at redhat.com> wrote:
>
> (as the one who has been dropping stuffs lately)
>
> To emphasize what Alex said:
> Yes there is a cost in maintaining all these services, and we would like to spend our time on doing something else but maintaining the world, and refocus on what does really matter.
>
> I agree very much that it's a shame to deprecate Designate. As we know it's an important service ans it was freshly added to TripleO. However, if there is no team to maintain its integration then it's always going to be the same folks who will maintain its integration (packaging, puppet-tripleo, THT, containers, etc).
>
> I believe that some of us are exhausted to support that amount of YAML when we know less than 50% is actually deployed & supported in production. Of course we don't have all numbers but it's a guess from our bug reports and feature requests.
> I also believe these people who tirelessly maintain CI & packaging might want to reduce their time to debug these unused (or less used) service and have cycles to actually simplify TripleO and think about the next steps.
>
> What I propose is that we continue to collect feedback from our users and people who deploy TripleO. And we deal with the services case by case.
> For Designate, I agree it's not ideal to deprecate it upstream and maybe we can give it one more chance (one cycle), to see if we have potential users.
> For Congress, I haven't seen any user to be honest. Same for Tacker. Same for ODL. And it will be the same for Docker in Train cycle.

I'd propose something slightly different. We start a
spreadsheet/wiki/git doc/whatever with a list of all the services and
specific maintainers. Each service must have at least one maintainer.
For those services that don't have a maintainer, they are deprecated.

That's the only requirement...there must be at least one specific
person who has volunteered to maintain the service, which includes all
t-h-t, puppet, packaging, and CI (if applicable). If the service is
not maintained then it's deprecated and will then be removed.

That way, there is a very straightforward path to avoid service
deprecation...maintain it.

Also, folks who generally maintain CI and packaging and keep things
running smoothly for the rest of us don't have to worry about
individual services that may or may not be maintained. If a service is
causing issues and it's documented as being maintained (but it's
actually not), then anyone can propose its deprecation as a way to
come to consensus on its actual state.

-- 
-- James Slagle
--