Open Stack

I was hoping that this thread won't be a discussion thread because it's
meant to be an announcement and I did encourage people to send me
feedback last week/meeting and on the ML too so that we can come up with
something that we can stick to.


I wanted to send this out as early. Also, some individuals have sent me
complaints for the lack of focus in the team.


Anyway, I want for us to stick to most of what's in this thread and I
will give my comments below. Also, I am planning to publish docs for
those processes and priority items (next week as this week has been
mostly discussions) I am willing to take comments/reviews on those so
that we can collaborate more, but let's try to knock those out soon.
Because, we all care about getting things done, right? ;-)


Another individual who had concerns after reading this email reached out
to me to get clarification. I plan to send more notices/docs on
lite-specs/specs (process, docs -- as above), focus for each week, etc.
in the upcoming weeks.


On 5/13/16 4:25 PM, Flavio Percoco wrote:
> On 12/05/16 01:44 -0400, Nikhil Komawar wrote:
>> Hello all,
>>
>> Here are a few important announcements for the members involved in the
>> Glance community.
>>
>>
>> Priorities:
>>
>> =======
>>
>> * The Glance priorities for Newton were discussed at the contributors'
>> meetup at summit.
>>
>> * There are a few items that were carried forward from Mitaka that are
>> still our priorities and there are a couple of items from the summit
>> that we have made a priority for reviews.
>>
>> Code review priority:
>>
>> * Import refactor
>>
>> * Nova v1, v2 support
>>
>> * Image sharing changes
>
> I'm sorry for bringing this up here but I believe I wasn't around when
> this
> discussion happened at the summit. To be honest, this strikes me as
> weird. I did
> not expect image sharing to be a priority and I would really
> appreciate the
> reasoning behind this. I'm a bit concerned by the impact, if any, this
> might or
> might not have on the image import work.

