[openstack-dev] [Glance][TC] Glance Functional API and Cross-project API Consistency

[Hemanth Makkapati]

Hello All,
I'm writing to notify you of the approach the Glance community has decided to 
take for doing functional API.  Also, I'm writing to solicit your feedback on 
this approach in the light of cross-project API consistency.

At the Atlanta Summit, the Glance team has discussed introducing functional API 
in Glance so as to be able to expose operations/actions that do not naturally 
fit into the CRUD-style. A few approaches are proposed and discussed 
herehttps://etherpad.openstack.org/p/glance-adding-functional-operations-to-api.
 We have all converged on the approach to include 'action' and action type in 
the URL. For instance, 'POST /images/{image_id}/actions/{action_type}'.

However, this is different from the way Nova does actions. Nova includes action 
type in the payload. For instance, 'POST /servers/{server_id}/action {type: 
action_type, ...}'. At this point, we hit a cross-project API consistency 
issue mentioned 
herehttps://etherpad.openstack.org/p/juno-cross-project-consistency-across-rest-apis
 (under the heading 'How to act on resource - cloud perform on resources'). 
Though we are differing from the way Nova does actions and hence another source 
of cross-project API inconsistency , we have a few reasons to believe that 
Glance's way is helpful in certain ways.

The reasons are as following:
1. Discoverability of operations.  It'll be easier to expose permitted actions 
through schemas a json home document living at /images/{image_id}/actions/.
2. More conducive for rate-limiting. It'll be easier to rate-limit actions in 
different ways if the action type is available in the URL.
3. Makes more sense for functional actions that don't require a request body 
(e.g., image deactivation).

At this point we are curious to see if the API conventions group believes this 
is a valid and reasonable approach.
Any feedback is much appreciated. Thank you!

Regards,
Hemanth Makkapati
___
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Glance] Core nominations.

[Hemanth Makkapati]

I like the idea of a 'core-member'. But, how are core-members different from 
core-reviewers? For instance, with core-reviewers it is very clear that these 
are folks you would trust with merging code because they are supposed to have a 
good understanding of the overall project. What about core-members? Are 
core-members essentially just core-reviewers who somehow don't fit the criteria 
of core-reviewers but are good candidates nevertheless? Just trying to 
understand here ... no offense meant.


Also, +1 to both the criteria for removing existing cores and addition of new 
cores.


-Hemanth.


From: Nikhil Komawar nikhil.koma...@rackspace.com
Sent: Friday, March 6, 2015 4:04 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Glance] Core nominations.


Thank you all for the input outside of the program: Kyle, Ihar, Thierry, Daniel!


Mike, Ian: It's a good idea to have the policy however, we need to craft one 
that is custom to the Glance program. It will be a bit different to ones out 
there as we've contributors who are dedicated to only subset of the code - for 
example just glance_store or python-glanceclient or metadefs. From here on, we 
may see that for Artifacts and other such features. It's already being observed 
for metadefs.


While I like Mike's suggestion to (semi-)adopt what Nova and Neutron are doing, 
it also makes me wonder if that's going to help us in long term. If not, then 
what can we do now to set a good path forward?


Flavio, Erno, Malini, Louis, Mike: Drafting a guideline policy and implementing 
rotation based on that was my intent so that everyone is aware of the changes 
in the program. That would let the core reviewers know what their duties are 
and let non-cores know what they need to do to become cores. Moreover, I've a 
idea for proposing a core-member status for our program than just 
core-reviewer. That seems more applicable for a few strong regular contributors 
like Travis and Lakshmi who work on bug fixes, bug triaging and client 
improvements however, do not seem to keep momentum on reviews. The core status 
can affect project decisions hence, this change may be important. This process 
may involve some interactions with governance so, will take more time.


Malini: I wish to take a strategic decision here rather an agile one. That 
needs a lot of brainpower before implementation. While warning and acting is 
good, it seems less applicable for this case. Simply because, we need to make a 
positive difference in the interactions of the community and we've a chance of 
doing that here.


Nevertheless, I do not want to block the new-core additions or ask Flavio 
et.al. to accommodate for the reviews that the new members would have been able 
to do (just kidding).


Tweaking Flavio's criterion of cleaning up the list for cores who have not done 
any reviews in the last 2 cycles (Icehouse and Juno), I've prepared a new list 
below (as Flavio's list did not match up even if we take cycles to be Juno, 
Kilo). They can be added back to the list faster in the future if they consider 
contributing to Glance again.


The criterion is:

Reviews = 50 in combined cycles.


