Open Stack

Hiya,

I wanted to chime in here a bit as I¹ve had many discussions with John and
as a team lead of a dev group I believe I have an interesting perspective
that spans dev and product:

1. Approaching the project (i.e. the cores) can be tricky. Devs need to
review and write code. The core devs are the gatekeepers to what is
accepted, and this is a pretty small pipe for the amount of work coming
in. Because they also have to review new features (i.e. specs) and
reported bugs, they try to group this into phases of work. It¹s a bit
archaic and amounts to essentially the customer service model of don¹t
answer the phone except on holidays and then make it quick because they¹re
very busy. Not altogether pleasant when calling in, so you really have
know how to navigate the system to get anything done. Just be aware that
this is a problem that exists (that desperately needs fixing) as you
approach, lest you might rage quit.

2. Don¹t get too close to any one project¹s priorities. Nova has a list of
priorities (John shared), but these are very much how vs what, IMHO. The
goal is to define what the expected behavior of a OpenStack configuration
should be. Given this OpenStack configuration, when I do this thing, I get
this result.


3. Create tests and show that it doesn¹t work. Advertise it. This
OpenStack configuration really ought to do this thing, and look it really
doesn¹t. How can we fix that? Draw the devs attention to the interesting
problem you just shared with the world instead of asking them to do
things. There are 1000 node clusters coming to use for testing, leverage
them.

4. I have more thoughts, but I gotta jet. We¹ll talk more.

Thanks,

Jesse

On 8/11/15, 1:29 PM, "Barrett, Carol L" <carol.l.barrett at intel.com> wrote:

