Open Stack

Thanks for all your leadership, Flavio! Really appreciated all help from you!


Abhishek


-----Original Message-----
From: Flavio Percoco [mailto:flavio at redhat.com] 
Sent: 09 March 2016 19:45
To: openstack-dev at lists.openstack.org
Subject: [openstack-dev] [glance] Glance Mitaka: Passing the torch


Greetings,

I'm not going to run for Glance's PTL position for the Newton timeframe.

There are many motivations behind this choice. Some of them I'm willing to discuss in private if people are interested but I'll go as far as saying there are personal and professional reasons for me to not run again.

As I've always done in my past cycles as PTL, I'd like to take some time to summarize what's happened in the past cycle not only for the new PTL to know what's coming up but for the community to know how things went.

Before I even start, I'd like to thank everyone in the Glance community. I truly believe this was a great cycle for the project and the community has gotten stronger. None of this would have been possible without the help of all of you and for that, I'm deeply in debt with you all. It does not just take an employer to get someone to contribute to a project. Being paid, for those who are, to do Open Source is not enough. It takes passion, motivation and a lot of patience to analyze a technology, think out of the box and look for ways it can be improved either by fixing bugs or by implementing new features. The amount of time and dedication this process requires is probably worth way more than what we get back from it.

Now, with all that being said, here's Glance Mitaka for all of you:

Completed Features
==================

I think I've mentioned this already but I'm proud of it so I'll say it again.
The prioritization and scheduling of Glance Mitaka went so well that we managed to release M-3 without any feature freeze exception (FFE) request. This doesn't mean all the features were implemented. In fact, at least 4 were pushed back to Newton. However, the team communicated, reviewed, sprinted and coded in such a way that we were able to re-organize the schedule to avoid wasting time on things we new weren't going to make it. This required transparency and hard decisions but that's part of the job, right?

* [0] CIM Namespace Metadata
* [1] Support download from and upload to Cinder volumes
* [2] Glance db purge utility
* [3] Deprecate Glance v3 API
* [4] Implement trusts for Glance
* [5] Migrate the HTTP Store to Use Requests
* [6] Glance Image Signing and Verification
* [7] Supporting OVF Single Disk Image Upload
* [8] Prevention of Unauthorized errors during upload/download in Swift driver
* [9] Add filters using an ‘in’ operator

[0] http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/cim-namespace-metadata-definitions.html
[1] http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/cinder-store-upload-download.html
[2] http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/database-purge.html
[3] http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/deprecate-v3-api.html
[4] http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/glance-trusts.html
[5] http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/http-store-on-requests.html
[6] http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/image-signing-and-verification-support.html
[7] http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/ovf-lite.html
[8] http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/prevention-of-401-in-swift-driver.html
[9] http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/v2-add-filters-with-in-operator.html

If the above doesn't sound impressive to you, let me fill you in with some extra info about Glance's community.

Community
=========

Glance's community currently has 12 core members, 3 of which joined during Mitaka and 2 of those 3 members joined at the end of the cycle. That means the team ran on 9 reviewers for most of the cycle except that out of those 9, 1 left the team and joined later in the cycle and 3 folks weren't super active this cycle. That left the team with 5 constant reviewers throughout the cycle.

Now, the above is *NOT* to say that the success of the cycle is thanks to those
5 constant reviewers. On the contrary, it's to say that we've managed to build a community capable of working together with other non-core reviewers. This was a key thing for this cycle.

I don't think it's a secret to anyone that, at the beginning of the cycle, the community was fragile and somewhat split. There were different opinions on what Glance should (or shouldn't) look like, what new features Glance should (or
shouldn't) have and where the project should be headed in the next 6 months.

The team sat down, the team talked and the team agreed on what the project should be and that's what the team did in the Mitaka cycle. Sharing one message with the rest of the OpenStack community (and especially new Glance
contributors) was a key for the community to become stronger.

What changed? What did the community do differently?

Priorities and Goals
--------------------

Mitaka was the first cycle that Glance strictly followed a list of priorities [0]. Funny enough, 2 of those priorities didn't make it in Mitaka but we'll get to that in a bit.

The list of priorities didn't do it all by itself. The list of priorities gave us a target, a goal. It helped us to remain focused. It kept us on track.
However, it did way more than that. The list of priorities allowed us for:

* Sending a clear message of what the community has agreed on and where the
  community is headed
* Selecting a narrow list of features that we would be able to work on and
  review throughout the cycle
* Scheduling and splitting reviews to accommodate the priorities

Of those points, I believe the second one is the one that really did it for us.
We kept the set of new features small so that we could focus on what was important. We had more proposals than we approved and we rejected the rest based on our priorities. This is something I'd like to see happening again in Glance and I'd like to encourage the next PTL to do the same and be *strict* about it.

[0] http://specs.openstack.org/openstack/glance-specs/priorities/mitaka-priorities.html

Reduce the review backlog
-------------------------

