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 :
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
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.
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
> -
>
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
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
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
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:
> > -
>
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)
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
>
> 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
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.
-
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
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
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
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
...@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
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
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
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
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)
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)
>
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)
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
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
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
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
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] [
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
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
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
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,
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
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
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,
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
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
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
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
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
> 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:
>>>
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
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*
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
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
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
> -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
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
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
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
>
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
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
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
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
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,
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
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
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
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
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
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
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
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
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
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
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
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
>>
> 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).
>
>
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
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.
>
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
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) -
>>
>>
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) -
>
>
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
+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) -
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 -
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
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
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
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'
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
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
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
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
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
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
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
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
: [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
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
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
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
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]
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
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.
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
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
>>
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
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
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 - 100 of 295 matches
Mail list logo