>John - If this is the wrong time, what is the right timing to have a
>discussion with the development team on use cases for the M-Design Summit?
>
>Thanks
>Carol
>
>-----Original Message-----
>From: johngarbutt at gmail.com [mailto:johngarbutt at gmail.com] On Behalf Of
>John Garbutt
>Sent: Tuesday, August 11, 2015 2:25 AM
>To: Shamail
>Cc: Barrett, Carol L; product-wg at lists.openstack.org
>Subject: Re: [Product] Nova and the Product Working Group
>
>Hi,
>
>So I am a bit worried this proposed approach will alienate a lot of the
>Nova developers. Let me explain...
>
>This is the exact point in the development cycle where we are focusing on
>almost everything except reviewing new use cases and features, so I think
>looking to review those user stores in a developer meeting will not go
>down well:
>https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule
>
>My aim is really to raise awareness of our current priorities and project
>scope (and discuss those, so we all understand them), while you are
>working on the use cases and working out priorities.
>
>On reflection, I think its better to get Nova folks into your
>discussions, rather than the other way around.
>
>Let me respond to a few specific questions...
>
>On 11 August 2015 at 03:37, Shamail <itzshamail at gmail.com> wrote:
>> Hi John,
>>
>> To follow up... We discussed the interlock opportunity today at our
>>meeting.  Geoff Arnold and I will join the upcoming Nova meeting this
>>Thursday at 21:00 UTC.  The offer for us to attend another meeting,
>>after the cross project meeting, the week of 8/24 still stands too.
>
>I am very unlikely to be at that meeting (as I am in a field, at a music
>festival at that time.)
>
>(For context, I don't usually chair that meeting, as I just can't do a
>good job of that at 10pm).
>
>> I wanted to make introductions and start the communication as soon as
>>possible per your suggestion.  We can discuss what your expectations are
>>from the Product WG, we can give an update on our activities, and find
>>out how we can best help before (and during) the Nova design summit for
>>Mitaka.
>
>My expectations are for the Product WG to engage with the existing
>development processes. I want to help guide you all through that.
>
>Once we try that out, I am sure there will be changes that make sense,
>but this is about you all gaining influence with the developer community.
>
>If you want a use case to get traction, I think you need to help recruit
>developers to work on that along side the rest of the upstream community.
>
>>> On Aug 10, 2015, at 6:27 PM, Barrett, Carol L
>>><carol.l.barrett at intel.com> wrote:
>>>
>>> John - I want to echo Shamail's Thank you. Your partnership is
>>>appreciated.
>>>
>>> I think that we are, roughly, on track to intercept Liberty 3/Start of
>>>Mikata Design Summit planning. We are working to complete the list of
>>>user stories for our pilot, with input from Operators by the end of
>>>next week. Our plan is to review that in the cross-project team meeting
>>>the week of 8/24 (haven't asked for agenda time yet). Do you think it
>>>will make sense to review the Nova related user stories in a Nova team
>>>meeting that week too? I'm sure it would be very helpful for the gaps
>>>analysis around each user story.
>
>Basically, no, I don't think thats a good idea. See above.
>
>>> I agree with Shamail about adding the product manager collaboration
>>>topic to our Mid-Cycle meeting.
>
>I think this is the most important thing for the group to do, by far.
>
>From where I am stood its 100 times (yes, thats a random number) more
>important than the list of user stories.
>
>Now if the list of user stories is a good way to start the conversation,
>and I think it probably is, then thats cool. Its just if the list ends up
>getting ignored by the developer community, the process is still a good
>stepping stone to where there is more cross company collaboration at the
>product level.
>
>>> On your Mission, it's a great starting place and with my Enterprise
>>>hat on, I am quite heartened to see upgrades included. I think there
>>>may also be something around robustness/reliability that would be
>>>important to Operators to include.
>
>I guess we consider robustness/reliability implicitly part of a good API.
>
>If the API doesn't work reliably, its pointless. If people keep having to
>retry deletes, well thats a bad API (slightly depending on who you ask).
>
>>> On priorities, Scheduler and Upgrades are v important.
>
>We have spend the last few years doing the ground work here. Its been a
>long process, but we are getting results now:
>http://www.danplanet.com/blog/2015/06/26/upgrading-nova-to-kilo-with-minim
>al-downtime
>
>The upgrade obligations are really slowing down development, but its
>important.
>
>>> I would propose adding something explicit about reducing outstanding
>>>bug count (Live migration being an important area) to help direct
>>>reviewers to those patches.
>
>As no one stepped up to help, it is on this list for liberty:
>http://specs.openstack.org/openstack/nova-specs/priorities/liberty-priorit
>ies.html#priorities-without-a-clear-plan
>
>We are trying out a few things to fix that (see subgroups recommending
>the most important patches, and my effort to bring back bug triage and
>bug review days).
>
>For those wanting to help live migrate, they should put effort behind
>making this test work:
>gate-tempest-dsvm-multinode-full
>Until that is properly working (i am told its getting close), there is
>little we can do.
>
>If there are bugs that need more attention (certainly review wise), get
>in touch, and I can help with that, using our existing processes.
>Do get in touch with me for some specific help, but there are some
>general tips here:
>https://wiki.openstack.org/wiki/Nova/Liberty_Release_Schedule#How_can_I_ge
>t_my_code_merged_faster.3F
>
>>> I believe that the Neutron/Nova-network migration path needs a good
>>>definition, esp in light of the DefCore direction.
>
>In general, a fully automated migration for all cases is just not
>feasible.
>
>We are looking for folks to help setup up an identify the specific
>scenarios that need a migration path.
>
>There are still worries about Neutron not supporting the same features as
>nova-network, and folks are working on the gaps there (better support
>from the linux bridge was one of the items).
>
>We missed that off from this list, mostly as we were more worried about
>the other items in this list (I really should describe those better, they
>are mostly about stability):
>http://specs.openstack.org/openstack/nova-specs/priorities/liberty-priorit
>ies.html#priorities-without-a-clear-plan
>
>>> As we put in placed CPL (Cross Project Liasons) between the Product
>>>Working group and the other Project teams, I'm hopeful that we will
>>>better both align and integrate with the community processes and
>>>methods.
>
>We have had variable success with CPLs, but I think its a good starting
>point. I don't see any listed on the wiki yet:
>https://wiki.openstack.org/wiki/CrossProjectLiaisons
>
>Thanks,
>John
>
>>> -----Original Message-----
>>> From: Shamail Tahir [mailto:itzshamail at gmail.com]
>>> Sent: Friday, August 07, 2015 8:33 AM
>>> To: John Garbutt
>>> Cc: product-wg at lists.openstack.org
>>> Subject: Re: [Product] Nova and the Product Working Group
>>>
>>> Hi John,
>>>
>>> Thank you for reaching out!  Please see my comments in-line.  We look
>>>forward to speaking with you soon.
>>>
>>>> On Fri, Aug 7, 2015 at 7:59 AM, John Garbutt <john at johngarbutt.com>
>>>>wrote:
>>>>
>>>> Hi,
>>>>
>>>> I would love to start a conversation with you all about Nova and
>>>>Mitaka.
>>>>
>>>> Probably makes sense to arrange a meeting to discuss these points,
>>>> or I could join one of your meetings. I can invite other developers
>>>> along that might be interested.
>>> [ST] We would love for yourself and the team do stop by for one of our
>>>meetings.  We should target either this coming Monday (8/17) or the
>>>Monday after the ops summit/product midcycle (8/24).  We can join one
>>>of your meetings as well but it would be great to have you join our
>>>meeting so that we can maximize the number of product WG members that
>>>can participate.
>>>
>>>>
>>>> It would be great to get this done before liberty-3, so can get to
>>>> something that can inform the chosen Design Summit sessions.
>>> [ST] +1.  The product WG is planning to pilot a "workflow" that spans
>>>the sequence of events leading from documenting user stories from
>>>various sources all the way through engagement/collaboration with the
>>>developer community.  We plan to discuss the available user stories
>>>next week and, hopefully, determine which ones we can use to "pilot"
>>>the process.
>>>
>>>>
>>>> Starting the Conversation
>>>> -------------------------
>>>>
>>>> If I was asked to pick on key deliverable for the Product Working
>>>> Group, I think it would be to create a forum for Product Managers to
>>>> collaborate, and discuss each others mission, goals and priorities.
>>>> Making it easier to understand where organisations can work together
>>>> and avoid duplicate efforts. It would be great if this includes you
>>>> all discussing the feedback from all the different user and operator
>>>> groups.
>>> [ST] This is good feedback and aligns well with portions of why there
>>>was an interest to create this group to begin with.  This discussion
>>>would probably make a great agenda item for our mid-cycle (8/20-8/21 in
>>>Santa Clara, CA).
>>>
>>>>
>>>> I am much less interested in any documents or deliverables, its that
>>>> cross company alignment and agreement, that will be extremely
>>>> valuable to the developer community.
>>> [ST] The user story deliverable is the medium through which we will be
>>>expressing our interests and documenting them so that they can be
>>>shared.
>>> The value is definitely in alignment, cross project
>>>collaboration/tracking, and being an aggregation point for feedback,
>>>however I do believe the user story (and the associated discussions)
>>>are vital for this alignment/agreement to be realized.
>>>
>>>>
>>>> That will naturally trickle back into the developer community
>>>> through the guidance you give to all the people you have working on
>>>>OpenStack.
>>>>
>>>> There is one big concern that has been raised around how the product
>>>> working group and the developer community interacts. If done
>>>> incorrectly, it can look like the developer community is ignoring
>>>> the user requests presented to it. I want to make sure we start
>>>> things off in a way that will not alienate either of the groups.
>>> [ST] +1
>>>
>>>>
>>>> I guess I am asking that we try and find a way for you all to engage
>>>> in the current developer community processes. I know we have had
>>>> great input from product managers during design summit sessions in
>>>> the past, it would be great to see more of that input again. Many
>>>> discussions (and nova-specs) start with a definition of the user
>>>> problem that needs addressing. I am sure good input into those
>>>> discussion would be welcomed.
>>> [ST] We might have limited bandwidth to really dig in at the moment
>>>since we are "piloting" the process through the Mitaka design summit,
>>>but we would be glad to help where we can!  The current plan is to
>>>review a set of initial user story submissions next week, identify team
>>>members to help coordinate them, share our list with the community for
>>>feedback (the prioritization process will change in the future but we
>>>opted for a lightweight weighing exercise for the pilot), perform a gap
>>>analysis to determine which areas/projects map to the user story (this
>>>is another potential area for collaboration with the development
>>>community), join developer team meetings to share user stories/context
>>>to get feedback and forge partnerships, and be available at the design
>>>summit to participate in discussions for those user stories that
>>>require further discussion.
>>>
>>>>
>>>>
>>>> Mission and Scope
>>>> -----------------
>>>>
>>>> Secondly, I just wanted to share this document we have on Nova's
>>>>scope:
>>>> http://docs.openstack.org/developer/nova/project_scope.html
>>>>
>>>> As a developer community, we do have quite a strong shared mission
>>>> for Nova. We are working to make sure that is articulated well, and
>>>> shared more widely. The key parts of that are something like this:
>>>> * Build a strong ecosystem by having a great API to access on demand
>>>> compute resources, that works in the same way across all deployments
>>>> * Help keep operators current by providing a good upgrade experience
>>>> * Flexibility to grow because we work well for all sizes of cloud
>>>> deployment
>>>>
>>>> We are reviewing all feature proposals through the lens of this
>>>> mission. We don't claim to have succeeded in this mission, we aim to
>>>> work towards that mission. I do feel there are key elements of the
>>>> API users experience that are missing from that above description,
>>>> but we have to start somewhere.
>>> [ST] This is amazing John!  I like the fact that a document like this
>>>helps identify the focus areas that the team will be pursuing in the
>>>future.  I am certain there will be more feedback once the team can
>>>review the document.
>>>
>>>>
>>>> I am really interested in the product working group's feedback on
>>>> our direction.
>>> [ST] Likewise!  Thanks again for sending this message, we look forward
>>>to the partnership between the teams.
>>>
>>>>
>>>>
>>>> Release Goals
>>>> -------------
>>>>
>>>> Lastly, I would love feedback on the current set of Nova priorities:
>>>>
>>>> http://specs.openstack.org/openstack/nova-specs/priorities/liberty-p
>>>> ri
>>>> orities.html
>>>>
>>>> It is likely for Mitaka that we keep a similar set of priorities,
>>>> but ideally adding at least one of these efforts:
>>>>
>>>> http://specs.openstack.org/openstack/nova-specs/priorities/liberty-p
>>>> ri orities.html#priorities-without-a-clear-plan
>>>>
>>>> My ask is, does this list surprise you at all?
>>>> Out of all these suggested items, which group would you choose?
>>> [ST] Will review and get back to you.
>>>
>>>>
>>>> This feedback will help with the picking of Nova Design Summit
>>>> Sessions. The outcomes of those sessions help decide what can
>>>> actually become a priority (a combination of reaching a certain
>>>> level of consensus and having people free and willing to work on
>>>>those things).
>>>>
>>>>
>>>> Anyways, I hope that sparks some good discussions. Let me know what
>>>> you all think.
>>>>
>>>> Thanks,
>>>> John
>>>>
>>>> Twitter/IRC: johnthetubaguy
>>>>
>>>> _______________________________________________
>>>> Product-wg mailing list
>>>> Product-wg at lists.openstack.org
>>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg
>>>
>>>
>>>
>>> --
>>> Thanks,
>>> Shamail Tahir
>>> t: @ShamailXD
>>> tz: Eastern Time
>>> _______________________________________________
>>> Product-wg mailing list
>>> Product-wg at lists.openstack.org
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg
>_______________________________________________
>Product-wg mailing list
>Product-wg at lists.openstack.org
>http://lists.openstack.org/cgi-bin/mailman/listinfo/product-wg