Open Stack

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
> <mailto:cdent%2Bos 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.


[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/20190220/ee1e9d1a/attachment-0001.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-discuss/attachments/20190220/ee1e9d1a/attachment-0001.sig>