<div dir="ltr"><div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Mon, 4 Mar 2019 at 17:52, Ben Nemec <<a href="mailto:openstack@nemebean.com">openstack@nemebean.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
<br>
On 3/4/19 9:16 AM, Alex Schultz wrote:<br>
> On Mon, Mar 4, 2019 at 6:11 AM Dan Prince <<a href="mailto:dprince@redhat.com" target="_blank">dprince@redhat.com</a>> wrote:<br>
>><br>
>> On Fri, 2019-03-01 at 15:43 -0700, Alex Schultz wrote:<br>
>>> On Fri, Mar 1, 2019 at 3:24 PM Dan Prince <<a href="mailto:dprince@redhat.com" target="_blank">dprince@redhat.com</a>> wrote:<br>
>>>> Recently we've been cleaning house in some of of the TripleO<br>
>>>> supported<br>
>>>> services.<br>
>>>><br>
>>>> We removed MongoDB as RDO was also dropping it. I guess we needed<br>
>>>> to<br>
>>>> follow suite as our CI is also based on the packages there.<br>
>>>><br>
>>>> For other services (Designate for example) if the RDO packages<br>
>>>> exist<br>
>>>> and we already have support do we really need to deprecate them?<br>
>>>> Having<br>
>>>> the ability to deploy some of the lesser used but still active<br>
>>>> OpenStack projects with our deployment framework is nice for<br>
>>>> developers<br>
>>>> and users alike. Especially when you want to try out a new<br>
>>>> services.<br>
>>>><br>
>>><br>
>>> It's the long term maintenance of them to ensure they continue to<br>
>>> work<br>
>>> (packaging/promotions/requirement syncing). If no one is watching<br>
>>> them<br>
>>> and making sure they still work, I'm not sure it's worth saying they<br>
>>> are "supported". Much like the baremetal support that we had, when we<br>
>>> drop any testing we might as well mark them deprecated since there is<br>
>>> no way to know if they still "work" the next day.  Adding and<br>
>>> maintaining services is non-trivial so unless it's actively used, I<br>
>>> don't think it's necessarily a bad thing to trim our "supported" list<br>
>>> to a set of known good services.<br>
>>><br>
>>> Just in the last two or three weeks I've had to go address packaging<br>
>>> problems with Vitrage[0] and Tacker[1] because requirements changed<br>
>>> in<br>
>>> the project and the packages weren't kept up to date so the puppet<br>
>>> module CI was broken.  No one noticed this was broken until we went<br>
>>> to<br>
>>> go update some unrelated things and found out that they were broken.<br>
>>> The same thing happens in TripleO too where a breakage in a less than<br>
>>> supported service takes away time for more important work.  The cost<br>
>>> to keep these things working is > 0.<br>
>><br>
>> Agree the cost isn't zero. But it also isn't high. And there is value<br>
>> to a project having a deep bench of services from which to choose and<br>
>> try out. The existance of at least some "niche" services in TripleO<br>
>> provides some value to our users and perhaps even an argument to use<br>
>> TripleO as it would be considered a feature to be able to try out these<br>
>> services. Perhaps even partially implemented ones in some cases still<br>
>> have value (no HA support for example).<br>
>><br>
> <br>
> So I gave it some thought and rather than just deprecating for<br>
> removal, could we instead mark them as experimental and treat them as<br>
> such?  Yes you're right that folks might want to try these services,<br>
> however there is no clear definition of a service that should always<br>
> work vs a service that might work.  From an end user perspective if<br>
> they see that something like Congress is defined and they try and<br>
> consume it only to find out it doesn't work or isn't configured<br>
> correctly then that is a poor experience.   I also don't think someone<br>
> who is new to TripleO who wants to try out a service will likely be<br>
> able to figure out why it's not working and just think "TripleO<br>
> doesn't work".  Can we move services which we have no guarentee to be<br>
> working (no testing/no owners) to a /experimental/ folder to indicate<br>
> the service may or may not work?<br>
<br>
As someone who wrote the templates for a now-deprecated service I like <br>
the idea of them living on in some format. On the other hand, in the <br>
course of writing the Designate templates they were broken multiple <br>
times by TripleO changes to the service interfaces. If a service isn't <br>
being tested regularly I suspect there's little chance of it continuing <br>
to work long-term without _someone_ looking after it.<br>
<br>
Heck, Designate _is_ in the gate right now and it still broke recently <br>
in real deployments with separate control and compute nodes. Without <br>
someone paying attention to it I don't know how that would ever have <br>
been found or fixed.<br>
<br>
I think my recommendation would be to keep James's maintainer <br>
requirement for even experimental services, but maybe instead of gating <br>
on them just have a periodic job that runs with them enabled once a <br>
night and emails the maintainer of record if it fails. That way they <br>
can't block other work and aren't consuming much in the way of ci <br>
resources, but they can be maintained with minimal effort. It might <br>
encourage more people to sign up as maintainers if they know breakages <br>
in the service aren't going to force them to drop everything to unblock <br>
the gate.<br></blockquote><div><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">In the kolla project we run some of the service-specific jobs only when relevant files have changed, using Zuuls files/irrelevant-files configuration syntax. This can be combined with a periodic job to catch code rot.</div><div class="gmail_default" style="font-family:verdana,sans-serif">Mark</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Or maybe that will just result in all the periodic jobs failing <br>
indefinitely, but if that happens then you know the maintainer isn't <br>
maintaining anymore and you can deprecate the service.<br>
<br>
I'm also not sure how much burden that would put on the ci squad to set <br>
up such jobs. That's another discussion we'd need to have.<br>
<br>
> <br>
> <br>
>> I just spent the time to "flatten" many of these services thinking they<br>
>> would stay for awhile. Many of us are willing to chip in to keep some<br>
>> of these I think.<br>
>><br>
>>><br>
>>> [0] <a href="https://review.rdoproject.org/r/#/c/19006/" rel="noreferrer" target="_blank">https://review.rdoproject.org/r/#/c/19006/</a><br>
>>> [1] <a href="https://review.rdoproject.org/r/#/c/18830/" rel="noreferrer" target="_blank">https://review.rdoproject.org/r/#/c/18830/</a><br>
>>><br>
>>>> Rather than debate these things ad-hoc on some of the various<br>
>>>> reviews I<br>
>>>> figured it work asking here. Do we have a criteria for when it is<br>
>>>> appropriate to deprecate a service that is implemented and fully<br>
>>>> working? Is it costing us that much in terms of CI and resources to<br>
>>>> keep a few of these services around?<br>
>>>><br>
>>><br>
>>> Do you have a definition of "fully implemented"?  Some of the<br>
>>> services<br>
>>> that have been added were added but never actually tested. Designate<br>
>>> only recently was covered with testing.  Things like Congress have<br>
>>> never been tested (like via tempest) and we've only done an install<br>
>>> but no actual service verification.  I would say Designate might be<br>
>>> closer to fully implemented but Tacker/Congress would not be<br>
>>> considered implemented.<br>
>>><br>
>>> Given that we've previously been asked to reduce our CI footprint, I<br>
>>> think it's hard to say is it really costing that much because the<br>
>>> answer would be yes if it has even the slightest impact.  The fewer<br>
>>> services we support, the less scenarios we have to have, the less<br>
>>> complex deployments we have and the less resource it consumes.<br>
>><br>
>> For the services we agree to keep we could always run them in a lower<br>
>> bandwidth CI framework. Something like periodic jobs. Understood these<br>
>> would occasionally get broken but the upstream feedback loop would at<br>
>> least exist and the services could stay. And we'd still be able to<br>
>> reduce our CI resources as well.<br>
>><br>
>>><br>
>>> Thanks,<br>
>>> -Alex<br>
>>><br>
>>>> Dan<br>
>>>><br>
>>>><br>
>><br>
> <br>
<br>
</blockquote></div></div>