[openstack-dev] [tc] [all] OpenStack moving both too fast and too slow at the same time

Fox, Kevin M Kevin.Fox at pnnl.gov
Fri May 5 17:36:02 UTC 2017


+1. ocata's cell v2 stuff added a lot of extra required complexity with no perceivable benefit to end users. If there was a long term stable version, then putting it in the non lts release would have been ok. In absence of lts, I would have recommended the cell v2 stuff have been done in a branch instead and merged all together when it provided something (pike I think)

OpenStack Operators already suffer a lot of pain and more pain without benefit is something we should be avoiding at all costs.

Thanks,
Kevin 
________________________________________
From: Alex Schultz [aschultz at redhat.com]
Sent: Friday, May 05, 2017 9:36 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [tc] [all] OpenStack moving both too fast and too slow at the same time

On Fri, May 5, 2017 at 6:16 AM, Sean Dague <sean at dague.net> wrote:
> On 05/04/2017 11:08 AM, Alex Schultz wrote:
>> On Thu, May 4, 2017 at 5:32 AM, Chris Dent <cdent+os at anticdent.org> wrote:
>>> On Wed, 3 May 2017, Drew Fisher wrote:
>>>
>>>> This email is meant to be the ML discussion of a question I brought up
>>>> during the TC meeting on April 25th.; [1]
>>>
>>>
>>> Thanks for starting this Drew, I hope my mentioning it in my tc
>>> report email wasn't too much of a nag.
>>>
>>> I've added [tc] and [all] tags to the subject in case people are
>>> filtering. More within.
>>>
>>>> The TL;DR version is:
>>>>
>>>> Reading the user survey [2], I see the same issues time and time again.
>>>> Pages 18-19 of the survey are especially common points.
>>>> Things move too fast, no LTS release, upgrades are terrifying for
>>>> anything that isn't N-1 -> N.
>>>> These come up time and time again
>>>> How is the TC working with the dev teams to address these critical issues?
>>>
>>>
>>> As I recall the "OpenStack-wide Goals"[a] are supposed to help address
>>> some of this sort of thing but it of course relies on people first
>>> proposing and detailing goals and then there actually being people
>>> to act on them. The first part was happening at[b] but it's not
>>> clear if that's the current way.
>>>
>>> Having people is the hard part. Given the current contribution
>>> model[c] that pretty much means enterprises ponying up the people do
>>> the work. If they don't do that then the work won't get done, and
>>> people won't buy the products they are supporting, I guess? Seems a
>>> sad state of affairs.
>>>
>>> There's also an issue where we seem to have decided that it is only
>>> appropriate to demand a very small number of goals per cycle
>>> (because each project already has too much on their plate, or too big
>>> a backlog, relative to resources). It might be that as the
>>> _Technical_ Committe is could be legitimate to make a larger demand.
>>> (Or it could be completely crazy.)
>>>
>>>> I asked this because on page 18 is this comment:
>>>>
>>>> "Most large customers move slowly and thus are running older versions,
>>>> which are EOL upstream sometimes before they even deploy them."
>>>
>>>
>>> Can someone with more of the history give more detail on where the
>>> expectation arose that upstream ought to be responsible things like
>>> long term support? I had always understood that such features were
>>> part of the way in which the corporately avaialable products added
>>> value?
>>>
>>>> This is exactly what we're seeing with some of our customers and I
>>>> wanted to ask the TC about it.
>>>
>>>
>>> I know you're not speaking as the voice of your employer when making
>>> this message, so this is not directed at you, but from what I can
>>> tell Oracle's presense upstream (both reviews and commits) in Ocata
>>> and thus far in Pike has not been huge. Maybe that's something that
>>> needs to change to keep the customers happy? Or at all.
>>>
>>
>> Probably because they are still on Kilo. Not sure how much they could
>> be contributing to the current when their customers are demanding that
>> something is rock solid which by now looks nothing like the current
>> upstream.   I think this is part of the problem as the upstream can
>> tend to outpace anyone else in terms of features or anything else.  I
>> think the the bigger question could be what's the benefit of
>> continuing to press forward and add yet more features when consumers
>> cannot keep up to consume these?  Personally I think usability (and
>> some stability) sometimes tends to take a backseat to features in the
>> upstream which is unfortunate because it makes these problems worse.
>
> The general statement of "people care more about features than
> usability/stability" gets thrown around a lot. And gets lots of head
> nodding. But rarely comes with specifics.
>
> Can we be specific about what feature work is outpacing the consumers
> that don't help with usability/stability?
>

The cell v2 initial implementation was neither usable or stable (for
my definition of stable). Yea you could say 'but it's a work and
progress' and I would say, why is it required for the end user then?
If I wanted to I could probably go back and go through every project
and point out when a feature was added yet we still have a pile of
outstanding issues.  As Chris Friesen pointed out in his reply email,
there are things out there are specifics if you go looking.  You have
to understand that as I'm mainly dealing with having to actually
deploy/configure the software, when I see 'new project X' that does
'cool new things Y, Z' it makes me cringe.  Because it's just added
complexity for new features that who knows if they are actually going
to be consumed by a majority of end users.  I see a lot of new
features for edge cases while the core functionally (insert the most
used project configuration) still have awkward deployment,
configuration and usability issues. But those aren't exciting so
people don't want to work on them...

Thanks,
-Alex


>         -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __________________________________________________________________________
> 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



More information about the OpenStack-dev mailing list