[openstack-dev] [nova] API updates week 18-42

2018-10-18 Thread Ghanshyam Mann
Hi All, Please find the Nova API highlights of this week. Weekly Office Hour: === What we discussed this week: - Discussed about API extensions works. - Discussed on 2 new bugs which needs more log for further debugging. added bug comments. Planned Features :

[openstack-dev] [nova] API updates week 18-41

2018-10-11 Thread Ghanshyam Mann
Hi All, Please find the Nova API highlights of this week. Weekly Office Hour: === What we discussed this week: - Discussed on api cleanup spec. - Discussed api extensions work and pending things on this work. Proposed all the pending item for this BP. - Discussed on 2 new

[openstack-dev] [nova] API updates week 02-08

2018-08-09 Thread Ghanshyam Mann
Hi All, Please find the Nova API highlights of this week. Weekly Office Hour: === What we discussed this week: - Discussed on granular policy spec to update that as default roles are present now. - Discussed keypair quota usage bug. and only doc update can be done for now.

Re: [openstack-dev] [nova] API updates week 19-25

2018-07-25 Thread Ghanshyam Mann
On Wed, 25 Jul 2018 23:53:18 +0900 Surya Seetharaman wrote > Hi! > On Wed, Jul 25, 2018 at 11:53 AM, Ghanshyam Mann > wrote: > > 5. API Extensions merge work > - https://blueprints.launchpad.net/nova/+spec/api-extensions-merge-rocky > - >

Re: [openstack-dev] [nova] API updates week 19-25

2018-07-25 Thread Surya Seetharaman
Hi! On Wed, Jul 25, 2018 at 11:53 AM, Ghanshyam Mann wrote: > > 5. API Extensions merge work > - https://blueprints.launchpad.net/nova/+spec/api-extensions-merge-rocky > - https://review.openstack.org/#/q/project:openstack/nova+ > branch:master+topic:bp/api-extensions-merge-rocky > - Weekly

[openstack-dev] [nova] API updates week 19-25

2018-07-25 Thread Ghanshyam Mann
Hi All, Please find the Nova API highlights of this week. Weekly Office Hour: === What we discussed this week: - Discussion on priority BP and remaining reviews on those. - Discussed keypair quota usage bug. Planned Features : == Below are the API related

[openstack-dev] [nova]API update week 12-18

2018-07-18 Thread Ghanshyam Mann
Hi All, Please find the Nova API highlights of this week. Weekly Office Hour: === What we discussed this week: - Discussion on priority BP and remaining reviews on those. - picked up 3 in-progress bug's patches and reviewed. Planned Features : == Below are the

Re: [openstack-dev] [nova]API update week 5-11

2018-07-15 Thread Zhenyu Zheng
Thank you very much for the review and updates during the weekends. On Sat, Jul 14, 2018 at 4:05 AM Matt Riedemann wrote: > On 7/11/2018 9:03 PM, Zhenyu Zheng wrote: > > 2. Abort live migration in queued state: > > - >

Re: [openstack-dev] [nova]API update week 5-11

2018-07-13 Thread Matt Riedemann
On 7/11/2018 9:03 PM, Zhenyu Zheng wrote: 2. Abort live migration in queued state: -https://blueprints.launchpad.net/nova/+spec/abort-live-migration-in-queued-status -https://review.openstack.org/#/q/topic:bp/abort-live-migration-in-queued-status+(status:open+OR+status:merged)

Re: [openstack-dev] [nova]API update week 5-11

2018-07-13 Thread Matt Riedemann
On 7/11/2018 8:14 PM, Ghanshyam Mann wrote: 4. Volume multiattach enhancements: -https://blueprints.launchpad.net/nova/+spec/volume-multiattach-enhancements -https://review.openstack.org/#/q/topic:bp/volume-multiattach-enhancements+(status:open+OR+status:merged) - Weekly Progress: mriedem

Re: [openstack-dev] [nova]API update week 5-11

2018-07-11 Thread Zhenyu Zheng
> > 2. Abort live migration in queued state: > - > https://blueprints.launchpad.net/nova/+spec/abort-live-migration-in-queued-status > > - > https://review.openstack.org/#/q/topic:bp/abort-live-migration-in-queued-status+(status:open+OR+status:merged) > > - Weekly Progress: Review is going and it

[openstack-dev] [nova]API update week 5-11

2018-07-11 Thread Ghanshyam Mann
Hi All, Please find the Nova API highlights of this week. Weekly Office Hour: === We had more attendees in this week office hours. What we discussed this week: - Discussion on API related BP. Discussion points are embedded inline with BP weekly progress in next section. -

Re: [openstack-dev] [nova]API update week 28-4

2018-07-06 Thread Matt Riedemann
On 7/4/2018 6:10 AM, Ghanshyam Mann wrote: Planned Features : == Below are the API related features for Rocky cycle. Nova API Sub team will start reviewing those to give their regular feedback. If anythings missing there feel free to add those in

Re: [openstack-dev] [nova]API update week 28-4