I have answered the impact to import part below. The roadmap ppt from
Mitaka was used and the Hierarchical access was something I saw. To have
the right semantics for that access pattern we need to work with our
existing image sharing model. You can find the reasons for it on the
review ( https://review.openstack.org/#/c/271019/ ). Also, we've been
discussing this since Mitaka and we did not want to do this in then. At
the meetup, (those who were there) evaluated what all was proposed
during the summit and then came up with a list that made sense.

Glare was listed on the whiteboard and it's considered as a side
priority (
http://lists.openstack.org/pipermail/openstack-dev/2016-May/093704.html
) as we have some cross project prototyping to finish too this cycle.
The intent is to get a Glare API ready this cycle that can then be more
concrete in Ocata is what I was communicated before the summit and
that's what I have taken forward.

Glance v1 deprecation doesn't need much reviews, it's a process work and
the mostly outside of Glance. So, are Nova v1, v2 reviews that minimally
involve glance-cores.

The glance_store refactor is something that was agreed to first do the
functional testing (non-defined priority) and answer the open questions
( https://etherpad.openstack.org/p/newton-glance-store-api-refactor ).

Categorization/centralization was mostly agreed upon  at the summit but
then after coming back some people have changed their mind on
centralization etc. Also, we are still working on breaking it down for
helping text, then categorizing etc. So, this can be done as a
non-defined priority. We can take the bits and pieces that are ready and
not controversial and see them through. (No comments on ML for this
please, I would like spec specific comments on the respective specs)

Micro-versions and rolling upgrades was something communicated to me --
as time permits work. So, they need to be considered after mid-cycle.

Quotas was too complicated for one cycle and having stuff in the library
will meet the hierarchical needs. (Lib is still WIP)

Import refactor is something we saw as a implementation only phase for
Newton with most of the design discussion on it done on or before the
summit. The merged spec for it has pretty broad scope and we think of
the whole implementation when we look at it. However, we all agreed for
a MVP implementation for import this cycle (thanks to Stuart for the
awesome effort leading the design & initial patches of it).  Brian
Rosmaita and I are going to see the rest of it through. So, the more
effort is required on the how, what, etc. communication that I'm working
on.
>
> I'd have voted for other topics so, I'm really curious to know the
> answer to the
> above. Also, I'm sorry for not having been there.
>
>> * Documentation changes [1], [2]
>>
>>
>> The required attention from Glance team on Nova v1, v2 support is
>> minimal; the people who are actively involved should review the code and
>> the spec.
>>
>>
>> Everyone is encouraged to review the Import refactor work however, if
>> you do not know where to start you can join the informal syncs on
>> #openstack-glance Thursdays at 1330 UTC. If you do not see people
>> chatting you are more than encouraged to highlight the following irc
>> nicks: rosmaita, nikhil (to the very least)
>>
>>
>> Everyone is encouraged to review the Image sharing changes that are
>> currently being discussed. Although, the constructs are not going to
>> hamper the standard image workflows, the experiences of sharing may be
>> different after these changes. There will be subsequent changes to the
>> python-glanceclient for accommodating server changes.
>
> Noticed you mentioned here the image sharing work won't impact the new
> import
> workflow.
>
>> Documentation changes are something that we must accommodate in this
>> cycle; thanks to the docs team the code draft was given to us.
>> Documentation liaison is working hard to get it in the right shape and a
>> couple more reviewers are to be assigned to review this change. We need
>> volunteers for the review work.
>>
>>
>> Process to be adopted in Newton:
>>
>> ==========================
>>
>>
>> Full specs:
>>
>> * For all newly introduced features, API Impacting changes and changes
>> that could either have an impact security or larger impact on operators
>> will need a full spec against the openstack/glance-specs repo.
>>
>> * For each spec, you need to create a corresponding blueprint in
>> launchpad [3] and indicate your intention to target that spec in the
>> newton milestone. You will want to be judicious on selecting the
>> milestone; if we see too many proposals for a particular milestone
>> glance-core team will have to selectively reject some of those or move
>> to a different milestone. Please set the url of the spec on your
>> blueprint.
>>
>> * Please use the template for the full spec [4] and try to complete it
>> as much as possible. A spec that is missing some critical info is likely
>> to not get feedback.
>>
>> * Only blueprints by themselves will not be reviewed. You need a spec
>> associated with a blueprint to get the proposal reviewed.
>
> The above seems to be exactly what we've done so far. Anything I'm
> missing?
>

Nothing. I am just stating it for the convenience of the proposers.
There's no significant change in the process ( since juno :-) ). The
requirement was reduced in Mitaka and I've increased a tiny bit in
Newton (specifically for changes that have larger impact on
operators/security).

It was an quick & easy way to communicate to those who want to propose a
glance-spec and want to know the difference between a lite-spec and a
full spec. (see conversation here
http://eavesdrop.openstack.org/meetings/glance/2016/glance.2016-05-05-14.00.log.html#l-48
)

> In Mitaka, we started writing the contributors guidelines for Glance.
> I believe
> the above should be put there. Thoughts? (I'm volunteering you :P)

I intend to work on the docs. This was just a quick way to send the info
out before Thursday meeting to see if anyone had concerns then.

>
> http://docs.openstack.org/developer/glance/contributing/index.html
>
>> * The reviewers section [5] is very important for us to determine if the
>> team will have enough time to review your spec and code. This
>> information plays important role in planning and prioritize your spec.
>> Reach out to these core-reviewer nicks [6] on #openstack-glance channel
>> to see who is interested in assigning themselves to your spec.
>
>
> Interestingly enough, I was going to propose to get rid of that
> section. I don't
> think it's useful and often enough the reviewers listed in the spec
> are not the
> ones actually reviewing the patches. I'm happy to discuss this on
> gerrit over a
> patch. Oh, look:
>
> https://review.openstack.org/#/c/316276/
>

gerrit it is (getting a bit bored with emails now)

>
>> * Please make sure that each spec has the problem statement well
>> defined. The problem statement isn't a one liner that indicates -- it
>> would be nice to have this change, admins should do operations that user
>> can't, Glance should do so and so, etc. Problem statement should
>> elaborate your use case and explain what in Glance or OpenStack can be
>> improved, what exists currently, if any, why would it be beneficial to
>> make this change, how would the view of cloud change after this
>> change, etc.
>>
>> * All full specs require +W from PTL/liaison
>>
>>
>> Lite specs:
>>
>> * All proposals that are expected to change the behavior of the system
>> significantly are required to have a lite-spec.
>>
>> * For a lite-spec you do not need a blueprint filed and you don't need
>> to target it to particular milestones. Glance would accept most
>> lite-specs until newton-3 unless a cross-project or another conflicting
>> change is a blocker.
>>
>> * Please make sure that each lite-spec has a well defined problem
>> statement. The problem statement is NOT a one liner that indicates -- it
>> would be nice to have this change, admins should do operations such
>> operations that user can't, Glance should do so and so, etc. Problem
>> statement should elaborate your use case and explain what in Glance or
>> OpenStack can be improved, what exists currently, if any, why would it
>> be beneficial to make this change, how would the view of cloud change
>> after this change, etc.
>>
>> * All lite specs should have at least two +2 (agreement from at least
>> two core reviewers). There is no need to wait on +W from the PTL but it
>> is highly encouraged to consult a liaison (module expert).
>>
>> * Lite specs can be merged irrespective of the spec freeze dates.
>>
>
> These lite specs are expected to be filled in the `lite-spec` file in
> glance-specs, right?

No, I changed that proposal. I am fixing the docs and the glance-specs
repo right now. More info 
http://eavesdrop.openstack.org/meetings/glance/2016/glance.2016-05-05-14.00.log.html#l-48


>
> Just want to make sure the process hasn't been changed here since
> Erno's patch
> is still on review:
>
> https://review.openstack.org/#/c/282517/
>
>

https://review.openstack.org/#/c/315339/ :-)

>> Important dates to remember:
>>
>> =======================
>>
>> * June 2, R-18: newton-1
>>
>> * June 17, R-16: Spec soft freeze, Glance mid-cycle (15th-17th)
>> (depending on attendance). If you've already booked travel contact me
>> ASAP.
>
> Not big deal but after looking at this list it seems the mid cycle
> might happen
> a bit too early in the cycle. Thoughts? Is that on purpose? I'm good
> either way,
> I just want to make sure we consider this.

On purpose; just wanted for people to focus on specs, lite-specs early
in the cycle so that all the impacting changes can be considered soon.
Also, wanted to utilize half a day during our 3 day mid-cycle for us to
be in the same room and filter out the specs that are not going to make it.

>
>> * July 14, R-12: newton-2
>>
>> * Jul 29, R-10: Spec hard freeze
>>
>> * Aug 23, R-6: final glance_store release
>>
>> * Aug 30, R-5: newton-3, lite-spec freeze, feature freeze, final
>> glanceclient release, soft string freeze
>>
>> * Sept 13, R-3: RC1, hard string freeze
>>
>> * Oct 7, R+0: Newton release
>>
>>
>> Spec owners and reviewers:
>>
>> ======================
>>
>> * Currently there are 12 Glance core reviewers with some on hiatus, some
>> part time core reviewers (even less than 50%) and a few others with more
>> than 70% upstream time.
>>
>> * I have consolidated some information that we effectively have a little
>> more than 5 core reviewers with 100% upstream time. I hope to improve
>> that over the next couple of months if enough people are interested in
>> contributing upstream who have already expressed in reviewing more
>> Glance code.
>
> I did a similar analysis in my summary email from Mitaka. Does the above
> considers Stuart hiatus?
>
> http://lists.openstack.org/pipermail/openstack-dev/2016-March/088811.html

I'm aware of this thread and did not (remember) realize it turns out to
be 5 in both cases.

I did consider Stuart's hiatus. Also, at the summit I asked for a
tentative availability from the folks and I anticipated some time
oriented-hick-ups/commitments after hearing about some changes in the
industry. (Some are going to have more time and some are likely to
disappear for a while)

>
> Flavio
>
>>
>> * So, while we would ideally be able to knock out 6 full specs in a
>> cycle (with each spec requiring at least two cores associated with it),
>> with current effectiveness we would like to target 2-3 specs depending
>> on the size of the changes.
>>
>> * All spec owners are highly encouraged to start a conversation with one
>> or two of the core-reviewers mentioned in [6] and see the possibility of
>> having 'champions' on those specs.
>>
>> * While the associated core reviewers are not required to review the
>> entire set of patches associated with that spec, they do however are a
>> point of contact, for representing Glance's point of view on the spec.
>>
>> * If you are looking to associate yourself as a reviewer to a spec and
>> do not know which one you should pick, feel free to reach out to me.
>>
>> * Also, if you are looking to make your mark and trying to work your way
>> into the core team, it will be highly appreciated if you assign yourself
>> to an important spec and help them drive the feature.
>>
>>
>> [1]
>> http://lists.openstack.org/pipermail/openstack-docs/2016-May/008536.html
>>
>> [2] https://review.openstack.org/#/c/312259
>>
>> [3] https://blueprints.launchpad.net/glance
>>
>> [4]
>> https://github.com/openstack/glance-specs/blob/master/specs/template.rst
>>
>> [5]
>> https://github.com/openstack/glance-specs/blob/master/specs/template.rst#reviewers
>>
>>
>> [6] core-reviewer nicks: rosmaita, jokke_, flwang, flaper87, hemanthm,
>> sigmavirus24, kairat, kragniz, mfedosin, nikhil, sabari, mclaren
>>
>> [7] https://review.openstack.org/315347
>>
>> -- 
>>
>> Thanks,
>> Nikhil
>>
>>
>> __________________________________________________________________________
>>
>> 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

-- 

Thanks,
Nikhil