Open Stack

On Thu, Feb 21, 2019 at 1:54 AM Lance Bragstad <lbragstad at gmail.com> wrote:

>
>
> On 2/20/19 11:23 AM, Sylvain Bauza wrote:
>
> Thanks Chris for asking us questions so we can clarify our opinions.
>
> On Wed, Feb 20, 2019 at 3:52 PM Chris Dent <cdent+os at anticdent.org> wrote:
>
>>
>> It's the Campaigning slot of the TC election process, where members
>> of the community (including the candidates) are encouraged to ask
>> the candidates questions and witness some debate. I have some
>> questions.
>>
>> First off, I'd like to thank all the candidates for running and
>> being willing to commit some of their time. I'd also like to that
>> group as a whole for being large enough to force an election. A
>> representative body that is not the result of an election would not
>> be very representing nor have much of a mandate.
>>
>>
> I agree with you on this point. It's important for OpenStack to have time
> to discuss about mandates.
>
> The questions follow. Don't feel obliged to answer all of these. The
>> point here is to inspire some conversation that flows to many
>> places. I hope other people will ask in the areas I've chosen to
>> skip. If you have a lot to say, it might make sense to create a
>> different message for each response. Beware, you might be judged on
>> your email etiquette and attention to good email technique!
>>
>> * How do you account for the low number of candidates? Do you
>>    consider this a problem? Why or why not?
>>
>>
> Yes, again, I agree and to be honest, when I only saw we were only having
> 4 candidates 8 hours before the deadline, I said to myself "OK, you love
> OpenStack. You think the TC is important. But then, why aren't you then
> throwing your hat ?"
> We all have opinions, right ? But then, why people don't want to be in the
> TC ? Because we don't have a lot of time for it ? Or because people think
> the TC isn't important ?
>
> I don't want to discuss about politics here. But I somehow see a parallel
> in between what the TC is and what the European Union is : both are
> governances not fully decision-makers but are there for sharing same rules
> and vision.
> If we stop having the TC, what would become OpenStack ? Just a set of
> parallel projects with no common guidance ?
>
> The fact that a large number of candidacies went very late (including me)
> is a bit concerning to me. How can we become better ? I have no idea but
> saying that probably given the time investment it requires, most of the
> candidacies were probably holding some management acceptance before people
> would propose their names. Probably worth thinking about how the investment
> it requires, in particular given we have less full-time contributors that
> can dedicate large time for governance.
>
>
> * Compare and contrast the role of the TC now to 4 years ago. If you
>>    weren't around 4 years ago, comment on the changes you've seen
>>    over the time you have been around. In either case: What do you
>>    think the TC role should be now?
>>
>>
> 4 years ago, we were in the Kilo timeframe. That's fun you mention this
> period, because at that exact time of the year, the TC voted on one of the
> probably most important decisions that impacted OpenStack : The Big Tent
> reform [1]
> Taking a look at this time, I remember frustration and hard talks but also
> people committed to change things.
> This decision hasn't changed a lot the existing service projects that were
> before the Big Tent, but it actually created a whole new ecosystem for
> developers. It had challenges but it never required to be abandoned, which
> means the program is a success.
>
> Now the buzz is gone and the number of projects stable, the TC necessarly
> has to mutate to a role of making sure all the projects sustain the same
> pace and reliability. Most of the challenges for the TC is now about
> defining and applying criterias for ensuring that all our projects have a
> reasonable state for production. If you see my candidacy letter, two of my
> main drivers for my nomination are about upgradability and scalability
> concerns.
>
>
> * What, to you, is the single most important thing the OpenStack
>>    community needs to do to ensure that packagers, deployers, and
>>    hobbyist users of OpenStack are willing to consistently upstream
>>    their fixes and have a positive experience when they do? What is
>>    the TC's role in helping make that "important thing" happen?
>>
>>
> There are two very distinct reasons when a company decides to
> downstream-only : either by choice or because of technical reasons.
> I don't think a lot of companies decide to manage technical debt on their
> own by choice. OpenStack is nearly 9 years old and most of the users know
> the price it is.
>
> Consequently, I assume that the reasons are technical :
> 1/ they're running an old version and haven't upgraded (yet). We have good
> user stories of large cloud providers that invested in upgrades (for
> example OVH) and see the direct benefit of it. Maybe we can educate more on
> the benefits of upgrading frequently.
> 2/ they think upstreaming is difficult. I'm all open to hear the barriers
> they have. For what it's worth, OpenStack invested a lot in mentoring with
> the FirstContact SIG, documentation and Upstream Institute. There will
> probably also be a new program about peer-mentoring and recognition [2] if
> the community agrees with the idea. Honestly, I don't know what do do more.
> If you really can't upstream but care about your production, just take a
> service contract I guess.
>
>
>
>> * If you had a magic wand and could inspire and make a single
>>    sweeping architectural or software change across the services,
>>    what would it be? For now, ignore legacy or upgrade concerns.
>>    What role should the TC have in inspiring and driving such
>>    changes?
>>
>>
> Take me as a fool but I don't think the role of the TC is to drive
> architectural decision between projects.
> The TC can help two projects to discuss, the TC can (somehow) help
> moderate between two teams about some architectural concern but certainly
> not be the driver of such change.
>
>
> Is there a particular reason why you feel this way?
>
> I think the TC is in a great position to have a profound impact on the
> architecture of OpenStack, with a caveat.
>
> I believe if you ask anyone with even a brief history in OpenStack, you'll
> dust up some architectural opinions. For example, Jim and Mohammed have
> already pointed out a bunch in their responses. Another example, Melanie
> and I had a productive discussion today about how restructuring the
> architecture of policy enforcement could significantly improvement
> usability and security [0], which certainly isn't specific to keystone or
> nova. I don't think we have to look very far to find excellent areas for
> improvement. As others have noted, the project is at a point where
> development and hype isn't nearly as intense as it was 4 years ago. While
> contributor numbers, in a way, reflect project stabilization, I also think
> it puts us in a prime position to address some of the architectural pain
> points we've grown to live with over the years. I think we can use the
> opportunity to make services more consistent, giving consumers and users a
> more refined and polished experience, among other benefits.
>
> That said, I certainly think if the TC is to _facilitate_ in architectural
> decisions, it needs to be done in the open and with plenty of communication
> and feedback with the entire community. Similar to the approach we try and
> take with community goals.
>
> I understand there may be a fine line in making decisions of this nature
> at the TC level, but I also think it presents numerous opportunities to
> communicate and focus efforts in a unified direction. I see that
> involvement range from socializing issues to advocating for sponsorship on
> a particular initiative to diving into the problem and helping projects
> directly.
>
>