2018-07-06 Thread Matt Riedemann
Thanks for sending out this update, it's useful for me when I'm not attending the office hours. On 7/4/2018 6:10 AM, Ghanshyam Mann wrote: 1. Servers Ips non-unique network names : -https://blueprints.launchpad.net/nova/+spec/servers-ips-non-unique-network-names - Spec Update need

[openstack-dev] [nova]API update week 28-4

2018-07-04 Thread Ghanshyam Mann
Hi All, Please find the Nova API highlights of this week. Weekly Office Hour: === We have re-started the Nova API discussion in office hour. I have updated the wiki page for more information about office hours: https://wiki.openstack.org/wiki/Meetings/NovaAPI What we discussed

[openstack-dev] [nova] API reference verification for servers APIs (parameter and example)

2018-01-23 Thread Takashi Natsume
Hi, Nova developers. There was work verifying the Nova compute API Reference (*1, *2, *3, *4) before. But the verification has not been completed yet in "Servers" APIs (creating, updating, deleting a server, listing servers, etc.). *1: Convert API Reference to RST and host it in the Nova tree

Re: [openstack-dev] [nova][api] why need PUT /servers/{server_id}/metadata/{key} ?

2017-09-20 Thread Chen CH Ji
...@cn.ibm.com Phone: +86-10-82451493 Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District, Beijing 100193, PRC From: Matt Riedemann <mriede...@gmail.com> To: openstack-dev@lists.openstack.org Date: 09/20/2017 09:15 PM Subject: Re: [openstack-dev] [nova][api] wh

Re: [openstack-dev] [nova][api] why need PUT /servers/{server_id}/metadata/{key} ?

2017-09-20 Thread Matt Riedemann
On 9/20/2017 8:33 AM, Alex Xu wrote:  is there any use-case that people update server's metadata such frequently? If you have automation tooling updating the metadata for whatever reason it could be a problem. This was the reported bug FWIW: https://bugs.launchpad.net/nova/+bug/1650188

Re: [openstack-dev] [nova][api] why need PUT /servers/{server_id}/metadata/{key} ?

2017-09-20 Thread Ghanshyam Mann
On Wed, Sep 20, 2017 at 10:14 PM, Matt Riedemann wrote: > On 9/20/2017 12:48 AM, Chen CH Ji wrote: >> >> in analyzing other code, found seems we don't need PUT >> /servers/{server_id}/metadata/{key} ? >> >> as the id is only used for check whether it's in the body and we will

Re: [openstack-dev] [nova][api] why need PUT /servers/{server_id}/metadata/{key} ?

2017-09-20 Thread Alex Xu
2017-09-20 21:14 GMT+08:00 Matt Riedemann : > On 9/20/2017 12:48 AM, Chen CH Ji wrote: > >> in analyzing other code, found seems we don't need PUT >> /servers/{server_id}/metadata/{key} ? >> >> as the id is only used for check whether it's in the body and we will >> honor the

Re: [openstack-dev] [nova][api] why need PUT /servers/{server_id}/metadata/{key} ?

2017-09-20 Thread Matt Riedemann
On 9/20/2017 12:48 AM, Chen CH Ji wrote: in analyzing other code, found seems we don't need PUT /servers/{server_id}/metadata/{key} ? as the id is only used for check whether it's in the body and we will honor the whole body (body['meta'] in the code)

Re: [openstack-dev] [nova][api] why need PUT /servers/{server_id}/metadata/{key} ?

2017-09-20 Thread Ghanshyam Mann
On Wed, Sep 20, 2017 at 2:48 PM, Chen CH Ji wrote: > in analyzing other code, found seems we don't need PUT > /servers/{server_id}/metadata/{key} ? > > as the id is only used for check whether it's in the body and we will honor > the whole body (body['meta'] in the code) >

[openstack-dev] [nova][api] why need PUT /servers/{server_id}/metadata/{key} ?

2017-09-19 Thread Chen CH Ji
in analyzing other code, found seems we don't need PUT /servers/{server_id}/metadata/{key} ? as the id is only used for check whether it's in the body and we will honor the whole body (body['meta'] in the code)

Re: [openstack-dev] [nova][api] Strict validation in query parameters

2017-06-16 Thread Sean Dague
On 06/15/2017 10:01 PM, Matt Riedemann wrote: > On 6/15/2017 8:43 PM, Alex Xu wrote: >> We added new decorator 'query_schema' to support validate the query >> parameters by JSON-Schema. >> >> It provides more strict valiadation as below: >> * set the 'additionalProperties=False' in the schema, it

Re: [openstack-dev] [nova][api] Strict validation in query parameters

2017-06-15 Thread Ghanshyam Mann
On Fri, Jun 16, 2017 at 11:01 AM, Matt Riedemann wrote: > On 6/15/2017 8:43 PM, Alex Xu wrote: >> >> We added new decorator 'query_schema' to support validate the query >> parameters by JSON-Schema. >> >> It provides more strict valiadation as below: >> * set the

Re: [openstack-dev] [nova][api] Strict validation in query parameters

