[openstack-dev] [Cinder] PTL Candidacy

Tristan Cacqueray tristan.cacqueray at enovance.com
Thu Apr 2 20:04:16 UTC 2015


confirmed

On 04/02/2015 02:46 PM, Mike Perez wrote:
> Hello all,
> 
> I'm announcing my candidacy for Cinder PTL for the Liberty release.
> 
> I have contributed to block storage in OpenStack since Bexar back when things
> were within nova-volume, before Cinder, and the honor of serving as PTL for
> Cinder in the Kilo cycle.
> 
> I've spoke in the past about focused participation, something I still feel is
> needed in the projects that are the basic foundation of OpenStack. Compute,
> storage and networking need to be solid. My work as core in Cinder and
> continuing as PTL has involved a lot of evangelizing and making new
> contributors feel comfortable with becoming part of the team. As a project
> grows, communication needs to be excellent, coordination is key to making sure
> reviews don't stick around too long for contributors to feel discouraged.
> I think the Cinder team has done an excellent job in managing this as we grow,
> based on the feedback received. I really do think participation in Cinder
> is getting better, and it's wonderful to be part of that.
> 
> If we take the Kilo-3 milestone for example, we landed 44 blueprints in
> a single milestone [1]. That's huge progress. I would like to believe this
> happens because of focus, and that happens because of better tracking of what
> is a priority and clear communication. Lastly participation, not just core
> folks, but any contributor that feels welcomed by the team and not to be burnt
> out on never ending patch revisions.
> 
> Most of 2014 in Cinder was a lot of discussions on third party CI's. Third
> party CI's are a great way for vendors to verify if a proposed upstream patch
> would break their integration. In addition, it identifies if a vendor really
> does work with the current state of the OpenStack project. There have been
> plenty of cases that vendors discovered that their integration in OpenStack
> really didn't work until they ran these tests. Last year, there was a real lack
> of coordination and communication with vendors on getting them on board with
> reporting third party CI results. In 2015 I took on the responsibility of being
> the point of contact for the 70+ drivers in Cinder, emailing the mailing list,
> countless reminders on IRC, contacting maintainers directly, and actually
> making phone calls to companies if maintainers were not responsive by email.
> 
> I'm happy to report that majority of vendors have responded back and are active
> in the Cinder community to ensure their integration is solid. Compare that to
> last year when we just had one or two vendors reporting and majority of vendors
> not having a clue! It's very exciting to help build a better experience for
> their users using OpenStack. The communities pouring support to me on this
> issue was hugely appreciated, and is what keeps me coming back to help.
> 
> We added 14 new drivers to Cinder in the Kilo release. Coordination was
> beautiful thanks to clear communication and coordination with the hard working
> reviewers in the Cinder team.
> 
> My priorities for Cinder in the Kilo release was to make progress on rolling
> upgrades. I have spent a greater deal of my time testing the work to allow
> Cinder services to not be dependent on database schemas. This is a big change,
> and doesn't completely solve rolling upgrades in Cinder, but is a building
> block needed to begin solving the other rolling upgrade problems. I'm really
> happy with the work done by the team in the Kilo release and excited with how
> comfortable I feel in terms of stability of the work thanks to the amount of
> testing we've done.
> 
> This work however not only benefits Cinder, but is a general solution into
> Oslo, in attempt to help other OpenStack projects in upgrades. Upgrades are
> a huge problem that needs to be solved across OpenStack, and I'm proud of the
> Cinder team for helping do their part to help drive adoption. Long term I see
> this work contributing to an ideal single upgrade solution, so that operators
> aren't having to learn how to upgrade 12 different services they may deploy.
> 
> My plans for Liberty is to work with the team on creating a better use of
> milestones for appropriate changes. While we started some initial requirements
> like making new drivers focus on the first milestone only, I think stability
> time needs to be stretched a bit longer, and I think others will agree Kilo
> didn't have a lot of this as planned for Kilo-3.
> 
> Cinder  will continue on efforts for rolling upgrades by now focusing on
> compatibility across Cinder services with RPC. This is a very important piece
> for making rolling upgrades complete. We will continue to work through projects
> like Oslo to make sure these solutions general enough to benefit other
> OpenStack projects, so as a whole, we will improve together.
> 
> Cinder volumes that end up in a stuck state. This has been a problem for ages,
> and I have heard from countless people at the Ops Midcycle Meetup that
> I attended. I'm happy to say, as reported from my take on the Ops Midcycle
> meetup [2], that this was something the Cinder team discussed at the Cinder
> Midcycle Meetup this year and we will be working on a solution that resolves
> these issues with your preferred storage backend. The current solution is silly
> dangerous database update and requires the operator to verify the real state
> a volume is in. This is not a great a solution and totally error prone.
> Instead, we will be working on improving this greatly by having Cinder
> communicate to the storage solution the desired state for the volume to be in.
> The solution will then either resolve the volume state internally and allow
> Cinder to update its state for that volume, or report that it's actually in
> a stuck state that not even it can resolve.
> 
> Lastly storage policies. Having the ability to use your preferred vendor for
> the awesome features it provides. A lot of things aren't being exposed through
> Cinder today easily. From my talks with small and big OpenStack
> deployers, they want
> more flexibility with this directly from the Cinder interface. I have spoke at
> the Cinder Midcycle meetup on this and got great feedback. This started a spec
> [3] which will greatly improve the visibility of what policies are possible
> with your storage solution your using from OpenStack via Cinder client and
> Horizon. This will greatly improve Operators knowledge in what's possible with
> their OpenStack deployment and storage solution, and eliminates a great deal of
> error prone issues. This is very exciting work coming from the team and I will
> be contributing on driving this forward after getting further feedback from
> operators at the next summit.
> 
> It would be an honor if the community would let me serve as the Cinder PTL for
> Liberty release to finish out the planned improvements.
> 
> 
> [1] - https://launchpad.net/cinder/+milestone/kilo-3
> [2] - http://superuser.openstack.org/articles/takeaways-from-openstack-s-mid-cycle-ops-meetup-a-little-more-conversation-a-little-more-action
> [3] - https://review.openstack.org/150511
> 
> --
> Mike Perez
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> 
> 


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 473 bytes
Desc: OpenPGP digital signature
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150402/e185e884/attachment.pgp>


More information about the OpenStack-dev mailing list