Open Stack

Excerpts from Maish Saidel-Keesing's message of 2015-05-05 18:00:15 +0300:
> 
> On 05/05/15 16:01, Doug Hellmann wrote:
> > Excerpts from Adam Lawson's message of 2015-05-04 10:25:10 -0700:
> >> So Thierry I agree. Developers are required to make it happen. I would say
> >> however that acknowledging the importance of developer contributions and
> >> selecting leadership from the development community is really half the
> >> battle as it's pretty rare to see project teams led and governed by only
> >> developers. I think addressing the inclusion of architects/operators/admins
> >> within this committee is a hugely positive development.
> > The community of contributors is led by members, not all of whom
> > are "developers" -- some are writers, translators, designers, or
> > fill other important roles. The characteristic that cuts across all
> > of those roles is that they are *contributors*.
> >
> > If "architects/operators/admins" or anyone else want to become
> > contributors, there is already a path to accomplish that by interacting
> > with the existing teams, and their insight and input would be very
> > welcome. But there is no shortcut to becoming a leader in this
> > community. Everyone has to earn their stripes.
> >
> > I've asked a couple of times in this thread what benefit you see
> > in having someone from outside of the contributor community on the
> > TC, but I haven't seen an answer. Is there something specific we
> > could be addressing beyond the question of representation?
> Hi Doug.
> 
> It is not only the representation - it is also action on the feedback.
> 
> There was an OPS summit not so long ago in Philadelphia [1]. Two full 
> days. I personally did not participate but from what I heard it was a 
> good two days of discussions.

Unfortunately I wasn't able to attend, either, but I've heard the same
general sentiments of the results.

> 
> There are at least 10 etherpads (Yay!! The OpenStack way of doing 
> things!) that summarized the thoughts and concerns of the participants.

+1 for writing things down

> I think it would be fair to ask - how many actionable items came out of 
> the this meeting that were implemented in any of the projects? If anyone 
> has answers - they would be highly appreciated.
> Did the TC follow up on these items?
> Did the PTL's? (I know some of the PTL's were present there at the summit)
> 
> Now you might say - that is not their job, but I do think that it should 
> be. The developer teams are asking for feedback the whole time. Saying 
> that Operators are not sending it back their way. Here they are. What 
> was done with all of this?
> 
> Were bugs raised?
> Were blueprints submitted to make changes to accommodate any of these 
> requests? Address any of them?
> Please don't tell me that you are waiting for the Operations people to 
> submit all of these - because it is not going to happen. Most of them do 
> not know how.

I don't expect them to file blueprints for new features, because
the contributor responsible for the implementation needs to document
their plans.

I absolutely *do* expect Operators to file bugs, though, just as
they would with any other software package they use.

> So here is a process that breaks down. The info is there, but that 
> information is not being followed through upon.
>
> Whose responsibility is this? The TC? The Foundation? The PTL's?
> Here we have proper feedback from those using the products, fighting 
> with (not against) the products and trying to get it working. If even 
> 10% of the items mentioned in these etherpads were addressed (or have a 
> documented plan to be addressed in the future) then I will be very 
> surprised.

OK, so we're finally getting to the real issues! :-)

What is your expectation for timing? Having a meetup to collect
feedback like this mid-cycle is unlikely to affect the current
release in significant ways. For example, bugs may be prioritized
differently, and I know some were, but we're not likely to stop
work on features already in progress to work on something new or start
any large new initiatives at that point in the cycle.

Is the feedback being taken into account during planning for liberty?
Has someone correlated the feedback with the proposed specs and
summit sessions? This is normally something I would expect the PTLs
to be involved with for individual projects, although it might help
to have a single document listing desired actionable changes from
those separate etherpads, and someone involved in the meeting is
probably better able to do that -- it can be difficult to look at
meeting logs after the fact and extract a summary if you weren't
in the room when the meeting occurred. Are there summaries of the
consensus from the meetings?

Looking through a few of the etherpads:

https://etherpad.openstack.org/p/PHL-ops-burning-issues

The first few items in the "burning issues" session look immediately
actionable, some of them (such as nova-net/neutron migration and
ceilometer performance improvements) are already under way as
long-term changes, but some of them are going to need more time to
solve.

https://etherpad.openstack.org/p/PHL-ops-rabbit-queue

I know the session on Rabbit was very helpful to the Oslo team, and
we will have some discussions about what to do with the messaging
library and alternative drivers.

The Oslo team also prioritized the heartbeat bug in part as a result
of these discussions.

https://etherpad.openstack.org/p/PHL-ops-tags

I've started seeing some new tags proposed to the governance repo.
Are those a result of the tagging conversation?

> It comes down to this. OpenStack developers have a way of doing things. 
> Operators also have a way of doing things - which is quite different to 
> the way OpenStack does things.
> 
> If each of these groups continue down the paths they are currently going 
> - never shall the twain meet. They need to come towards each other. The 
> OpenStack community needs be more receptive to the way Operators need 
> things done. Operators need to be more receptive to the way things are 
> done in OpenStack.
> Yes we have made progress. Yes we will continue to make progress. But 
> until the Operators/users (and you can interchange users with Operators 
> throughout my whole email - I was lazy) are accepted to be part of the 
> decision process in OpenStack (and I think that you can agree - that if 
> that actually happens today - it is way after the fact - or extremely 
> late in the process) then this disconnect is going to continue.

Yes, I think we all want operator and user input to be included
much earlier in the process. It remains to be seen if the TC is the
right group to address those concerns directly, since we tend to
deal with issues that affect all projects rather than individual
projects.  That said, there is certainly still a gap in expectations
for how feedback should be handled, and there's work to do to collect
it and make sure the right audience sees it, and helping to develop
the process to facilitate that communication may be something for
the TC to take on.

> There is a feeling (at least that is my perception) that code is 
> developed in a vacuum today. Without actually going into the field and 
> asking what is needed - what is being used - what could be made better - 
> before deciding what to write and fix.

That's an unfortunate impression, and I know it is not always true.
Many contributors are employed by companies who distribute OpenStack,
and their work is informed by the feedback they have from their
customers. Similarly, many contributors are employed by companies
where they run OpenStack themselves, so they have first-hand
experience. I'm not personally aware of any contributor who doesn't
fall into one of those two categories, but there may well be some.
Either way, those collective experiences may be different, but I
think very little is happening in a total vacuum.

Doug