<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body text="#000000" bgcolor="#FFFFFF">
You've been fantastic. Thanks for all you have done, Fla.<br>
<br>
<br>
<div class="moz-cite-prefix">On 10/03/16 03:15, Flavio Percoco
wrote:<br>
</div>
<blockquote cite="mid:20160309141521.GD21817@redhat.com" type="cite">
<br>
Greetings,
<br>
<br>
I'm not going to run for Glance's PTL position for the Newton
timeframe.
<br>
<br>
There are many motivations behind this choice. Some of them I'm
willing to
<br>
discuss in private if people are interested but I'll go as far as
saying there
<br>
are personal and professional reasons for me to not run again.
<br>
<br>
As I've always done in my past cycles as PTL, I'd like to take
some time to
<br>
summarize what's happened in the past cycle not only for the new
PTL to know
<br>
what's coming up but for the community to know how things went.
<br>
<br>
Before I even start, I'd like to thank everyone in the Glance
community. I truly
<br>
believe this was a great cycle for the project and the community
has gotten
<br>
stronger. None of this would have been possible without the help
of all of you
<br>
and for that, I'm deeply in debt with you all. It does not just
take an employer
<br>
to get someone to contribute to a project. Being paid, for those
who are, to do
<br>
Open Source is not enough. It takes passion, motivation and a lot
of patience to
<br>
analyze a technology, think out of the box and look for ways it
can be improved
<br>
either by fixing bugs or by implementing new features. The amount
of time and
<br>
dedication this process requires is probably worth way more than
what we get
<br>
back from it.
<br>
<br>
Now, with all that being said, here's Glance Mitaka for all of
you:
<br>
<br>
Completed Features
<br>
==================
<br>
<br>
I think I've mentioned this already but I'm proud of it so I'll
say it again.
<br>
The prioritization and scheduling of Glance Mitaka went so well
that we managed
<br>
to release M-3 without any feature freeze exception (FFE) request.
This doesn't
<br>
mean all the features were implemented. In fact, at least 4 were
pushed back to
<br>
Newton. However, the team communicated, reviewed, sprinted and
coded in such a
<br>
way that we were able to re-organize the schedule to avoid wasting
time on
<br>
things we new weren't going to make it. This required transparency
and hard
<br>
decisions but that's part of the job, right?
<br>
<br>
* [0] CIM Namespace Metadata
<br>
* [1] Support download from and upload to Cinder volumes
<br>
* [2] Glance db purge utility
<br>
* [3] Deprecate Glance v3 API
<br>
* [4] Implement trusts for Glance
<br>
* [5] Migrate the HTTP Store to Use Requests
<br>
* [6] Glance Image Signing and Verification
<br>
* [7] Supporting OVF Single Disk Image Upload
<br>
* [8] Prevention of Unauthorized errors during upload/download in
Swift driver
<br>
* [9] Add filters using an ‘in’ operator
<br>
<br>
[0]
<a class="moz-txt-link-freetext" href="http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/cim-namespace-metadata-definitions.html">http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/cim-namespace-metadata-definitions.html</a><br>
[1]
<a class="moz-txt-link-freetext" href="http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/cinder-store-upload-download.html">http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/cinder-store-upload-download.html</a><br>
[2]
<a class="moz-txt-link-freetext" href="http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/database-purge.html">http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/database-purge.html</a><br>
[3]
<a class="moz-txt-link-freetext" href="http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/deprecate-v3-api.html">http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/deprecate-v3-api.html</a><br>
[4]
<a class="moz-txt-link-freetext" href="http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/glance-trusts.html">http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/glance-trusts.html</a><br>
[5]
<a class="moz-txt-link-freetext" href="http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/http-store-on-requests.html">http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/http-store-on-requests.html</a><br>
[6]
<a class="moz-txt-link-freetext" href="http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/image-signing-and-verification-support.html">http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/image-signing-and-verification-support.html</a><br>
[7]
<a class="moz-txt-link-freetext" href="http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/ovf-lite.html">http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/ovf-lite.html</a><br>
[8]
<a class="moz-txt-link-freetext" href="http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/prevention-of-401-in-swift-driver.html">http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/prevention-of-401-in-swift-driver.html</a><br>
[9]
<a class="moz-txt-link-freetext" href="http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/v2-add-filters-with-in-operator.html">http://specs.openstack.org/openstack/glance-specs/specs/mitaka/implemented/v2-add-filters-with-in-operator.html</a><br>
<br>
If the above doesn't sound impressive to you, let me fill you in
with some extra
<br>
info about Glance's community.
<br>
<br>
Community
<br>
=========
<br>
<br>
Glance's community currently has 12 core members, 3 of which
joined during
<br>
Mitaka and 2 of those 3 members joined at the end of the cycle.
That means the
<br>
team ran on 9 reviewers for most of the cycle except that out of
those 9, 1 left
<br>
the team and joined later in the cycle and 3 folks weren't super
active this
<br>
cycle. That left the team with 5 constant reviewers throughout the
cycle.
<br>
<br>
Now, the above is *NOT* to say that the success of the cycle is
thanks to those
<br>
5 constant reviewers. On the contrary, it's to say that we've
managed to build a
<br>
community capable of working together with other non-core
reviewers. This was a
<br>
key thing for this cycle.
<br>
<br>
I don't think it's a secret to anyone that, at the beginning of
the cycle, the
<br>
community was fragile and somewhat split. There were different
opinions on what
<br>
Glance should (or shouldn't) look like, what new features Glance
should (or
<br>
shouldn't) have and where the project should be headed in the next
6 months.
<br>
<br>
The team sat down, the team talked and the team agreed on what the
project
<br>
should be and that's what the team did in the Mitaka cycle.
Sharing one message
<br>
with the rest of the OpenStack community (and especially new
Glance
<br>
contributors) was a key for the community to become stronger.
<br>
<br>
What changed? What did the community do differently?
<br>
<br>
Priorities and Goals
<br>
--------------------
<br>
<br>
Mitaka was the first cycle that Glance strictly followed a list of
priorities
<br>
[0]. Funny enough, 2 of those priorities didn't make it in Mitaka
but we'll get
<br>
to that in a bit.
<br>
<br>
The list of priorities didn't do it all by itself. The list of
priorities gave
<br>
us a target, a goal. It helped us to remain focused. It kept us on
track.
<br>
However, it did way more than that. The list of priorities allowed
us for:
<br>
<br>
* Sending a clear message of what the community has agreed on and
where the
<br>
community is headed
<br>
* Selecting a narrow list of features that we would be able to
work on and
<br>
review throughout the cycle
<br>
* Scheduling and splitting reviews to accommodate the priorities
<br>
<br>
Of those points, I believe the second one is the one that really
did it for us.
<br>
We kept the set of new features small so that we could focus on
what was
<br>
important. We had more proposals than we approved and we rejected
the rest based
<br>
on our priorities. This is something I'd like to see happening
again in Glance
<br>
and I'd like to encourage the next PTL to do the same and be
*strict* about it.
<br>
<br>
[0]
<a class="moz-txt-link-freetext" href="http://specs.openstack.org/openstack/glance-specs/priorities/mitaka-priorities.html">http://specs.openstack.org/openstack/glance-specs/priorities/mitaka-priorities.html</a><br>
<br>
Reduce the review backlog
<br>
-------------------------
<br>
<br>
We abandoned patches [0]! We removed from the review queue all the
patches that,
<br>
for 2 or more months, had been in merge conflict, had had -1/-2
from cores or
<br>
had had -1 from jenkins (hope I'm not missing something here). We
did that and
<br>
we made the backlog shorter, we kept in the review list what was
really relevant
<br>
at that moment.
<br>
<br>
Something important about the above is that we didn't abandon
patches that had
<br>
stalled for lack of reviews. We prioritized those, we bumped those
to the top of
<br>
our review list and we provided the reviews those patches
deserved. Some of them
<br>
landed, some didn't but the important bit is that those patches
were reviewed.
<br>
Glance's current backlog (verified patches, Workflow 0 and no -2s)
is less than
<br>
90 patches across all projects (likely way less than that but I
just did a rough
<br>
count) and the most important thing is that *ALL* these patches
have received
<br>
reviews in 2016. Now, if you don't think this is great, you should
have seen our
<br>
backlog before.
<br>
<br>
Now, there's no point in cleaning up the review queue if we're
going to let it
<br>
fill up again. Right? This is where the community awesomeness
comes to light. We
<br>
created a review dashboard[1], which some folks used to organize
their reviews. I
<br>
found it super useful, I used it to prioritize my reviews and help
other folks
<br>
to prioritize theirs. When you're given an organized list of
reviews rather than
<br>
just a list of random reviews, it's *way* easier for you to know
what to review.
<br>
That right there is the key. To know what to review. I believe, in
Mitaka, the
<br>
team knew what to focus on and the team also knew someone in the
community was
<br>
ready to provide a fresher, cleaner, list of reviews they could
focus on. Some
<br>
folks would prefer to go and make up a list themselves, others
will prefer to
<br>
have one ready. Either way, having a clear story of where the
focus should go is
<br>
the key to help reviews move faster. Remove the noise, it
distracts from people
<br>
from what's really important.
<br>
<br>
[0] <a class="moz-txt-link-freetext" href="http://stackalytics.com/?user_id=glancebot@mailinator.com">http://stackalytics.com/?user_id=glancebot@mailinator.com</a>
<br>
[1] <a class="moz-txt-link-freetext" href="http://bit.ly/glance-dashboard">http://bit.ly/glance-dashboard</a>
<br>
<br>
Review Days
<br>
-----------
<br>
<br>
Not really a new thing. This has happened before and we just kept
doing it. The
<br>
difference, perhaps, is that we increased the number of review
days in the
<br>
cycle. We tried to do at least 1 review day per milestone and
we're now doing a
<br>
Review Monday until the end of the cycle to get as many bug fixes
as possible in
<br>
before the release. RC1 is looking good already!
<br>
<br>
So, if you'd ask me, I believe what changed was the community. The
community got
<br>
together, polished some things, and focused on what's important
*the project*.
<br>
If you read between lines, the above shows one constant pattern,
the community
<br>
matured and it found what its placed in the OpenStack community.
<br>
<br>
Single Team
<br>
-----------
<br>
<br>
The Glance team is now back to being a single reviewing machine
rather than
<br>
several, isolated, teams with specific tasks, which sometimes
ended up
<br>
duplicated. The Glance Driver's team has been merged into the
Glance Core team
<br>
and the Glare team (Artifacts) is not using the Fast Track
anymore.
<br>
<br>
Having smaller teams has resulted in a very useful thing to do for
other
<br>
projects. Depending on the size of the project, it'd be possible
to map tasks to
<br>
smaller teams and then reduce them once the job is done ;).
Unfortunately, given
<br>
Glance's team size, this ended up adding *more* things to do to
members of those
<br>
smaller teams that were also part of the other teams as well.
<br>
<br>
One reason to mention this is because we'll have the temptation to
do this again
<br>
in the future but, as it's been proven thus far, Glance's
community is not big
<br>
enough to make such splits worth it and those end up causing more
harm to the
<br>
community than good.
<br>
<br>
Spec Freeze
<br>
-----------
<br>
<br>
The team incorporated a spec freeze in this cycle. The dates that
were picked
<br>
were not the most ideal ones but the freeze helped a lot to bring
back focus on
<br>
code reviews and coding. This freeze put a timeline on folks to
get their
<br>
proposals ready, hence forcing them to have enough time to
implement such
<br>
proposals. Having open milestones distracts the community from the
schedule.
<br>
Announcing such milestones in advance and providing constant
reminders helped
<br>
with making sure folks were prepared and ready to react.
<br>
<br>
<br>
Was it all rainbows?
<br>
====================
<br>
<br>
No, it was not. There were and there are *many* things we need to
work on and
<br>
improve. For instance, 2 of the priorities didn't make it this
cycle. One of
<br>
them (Nova's adoption of Glance's v2) simply requires a bit of
more work and it
<br>
specifically requires a better alignment with the Nova community's
priorities.
<br>
In other words, Nova needs to make this a priority for them.
<br>
<br>
The second priority that missed the deadline is the refactor of
the image import
<br>
workflow. Some of you might be thinking "Guys, you had 1 job,
*ONE* job and it
<br>
was to discuss and implement that refactor". Well, turns out that
such refactor
<br>
has an impact on *every* cloud and it's not something the team can
afford to
<br>
change a third time (yes, this is the second time the image import
workflow is
<br>
refactored). I'm actually happy it didn't make it in Mitaka
because that gave
<br>
the team more time to evaluate the proposal that had been
discussed at the
<br>
summit, the issues around it and the different alternatives.
Nonetheless, I am a
<br>
bit sad about how things evolved with this proposal because at the
very
<br>
beginning of the cycle we were a bit naive in our planning of this
work. That is
<br>
to say, that we should've probably known from the beginning that
we wouldn't
<br>
have had the time to implement this spec and that it would have
taken us the
<br>
whole cycle to discuss it. The problem is not that we didn't know
it to begin
<br>
with but the fact that we weren't able to communicate that to the
community from
<br>
the beginning. I don't think this is a big deal, though. We
realized soon enough
<br>
that we shouldn't rush this and that dedicating the cycle to
discuss this spec
<br>
was more better than rushing it and then have a poor
implementation of it.
<br>
<br>
We also experimented with a new process for lite specs and it was
not a huge
<br>
success. This impacted some of the lite specs that had been
proposed but we did
<br>
our best to come out of that situation without impacting other's
people work. In
<br>
fact, that situation not just highlighted the issues we had with
the process but
<br>
the team responsible for it (the glance-drivers team), which ended
up being
<br>
merged into the glance core team (as I mentioned in the previous
section). This
<br>
process is being refactored and you can learn a bit more about it
in this
<br>
review[0].
<br>
<br>
There's one more thing I wish we would have dedicated more time
on. That's
<br>
tempest. Unfortunately, given the time available, size of the team
and the
<br>
priorities we had, tempest did not receive as much love as we'd
have loved to.
<br>
There are several tempest tests that need to be cleaned up a bit,
especially on
<br>
the V2 side.
<br>
<br>
[0] <a class="moz-txt-link-freetext" href="https://review.openstack.org/#/c/282516/">https://review.openstack.org/#/c/282516/</a>
<br>
<br>
To the Glance Community
<br>
=======================
<br>
<br>
All the credits for the above goes to you! As a PTL I don't think
I can take
<br>
*any* credit for what I consider a successful cycle brought by the
community
<br>
itself. I instead recognize that it was all possible because the
community
<br>
decided to go back to being awesome. I'm a believer that the PTL's
role is all
<br>
about enabling the community to be awesome. Planning,
prioritization,
<br>
scheduling, etc. it all serves a single goal, which is to allow
the community
<br>
for doing what they know best and focus on that.
<br>
<br>
I've enjoyed every single of my stages in this community. Rushing
through
<br>
reviews, coding like crazy, ranting like crazy, leading the
community and back
<br>
to reviewing like crazy. These years as a member of Glance's
community have
<br>
taught me a lot about this project and how critical it is for the
rest of the
<br>
community. As I always say, it's one of those projects that can
take your whole
<br>
cloud down without you even noticing but I do hope you notice it.
<br>
<br>
Glance is often referred to as a simple project (true), as a small
project
<br>
(kinda true) and sometimes as not super cool (false). I'd like to
remind you
<br>
that not only Glance is a "cool" project to work on but it's also
super critical
<br>
for OpenStack. As I remind you this, I'd like to urge you to help
the project
<br>
stay on track across the cycles. Glance (as every other projects)
depends on the
<br>
ability of its community to dictate what's best for it.
<br>
<br>
Glance's interoperability has been compromised and there's a plan
to help
<br>
bringing it back. Let's get that done. Glance's v1 is not
considered secure and
<br>
it must be deprecated. Let's do that as well. Glance's stability
and security
<br>
has shown some weaknesses. Let's not ignore that. Working on new
features is
<br>
always sexy. Working on the new cool stuff that other projects are
doing might
<br>
seem like a must do task. I'd argue and say there's a time for
everything and,
<br>
while Glance shares OpenStack's priorities, there are times where
the project
<br>
needs to take a step back, put itself together again and start
again. I don't
<br>
believe Glance has left that self-healing period and I'd like to
urge the whole
<br>
community to keep this in mind.
<br>
<br>
To the new PTL
<br>
==============
<br>
<br>
Listen! Listen to the things the OpenStack community has to say.
Listen to the
<br>
things external folks have to say. Most importantly, listen to
what the Glance
<br>
community has to say. Glance is not a playground for making random
decisions. If
<br>
you listen to what the community has to say, it'll be easy enough
to know what
<br>
to do and what the next steps are. However, you should be ready
for making hard
<br>
decisions and you need to have the courage to do so. During the
last elections,
<br>
I wrote a post[0] about what being a PTL means and I'd like to
encourage you to
<br>
read it, even if you've done so already.
<br>
<br>
If you look at the goals we set for Glance during Mitaka and the
results we
<br>
achieved, you'll soon notice what the priorities for the next
cycle should be.
<br>
The community will help shaping those priorities but the baseline
is there
<br>
already.
<br>
<br>
A great cycle is not measured on how many features the community
is able to
<br>
implement. Therefore, I encourage you to not fall under the
temptation of
<br>
approving as many specs as possible. It is *perfectly fine* to say
no to specs
<br>
because they conflict with the project's priorities. The more
specs the team
<br>
approves, the more code there will be, the more people the project
will need to
<br>
complete the feature (code wise and review wise). Keep the release
small, keep
<br>
it concise, keep it focused. It's extremely important to
communicate the intent
<br>
of the release to the rest of the community. Do not forget Glance
*is* a
<br>
critical piece of every cloud.
<br>
<br>
Glance's community is not formed by the core team. It's formed by
every person
<br>
willing to dedicate time to the project either on reviews or code.
Work with
<br>
them, encourage them. They *are* helping the project. Some folks
simply don't
<br>
want to do reviews, that's fine. They are still helping with code
and bug fixes.
<br>
Recognize that and make sure they feel part of the community
because they are.
<br>
Expanding the core team is great as long as you can ensure folks
in the team are
<br>
aligned with the team's priorities. Welcome new members and do it
gradually.
<br>
<br>
One more thing, learn to delegate. During my time as a PTL, I
relied on other
<br>
members as much as possible for keeping up with some tasks. For
instance, Erno
<br>
Kuvaja helped immensely with releases and stable maintenance,
Nikhil Komawar
<br>
kept the team updated about the cross-project initiatives, Stuart
Mclaren,
<br>
Hemanth Makkapati and Brian Rosmaita worked with the vulnerability
team on
<br>
security issues, etc. Thanks to all of them for their immense help
and I do hope
<br>
you'll keep up at what you're doing :). In other words, burnout is
real and you
<br>
gotta take care of yourself too. Work with the community, there's
no need to
<br>
take everything on your shoulders as you might end up dropping
some balls. When
<br>
folks don't show up on reviews and they don't share their
opinions, do not give
<br>
those as granted. Find them and ask for it.
<br>
<br>
And please, I beg you, let's get rid of v1!
<br>
<br>
[0] <a class="moz-txt-link-freetext" href="http://blog.flaper87.com/post/something-about-being-a-ptl/">http://blog.flaper87.com/post/something-about-being-a-ptl/</a>
<br>
<br>
Thanks for reading this long email (or to at least have bothered
to skip till
<br>
the end of it ;)
<br>
Flavio
<br>
<br>
P.S: I've posted this in my blog too:
<a class="moz-txt-link-freetext" href="http://blog.flaper87.com/post/glance-mitaka-passing-the-torch">http://blog.flaper87.com/post/glance-mitaka-passing-the-torch</a>
<br>
/
<br>
<br>
<fieldset class="mimeAttachmentHeader"></fieldset>
<br>
<pre wrap="">__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
</pre>
</blockquote>
<br>
<pre class="moz-signature" cols="72">--
Cheers & Best regards,
Fei Long Wang (王飞龙)
--------------------------------------------------------------------------
Senior Cloud Software Engineer
Tel: +64-48032246
Email: <a class="moz-txt-link-abbreviated" href="mailto:flwang@catalyst.net.nz">flwang@catalyst.net.nz</a>
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
-------------------------------------------------------------------------- </pre>
</body>
</html>