Open Stack

On 11 August 2015 at 22:16, Shamail Tahir <itzshamail at gmail.com> wrote:
> Hi everyone,
>
> First of all, I really appreciate the dialogue as we will certainly want to
> avoid alienating any members of the community, especially the developers who
> are responsible for making OpenStack software!
>
> I believe this thread is possibly a compelling event for a third, major,
> work-stream.
>
> The high-level objectives of the Product WG are to:
>
> Aggregate and help prioritize User Stories from working groups/teams across
> the community
> Work with project leadership and developers to support priority user
> stories, facilitate cross-vendor collaboration, align development efforts,
> and track cross-project/multi-release implementation
> Work with the Foundation Team to publish and message a multi-release
> (non-committed) roadmap
>
> The workflow pilot we are conducting addresses item #1 and also a part of #2
> and the mutli-release roadmap sub-team is addressing #3.  This thread is
> possibly related to expanding our coverage of item #2 by creating a
> work-stream to help project teams get a common view of priorities from the
> companies participating in their development team.  John, are we
> interpreting the need correctly?

Something like that.

>From my perspective the deliverable is more alignment between the
hidden influencers, by being less hidden.

I am find it hard to describe this in email.

> Are you trying to determine how the
> product work-group could help Nova prioritize amongst the various items that
> the team could pursue in Mitaka based on
> A) the fit for the scope/mission for Nova and
> B) the mission and priorities of the various organizations?
> (e.g. not looking for new user stories but help with consensus building
> across the different companies on the priority of planned stories)

Yes.

> We naturally believe that pursuing all three objectives is worthwhile but I
> think we were only approaching #2 from a "greenfield perspective" (how do we
> partner on prioritized user stories vs. helping teams use this forum with a
> diverse organizational membership to prioritize internally).

I just think we will get better results if they are presented in the
context of the current project plans.

So rather than:

Q: Please work on feature A, its important.
A: Interesting, but everyone is busy already. Can't help you.

Going for something more like:

Q: I know feature B, C and D are high priority, but how could we make
feature A happen sooner, instead of D, because of XYZ?
A: Maybe, but we need to get C fixed before we are able to add feature
A, you should get your dev people to help with C.
(... I mean start a conversation, basically).

> At this point, Geoff and I will not join the Nova meeting this Thursday but
> we definitely welcome yourself and other developers from Nova to join one of
> our future meetings to continue this discussion.  We believe the partnership
> between developers and product-wg is critical and thank you for reaching out
> to discuss how to provide the best value to your team.

Sounds good.

I am keen to wider product community aligned before we start that conversation.

> John, I do have another question for you as well... You stated that "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
> wanted to know when is the appropriate time to start conversation on
> "greenfield" user-stories/items?  The reason I ask is because we will
> eventually need to figure out how to discuss cross-project user stories with
> various teams (e.g. user story might require a blueprint/spec in 3 different
> projects to be realized) and this will require conversations with the
> development teams with enough buffer to facilitate possible
> collaboration/inclusion in the next release(s).  We thought the ideal time
> would be after milestone 3 but prior to the design summit, but it sounds
> like we are miscalculating the correct window based on your response.

I think just after liberty-3 is the best possible time for that.

I am reaching out now to make sure we get that debate going before the summit.

> Carol, can we make this an agenda item for our next team meeting if John
> agrees that this message captures his ask?  It would require a third
> work-stream and therefore we would have to figure out how to operationalise.

I was imagining a quick "show and tell" style look at each others
short and medium term goals at your meetup, to see where you all
agree.
Maybe something like, if you got to pick all 5 user stories, what
would you pick?

Thanks,
John

> On Tue, Aug 11, 2015 at 5:24 AM, John Garbutt <john at johngarbutt.com> wrote:
>>
>> 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-pri
>> >>> 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-pri
>> >>> 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
>
>
>
>
> --
> Thanks,
> Shamail Tahir
> t: @ShamailXD
> tz: Eastern Time