Open Stack

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-minimal-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-priorities.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_get_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-priorities.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