Hi Lance,
Thanks for your reply and leaving me a chance to clarify my thoughts on a
possible strawman.
I'm not opposed to architectural modifications, and like you mention the
fact that we're past the hype leaves us a good opportunity for revisiting
some crucial cross-project pain points like the ones you mention (and which
I'm fully onboard). For example, I remember some hard talks we had at
Summits about a potential 'Architecture WG' and all the concerns that were
around it.

What I said earlier was that IMHO the TC should not dictate any
architectural changes or be the initiator of important architectural
redesigns (unless I misunderstand the word 'driving' and in this case my
bad). I rather prefer to see the TC to be a facilitator of such initiatives
coming from individuals or projects (in particular given we're not in a
position where we have less resources that can take time to work full-time
on those big changes that are multi-cycle). We sometimes failed in the past
to have such initiatives, but now we have goals we're in a better position
than in the past.
That said, given the nature of goals to be community-wide, I'm open for
discussing other ways to engage architectural redesigns that imply only a
few services (eg. placement and other services that would consume it). We
generally have cross-project sessions at the PTG that help driving those
discussions, but I somehow feel we miss some better way to promote those.
architectural redesigns.

Hoping I answered your concerns.

-Sylvain



> [0]
> http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-keystone.2019-02-20.log.html#t2019-02-20T18:35:06
>
>
> That doesn't mean the TC can't be technical. We have goals, for example.
> But in order to have well defined goals that are understandable by project
> contributors, we also need to have the projects be the drivers of such
> architectural changes.
>
>
>
>> * What can the TC do to make sure that the community (in its many
>>    dimensions) is informed of and engaged in the discussions and
>>    decisions of the TC?
>>
>>
> You made a very good job in providing TC feedback. I surely think the TC
> has to make sure that a regular weekly feedback is provided.
> For decisions that impact projects, I don't really see how TC members can
> vote without getting feedback from the project contributors, so here I see
> communication (thru Gerrit at least).
>
>
>
>
>> * How do you counter people who assert the TC is not relevant?
>>    (Presumably you think it is, otherwise you would not have run. If
>>    you don't, why did you run?)
>>
>
> Again, I think that is a matter of considering the TC responsibilities. We
> somehow need to clarify what are those responsibilities and I think I
> voiced on that above.
>
>
>
>> That's probably more than enough. Thanks for your attention.
>>
>>
> I totally appreciate you challenging us. That's very important that people
> vote based on opinions rather than popularity.
> -Sylvain
>
> [1]
> https://governance.openstack.org/tc/resolutions/20141202-project-structure-reform-spec.html
> [2] https://review.openstack.org/#/c/636956/
>
>> --
>> Chris Dent                       ٩◔̯◔۶           https://anticdent.org/
>> freenode: cdent                                         tw: @anticdent
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190221/8c7c3cd7/attachment-0001.html>