2017-06-15 Thread Matt Riedemann
On 6/15/2017 8:43 PM, Alex Xu wrote: We added new decorator 'query_schema' to support validate the query parameters by JSON-Schema. It provides more strict valiadation as below: * set the 'additionalProperties=False' in the schema, it means that reject any invalid query parameters and return

[openstack-dev] [nova][api] Strict validation in query parameters

2017-06-15 Thread Alex Xu
We added new decorator 'query_schema' to support validate the query parameters by JSON-Schema. It provides more strict valiadation as below: * set the 'additionalProperties=False' in the schema, it means that reject any invalid query parameters and return HTTPBadRequest 400 to the user. * use the

Re: [openstack-dev] [nova][api] quota-class-show not sync toquota-show

2017-04-12 Thread Chen CH Ji
Park, Haidian District, Beijing 100193, PRC From: Lance Bragstad <lbrags...@gmail.com> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org> Date: 04/12/2017 03:09 AM Subject: Re: [openstack-dev] [

Re: [openstack-dev] [nova][api] quota-class-show not sync to quota-show

2017-04-11 Thread Lance Bragstad
On Tue, Apr 11, 2017 at 1:21 PM, Matt Riedemann wrote: > On 4/11/2017 2:52 AM, Alex Xu wrote: > >> We talked about remove the quota-class API for multiple times >> (http://lists.openstack.org/pipermail/openstack-dev/2016-July/099218.html >> ) >> >> I guess we can deprecate

Re: [openstack-dev] [nova][api] quota-class-show not sync to quota-show

2017-04-11 Thread Matt Riedemann
On 4/11/2017 2:52 AM, Alex Xu wrote: We talked about remove the quota-class API for multiple times (http://lists.openstack.org/pipermail/openstack-dev/2016-July/099218.html) I guess we can deprecate the entire quota-class API directly. I had a spec proposed to deprecate the

Re: [openstack-dev] [nova][api] quota-class-show not sync to quota-show

2017-04-11 Thread Alex Xu
We talked about remove the quota-class API for multiple times ( http://lists.openstack.org/pipermail/openstack-dev/2016-July/099218.html) I guess we can deprecate the entire quota-class API directly. 2017-04-07 18:19 GMT+08:00 Chen CH Ji : > Version 2.35 removed most

[openstack-dev] [nova][api] quota-class-show not sync to quota-show

2017-04-07 Thread Chen CH Ji
Version 2.35 removed most deprecated output like floating ip etc so we won't have following in quota-show output | floating_ips| 10| | fixed_ips | -1| | security_groups | 10| | security_group_rules| 20| however,

Re: [openstack-dev] [nova][api] GET or HEAD for checking trait existence

2017-03-30 Thread Ken'ichi Ohmichi
Hi Jay, Thanks for your reply. 2017-03-29 12:26 GMT-07:00 Jay Pipes : > On 03/29/2017 02:04 PM, Ken'ichi Ohmichi wrote: >> >> Hi >> >> I have some questions about plancement API design from >> https://review.openstack.org/#/c/376200 >> Current implementation of the above

Re: [openstack-dev] [nova][api] GET or HEAD for checking trait existence

2017-03-29 Thread Jay Pipes
On 03/29/2017 02:04 PM, Ken'ichi Ohmichi wrote: Hi I have some questions about plancement API design from https://review.openstack.org/#/c/376200 Current implementation of the above patch (PS26) adds GET method for checking trait existence, and tags.rst of api-wg guideline[1] requires GET for

[openstack-dev] [nova][api] GET or HEAD for checking trait existence

2017-03-29 Thread Ken'ichi Ohmichi
Hi I have some questions about plancement API design from https://review.openstack.org/#/c/376200 Current implementation of the above patch (PS26) adds GET method for checking trait existence, and tags.rst of api-wg guideline[1] requires GET for checking trait existence. On the other hand,

[openstack-dev] [nova] API work for ocata summit session recap

2016-11-04 Thread Matt Riedemann
John Garbutt led a session at the summit focusing on some of the API work items for Ocata. The full etherpad is here: https://etherpad.openstack.org/p/ocata-nova-summit-api API capabilities We talked a bit about the cross-project discoverable API spec. There was also a xp

Re: [openstack-dev] [Nova][API] Need naming suggestions for "capabilities"

2016-08-31 Thread Michał Dulko
On 08/25/2016 07:52 PM, Andrew Laski wrote: > On Thu, Aug 25, 2016, at 12:22 PM, Everett Toews wrote: >> Top posting with general comment... >> >> It sounds like there's some consensus in Nova-land around these >> traits (née "capabilities"). The API Working Group [4] is >> also aware of similar

Re: [openstack-dev] [Nova][API] Need naming suggestions for "capabilities"

2016-08-25 Thread Andrew Laski
On Thu, Aug 25, 2016, at 12:22 PM, Everett Toews wrote: > Top posting with general comment... > > It sounds like there's some consensus in Nova-land around these traits > (née "capabilities"). The API Working Group [4] is > also aware of similar efforts in Cinder [1][2] and Glance [3]. To be

Re: [openstack-dev] [Nova][API] Need naming suggestions for "capabilities"

2016-08-25 Thread Everett Toews
Top posting with general comment... It sounds like there's some consensus in Nova-land around these traits (née "capabilities"). The API Working Group [4] is also aware of similar efforts in Cinder [1][2] and Glance [3]. If these are truly the same concepts being discussed across projects, it

Re: [openstack-dev] [Nova][API] Need naming suggestions for "capabilities"

2016-08-16 Thread Sylvain Bauza
Le 15/08/2016 22:59, Andrew Laski a écrit : On Mon, Aug 15, 2016, at 10:33 AM, Jay Pipes wrote: On 08/15/2016 09:27 AM, Andrew Laski wrote: Currently in Nova we're discussion adding a "capabilities" API to expose to users what actions they're allowed to take, and having compute hosts expose

Re: [openstack-dev] [Nova][API] Need naming suggestions for "capabilities"

2016-08-16 Thread Jim Meyer
> On Aug 15, 2016, at 10:49 AM, Doug Hellmann wrote: > > Excerpts from Jim Meyer's message of 2016-08-15 09:37:36 -0700: >> A fast reply where others will expand further (I hope): >> >>> On Aug 15, 2016, at 9:01 AM, Doug Hellmann wrote: >>>

Re: [openstack-dev] [Nova][API] Need naming suggestions for "capabilities"

2016-08-15 Thread Andrew Laski
On Mon, Aug 15, 2016, at 10:33 AM, Jay Pipes wrote: > On 08/15/2016 09:27 AM, Andrew Laski wrote: > > Currently in Nova we're discussion adding a "capabilities" API to expose > > to users what actions they're allowed to take, and having compute hosts > > expose "capabilities" for use by the

Re: [openstack-dev] [Nova][API] Need naming suggestions for "capabilities"

2016-08-15 Thread Doug Hellmann
Excerpts from Jim Meyer's message of 2016-08-15 09:37:36 -0700: > A fast reply where others will expand further (I hope): > > > On Aug 15, 2016, at 9:01 AM, Doug Hellmann wrote: > > > >> My vote is the following: > >> > >> GET /capabilities <-- returns a set of *actions*

Re: [openstack-dev] [Nova][API] Need naming suggestions for "capabilities"

2016-08-15 Thread Jim Meyer
A fast reply where others will expand further (I hope): > On Aug 15, 2016, at 9:01 AM, Doug Hellmann wrote: > >> My vote is the following: >> >> GET /capabilities <-- returns a set of *actions* or *abilities* that the >> user is capable of performing > > Does this

Re: [openstack-dev] [Nova][API] Need naming suggestions for "capabilities"

2016-08-15 Thread Jay Pipes
On 08/15/2016 12:01 PM, Doug Hellmann wrote: Excerpts from Jay Pipes's message of 2016-08-15 10:33:49 -0400: On 08/15/2016 09:27 AM, Andrew Laski wrote: Currently in Nova we're discussion adding a "capabilities" API to expose to users what actions they're allowed to take, and having compute

Re: [openstack-dev] [Nova][API] Need naming suggestions for "capabilities"

2016-08-15 Thread Doug Hellmann
Excerpts from Jay Pipes's message of 2016-08-15 10:33:49 -0400: > On 08/15/2016 09:27 AM, Andrew Laski wrote: > > Currently in Nova we're discussion adding a "capabilities" API to expose > > to users what actions they're allowed to take, and having compute hosts > > expose "capabilities" for use

Re: [openstack-dev] [Nova][API] Need naming suggestions for "capabilities"

2016-08-15 Thread Mooney, Sean K
> -Original Message- > From: Jay Pipes [mailto:jaypi...@gmail.com] > Sent: Monday, August 15, 2016 3:34 PM > To: openstack-dev@lists.openstack.org > Subject: Re: [openstack-dev] [Nova][API] Need naming suggestions for > "capabilities" > > On 08/15

Re: [openstack-dev] [Nova][API] Need naming suggestions for "capabilities"

2016-08-15 Thread Jay Pipes
On 08/15/2016 10:50 AM, Dean Troyer wrote: On Mon, Aug 15, 2016 at 9:33 AM, Jay Pipes > wrote: On 08/15/2016 09:27 AM, Andrew Laski wrote: After some thought, I think I've changed my mind on referring to the adjectives as

Re: [openstack-dev] [Nova][API] Need naming suggestions for "capabilities"

2016-08-15 Thread Dean Troyer
On Mon, Aug 15, 2016 at 9:33 AM, Jay Pipes wrote: > On 08/15/2016 09:27 AM, Andrew Laski wrote: > >> After some thought, I think I've changed my mind on referring to the >> adjectives as "capabilities" and actually think that the term >> "capabilities" is better left for the

Re: [openstack-dev] [Nova][API] Need naming suggestions for "capabilities"

2016-08-15 Thread Dean Troyer
On Mon, Aug 15, 2016 at 8:27 AM, Andrew Laski wrote: > An API "capability" is going to be an action, or URL, that a user is > allowed to use. So "boot an instance" or "resize this instance" are > capabilities from the API point of view. Whether or not a user has this >

Re: [openstack-dev] [Nova][API] Need naming suggestions for "capabilities"

2016-08-15 Thread Jay Pipes
On 08/15/2016 09:27 AM, Andrew Laski wrote: Currently in Nova we're discussion adding a "capabilities" API to expose to users what actions they're allowed to take, and having compute hosts expose "capabilities" for use by the scheduler. As much fun as it would be to have the same term mean two

[openstack-dev] [Nova][API] Need naming suggestions for "capabilities"

2016-08-15 Thread Andrew Laski
Currently in Nova we're discussion adding a "capabilities" API to expose to users what actions they're allowed to take, and having compute hosts expose "capabilities" for use by the scheduler. As much fun as it would be to have the same term mean two very different things in Nova to retain some

Re: [openstack-dev] [nova] [api] [placement] strategy for placement api structure

2016-06-20 Thread Jay Pipes
On 06/20/2016 12:47 PM, Doug Hellmann wrote: Excerpts from Jay Pipes's message of 2016-06-20 10:04:06 -0400: On 06/17/2016 11:23 AM, Sylvain Bauza wrote: +1000 yes to that. Now the devil could be in the details, in particular how we implement the WSGI server, the corresponding WSGI app and the

Re: [openstack-dev] [nova] [api] [placement] strategy for placement api structure

2016-06-20 Thread Doug Hellmann
Excerpts from Jay Pipes's message of 2016-06-20 10:04:06 -0400: > On 06/17/2016 11:23 AM, Sylvain Bauza wrote: > > +1000 yes to that. Now the devil could be in the details, in particular > > how we implement the WSGI server, the corresponding WSGI app and the > > associated routing, and that's

Re: [openstack-dev] [nova] [api] [placement] strategy for placement api structure

2016-06-20 Thread Jay Pipes
On 06/20/2016 10:21 AM, Sylvain Bauza wrote: Le 20/06/2016 16:04, Jay Pipes a écrit : On 06/17/2016 11:23 AM, Sylvain Bauza wrote: +1000 yes to that. Now the devil could be in the details, in particular how we implement the WSGI server, the corresponding WSGI app and the associated routing,

Re: [openstack-dev] [nova] [api] [placement] strategy for placement api structure

2016-06-20 Thread Sylvain Bauza
Le 20/06/2016 16:04, Jay Pipes a écrit : On 06/17/2016 11:23 AM, Sylvain Bauza wrote: +1000 yes to that. Now the devil could be in the details, in particular how we implement the WSGI server, the corresponding WSGI app and the associated routing, and that's exactly the problem below. We

Re: [openstack-dev] [nova] [api] [placement] strategy for placement api structure

2016-06-20 Thread Jay Pipes
On 06/17/2016 11:23 AM, Sylvain Bauza wrote: +1000 yes to that. Now the devil could be in the details, in particular how we implement the WSGI server, the corresponding WSGI app and the associated routing, and that's exactly the problem below. We shouldn't be implementing a WSGI server *at

Re: [openstack-dev] [nova] [api] [placement] strategy for placement api structure

2016-06-20 Thread Sean Dague
On 06/17/2016 12:14 PM, Chris Dent wrote: > On Fri, 17 Jun 2016, Sylvain Bauza wrote: > >> In the review, you explain why you don't trust Routes and I respect >> that. That said, are those issues logged as real problems for our API >> consumers, which are mostly client libraries that we own and

Re: [openstack-dev] [nova] [api] [placement] strategy for placement api structure

2016-06-17 Thread Sylvain Bauza
Le 17/06/2016 18:11, Dean Troyer a écrit : On Fri, Jun 17, 2016 at 10:23 AM, Sylvain Bauza > wrote: In the review, you explain why you don't trust Routes and I respect that. That said, are those issues logged as real problems for our

Re: [openstack-dev] [nova] [api] [placement] strategy for placement api structure

2016-06-17 Thread Chris Dent
On Fri, 17 Jun 2016, Sylvain Bauza wrote: In the review, you explain why you don't trust Routes and I respect that. That said, are those issues logged as real problems for our API consumers, which are mostly client libraries that we own and other projects we know, like Horizon ? The

Re: [openstack-dev] [nova] [api] [placement] strategy for placement api structure

2016-06-17 Thread Dean Troyer
On Fri, Jun 17, 2016 at 10:23 AM, Sylvain Bauza wrote: > > In the review, you explain why you don't trust Routes and I respect that. > That said, are those issues logged as real problems for our API consumers, > which are mostly client libraries that we own and other projects

Re: [openstack-dev] [nova] [api] [placement] strategy for placement api structure

2016-06-17 Thread Chris Dent
On Fri, 17 Jun 2016, Andrey Volkov wrote: IMHO selector is too young in terms of version (0.1) and too old in terms of updates (3 years ago). It's 0.10. When I contacted the author (see the comments on https://review.openstack.org/#/c/329386/ ) he said the reason there were no recent

Re: [openstack-dev] [nova] [api] [placement] strategy for placement api structure

2016-06-17 Thread Sylvain Bauza
Le 17/06/2016 12:55, Chris Dent a écrit : tl;dr: Have a look at https://review.openstack.org/#/c/329386/ to help move some placement API decisions along. Not really that long, do read: As part of the generic resource pools spec[1] a new, independent of the rest of nova, API is being

Re: [openstack-dev] [nova] [api] [placement] strategy for placement api structure

2016-06-17 Thread Andrey Volkov
It's nice to hear about HTTP API. I'm quite new in nova and openstack and don't grasp all that rpc things yet and can miss something but anyway I have several thoughts about API. Boring standpoint. First to choose some technology I think we can look at how widely it's adopted and how many people

[openstack-dev] [nova] [api] [placement] strategy for placement api structure

2016-06-17 Thread Chris Dent
tl;dr: Have a look at https://review.openstack.org/#/c/329386/ to help move some placement API decisions along. Not really that long, do read: As part of the generic resource pools spec[1] a new, independent of the rest of nova, API is being developed called the "Placement API". The API will

[openstack-dev] Nova API extensions removal plan

2016-06-14 Thread Sean Dague
Nova is getting towards it's final phases of the long term arc to really standardize the API, which includes removing the API extensions facility. This has been a long arc that was started in Atlanta. And has been talked about in a lot of channels, but some interactions this past week made us

Re: [openstack-dev] [nova] API changes on limit / marker / sort in Newton

2016-06-02 Thread Sean Dague
On 06/02/2016 12:53 PM, Everett Toews wrote: > >> On Jun 1, 2016, at 2:01 PM, Matt Riedemann >> wrote: >> >> Agree with Sean, I'd prefer separate microversions since it makes getting >> these in easier since they are easier to review (and remember we make >>

Re: [openstack-dev] [nova] API changes on limit / marker / sort in Newton

2016-06-02 Thread Everett Toews
> On Jun 1, 2016, at 2:01 PM, Matt Riedemann wrote: > > Agree with Sean, I'd prefer separate microversions since it makes getting > these in easier since they are easier to review (and remember we make changes > to python-novaclient for each of these also). > >

Re: [openstack-dev] [nova] API changes on limit / marker / sort in Newton

2016-06-01 Thread Matt Riedemann
On 5/31/2016 7:38 AM, Sean Dague wrote: On 05/30/2016 10:05 PM, Zhenyu Zheng wrote: I think it is good to share codes and a single microversion can make life more easier during coding. Can we approve those specs first and then decide on the details in IRC and patch review? Because the

Re: [openstack-dev] [nova] API changes on limit / marker / sort in Newton

2016-05-31 Thread Sean Dague
On 05/30/2016 10:05 PM, Zhenyu Zheng wrote: > I think it is good to share codes and a single microversion can make > life more easier during coding. > Can we approve those specs first and then decide on the details in IRC > and patch review? Because > the non-priority spec deadline is so close. >

Re: [openstack-dev] [nova] API changes on limit / marker / sort in Newton

2016-05-30 Thread Zhenyu Zheng
I think it is good to share codes and a single microversion can make life more easier during coding. Can we approve those specs first and then decide on the details in IRC and patch review? Because the non-priority spec deadline is so close. Thanks On Tue, May 31, 2016 at 1:09 AM, Ken'ichi

Re: [openstack-dev] [nova] API changes on limit / marker / sort in Newton

2016-05-30 Thread Ken'ichi Ohmichi
2016-05-29 19:25 GMT-07:00 Alex Xu : > > > 2016-05-20 20:05 GMT+08:00 Sean Dague : >> >> There are a number of changes up for spec reviews that add parameters to >> LIST interfaces in Newton: >> >> * keypairs-pagination (MERGED) - >> >>

Re: [openstack-dev] [nova] API changes on limit / marker / sort in Newton

2016-05-29 Thread Alex Xu
2016-05-20 20:05 GMT+08:00 Sean Dague : > There are a number of changes up for spec reviews that add parameters to > LIST interfaces in Newton: > > * keypairs-pagination (MERGED) - > >

Re: [openstack-dev] [nova] API changes on limit / marker / sort in Newton

2016-05-25 Thread Zhenyu Zheng
Thanks for the information, really hope these two can get merged for Newton: https://review.openstack.org/#/c/240401/ https://review.openstack.org/#/c/239869/ On Sat, May 21, 2016 at 5:55 AM, Jay Pipes wrote: > +1 on all your suggestions below, Sean. > > -jay > > > On

Re: [openstack-dev] [nova] API changes on limit / marker / sort in Newton

2016-05-20 Thread Jay Pipes
+1 on all your suggestions below, Sean. -jay On 05/20/2016 08:05 AM, Sean Dague wrote: There are a number of changes up for spec reviews that add parameters to LIST interfaces in Newton: * keypairs-pagination (MERGED) -

[openstack-dev] [nova] API changes on limit / marker / sort in Newton

2016-05-20 Thread Sean Dague
There are a number of changes up for spec reviews that add parameters to LIST interfaces in Newton: * keypairs-pagination (MERGED) - https://github.com/openstack/nova-specs/blob/8d16fc11ee6d01b5a9fe1b8b7ab7fa6dff460e2a/specs/newton/approved/keypairs-pagination.rst#L2 * os-instances-actions -

Re: [openstack-dev] [nova] api-ref sprint Monday update

2016-05-16 Thread Sean Dague
On 05/16/2016 03:18 PM, Sean Dague wrote: > On 05/09/2016 08:23 AM, Sean Dague wrote: >> There is a lot of work to be done to get the api-ref into a final state. >> >> Review / fix existing patches - >> https://review.openstack.org/#/q/project:openstack/nova+file:api-ref+status:open >> shows

Re: [openstack-dev] [nova] api-ref sprint Monday update

2016-05-16 Thread Sean Dague
On 05/09/2016 08:23 AM, Sean Dague wrote: > There is a lot of work to be done to get the api-ref into a final state. > > Review / fix existing patches - > https://review.openstack.org/#/q/project:openstack/nova+file:api-ref+status:open > shows patches not yet merged. Please review them, and if

Re: [openstack-dev] Nova API is run on controller node instead of Compute node

2016-05-16 Thread John Garbutt
On 16 May 2016 at 09:58, Tarun wrote: > Hi All, > > I have setup the Openstack controller and compue node on 2 VMs in my windows > 8 Laptop. > > It is running. > > I am starting development for the NOVA compute APIs. > > To kick-off, i am trying to call compute API, for

[openstack-dev] Nova API is run on controller node instead of Compute node

2016-05-16 Thread Tarun
Hi All, I have setup the Openstack controller and compue node on 2 VMs in my windows 8 Laptop. It is running. I am starting development for the NOVA compute APIs. To kick-off, i am trying to call compute API, for example: $nova hypervisor-list Response is OK. It should call the 'show'

Re: [openstack-dev] [nova] api-ref sprint - Friday wrap up

2016-05-13 Thread Matt Riedemann
On 5/13/2016 7:14 PM, Sean Dague wrote: On 05/09/2016 08:23 AM, Sean Dague wrote: There is a lot of work to be done to get the api-ref into a final state. Review / fix existing patches - https://review.openstack.org/#/q/project:openstack/nova+file:api-ref+status:open shows patches not yet

Re: [openstack-dev] [nova] api-ref sprint - Friday wrap up

2016-05-13 Thread Sean Dague
On 05/09/2016 08:23 AM, Sean Dague wrote: There is a lot of work to be done to get the api-ref into a final state. Review / fix existing patches - https://review.openstack.org/#/q/project:openstack/nova+file:api-ref+status:open shows patches not yet merged. Please review them, and if there are

Re: [openstack-dev] [nova] api-ref sprint - Thursday Status - nova core reviewers needed

2016-05-12 Thread Sean Dague
On 05/09/2016 08:23 AM, Sean Dague wrote: > There is a lot of work to be done to get the api-ref into a final state. > > Review / fix existing patches - > https://review.openstack.org/#/q/project:openstack/nova+file:api-ref+status:open > shows patches not yet merged. Please review them, and if

Re: [openstack-dev] [nova] api-ref sprint Wed status

2016-05-11 Thread Sean Dague
On 05/11/2016 09:06 AM, Sean Dague wrote: > On 05/09/2016 08:23 AM, Sean Dague wrote: >> There is a lot of work to be done to get the api-ref into a final state. >> >> Review / fix existing patches - >> https://review.openstack.org/#/q/project:openstack/nova+file:api-ref+status:open >> shows

Re: [openstack-dev] [nova] api-ref sprint Wed morning status

2016-05-11 Thread Sean Dague
On 05/09/2016 08:23 AM, Sean Dague wrote: > There is a lot of work to be done to get the api-ref into a final state. > > Review / fix existing patches - > https://review.openstack.org/#/q/project:openstack/nova+file:api-ref+status:open > shows patches not yet merged. Please review them, and if

Re: [openstack-dev] [nova] api-ref sprint today & wed

2016-05-10 Thread Sean Dague
On 05/09/2016 06:27 PM, Augustina Ragwitz wrote: > Currently it's really hard to tell (at least to me) which files have > patches against them and which don't. I've had to manually make a > spreadsheet because it's not obvious to me, at a glance, from the > current commit messages, and I've

Re: [openstack-dev] [nova] api-ref sprint: Tuesday status

2016-05-10 Thread Sean Dague
On 05/09/2016 08:23 AM, Sean Dague wrote: > There is a lot of work to be done to get the api-ref into a final state. > > Review / fix existing patches - > https://review.openstack.org/#/q/project:openstack/nova+file:api-ref+status:open > shows patches not yet merged. Please review them, and if

Re: [openstack-dev] [nova] api-ref sprint today & wed

2016-05-10 Thread Sean Dague
e - > From: Augustina Ragwitz <aragwitz.li...@pobox.com> > To: OpenStack Development Mailing List > <openstack-dev@lists.openstack.org> (not for usage questions) > Cc: > Subject: Re: [openstack-dev] [nova] api-ref sprint today & wed > Date: Tue

Re: [openstack-dev] [nova] api-ref sprint today & wed

2016-05-10 Thread Chen CH Ji
: [openstack-dev] [nova] api-ref sprint today & wedDate: Tue, May 10, 2016 12:29 AM  Currently it's really hard to tell (at least to me) which files havepatches against them and which don't. I've had to manually make aspreadsheet because it's not obvious to me, at a glance, from thecurrent

Re: [openstack-dev] [nova] api-ref sprint today & wed

2016-05-09 Thread Augustina Ragwitz
Currently it's really hard to tell (at least to me) which files have patches against them and which don't. I've had to manually make a spreadsheet because it's not obvious to me, at a glance, from the current commit messages, and I've accidentally started work on several files that already have

[openstack-dev] [nova] api-ref sprint today & wed

2016-05-09 Thread Sean Dague
There is a lot of work to be done to get the api-ref into a final state. Review / fix existing patches - https://review.openstack.org/#/q/project:openstack/nova+file:api-ref+status:open shows patches not yet merged. Please review them, and if there are issues feel free to fix them. Help create

Re: [openstack-dev] [nova] api-ref docs cleanup review sprint 5/9 and 5/11

2016-05-06 Thread Sean Dague
On 05/03/2016 04:12 PM, Matt Riedemann wrote: > We discussed at the summit a need for a review sprint on the api-ref > docs cleanup effort that's going on. See Sean's email on that from a > few weeks ago [1]. > > So we plan to do a review sprint next Monday 5/9 and Wednesday 5/11. > > The

[openstack-dev] [nova] api-ref docs cleanup review sprint 5/9 and 5/11

2016-05-03 Thread Matt Riedemann
We discussed at the summit a need for a review sprint on the api-ref docs cleanup effort that's going on. See Sean's email on that from a few weeks ago [1]. So we plan to do a review sprint next Monday 5/9 and Wednesday 5/11. The series to review is here [2]. [1]

Re: [openstack-dev] [nova] api-ref content verification phase doc push

2016-04-21 Thread Sean Dague
On 04/21/2016 09:54 AM, Matt Riedemann wrote: > How about an etherpad where they are listed and people can assign > themselves per file? I guess that gets messy when you have some changes > doing step 1 on multiple files... The giant etherpads become a mess to keep track of source of truth, and

Re: [openstack-dev] [nova] api-ref content verification phase doc push

2016-04-21 Thread Matt Riedemann
On 4/20/2016 6:25 PM, Sean Dague wrote: This morning we finally cleaned up the last warnings in api-ref, so now we can enforce errors on warnings. Woot! That went much faster than I anticipated, and puts us at a really good place for summit. The next phase is the content verification phase.

[openstack-dev] [nova] api-ref content verification phase doc push

2016-04-20 Thread Sean Dague
This morning we finally cleaned up the last warnings in api-ref, so now we can enforce errors on warnings. Woot! That went much faster than I anticipated, and puts us at a really good place for summit. The next phase is the content verification phase. This patch is merging a set of comments at

Re: [openstack-dev] [nova] API priorities in Newton

2016-03-31 Thread GHANSHYAM MANN
On Thu, Mar 31, 2016 at 4:47 AM, Matthew Treinish wrote: > On Wed, Mar 30, 2016 at 03:26:13PM -0400, Sean Dague wrote: >> During the Nova API meeting we had some conversations about priorities, >> but this feels like the thing where a mailing list conversation is more >>

Re: [openstack-dev] [nova] API priorities in Newton

2016-03-31 Thread Ken'ichi Ohmichi
2016-03-30 12:54 GMT-07:00 Matt Riedemann : >>> - Microversion Testing in Tempest (underway) > > How much coverage do we have today? This could be like novaclient where > people just start hacking on adding tests for each microversion (assuming > gmann would be working

Re: [openstack-dev] [nova] API priorities in Newton

2016-03-31 Thread Ken'ichi Ohmichi
2016-03-30 12:26 GMT-07:00 Sean Dague : > > One other issue that we've been blocking on for a while has been > Capabilities discovery. Some API proposed adds like live resize have > been conceptually blocked behind this one. Once upon a time there was a > theory that JSON Home was

Re: [openstack-dev] [nova] API priorities in Newton

2016-03-31 Thread Alex Xu
2016-03-31 19:21 GMT+08:00 Sean Dague : > On 03/31/2016 04:55 AM, Alex Xu wrote: > > > > > > 2016-03-31 5:36 GMT+08:00 Matt Riedemann > > As discussed in IRC today, first steps (I think) are removing the > > deprecated 'osapi_v21.enabled'

  1   2   3   >