(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.

Thanks for running this discussion Dan, I hope we can find some consensus.

On Fri, Mar 1, 2019 at 5:48 PM Alex Schultz <aschultz@redhat.com> wrote:

On Fri, Mar 1, 2019 at 3:24 PM Dan Prince <dprince@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[0] and Tacker[1] 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.

[0] https://review.rdoproject.org/r/#/c/19006/
[1] https://review.rdoproject.org/r/#/c/18830/

> Rather than debate these things ad-hoc on some of the various reviews I
> figured it work asking here. Do we have a criteria for when it is
> appropriate to deprecate a service that is implemented and fully
> working? Is it costing us that much in terms of CI and resources to
> keep a few of these services around?
>

Do you have a definition of "fully implemented"? Some of the services
that have been added were added but never actually tested. Designate
only recently was covered with testing. Things like Congress have
never been tested (like via tempest) and we've only done an install
but no actual service verification. I would say Designate might be
closer to fully implemented but Tacker/Congress would not be
considered implemented.

Given that we've previously been asked to reduce our CI footprint, I
think it's hard to say is it really costing that much because the
answer would be yes if it has even the slightest impact. The fewer
services we support, the less scenarios we have to have, the less
complex deployments we have and the less resource it consumes.

Thanks,
-Alex

> Dan
>
>