We abandoned patches [0]! We removed from the review queue all the patches that, for 2 or more months, had been in merge conflict, had had -1/-2 from cores or had had -1 from jenkins (hope I'm not missing something here). We did that and we made the backlog shorter, we kept in the review list what was really relevant at that moment.

Something important about the above is that we didn't abandon patches that had stalled for lack of reviews. We prioritized those, we bumped those to the top of our review list and we provided the reviews those patches deserved. Some of them landed, some didn't but the important bit is that those patches were reviewed.
Glance's current backlog (verified patches, Workflow 0 and no -2s) is less than
90 patches across all projects (likely way less than that but I just did a rough
count) and the most important thing is that *ALL* these patches have received reviews in 2016. Now, if you don't think this is great, you should have seen our backlog before.

Now, there's no point in cleaning up the review queue if we're going to let it fill up again. Right? This is where the community awesomeness comes to light. We created a review dashboard[1], which some folks used to organize their reviews. I found it super useful, I used it to prioritize my reviews and help other folks to prioritize theirs. When you're given an organized list of reviews rather than just a list of random reviews, it's *way* easier for you to know what to review.
That right there is the key. To know what to review. I believe, in Mitaka, the team knew what to focus on and the team also knew someone in the community was ready to provide a fresher, cleaner, list of reviews they could focus on. Some folks would prefer to go and make up a list themselves, others will prefer to have one ready. Either way, having a clear story of where the focus should go is the key to help reviews move faster. Remove the noise, it distracts from people from what's really important.

[0] http://stackalytics.com/?user_id=glancebot@mailinator.com
[1] http://bit.ly/glance-dashboard

Review Days
-----------

Not really a new thing. This has happened before and we just kept doing it. The difference, perhaps, is that we increased the number of review days in the cycle. We tried to do at least 1 review day per milestone and we're now doing a Review Monday until the end of the cycle to get as many bug fixes as possible in before the release. RC1 is looking good already!

So, if you'd ask me, I believe what changed was the community. The community got together, polished some things, and focused on what's important *the project*.
If you read between lines, the above shows one constant pattern, the community matured and it found what its placed in the OpenStack community.

Single Team
-----------

The Glance team is now back to being a single reviewing machine rather than several, isolated, teams with specific tasks, which sometimes ended up duplicated. The Glance Driver's team has been merged into the Glance Core team and the Glare team (Artifacts) is not using the Fast Track anymore.

Having smaller teams has resulted in a very useful thing to do for other projects. Depending on the size of the project, it'd be possible to map tasks to smaller teams and then reduce them once the job is done ;). Unfortunately, given Glance's team size, this ended up adding *more* things to do to members of those smaller teams that were also part of the other teams as well.

One reason to mention this is because we'll have the temptation to do this again in the future but, as it's been proven thus far, Glance's community is not big enough to make such splits worth it and those end up causing more harm to the community than good.

Spec Freeze
-----------

The team incorporated a spec freeze in this cycle. The dates that were picked were not the most ideal ones but the freeze helped a lot to bring back focus on code reviews and coding. This freeze put a timeline on folks to get their proposals ready, hence forcing them to have enough time to implement such proposals. Having open milestones distracts the community from the schedule.
Announcing such milestones in advance and providing constant reminders helped with making sure folks were prepared and ready to react.


Was it all rainbows?
====================

No, it was not. There were and there are *many* things we need to work on and improve. For instance, 2 of the priorities didn't make it this cycle. One of them (Nova's adoption of Glance's v2) simply requires a bit of more work and it specifically requires a better alignment with the Nova community's priorities.
In other words, Nova needs to make this a priority for them.

The second priority that missed the deadline is the refactor of the image import workflow. Some of you might be thinking "Guys, you had 1 job, *ONE* job and it was to discuss and implement that refactor". Well, turns out that such refactor has an impact on *every* cloud and it's not something the team can afford to change a third time (yes, this is the second time the image import workflow is refactored). I'm actually happy it didn't make it in Mitaka because that gave the team more time to evaluate the proposal that had been discussed at the summit, the issues around it and the different alternatives. Nonetheless, I am a bit sad about how things evolved with this proposal because at the very beginning of the cycle we were a bit naive in our planning of this work. That is to say, that we should've probably known from the beginning that we wouldn't have had the time to implement this spec and that it would have taken us the whole cycle to discuss it. The problem is not that we didn't know it to begin with but the fact that we weren't able to communicate that to the community from the beginning. I don't think this is a big deal, though. We realized soon enough that we shouldn't rush this and that dedicating the cycle to discuss this spec was more better than rushing it and then have a poor implementation of it.

We also experimented with a new process for lite specs and it was not a huge success. This impacted some of the lite specs that had been proposed but we did our best to come out of that situation without impacting other's people work. In fact, that situation not just highlighted the issues we had with the process but the team responsible for it (the glance-drivers team), which ended up being merged into the glance core team (as I mentioned in the previous section). This process is being refactored and you can learn a bit more about it in this review[0].

There's one more thing I wish we would have dedicated more time on. That's tempest. Unfortunately, given the time available, size of the team and the priorities we had, tempest did not receive as much love as we'd have loved to.
There are several tempest tests that need to be cleaned up a bit, especially on the V2 side.

[0] https://review.openstack.org/#/c/282516/

To the Glance Community
=======================

All the credits for the above goes to you! As a PTL I don't think I can take
*any* credit for what I consider a successful cycle brought by the community itself. I instead recognize that it was all possible because the community decided to go back to being awesome. I'm a believer that the PTL's role is all about enabling the community to be awesome. Planning, prioritization, scheduling, etc. it all serves a single goal, which is to allow the community for doing what they know best and focus on that.

I've enjoyed every single of my stages in this community. Rushing through reviews, coding like crazy, ranting like crazy, leading the community and back to reviewing like crazy. These years as a member of Glance's community have taught me a lot about this project and how critical it is for the rest of the community. As I always say, it's one of those projects that can take your whole cloud down without you even noticing but I do hope you notice it.

Glance is often referred to as a simple project (true), as a small project (kinda true) and sometimes as not super cool (false). I'd like to remind you that not only Glance is a "cool" project to work on but it's also super critical for OpenStack. As I remind you this, I'd like to urge you to help the project stay on track across the cycles. Glance (as every other projects) depends on the ability of its community to dictate what's best for it.

Glance's interoperability has been compromised and there's a plan to help bringing it back. Let's get that done. Glance's v1 is not considered secure and it must be deprecated. Let's do that as well. Glance's stability and security has shown some weaknesses. Let's not ignore that. Working on new features is always sexy. Working on the new cool stuff that other projects are doing might seem like a must do task. I'd argue and say there's a time for everything and, while Glance shares OpenStack's priorities, there are times where the project needs to take a step back, put itself together again and start again. I don't believe Glance has left that self-healing period and I'd like to urge the whole community to keep this in mind.

To the new PTL
==============

Listen! Listen to the things the OpenStack community has to say. Listen to the things external folks have to say. Most importantly, listen to what the Glance community has to say. Glance is not a playground for making random decisions. If you listen to what the community has to say, it'll be easy enough to know what to do and what the next steps are. However, you should be ready for making hard decisions and you need to have the courage to do so. During the last elections, I wrote a post[0] about what being a PTL means and I'd like to encourage you to read it, even if you've done so already.

If you look at the goals we set for Glance during Mitaka and the results we achieved, you'll soon notice what the priorities for the next cycle should be.
The community will help shaping those priorities but the baseline is there already.

A great cycle is not measured on how many features the community is able to implement. Therefore, I encourage you to not fall under the temptation of approving as many specs as possible. It is *perfectly fine* to say no to specs because they conflict with the project's priorities. The more specs the team approves, the more code there will be, the more people the project will need to complete the feature (code wise and review wise). Keep the release small, keep it concise, keep it focused. It's extremely important to communicate the intent of the release to the rest of the community. Do not forget Glance *is* a critical piece of every cloud.

Glance's community is not formed by the core team. It's formed by every person willing to dedicate time to the project either on reviews or code. Work with them, encourage them. They *are* helping the project. Some folks simply don't want to do reviews, that's fine. They are still helping with code and bug fixes.
Recognize that and make sure they feel part of the community because they are.
Expanding the core team is great as long as you can ensure folks in the team are aligned with the team's priorities. Welcome new members and do it gradually.

One more thing, learn to delegate. During my time as a PTL, I relied on other members as much as possible for keeping up with some tasks. For instance, Erno Kuvaja helped immensely with releases and stable maintenance, Nikhil Komawar kept the team updated about the cross-project initiatives, Stuart Mclaren, Hemanth Makkapati and Brian Rosmaita worked with the vulnerability team on security issues, etc. Thanks to all of them for their immense help and I do hope you'll keep up at what you're doing :). In other words, burnout is real and you gotta take care of yourself too. Work with the community, there's no need to take everything on your shoulders as you might end up dropping some balls. When folks don't show up on reviews and they don't share their opinions, do not give those as granted. Find them and ask for it.

And please, I beg you, let's get rid of v1!

[0] http://blog.flaper87.com/post/something-about-being-a-ptl/

Thanks for reading this long email (or to at least have bothered to skip till the end of it ;) Flavio

P.S: I've posted this in my blog too: http://blog.flaper87.com/post/glance-mitaka-passing-the-torch
/
--
@flaper87
Flavio Percoco

______________________________________________________________________
Disclaimer: This email and any attachments are sent in strictest confidence
for the sole use of the addressee and may contain legally privileged,
confidential, and proprietary data. If you are not the intended recipient,
please advise the sender by replying promptly to this email and then delete
and destroy this email and any attachments without any further use, copying
or forwarding.