Proposal to remove the following members(review_count) from the glance-core 
list:

  *   Brian Lamar (0+15)
  *   Brian Waldon (0+0)
  *   Dan Prince (3+1)
  *   Eoghan Glynn (0+3)
  *   John Bresnahan (31+12)

And we would add the following new members:

  *   Ian Cordasco
  *   Louis Taylor
  *   Mike Fedosin
  *   Hemanth Makkapati


This way we've a first round of consolidation done. It must be evident that the 
list-cleanup proposed above is not comprehensive with regards to who is truly 
inactive. Thus, misses out on a few names due to lack of established criterion. 
We can do more about rotation in the following weeks.


Hope it works!


Regards,
-Nikhil

From: Kyle Mestery mest...@mestery.com
Sent: Friday, March 6, 2015 12:45 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Glance] Core nominations.

On Fri, Mar 6, 2015 at 11:40 AM, Ian Cordasco 
ian.corda...@rackspace.commailto:ian.corda...@rackspace.com wrote:
I like that idea. Can you start it out with Nova or Neutron's guidelines?

FYI, the core reviewer guidelines for Neutron are in-tree now [1], along with 
all of our other policies around operating in Neutron [2].

[1] 
https://github.com/openstack/neutron/blob/master/doc/source/policies/core-reviewers.rst
[2] https://github.com/openstack/neutron/tree/master/doc/source/policies

On 3/5/15, 17:38, Mikhail Fedosin 
mfedo...@mirantis.commailto:mfedo...@mirantis.com wrote:

I think yes, it does. But I mean that now we're writing a document called
Glance Review Guidelines

https://docs.google.com/document/d/1Iia0BjQoXvry9XSbf30DRwQt--ODglw-ZTT_5R
JabsI/edit?usp=sharing
https://docs.google.com/document/d/1Iia0BjQoXvry9XSbf30DRwQt--ODglw

Re: [openstack-dev] [Glance] Proposal to change Glance meeting time.

[Hemanth Makkapati]

+1 to consistent time. 
Both 1400 and 1500 work me.

-Hemanth

From: Ian Cordasco ian.corda...@rackspace.com
Sent: Wednesday, March 11, 2015 10:25 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Glance] Proposal to change Glance meeting time.

I have no opinions on the matter. Either 1400 or 1500 work for me. I think
there are a lot of people asking for it to be at 1500 instead though.
Would anyone object to changing it to 1500 instead (as long as it is one
consistent time for the meeting)?

On 3/11/15, 01:53, Inessa Vasilevskaya ivasilevsk...@mirantis.com
wrote:

+1


On Mon, Mar 9, 2015 at 2:43 AM, Alexander Tivelkov
ativel...@mirantis.com wrote:

Works for me, but the previous one worked as well. So, consider my vote
as +1 unless the majority is against this :)


--
Regards,
Alexander Tivelkov




On Mon, Mar 9, 2015 at 12:36 AM, Fei Long Wang
feil...@catalyst.net.nz wrote:

Oh, it means 3:00AM for me :-(


On 09/03/15 09:07, Nikhil Komawar wrote:






Hi all,


Currently, we've alternating time for Glance meetings. Now, with the
Daylight savings being implemented in some parts of the world, we're
thinking of moving the meeting time to just one slot i.e. earlier in the
day(night). This solves the original conflicting
 times issue that a subset of the individuals had; to add to that the
schedule is less confusing and unified.



So, the new proposal is:
Glance meetings [1] to be conducted
weekly on
Thursdays at 1400UTC [2] on
#openstack-meeting-4



This would be implemented on Mar 19th, given there are no major
objections.


Please vote with +1/-1 here.



[1]
https://wiki.openstack.org/wiki/Meetings#Glance_Team_meeting
https://wiki.openstack.org/wiki/Meetings#Glance_Team_meeting
[2]
http://www.timeanddate.com/worldclock/fixedtime.html?hour=14min=0sec=0
http://www.timeanddate.com/worldclock/fixedtime.html?hour=14min=0sec=0


Thanks,
-Nikhil






__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribehttp://lists.
openstack.org/cgi-bin/mailman/listinfo/openstack-dev


--
Cheers  Best regards,
Fei Long Wang (王飞龙)
--
Senior Cloud Software Engineer
Tel: +64-48032246 tel:%2B64-48032246
Email: flw...@catalyst.net.nz
Catalyst IT Limited
Level 6, Catalyst House, 150 Willis Street, Wellington
--


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://openstack-dev-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance] [VMT] [Security] Proposal to add Brian Rosmaita to the glance-coresec team

[Hemanth Makkapati]

+1

-Hemanth

From: Nikhil Komawar 
Sent: Wednesday, May 11, 2016 10:39 PM
To: OpenStack Development Mailing List
Subject: [openstack-dev] [glance] [VMT] [Security] Proposal to add Brian 
Rosmaita to the glance-coresec team

Hello all,

I would like to propose adding add Brian to the team. He has been doing
great work on improving the Glance experience for user and operators and
tying the threads with the security aspects of the service. He also
brings in good perspective of running large scale glance deployment and
the issues seen therein.

Please cast your vote with +1, 0 or -1, or you can reply back to me.

Thank you.

--

Thanks,
Nikhil


__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [all][oslo_config] Improving Config Option Help Texts

[Hemanth Makkapati]

+1 to what Ian said.

We had an Ops session at the Austin summit on this and we didn't hear any 
concerns about the clutter from what I can recall.
Some notes from that session are here [0].
May be the clutter is not a problem after all? At least, not yet.

If it does become a problem down the line, we can probably move the 
descriptions around or have ways to not generate them at all like Ian 
suggested. 
But, keeping the help texts themselves short and compact won't solve anything. 
It is, in fact, against what we are trying to solve for here, I think.

-Hemanth

[0] https://etherpad.openstack.org/p/AUS-ops-Config-Options

From: Ian Cordasco 
Sent: Tuesday, May 24, 2016 1:03 PM
To: Erno Kuvaja; OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [all][oslo_config] Improving Config Option Help
Texts

-Original Message-
From: Erno Kuvaja 
Reply: OpenStack Development Mailing List (not for usage questions)

Date: May 24, 2016 at 06:06:14
To: OpenStack Development Mailing List (not for usage questions)

Subject:  [openstack-dev] [all][oslo_config] Improving Config Option Help Texts

> Hi all,
>
> Based on the not yet merged spec of categorized config options [0] some
> project seems to have started improving the config option help texts. This
> is great but I noticed scary trend on clutter to be added on these
> sections. Now looking individual changes it does not look that bad at all
> in the code 20 lines well structured templating. Until you start comparing
> it to the example config files. Lots of this data is redundant to what is
> generated to the example configs already and then the maths struck me.
>
> In Glance only we have ~120 config options (this does not include
> glance_store nor any other dependencies we pull in for our configs like
> Keystone auth. Those +20 lines of templating just became over 2000 lines of
> clutter in the example configs and if all projects does that we can
> multiply the issue. I think no-one with good intention can say that it's
> beneficial for our deployers and admins who are already struggling with the
> configs.
>
> So I beg you when you do these changes to the config option help fields
> keep them short and compact. We have the Configuration Docs for extended
> descriptions and cutely formatted repetitive fields, but lets keep those
> off from the generated (Example) config files. At least I would like to be
> able to fit more than 3 options on the screen at the time when reading
> configs.
>
> [0] https://review.openstack.org/#/c/295543/

Hey Erno,

So here's where I have to very strongly disagree with you. That spec
was caused by operator feedback, specifically for projects that
provide multiple services that may or may not have separated config
files which and which already have "short and compact" descriptions
that are not very helpful to oeprators.

The *example* config files will have a lot more detail in them. Last I
saw (I've stopped driving that specification) there was going to be a
way to generate config files without all of the descriptions. That
means that for operators who don't care about that can ignore it when
they generate configuration files. Maybe the functionality doesn't
work right this instant, but I do believe that's a goal and it will be
implemented.

Beyond that, I don't think example/sample configuration files should
be treated differently from documentation, nor do I think that our
documentation team couldn't make use of the improved documentation
we're adding to each option. In short, I think this effort will
benefit many different groups of people in and around OpenStack.
Simply arguing that this is going to make the sample config files have
more lines of code is not a good argument against this. Please do
reconsider.

--
Ian Cordasco

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance] priorities for the coming week (01/27-02/02)

[Hemanth Makkapati]

I'm working on that patch, Ian.

-Hemanth

From: Ian Cordasco 
Sent: Friday, January 27, 2017 9:53 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [glance] priorities for the coming week
(01/27-02/02)

-Original Message-
From: Brian Rosmaita 
Reply: OpenStack Development Mailing List (not for usage questions)

Date: January 26, 2017 at 17:03:58
To: OpenStack Development Mailing List 
Subject:  [openstack-dev] [glance] priorities for the coming week (01/27-02/02)

> First, please read the email from Ian (our release czar) about the
> feature freeze:
> http://lists.openstack.org/pipermail/openstack-dev/2017-January/111067.html
>
> We have three priorities this week. The first is an all-hands-on-deck
> super priority, namely, reviewing (and re-reviewing, as appropriate) the
> code associated with Rolling Upgrades, which has received a FFE:
>
> - https://review.openstack.org/#/c/382958/
> - https://review.openstack.org/#/c/392993/
> - https://review.openstack.org/#/c/397409/
> - https://review.openstack.org/#/c/424774/

This last patch is described (in the commit title) as a WIP and the
author is not around (they're taking time off). Is someone else
working on it/taking it over? Does it belong in this list?

> Please start your reviews now. We don't want to be in a situation next
> week where people are rush-reviewing things.
>
> The other, secondary, not as important as the above, items are:
>
> * nominate any appropriate glanceclient bugs that didn't make it into
> this week's release by tagging them in Launchpad with
> "ocata-backport-potential". Please do this earlier rather than later,
> but do it consistently with the above.
>
> * ongoing work on the security bug - actually, this one is pretty
> important. Anyone in coresec, the only excuse for not reviewing Rolling
> Upgrades patches is if you are actively working on this bug.
>
> Have a good week, everyone!
>
> cheers,
> brian
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>

--
Ian Cordasco

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [Glance] Gerrit is blocking the workflow with -2 for reason

[Hemanth Makkapati]

Erno,

Totally with you on not circumventing the process.
I regret the fact that I had to resort to "side-stepping" your -2. 
But, please let's not look at this incident in isolation.
We had to do it considering the circumstances that
1. You were unavailable to remove the -2
2. N-3 milestone is right around the corner
3. Approaching long weekend in the U.S.

I'd like to bring your attention to the following patches
where there's more context on what happened.
https://review.openstack.org/#/c/361474/
https://review.openstack.org/#/c/361493/
https://review.openstack.org/#/c/360043/

I know sometimes 2 days could be a short window to respond,
but it is a milestone week and 2 days count.

Again, like I said, I regret the fact that we had to do this.
I don't mean to disrespect the process and neither do I encourage it. 
I hope you see that this decision was made based purely on the circumstances.
And, I hope it is seen as such.

Regards,
Hemanth


From: Erno Kuvaja 
Sent: Thursday, September 1, 2016 2:50 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [Glance] Gerrit is blocking the workflow with -2   
for reason

Hi all,

As it seems by the "Improving help text for *" string of patches like
[0][1] that the Glance core group is willing to get around -2s by
abandoning, reproposing and merging just because not all of us are
around in US office hours, I'd like to propose that we would just
remove the -2 right from glance-core group all together. The issues
leading to the -2s were flagged ages ago and got chased just over past
couple of days with huge urgency that didn't seem to be there earlier.

If this is ok just to get around my reviews, feel free to remove me
from Glance core to avoid such inconveniences in the future.

[0] https://review.openstack.org/#/c/360773/
[1] https://review.openstack.org/#/c/363870/

Best,
Erno

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Re: [openstack-dev] [glance][VMT][Security] Glance coresec reorg

[Hemanth Makkapati]

+1 to both Erno and Ian.
Both have made solid contributions to Glance over the past few cycles and are 
very thorough in their approach.
I believe both of them will be great additions to the Glance coresec group.

-Hemanth

From: Brian Rosmaita 
Sent: Tuesday, October 18, 2016 5:22:28 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: [openstack-dev] [glance][VMT][Security] Glance coresec reorg

Hello everyone,

First, I'd like to thank Flavio Percoco and Kairat Kushaev for their past
service as members of the Glance core security contacts team.
Unfortunately, due to other commitments, they don't have time to continue
on coresec.

Thus, the main point of this email is to propose Ian Cordasco and Erno
Kuvaja as new members of the Glance coresec team.  They've both been
Glance cores for several cycles, have a broad knowledge of the software
and team, contribute high-quality reviews, and are conversant with good
security practices.

Replacing Flavio and Kairat with Ian and Erno will keep the Glance coresec
team at 5 members.

Please cast your vote with +1, 0, or -1, or you can reply back to me.

Please reply before 23:59 UTC on Wednesday, October 26, 2016.

Thank you,
brian



__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

[openstack-dev] [glance] Stepping Down

[Hemanth Makkapati]

Glancers,
Due to a significant change to my job description, I wouldn't be able to
contribute to Glance in the capacity of a core reviewer going forward.
Hence, I'd like to step down from my role immediately.
For the same reason, I'd like to step down from Glance coresec and release
liaison roles as well.

Thanks for all the help!

Rooting for Glance to do great things,
Hemanth Makkapati
__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev