Open Stack

I am not involved in Glance, however this was well worth reading for the
experiences during the cycle, not just as a PTL but as a team and the
communication of improving the software development process.




On Wed, Mar 9, 2016 at 11:47 PM, Bhandaru, Malini K <
malini.k.bhandaru at intel.com> wrote:

> Flavio, Glance and OpenStack benefited during your reign or period of
> humble service.
> Will miss you at the helm. Also thank you for anointing/attracting two new
> solid cores: Brian and Sabari
> Malini
>
>
> -----Original Message-----
> From: Tom Fifield [mailto:tom at openstack.org]
> Sent: Wednesday, March 09, 2016 7:55 PM
> To: openstack-dev at lists.openstack.org
> Subject: Re: [openstack-dev] [glance] Glance Mitaka: Passing the torch
>
> A beautiful post, sir. Thank you for everything!
>
> On 09/03/16 22:15, Flavio Percoco wrote:
> >
> > 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/impleme
> > nted/cim-namespace-metadata-definitions.html
> >
> > [1]
> > http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme
> > nted/cinder-store-upload-download.html
> >
> > [2]
> > http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme
> > nted/database-purge.html
> >
> > [3]
> > http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme
> > nted/deprecate-v3-api.html
> >
> > [4]
> > http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme
> > nted/glance-trusts.html
> >
> > [5]
> > http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme
> > nted/http-store-on-requests.html
> >
> > [6]
> > http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme
> > nted/image-signing-and-verification-support.html
> >
> > [7]
> > http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme
> > nted/ovf-lite.html
> >
> > [8]
> > http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme
> > nted/prevention-of-401-in-swift-driver.html
> >
> > [9]
> > http://specs.openstack.org/openstack/glance-specs/specs/mitaka/impleme
> > nted/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-pr
> > iorities.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
> > /
> >
> >
> > ______________________________________________________________________
> > ____ 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
> >
>
>
> __________________________________________________________________________
> 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
> __________________________________________________________________________
> 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 --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20160310/37070ca4/attachment.html>