subject:"\[openstack\-dev\] \[nova\]\[api\]"

[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 :
==
Below are the API related features for Stein. Ref -
https://etherpad.openstack.org/p/stein-nova-subteam-tracking (feel free to add
API item there if you are working or found any). NOTE: sequence order are not
the priority, they are listed as per their start date.

1. API Extensions merge work
- https://blueprints.launchpad.net/nova/+spec/api-extensions-merge-stein
-
https://review.openstack.org/#/q/project:openstack/nova+branch:master+topic:bp/api-extensions-merge-stein+status:open

- Weekly Progress: last patch has +2 and other has +A and on gate.

2. Handling a down cell
- https://blueprints.launchpad.net/nova/+spec/handling-down-cell
-
https://review.openstack.org/#/q/topic:bp/handling-down-cell+(status:open+OR+status:merged)

- Weekly Progress: tssurya has updated the patches on this. can we get this in
runway ?

3. Servers Ips non-unique network names :
-
https://blueprints.launchpad.net/nova/+spec/servers-ips-non-unique-network-names

- Spec Merged
-
https://review.openstack.org/#/q/topic:bp/servers-ips-non-unique-network-names+(status:open+OR+status:merged)

- Weekly Progress: No progress.

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: No progress.

5. Boot instance specific storage backend
-
https://blueprints.launchpad.net/nova/+spec/boot-instance-specific-storage-backend

-
https://review.openstack.org/#/q/topic:bp/boot-instance-specific-storage-backend+(status:open+OR+status:merged)

- Weekly Progress: COMPLETED

6. Add API ref guideline for body text (takashin)
- https://review.openstack.org/#/c/605628/
- Weekly Progress: Reviewed most of the patches.

Specs:
7. Detach and attach boot volumes
-
https://review.openstack.org/#/q/topic:bp/detach-boot-volume+(status:open+OR+status:merged)

- Weekly Progress: under review. Kevin has updated the spec with review comment
fix.

8. Nova API policy updates
https://blueprints.launchpad.net/nova/+spec/granular-api-policy
Spec: https://review.openstack.org/#/c/547850/
- Weekly Progress: No progress in this. first concentrating on its dependency
on 'consistent policy name' - https://review.openstack.org/#/c/606214/

10. Support deleting data volume when destroy instance(Brin Zhang)
- https://review.openstack.org/#/c/580336/
- Weekly Progress: No Progress.

Bugs:

This week Bug Progress:
https://etherpad.openstack.org/p/nova-api-weekly-bug-report

Critical: 0->0
High importance: 2->1
By Status:
New: 4->2
Confirmed/Triage: 32-> 32
In-progress: 35->36
Incomplete: 3->5
=
Total: 74->75

NOTE- There might be some bug which are not tagged as 'api' or 'api-ref', those
are not in above list. Tag such bugs so that we can keep our eyes.

-gmann

[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 bugs which needs more log for further debugging. added bug
comments.

2. Handling a down cell
- https://blueprints.launchpad.net/nova/+spec/handling-down-cell
-
https://review.openstack.org/#/q/topic:bp/handling-down-cell+(status:open+OR+status:merged)

- Weekly Progress: No progress. Need to open for stein

3. Servers Ips non-unique network names :
-
https://blueprints.launchpad.net/nova/+spec/servers-ips-non-unique-network-names

- Spec Merged
-
https://review.openstack.org/#/q/topic:bp/servers-ips-non-unique-network-names+(status:open+OR+status:merged)

- Weekly Progress: No progress. I will push code after API extensions work is
merged.

- Weekly Progress: No progress.

5. Boot instance specific storage backend
-
https://blueprints.launchpad.net/nova/+spec/boot-instance-specific-storage-backend
-
https://review.openstack.org/#/q/topic:bp/boot-instance-specific-storage-backend+(status:open+OR+status:merged)
- Weekly Progress: Code is up and it is in runway. I am adding this in my
tomorrow review list.

6. Add API ref guideline for body text (takashin)
- https://review.openstack.org/#/c/605628/
- Weekly Progress: patch is up for review. I have reviewed it to map it in more
structural way.

Specs:
7. Detach and attach boot volumes
-
https://review.openstack.org/#/q/topic:bp/detach-boot-volume+(status:open+OR+status:merged)
- Weekly Progress: under review. Kevin has updated the spec with review
comment fix.

9. Nova API cleanup
https://blueprints.launchpad.net/nova/+spec/api-consistency-cleanup
Spec: https://review.openstack.org/#/c/603969/
- Weekly Progress: No progress on this. I am thinking to keep it open till T
cycle and we keep adding more and more API cleanup in this and then discuss
that what all we can fix or not. This way we can avoid the re-iterate of API
cleanup fixes. Obviously we cannot find all API cleanup till T but it is good
to cover most of them together. Thoughts ?

10. Support deleting data volume when destroy instance(Brin Zhang)
- https://review.openstack.org/#/c/580336/
- Weekly Progress: No Progress.

Bugs:

This week Bug Progress:
https://etherpad.openstack.org/p/nova-api-weekly-bug-report

Critical: 0->0
High importance: 1->2
By Status:
New: 1->4
Confirmed/Triage: 30-> 32
In-progress: 31->35
Incomplete: 3->3
=
Total: 65->74

NOTE- There might be some bug which are not tagged as 'api' or 'api-ref', those
are not in above list. Tag such bugs so that we can keep our eyes.

-gmann

[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.
Patch is up for this https://review.openstack.org/#/c/590081/

- Discussed about simple-tenant-usage bug about value error. We need to handle
500 error for non iso8601 time format input. Bug was reported on Pike but due
to env issue as author confirmed. I also tried this on master and not
reproducible. Anyways we need to handle the 500 in this API. I will push patch
for that. : https://bugs.launchpad.net/nova/+bug/1783338

Planned Features :
==
Below are the API related features which did not make to Rocky and need to
propose for Stein. Not much progress to share on these as of now.

1. Servers Ips non-unique network names :
-
https://blueprints.launchpad.net/nova/+spec/servers-ips-non-unique-network-names

- Spec Merged
-
https://review.openstack.org/#/q/topic:bp/servers-ips-non-unique-network-names+(status:open+OR+status:merged)

- Weekly Progress: No progress. Need to open for stein

2. 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: No progress.

3. API Extensions merge work
- https://blueprints.launchpad.net/nova/+spec/api-extensions-merge-stein
-
https://review.openstack.org/#/q/project:openstack/nova+branch:master+topic:bp/api-extensions-merge-stein

- Weekly Progress: Done for Rocky, and new BP open for remaining work on this
BP. I will remove the deprecated extensions policy first which will be more
clean.

4. Handling a down cell
- https://blueprints.launchpad.net/nova/+spec/handling-down-cell
-
https://review.openstack.org/#/q/topic:bp/handling-down-cell+(status:open+OR+status:merged)

- Weekly Progress: No progress. Need to open for stein

Bugs:

This week Bug Progress:
https://etherpad.openstack.org/p/nova-api-weekly-bug-report

Critical: 0->0
High importance: 2->1
By Status:
New: 1->0
Confirmed/Triage: 30-> 32
In-progress: 34->32
Incomplete: 4->4
=
Total: 68->68

NOTE- There might be some bug which are not tagged as 'api' or 'api-ref', those
are not in above list. Tag such bugs so that we can keep our eyes.

-gmann

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 
 >  - 
 > https://review.openstack.org/#/q/project:openstack/nova+branch:master+topic:bp/api-extensions-merge-rocky
 >  
 >  - Weekly Progress: part-1 of schema merge and part-2 of server_create merge 
 > has been merged for Rocky. 1 last patch of removing the placeholder method 
 > are on gate.
 >  part-3 of view builder merge 
 > cannot make it to Rocky (7 patch up for review + 5 more to push)< Postponed 
 > this work to Stein.
 >  
 >  6. Handling a down cell 
 >  - https://blueprints.launchpad.net/nova/+spec/handling-down-cell 
 >  - 
 > https://review.openstack.org/#/q/topic:bp/handling-down-cell+(status:open+OR+status:merged)
 >  
 >  - Weekly Progress: It is difficult to make it in Rocky? matt has open 
 > comment on patch about changing the service list along with server list in 
 > single microversion which make 
 > sense. 
 > 
 > 
 > The handling down cell spec related API changes will also be postponed to 
 > Stein since the view builder merge (part-3 of API Extensions merge work) is 
 > postponed to Stein. It would be more cleaner.

Yeah, I will make sure view builder things gets in early in stein. I am going 
to push all remaining patches and make them ready for review once we have stein 
branch. 

-gmann

 > -- 
 > 
 > Regards,
 > Surya.
 >   __
 > 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] [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 Progress: part-1 of schema merge and part-2 of server_create
> merge has been merged for Rocky. 1 last patch of removing the placeholder
> method are on gate.
> part-3 of view builder merge
> cannot make it to Rocky (7 patch up for review + 5 more to push)< Postponed
> this work to Stein.
>
> 6. Handling a down cell
> - https://blueprints.launchpad.net/nova/+spec/handling-down-cell
> - https://review.openstack.org/#/q/topic:bp/handling-down-
> cell+(status:open+OR+status:merged)
> - Weekly Progress: It is difficult to make it in Rocky? matt has open
> comment on patch about changing the service list along with server list in
> single microversion which make
>sense.
>
>
The handling down cell spec related API changes will also be postponed to
Stein since the view builder merge (part-3 of API Extensions merge work)
is postponed to Stein. It would be more cleaner.

-- 

Regards,
Surya.
__
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] [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 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 etherpad-
https://etherpad.openstack.org/p/rocky-nova-priorities-tracking

1. Servers Ips non-unique network names :
-
https://blueprints.launchpad.net/nova/+spec/servers-ips-non-unique-network-names

- Spec Merged
-
https://review.openstack.org/#/q/topic:bp/servers-ips-non-unique-network-names+(status:open+OR+status:merged)

- Weekly Progress: I did not start this due to other work. This cannot make in
Rocky and will plan for Stein early.

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: COMPLETED

3. Complex anti-affinity policies:
- https://blueprints.launchpad.net/nova/+spec/complex-anti-affinity-policies
-
https://review.openstack.org/#/q/topic:bp/complex-anti-affinity-policies+(status:open+OR+status:merged)

- Weekly Progress: COMPLETED

- Weekly Progress: No progress.

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 Progress: part-1 of schema merge and part-2 of server_create merge has
been merged for Rocky. 1 last patch of removing the placeholder method are on
gate.
part-3 of view builder merge cannot
make it to Rocky (7 patch up for review + 5 more to push)< Postponed this work
to Stein.

6. Handling a down cell
- https://blueprints.launchpad.net/nova/+spec/handling-down-cell
-
https://review.openstack.org/#/q/topic:bp/handling-down-cell+(status:open+OR+status:merged)

- Weekly Progress: It is difficult to make it in Rocky? matt has open comment
on patch about changing the service list along with server list in single
microversion which make
sense.

Bugs:

Discussed about keypair quota bug. Sent separate mailing list for more
feedback[1]

This week Bug Progress:
https://etherpad.openstack.org/p/nova-api-weekly-bug-report

Critical: 0->0
High importance: 3->2
By Status:
New: 0->0
Confirmed/Triage: 29-> 30
In-progress: 36->34
Incomplete: 4->4
=
Total: 69->68

NOTE- There might be some bug which are not tagged as 'api' or 'api-ref', those
are not in above list. Tag such bugs so that we can keep our eyes.

[1] http://lists.openstack.org/pipermail/openstack-dev/2018-July/132459.html

-gmann

[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 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 etherpad- 
https://etherpad.openstack.org/p/rocky-nova-priorities-tracking 

1. Servers Ips non-unique network names : 
- 
https://blueprints.launchpad.net/nova/+spec/servers-ips-non-unique-network-names
 
- Spec Merged 
- 
https://review.openstack.org/#/q/topic:bp/servers-ips-non-unique-network-names+(status:open+OR+status:merged)
 
- Weekly Progress: I sent mail to author but no response yet.  I will push the 
code update during next week early. 

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: API patch is in gate to merge. nova client patch is 
remaining to mark this complete (Kevin mentioned he is working on that). 

3. Complex anti-affinity policies: 
- https://blueprints.launchpad.net/nova/+spec/complex-anti-affinity-policies 
- 
https://review.openstack.org/#/q/topic:bp/complex-anti-affinity-policies+(status:open+OR+status:merged)
 
- Weekly Progress: API patch is merged. nova client and 1 follow up patch is 
remaining. 

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: No progress. 

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 Progress: I pushed patches for part-2 (server_create merge). I will 
work on pushing last part-3 max by early next week. 

6. Handling a down cell 
- https://blueprints.launchpad.net/nova/+spec/handling-down-cell 
- 
https://review.openstack.org/#/q/topic:bp/handling-down-cell+(status:open+OR+status:merged)
- Weekly Progress: Code is up and matt has reviewed few patches. API subteam 
will target this BP as other BP work are almost merged. 

Bugs: 
 
Did review on in-progress bugs's patches. 

This week Bug Progress: 
Critical: 0->0 
High importance: 3->3 
By Status: 
New: 0->0 
Confirmed/Triage: 31-> 29 
In-progress: 36->36 
Incomplete: 4->4 
= 
Total: 70->69

NOTE- There might be some bug which are not tagged as 'api' or 'api-ref', those 
are not in above list. Tag such bugs so that we can keep our eyes. 

Ref: https://etherpad.openstack.org/p/nova-api-weekly-bug-report 

-gmann 





__
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] [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:
> > -
> 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)
> > <
> https://review.openstack.org/#/q/topic:bp/abort-live-migration-in-queued-status+%28status:open+OR+status:merged%29
> >
> > - Weekly Progress: Review is going and it is in nova runway this
> > week. In API office hour, we discussed about doing the compute
> > service version checks oncompute.api.py side
> > than on rpc side. Dan has point of doing it on rpc side where
> > migration status can changed to running. We decided to further
> > discussed it on patch.
> >
> >
> > This is my own defence, Dan's point seems to be that the actual rpc
> > version pin could be set to be lower than the can_send_version even when
> > the service version is new enough, so he thinks doing it in rpc is
> better.
>
> That series is all rebased now and I'm +2 up the stack until the API
> change, where I'm just +1 since I wrote the compute service version
> checking part, but I think this series is ready for wider review.
>
> --
>
> Thanks,
>
> Matt
>
> __
> 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] [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)


- Weekly Progress: Review is going and it is in nova runway this
week. In API office hour, we discussed about doing the compute
service version checks oncompute.api.py side
than on rpc side. Dan has point of doing it on rpc side where
migration status can changed to running. We decided to further
discussed it on patch.


This is my own defence, Dan's point seems to be that the actual rpc 
version pin could be set to be lower than the can_send_version even when 
the service version is new enough, so he thinks doing it in rpc is better.


That series is all rebased now and I'm +2 up the stack until the API 
change, where I'm just +1 since I wrote the compute service version 
checking part, but I think this series is ready for wider review.


--

Thanks,

Matt

__
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] [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 mentioned in last week status mail that he will continue work on this.


I failed to work on this again this week since I spent the majority of 
my week doing reviews.


--

Thanks,

Matt

__
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] [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 is in nova runway this week. In
> API office hour, we discussed about doing the compute service version
> checks on compute.api.py side than on rpc side. Dan has point of doing it
> on rpc side where migration status can changed to running. We decided to
> further discussed it on patch.


This is my own defence, Dan's point seems to be that the actual rpc version
pin could be set to be lower than the can_send_version even when the
service version is new enough, so he thinks doing it in rpc is better.

On Thu, Jul 12, 2018 at 9:15 AM Ghanshyam Mann 
wrote:

> 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.
> - Triage 1 new bug and Alex reviewed one in-progress
>
> 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 etherpad-
> https://etherpad.openstack.org/p/rocky-nova-priorities-tracking
>
> 1. Servers Ips non-unique network names :
> -
> https://blueprints.launchpad.net/nova/+spec/servers-ips-non-unique-network-names
> - Spec Merged
> -
> https://review.openstack.org/#/q/topic:bp/servers-ips-non-unique-network-names+(status:open+OR+status:merged)
> - Weekly Progress: Spec is merged. I am in contact with author about code
> update (sent email last night). If no response till this week, i will push
> the code update for this BP.
>
> 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 is in nova runway this week. In
> API office hour, we discussed about doing the compute service version
> checks on compute.api.py side than on rpc side. Dan has point of doing it
> on rpc side where migration status can changed to running. We decided to
> further discussed it on patch.
>
> 3. Complex anti-affinity policies:
> -
> https://blueprints.launchpad.net/nova/+spec/complex-anti-affinity-policies
> -
> https://review.openstack.org/#/q/topic:bp/complex-anti-affinity-policies+(status:open+OR+status:merged)
> - Weekly Progress: Good review progress. In API office hour, we discussed
> on 2 points-
>1. whether request also need to have flat format like response. IMO
> we need to have flat in both request and response. Yikun need more opinion
> on that.
>
>2. naming fields to policy_* as we are moving these new fields in
> flat format. I like to have policy_* for clear understanding of attributes
> by their name. This is not concluded
>  and alex will give feedback on patch.
>Discussion is on patch for consensus on naming things.
>
> 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 mentioned in last week status mail that he will
> continue work on this.
>
> 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 Progress: I did not get chance to push more patches on this. I
> will target this one before next office hour.
>
> 6. Handling a down cell
>  - https://blueprints.launchpad.net/nova/+spec/handling-down-cell
>  -  Spec mriedem  mentioned in previous week ML is merged -
> https://review.openstack.org/#/c/557369/
>
> Bugs:
> 
> Triage 1 new bug and Alex reviewed one in-progress. I did not do my home
> work of doing review on in-progress patches (i will accommodate that in
> next week)
>
> This week Bug Progress:
> Critical: 0->0
> High importance: 2->3
> By Status:
> New:  1->0
> Confirmed/Triage: 30-> 31
> In-progress: 36->36
> Incomplete: 4->4
> =
> Total: 70->71
>
> NOTE- There might be some bug which are not tagged as 'api' or 'api-ref',
> those are not in above list. Tag such bugs so that we can keep our eyes.
>
> Ref: https://etherpad.openstack.org/p/nova-api-weekly-bug-report
>
> -gmann
>
>
>
>
>
> __
> OpenStack Development Mailing List (not for usage questi

[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.
- Triage 1 new bug and Alex reviewed one in-progress

1. Servers Ips non-unique network names :
-
https://blueprints.launchpad.net/nova/+spec/servers-ips-non-unique-network-names

- Spec Merged
-
https://review.openstack.org/#/q/topic:bp/servers-ips-non-unique-network-names+(status:open+OR+status:merged)

- Weekly Progress: Spec is merged. I am in contact with author about code
update (sent email last night). If no response till this week, i will push the
code update for this BP.

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 is in nova runway this week. In API
office hour, we discussed about doing the compute service version checks on
compute.api.py side than on rpc side. Dan has point of doing it on rpc side
where migration status can changed to running. We decided to further discussed
it on patch.

- Weekly Progress: Good review progress. In API office hour, we discussed on 2
points-
1. whether request also need to have flat format like response. IMO we
need to have flat in both request and response. Yikun need more opinion on
that.

2. naming fields to policy_* as we are moving these new fields in flat
format. I like to have policy_* for clear understanding of attributes by their
name. This is not concluded
and alex will give feedback on patch.
Discussion is on patch for consensus on naming things.

- Weekly Progress: mriedem mentioned in last week status mail that he will
continue work on this.

- Weekly Progress: I did not get chance to push more patches on this. I will
target this one before next office hour.

6. Handling a down cell
- https://blueprints.launchpad.net/nova/+spec/handling-down-cell
- Spec mriedem mentioned in previous week ML is merged -
https://review.openstack.org/#/c/557369/

Bugs:

Triage 1 new bug and Alex reviewed one in-progress. I did not do my home work
of doing review on in-progress patches (i will accommodate that in next week)

This week Bug Progress:
Critical: 0->0
High importance: 2->3
By Status:
New: 1->0
Confirmed/Triage: 30-> 31
In-progress: 36->36
Incomplete: 4->4
=
Total: 70->71

NOTE- There might be some bug which are not tagged as 'api' or 'api-ref', those
are not in above list. Tag such bugs so that we can keep our eyes.

Ref: https://etherpad.openstack.org/p/nova-api-weekly-bug-report

-gmann

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 etherpad-https://etherpad.openstack.org/p/rocky-nova-priorities-tracking  


Oh yeah, getting agreement on the direction of the "handling a down 
cell" spec is going to be important and we don't have much time to get 
this done now either (~3 weeks).


https://review.openstack.org/#/c/557369/

--

Thanks,

Matt

__
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] [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 another +2 -https://review.openstack.org/#/c/558125/
-https://review.openstack.org/#/q/topic:bp/servers-ips-non-unique-network-names+(status:open+OR+status:merged)
- Weekly Progress: On Hold. Waiting for spec update to merge first.

I've poked dansmith to approve this. However, the author (or someone)
should start working on the code changes since it's a pretty
straight-forward change and we don't have much time left in the cycle
for this.

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: Code is up for review. No Review last week.

This is in the runways queue so it should be coming up in the next slot.

3. Complex anti-affinity policies:
-https://blueprints.launchpad.net/nova/+spec/complex-anti-affinity-policies
-https://review.openstack.org/#/q/topic:bp/complex-anti-affinity-policies+(status:open+OR+status:merged)
- Weekly Progress: Code is up for review. Few reviews done .

This is currently in a runways slot and has had quite a bit of review
this week. It's not going to be done this week but hopefully we can get
it all merged next week (there aren't any major issues that I foresee at
this point after having gone through the full series yesterday).

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: Waiting to hear from mriedem about his WIP on base patch -https://review.openstack.org/#/c/569649/3

Yeah this is on my TODO list. I was waiting for the spec to merge before
starting in on the API changes, and have just been busy with other
stuff. I'll try to get the API changes done next week.

Thanks,

Matt

[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 this week:
- This was the first office hours after long time.
- Collected the API related BPs on etherpad (rocky-nova-priorities-tracking)
for review.
- Created the weekly bug report etherpad and we will track down the number
there.
- Home work for API subteam to at least review 3 in-progress bug patches.
- From next week we will do some online bug triage/review or discussion around
ongoing BP.

1. Servers Ips non-unique network names :
-
https://blueprints.launchpad.net/nova/+spec/servers-ips-non-unique-network-names
- Spec Update need another +2 - https://review.openstack.org/#/c/558125/
-
https://review.openstack.org/#/q/topic:bp/servers-ips-non-unique-network-names+(status:open+OR+status:merged)

- Weekly Progress: On Hold. Waiting for spec update to merge first.

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: Code is up for review. No Review last week.

- Weekly Progress: Code is up for review. Few reviews done .

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: Waiting to hear from mriedem about his WIP on base patch
- https://review.openstack.org/#/c/569649/3

- Weekly Progress: Good progress. 1/3 part is merged.

Bugs:

We discussed in office hour to start reviewing the in-progress bugs and
minimize the number. From next week, I will show the weekly progress on the
bug numbers.

Current Bugs Status:
Critical bug 0
High importance bugs 2
Status:
New bugs 0
Confirmed/Triage 30
In-progress bugs 36
Incomplete:4
=
Total:70

NOTE- There might be some bug which are not tagged as 'api' or 'api-ref', those
are not in above list. Tag such bugs so that we can keep our eyes.

Ref: https://etherpad.openstack.org/p/nova-api-weekly-bug-report

-gmann

[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 (partial)
https://blueprints.launchpad.net/nova/+spec/api-ref-in-rst

*2: Convert API Reference to RST and host it in the Nova tree (Ocata)
https://blueprints.launchpad.net/nova/+spec/api-ref-in-rst-ocata

*3: Convert API Reference to RST and host it in the Nova tree (Pike)
https://blueprints.launchpad.net/nova/+spec/api-ref-in-rst-pike

*4: NovaAPIRef
https://wiki.openstack.org/wiki/NovaAPIRef


I submitted the following patches
to complete parameter and example verification in "Servers" APIs.

api-ref: Parameter verification for servers.inc
https://review.openstack.org/#/c/528201/

api-ref: Example verification for servers.inc
https://review.openstack.org/#/c/529520/

Regards,
Takashi Natsume
NTT Software Innovation Center
E-mail: natsume.taka...@lab.ntt.co.jp


__
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] [nova][api] why need PUT /servers/{server_id}/metadata/{key} ?

2017-09-20 Thread Chen CH Ji

yes, I didn't go to that detail and missed the delete flag , that's exactly
what I am looking for, which is a little bit confusing...
Thanks for the info for know this...

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82451493
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Matt Riedemann 
To: openstack-dev@lists.openstack.org
Date:   09/20/2017 09:15 PM
Subject:    Re: [openstack-dev] [nova][api] why need
PUT /servers/{server_id}/metadata/{key} ?



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)
>
https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_nova_blob_master_nova_api_openstack_compute_server-5Fmetadata.py-23L80&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0&m=DSFbFb2bqll3hC8yrttkW6teiZtFod4XBQIC8jauVlE&s=1S1y1O0K2KOZgQd1wmx5_P8IhzNqf-i6d4IThx0yLrI&e=

>
> looks like it's identical to
> PUT /servers/{server_id}/metadata
>
> why we need this API or it should be something like
>
> PUT /servers/{server_id}/metadata/{key}but we only accept a value to
> modify the meta given by {key} in the API side?
>
> Best Regards!
>
> Kevin (Chen) Ji 纪 晨
>
> Engineer, zVM Development, CSTL
> Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com
> Phone: +86-10-82451493
> Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian
> District, Beijing 100193, PRC
>
>
>
__
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
>
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0&m=DSFbFb2bqll3hC8yrttkW6teiZtFod4XBQIC8jauVlE&s=EMTJozBhxl7wXNyB7emtzxXMkegVXKWV6Ko8E2uhsPs&e=

>

This API is a bit confusing, and the code is too since it all goes down
to some common code, and I think you're missing the 'delete' flag:

https://urldefense.proofpoint.com/v2/url?u=https-3A__github.com_openstack_nova_blob_5bf1bb47c7e17c26592a699d07c2faa59d98bfb8_nova_compute_api.py-23L3830&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0&m=DSFbFb2bqll3hC8yrttkW6teiZtFod4XBQIC8jauVlE&s=AMY4S8Ux0G78V_Nu2H17kNivICkiKErqDzPj0eFsUgg&e=


If delete=False, as it is in this case, we only add/update the existing
metadata with the new metadata from the request body. If delete=True,
then we overwrite the instance metadata with whatever is in the request.

Does that answer your question?

This API is problematic and we have bugs against it since it's not
atomic, i.e. two concurrent requests will overwrite one of them. We
should really have a generation ID or etag on this data to be sure it's
atomically updated.

--

Thanks,

Matt

__
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
https://urldefense.proofpoint.com/v2/url?u=http-3A__lists.openstack.org_cgi-2Dbin_mailman_listinfo_openstack-2Ddev&d=DwIGaQ&c=jf_iaSHvJObTbx-siA1ZOg&r=8sI5aZT88Uetyy_XsOddbPjIiLSGM-sFnua3lLy2Xr0&m=DSFbFb2bqll3hC8yrttkW6teiZtFod4XBQIC8jauVlE&s=EMTJozBhxl7wXNyB7emtzxXMkegVXKWV6Ko8E2uhsPs&e=




__
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] [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

--

Thanks,

Matt

__
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] [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
>> honor the whole body (body['meta'] in the code)
>>
>> https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/server_metadata.py#L80
>>
>> looks like it's identical to
>> PUT /servers/{server_id}/metadata
>>
>> why we need this API or it should be something like
>>
>> PUT /servers/{server_id}/metadata/{key}but we only accept a value to
>> modify the meta given by {key} in the API side?
>>
>> Best Regards!
>>
>> Kevin (Chen) Ji 纪 晨
>>
>> Engineer, zVM Development, CSTL
>> Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com
>> Phone: +86-10-82451493
>> Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
>> Beijing 100193, PRC
>>
>>
>> __
>> 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
>>
>
> This API is a bit confusing, and the code is too since it all goes down to
> some common code, and I think you're missing the 'delete' flag:
>
> https://github.com/openstack/nova/blob/5bf1bb47c7e17c26592a699d07c2faa59d98bfb8/nova/compute/api.py#L3830
>
> If delete=False, as it is in this case, we only add/update the existing
> metadata with the new metadata from the request body. If delete=True, then
> we overwrite the instance metadata with whatever is in the request.
>
> Does that answer your question?
>
> This API is problematic and we have bugs against it since it's not atomic,
> i.e. two concurrent requests will overwrite one of them. We should really
> have a generation ID or etag on this data to be sure it's atomically
> updated.
>

I think confusion is for updating the single metadata item by key [1].
and whether it has bug to allow update more than 1 item. But It does
not as schema restrict request body to allow only 1 item in body.

Which means update metadata item by key only allow to update that key
value only.

Also we do have tests to verify that:
https://github.com/openstack/nova/blob/5bf1bb47c7e17c26592a699d07c2faa59d98bfb8/nova/tests/unit/api/openstack/compute/test_server_metadata.py#L529


..1 
https://developer.openstack.org/api-ref/compute/#create-or-update-metadata-item

> --
>
> Thanks,
>
> Matt
>
> __
> 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] [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 whole body (body['meta'] in the code)
>> https://github.com/openstack/nova/blob/master/nova/api/opens
>> tack/compute/server_metadata.py#L80
>>
>> looks like it's identical to
>> PUT /servers/{server_id}/metadata
>>
>> why we need this API or it should be something like
>>
>> PUT /servers/{server_id}/metadata/{key}but we only accept a value to
>> modify the meta given by {key} in the API side?
>>
>> Best Regards!
>>
>> Kevin (Chen) Ji 纪 晨
>>
>> Engineer, zVM Development, CSTL
>> Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com
>> Phone: +86-10-82451493
>> Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
>> Beijing 100193, PRC
>>
>>
>> 
>> __
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscrib
>> e
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
> This API is a bit confusing, and the code is too since it all goes down to
> some common code, and I think you're missing the 'delete' flag:
>
> https://github.com/openstack/nova/blob/5bf1bb47c7e17c26592a6
> 99d07c2faa59d98bfb8/nova/compute/api.py#L3830
>
> If delete=False, as it is in this case, we only add/update the existing
> metadata with the new metadata from the request body. If delete=True, then
> we overwrite the instance metadata with whatever is in the request.
>
> Does that answer your question?
>
> This API is problematic and we have bugs against it since it's not atomic,
> i.e. two concurrent requests will overwrite one of them. We should really
> have a generation ID or etag on this data to be sure it's atomically
> updated.


 is there any use-case that people update server's metadata such frequently?


>
> --
>
> Thanks,
>
> Matt
>
>
> __
> 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] [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)

https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/server_metadata.py#L80

looks like it's identical to
PUT /servers/{server_id}/metadata

why we need this API or it should be something like

PUT /servers/{server_id}/metadata/{key}but we only accept a value to 
modify the meta given by {key} in the API side?


Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com
Phone: +86-10-82451493
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian 
District, Beijing 100193, PRC



__
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



This API is a bit confusing, and the code is too since it all goes down 
to some common code, and I think you're missing the 'delete' flag:


https://github.com/openstack/nova/blob/5bf1bb47c7e17c26592a699d07c2faa59d98bfb8/nova/compute/api.py#L3830

If delete=False, as it is in this case, we only add/update the existing 
metadata with the new metadata from the request body. If delete=True, 
then we overwrite the instance metadata with whatever is in the request.


Does that answer your question?

This API is problematic and we have bugs against it since it's not 
atomic, i.e. two concurrent requests will overwrite one of them. We 
should really have a generation ID or etag on this data to be sure it's 
atomically updated.


--

Thanks,

Matt

__
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] [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)
> https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/server_metadata.py#L80

Schema restrict to 1 item in body
- 
https://github.com/openstack/nova/blob/5bf1bb47c7e17c26592a699d07c2faa59d98bfb8/nova/api/openstack/compute/schemas/server_metadata.py#L32

User will not be able to pass more than 1 meta item in this API. Does
not it work that way or you are able to pass more than 1 key in body ?


>
> looks like it's identical to
> PUT /servers/{server_id}/metadata
>
> why we need this API or it should be something like
>
> PUT /servers/{server_id}/metadata/{key} but we only accept a value to modify
> the meta given by {key} in the API side?
>
> Best Regards!
>
> Kevin (Chen) Ji 纪 晨
>
> Engineer, zVM Development, CSTL
> Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com
> Phone: +86-10-82451493
> Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
> Beijing 100193, PRC
>
>
> __
> 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
>

-gmann

__
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] [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)
https://github.com/openstack/nova/blob/master/nova/api/openstack/compute/server_metadata.py#L80

looks like it's identical to
PUT /servers/{server_id}/metadata

why we need this API or it should be something like

PUT /servers/{server_id}/metadata/{key} but we only accept a value to
modify the meta given by {key} in the API side?

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82451493
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC
__
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] [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 means that
>> reject any invalid query parameters and return HTTPBadRequest 400 to
>> the user.
>> * use the marco function 'single_param' to declare the specific query
>> parameter only support single value. For example, the 'marker'
>> parameters for the pagination actually only one value is the valid. If
>> the user specific multiple values "marker=1&marker=2", the validation
>> will return 400 to the user.
>>
>> Currently there is patch related to this:
>> https://review.openstack.org/#/c/459483/13/nova/api/openstack/compute/schemas/server_migrations.py
>>
>>
>> So my question is:
>> Are we all good with this strict validation in all the future
>> microversion?
>>
>> I didn't remember we explicit agreement this at somewhere, just want
>> to double check this is the direction everybody want to go.
>>
>> Thanks
>> Alex
>>
>>
>> __
>>
>> 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
>>
> 
> I think this is fine and makes sense for new microversions. The spec for
> consistent query parameter validation does talk about it a bit:
> 
> https://specs.openstack.org/openstack/nova-specs/specs/ocata/implemented/consistent-query-parameters-validation.html#proposed-change
> 
> 
> "The behaviour additionalProperties as below:
> 
> * When the value of additionalProperties is True means the extra query
> parameters are allowed. But those extra query parameters will be
> stripped out.
> * When the value of additionalProperties is False means the extra query
> aren’t allowed.
> 
> The value of additionalProperties will be True until we decide to
> restrict the parameters in the future, and it will be changed with new
> microversion."
> 
> I don't see a point in allowing someone to specify a query parameter
> multiple times if we only pick the first one from the list and use that.

Agreed. The point of doing strict validation and returning a 400 is to
help the user eliminate bugs in their program. If they specified marker
twice either they thought it did something, or they made a mistake. Both
are wrong. When we are silent on that front it means they may not be
getting the behavior they were expecting, which hurts their experience
with the API.

-Sean

-- 
Sean Dague
http://dague.net

__
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] [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 'additionalProperties=False' in the schema, it means that reject
>> any invalid query parameters and return HTTPBadRequest 400 to the user.
>> * use the marco function 'single_param' to declare the specific query
>> parameter only support single value. For example, the 'marker' parameters
>> for the pagination actually only one value is the valid. If the user
>> specific multiple values "marker=1&marker=2", the validation will return 400
>> to the user.
>>
>> Currently there is patch related to this:
>>
>> https://review.openstack.org/#/c/459483/13/nova/api/openstack/compute/schemas/server_migrations.py
>>
>> So my question is:
>> Are we all good with this strict validation in all the future
>> microversion?
>>
>> I didn't remember we explicit agreement this at somewhere, just want to
>> double check this is the direction everybody want to go.
>>
>> Thanks
>> Alex
>>
>>
>> __
>> 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
>>
>
> I think this is fine and makes sense for new microversions. The spec for
> consistent query parameter validation does talk about it a bit:
>
> https://specs.openstack.org/openstack/nova-specs/specs/ocata/implemented/consistent-query-parameters-validation.html#proposed-change
>
> "The behaviour additionalProperties as below:
>
> * When the value of additionalProperties is True means the extra query
> parameters are allowed. But those extra query parameters will be stripped
> out.
> * When the value of additionalProperties is False means the extra query
> aren’t allowed.
>
> The value of additionalProperties will be True until we decide to restrict
> the parameters in the future, and it will be changed with new microversion."
>
> I don't see a point in allowing someone to specify a query parameter
> multiple times if we only pick the first one from the list and use that.
>
> There are certain query parameters that we allow multiple instances of, for
> sorting I believe. But for other things like filtering restricting to 1
> should be fine, and using additionalProperties=False should also be fine on
> new microversions. For example, if we allow additional properties, someone
> could type the parameter name incorrectly and we'd just ignore it. With
> strict validation, we'll return a 400 which should be clear to the end user
> that what they requested as invalid and they need to fix it on their end.

Yea, strict validation is always good and makes interface hard to use
wrongly. Starting strict validation on query param with microversion
is nice way but yes we cannot do that without microversion.

+1 on that direction.

>
> --
>
> Thanks,
>
> Matt
>
> __
> 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] [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 HTTPBadRequest 400 to the 
user.
* use the marco function 'single_param' to declare the specific query 
parameter only support single value. For example, the 'marker' 
parameters for the pagination actually only one value is the valid. If 
the user specific multiple values "marker=1&marker=2", the validation 
will return 400 to the user.


Currently there is patch related to this:
https://review.openstack.org/#/c/459483/13/nova/api/openstack/compute/schemas/server_migrations.py

So my question is:
Are we all good with this strict validation in all the future microversion?

I didn't remember we explicit agreement this at somewhere, just want to 
double check this is the direction everybody want to go.


Thanks
Alex


__
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



I think this is fine and makes sense for new microversions. The spec for 
consistent query parameter validation does talk about it a bit:


https://specs.openstack.org/openstack/nova-specs/specs/ocata/implemented/consistent-query-parameters-validation.html#proposed-change

"The behaviour additionalProperties as below:

* When the value of additionalProperties is True means the extra query 
parameters are allowed. But those extra query parameters will be 
stripped out.
* When the value of additionalProperties is False means the extra query 
aren’t allowed.


The value of additionalProperties will be True until we decide to 
restrict the parameters in the future, and it will be changed with new 
microversion."


I don't see a point in allowing someone to specify a query parameter 
multiple times if we only pick the first one from the list and use that.


There are certain query parameters that we allow multiple instances of, 
for sorting I believe. But for other things like filtering restricting 
to 1 should be fine, and using additionalProperties=False should also be 
fine on new microversions. For example, if we allow additional 
properties, someone could type the parameter name incorrectly and we'd 
just ignore it. With strict validation, we'll return a 400 which should 
be clear to the end user that what they requested as invalid and they 
need to fix it on their end.


--

Thanks,

Matt

__
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] [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 marco function 'single_param' to declare the specific query
parameter only support single value. For example, the 'marker' parameters
for the pagination actually only one value is the valid. If the user
specific multiple values "marker=1&marker=2", the validation will return
400 to the user.

Currently there is patch related to this:
https://review.openstack.org/#/c/459483/13/nova/api/openstack/compute/schemas/server_migrations.py

So my question is:
Are we all good with this strict validation in all the future microversion?

I didn't remember we explicit agreement this at somewhere, just want to
double check this is the direction everybody want to go.

Thanks
Alex
__
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] [nova][api] quota-class-show not sync toquota-show

2017-04-12 Thread Chen CH Ji

ok, thanks for the info,  I will submit the spec and wait for more response
from the spec

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82451493
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC



From:   Lance Bragstad 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   04/12/2017 03:09 AM
Subject:    Re: [openstack-dev] [nova][api] quota-class-show not sync to
quota-show





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 the entire quota-class API directly.


  I had a spec proposed to deprecate the os-quota-class-sets API [1] but it
  was abandoned since we discussed it at the Pike PTG and decided we would
  just leave it alone until Nova was getting limits information from
  Keystone [2].

FWIW - in addition to merging the conceptual document [0], Sean recently
proposed the limits interface [1] for the keystone bits.

[0]
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/unified-limits.htm
[1] https://review.openstack.org/#/c/455709/


  I think the reason we probably missed this API was because of the really
  roundabout way that the information is provided in the response. It calls
  the quota engine driver [3] to get the class quotas. For the DB driver if
  nothing is overridden then nothing comes back here [4]. And the resources
  in the quota driver have a default property which is based on the config
  options [5]. So we'll return quotas on floating_ips and other proxy
  resources simply because of how abstract this all is.

  To fix it, the os-quota-class-sets API would have to maintain a blacklist
  of resources to exclude from the response, like what we do for limits
  [6].

  So yeah, I guess we'd need a new spec and microversion for this.

  [1] https://review.openstack.org/#/c/411035/
  [2] https://review.openstack.org/#/c/440815/
  [3]
  
https://github.com/openstack/nova/blob/15.0.0/nova/api/openstack/compute/quota_classes.py#L67

  [4] https://github.com/openstack/nova/blob/15.0.0/nova/quota.py#L92
  [5] https://github.com/openstack/nova/blob/15.0.0/nova/quota.py#L1069
  [6]
  
https://github.com/openstack/nova/blob/15.0.0/nova/api/openstack/compute/views/limits.py#L20


  --

  Thanks,

  Matt


  __

  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 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] [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 the entire quota-class API directly.
>>
>>
> I had a spec proposed to deprecate the os-quota-class-sets API [1] but it
> was abandoned since we discussed it at the Pike PTG and decided we would
> just leave it alone until Nova was getting limits information from Keystone
> [2].
>

FWIW - in addition to merging the conceptual document [0], Sean recently
proposed the limits interface [1] for the keystone bits.

[0]
http://specs.openstack.org/openstack/keystone-specs/specs/keystone/ongoing/unified-limits.htm
[1] https://review.openstack.org/#/c/455709/


>
> I think the reason we probably missed this API was because of the really
> roundabout way that the information is provided in the response. It calls
> the quota engine driver [3] to get the class quotas. For the DB driver if
> nothing is overridden then nothing comes back here [4]. And the resources
> in the quota driver have a default property which is based on the config
> options [5]. So we'll return quotas on floating_ips and other proxy
> resources simply because of how abstract this all is.
>
> To fix it, the os-quota-class-sets API would have to maintain a blacklist
> of resources to exclude from the response, like what we do for limits [6].
>
> So yeah, I guess we'd need a new spec and microversion for this.
>
> [1] https://review.openstack.org/#/c/411035/
> [2] https://review.openstack.org/#/c/440815/
> [3] https://github.com/openstack/nova/blob/15.0.0/nova/api/opens
> tack/compute/quota_classes.py#L67
> [4] https://github.com/openstack/nova/blob/15.0.0/nova/quota.py#L92
> [5] https://github.com/openstack/nova/blob/15.0.0/nova/quota.py#L1069
> [6] https://github.com/openstack/nova/blob/15.0.0/nova/api/opens
> tack/compute/views/limits.py#L20
>
> --
>
> Thanks,
>
> Matt
>
>
> __
> 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] [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 os-quota-class-sets API [1] but 
it was abandoned since we discussed it at the Pike PTG and decided we 
would just leave it alone until Nova was getting limits information from 
Keystone [2].


I think the reason we probably missed this API was because of the really 
roundabout way that the information is provided in the response. It 
calls the quota engine driver [3] to get the class quotas. For the DB 
driver if nothing is overridden then nothing comes back here [4]. And 
the resources in the quota driver have a default property which is based 
on the config options [5]. So we'll return quotas on floating_ips and 
other proxy resources simply because of how abstract this all is.


To fix it, the os-quota-class-sets API would have to maintain a 
blacklist of resources to exclude from the response, like what we do for 
limits [6].


So yeah, I guess we'd need a new spec and microversion for this.

[1] https://review.openstack.org/#/c/411035/
[2] https://review.openstack.org/#/c/440815/
[3] 
https://github.com/openstack/nova/blob/15.0.0/nova/api/openstack/compute/quota_classes.py#L67

[4] https://github.com/openstack/nova/blob/15.0.0/nova/quota.py#L92
[5] https://github.com/openstack/nova/blob/15.0.0/nova/quota.py#L1069
[6] 
https://github.com/openstack/nova/blob/15.0.0/nova/api/openstack/compute/views/limits.py#L20


--

Thanks,

Matt

__
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] [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 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, quota-class-show still have those output, should we use 2.35 to
> fix this bug or add a new microversion or because os-quota-class-sets is
> about to deprecate, we can let it be ? Thanks
>
> DEBUG (session:347) REQ: curl -g -i -X GET http://192.168.123.10:8774/v2.
> 1/os-quota-class-sets/1 -H "OpenStack-API-Version: compute 2.41" -H
> "User-Agent: python-novaclient" -H "Accept: application/json" -H
> "X-OpenStack-Nova-API-Version: 2.41" -H "X-Auth-Token: {SHA1}
> 5008bb2787a9548d65b063f4db2525b4e3bf7163"
>
> RESP BODY: {"quota_class_set": {"injected_file_content_bytes": 10240,
> "metadata_items": 128, "ram": 51200, "floating_ips": 10, "key_pairs": 100,
> "id": "1", "instances": 10, "security_group_rules": 20, "injected_files":
> 5, "cores": 20, "fixed_ips": -1, "injected_file_path_bytes": 255,
> "security_groups": 10}}
>
> Best Regards!
>
> Kevin (Chen) Ji 纪 晨
>
> Engineer, zVM Development, CSTL
> Notes: Chen CH Ji/China/IBM@IBMCN Internet: jiche...@cn.ibm.com
> Phone: +86-10-82451493 <010%208245%201493>
> Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
> Beijing 100193, PRC
>
> __
> 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] [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, quota-class-show still have those output, should we use 2.35 to
fix this bug or add a new microversion or because os-quota-class-sets is
about to deprecate, we can let it be ? Thanks

DEBUG (session:347) REQ: curl -g -i -X GET
http://192.168.123.10:8774/v2.1/os-quota-class-sets/1 -H
"OpenStack-API-Version: compute 2.41" -H "User-Agent: python-novaclient" -H
"Accept: application/json" -H "X-OpenStack-Nova-API-Version: 2.41" -H
"X-Auth-Token: {SHA1}5008bb2787a9548d65b063f4db2525b4e3bf7163"

RESP BODY: {"quota_class_set": {"injected_file_content_bytes": 10240,
"metadata_items": 128, "ram": 51200, "floating_ips": 10, "key_pairs": 100,
"id": "1", "instances": 10, "security_group_rules": 20, "injected_files":
5, "cores": 20, "fixed_ips": -1, "injected_file_path_bytes": 255,
"security_groups": 10}}

Best Regards!

Kevin (Chen) Ji 纪 晨

Engineer, zVM Development, CSTL
Notes: Chen CH Ji/China/IBM@IBMCN   Internet: jiche...@cn.ibm.com
Phone: +86-10-82451493
Address: 3/F Ring Building, ZhongGuanCun Software Park, Haidian District,
Beijing 100193, PRC
__
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] [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 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, http.rst of api-wg guideline[2] requires HEAD instead.
>>
>> So there are two questions.
>> 1. Why the part of tags.rst is different from http.rst?
>> I checked the review history of
>> https://review.openstack.org/#/c/155620/ which have added the part,
>> but I could not find the reason.
>> 2. trait should follow tags.rst? or http.rst?
>
>
> This is from the http.rst guideline in the API-WG:
>
> "TODO: HEAD is weird in a bunch of our wsgi frameworks and you don't have
> access to it. Figure out if there is anything useful there."
>
> and frankly, I tend to agree with the above statement. I'd say use GET for
> exists checking.

Ed submitted a LP about this as
https://bugs.launchpad.net/openstack-api-wg/+bug/1677360
On the LP, Chris did put a nice comment like:

  "HEAD is a shortcut to use when you don't want to pay the price of GET"

We can use HEAD without receiving a response body to check a resource
existence if the response body could be huge on GET.
In this case, IIUC trait API doesn't return a response body when
getting the detail of resource, that would be the same as a resource
existence check.
Both GET and HEAD could be acceptable in this case.
I was confused when seeing the conflict between tags.rst and http.rst,
I will try it clear later on api-wg guideline.

Thanks

__
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] [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 checking trait existence.
On the other hand, http.rst of api-wg guideline[2] requires HEAD instead.

So there are two questions.
1. Why the part of tags.rst is different from http.rst?
I checked the review history of
https://review.openstack.org/#/c/155620/ which have added the part,
but I could not find the reason.
2. trait should follow tags.rst? or http.rst?


This is from the http.rst guideline in the API-WG:

"TODO: HEAD is weird in a bunch of our wsgi frameworks and you don't 
have access to it. Figure out if there is anything useful there."


and frankly, I tend to agree with the above statement. I'd say use GET 
for exists checking.


Best,
-jay

__
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] [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, http.rst of api-wg guideline[2] requires HEAD instead.

So there are two questions.
1. Why the part of tags.rst is different from http.rst?
I checked the review history of
https://review.openstack.org/#/c/155620/ which have added the part,
but I could not find the reason.
2. trait should follow tags.rst? or http.rst?

Any comments are welcome.

Thanks

---
[1]: 
https://github.com/openstack/api-wg/blob/master/guidelines/tags.rst#addressing-individual-tags
[2]: 
https://github.com/openstack/api-wg/blob/master/guidelines/http.rst#http-methods

__
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] [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 session on that earlier in the week so John was reporting the 
highlights of that session. There is some general consensus on the 
approach, but the details are going to be hashed out in the API WG spec:


https://review.openstack.org/#/c/386555

The goal for Ocata is just finding agreement in the API WG spec and 
getting that merged so we can start focusing on implementation in Pike.


Proxy APIs
--

We deprecated a lot of the proxy APIs in the 2.36 microversion in 
Newton, but there are still other proxy APIs left in Nova. Some are 
straight-forward and we've already approved specs to clean them up, like 
the image metadata proxy extension. But others like multinic and 
floating IP actions and security group handling in server create 
requests are more complicated so we've elected to defer those topics for 
Ocata as we have higher priorities.


API extension folding
-

sdague started doing some of this in Newton and while it's fairly 
mechanical it's not trivial work to do correctly or review, so it's 
probably the type of thing that's going to be deferred to Pike.


API docs


We'll continue working the api-ref cleanups. We now have docs generated 
for the sample policy file in the nova devref. The policy.yaml docs 
could use descriptions for each policy, but we said we wouldn't start on 
that until after the config option cleanup effort is done.


General loose ends and new ideas


There are several random API impacting specs up for review. We didn't 
discuss many of these in great detail. The thing to take away from this 
is we have several approved blueprints already that impact the REST API 
and will require microversions, so we already have plenty to do (and 
review). I'll also make a side note that some of the approved blueprints 
don't have code up for review yet which is concerning.


Some new things that we wanted to focus on for Ocata was json schema 
validation of query parameters, which is something we need to restrict 
server sort/filter parameters. Today you can sort on anything including 
joined tables to the instances table. We need to restrict this in 
general as it's a security issue, but also because of it's impact on 
cells v2 and how we're going to be handling querying instances across 
multiple cells. Alex Xu is working on the spec for the json schema 
validation and Kevin Zheng is working on the fixes.


Priorities
--

Not really discussed in the session, but this is the rough list if 
you're keeping track at home:


- query parameter validation
- restricting server sort/filter parameters
- agree on and get the API WG capabilities spec approved

--

Thanks,

Matt Riedemann


__
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] [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 efforts in Cinder [1][2] and Glance [3].
>
> To be clear, we're looking at exposing both traits and capabilities in
> Nova. This puts us in a weird spot where I think our concept of traits
> aligns with cinders capabilities, but I don't see any match for the
> Nova concept of capabilities. So I'm still open to naming suggestions
> but I think capabilities most accurately describes what it is. Dean
> has it right, I think, that what we really have are 'api capabilities'
> and 'host capabilities'. But people will end up just using
> 'capabilities' and cause confusion.

I think I need to clarify this a bit. In Cinder we're already having a
resource called "capabilities". It returns possible hardware features of
a particular volume backend, like compression or QoS support. This is
returned in a form similar to Glance's Metadata Catalog API (aka
Graffiti), so should be easily consumable by Horizon to produce a
structured UI letting admin define meaningful volume type metadata that
will enable particular backend options. As it's based on internal host
and backend names, it's rather admin-facing API. This is what in current
Nova's definition would be called "traits", right?

Now what we're looking to also expose is possible actions per
deployment, volume type, or maybe even a particular volume. An API that
will make answers to questions like "can I create a volume backup in
this cloud?", "can volumes of this type be included in consistency
groups?" easily discoverable. These are more like Nova's "capabilities".

>> If these are truly the same concepts being discussed across projects,
>> it would be great to see consistency in the APIs and have the
>> projects come together under a new guideline. I encourage the
>> projects and people to propose such a guideline and for someone to
>> step up and champion it. Seems like good fodder for a design session
>> proposal at the upcoming summit.
>
> Here's what all of these different things look like to me:
>
> Cinder is looking to expose hardware capabilities. This pretty closely
> aligns with what traits are intending to do in Nova. This answers the
> question of "can I create a resource that needs/does X in this
> deployment?" However in Nova we ultimately want users to be able to
> specify which traits they want for their instance. That may be
> embedded in a flavor or arbitrarily specified in the request but a
> trait is not implicitly available to all resources like it seems it is
> in Cinder. We assume there could be a heterogeneous environment so
> without requesting a trait there's no guarantee of getting it.

Requesting "traits" in Cinder is still based on an admin-defined volume
types and there are no plans to change that yet, so I think that's one
of the main differences - in Nova's case "traits" API must be user-facing.

> Nova capabilities are intended to answer the question of "as user Y
> with resource X what can I do with it?" This is dependent on user
> authorization, hardware "traits" where the resource lives, and service
> version. I didn't see an analog to this in any of the proposals below.
> And one major difference between this and the other proposals is that,
> if possible, we would like the response to map to the API action that
> will perform that capability. So if a user can perform a resize on
> their instance the response might include 'POST
> .../servers//action -d resize' or whatever form we come up with.

Yup, that's basically what [1] wants to implement in Cinder. I think we
should hold up this patch until either we come up with consistent
cross-project solution, or agree that all the projects should go their
own way on this topic.

> The Glance concept of value discovery maps closely to what Nova
> capabilities are in intent in that it answers the question of "what
> can I do in this API request that will be valid?" But the scope is
> completely different in that it doesn't answer the question of which
> API requests can be made, just what values can be used in this
> specific call.
>
>
> Given the above I find that I don't have the imagination required to
> consolidate those into a consistent API concept that can be shared
> across projects. Cinder capabilities and Nova traits could potentially
> work, but the rest seem too different to me. And if we change
> traits->capabilities then we should find another name for what is
> currently Nova capabilities.
>
> -Andrew

I see similarities between Nova's and Cinder's problem space and I
believe we can come up with a consistent API here. This sounds like a
topic suitable for a cross-project discussion at the Design Summit.

[1] https://review.openstack.org/#/c/350310

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 clear, we're looking at exposing both traits and capabilities in
Nova. This puts us in a weird spot where I think our concept of traits
aligns with cinders capabilities, but I don't see any match for the Nova
concept of capabilities. So I'm still open to naming suggestions but I
think capabilities most accurately describes what it is. Dean has it
right, I think, that what we really have are 'api capabilities' and
'host capabilities'. But people will end up just using 'capabilities'
and cause confusion.

>
> If these are truly the same concepts being discussed across projects,
> it would be great to see consistency in the APIs and have the projects
> come together under a new guideline. I encourage the projects and
> people to propose such a guideline and for someone to step up and
> champion it. Seems like good fodder for a design session proposal at
> the upcoming summit.

Here's what all of these different things look like to me:

Cinder is looking to expose hardware capabilities. This pretty closely
aligns with what traits are intending to do in Nova. This answers the
question of "can I create a resource that needs/does X in this
deployment?" However in Nova we ultimately want users to be able to
specify which traits they want for their instance. That may be embedded
in a flavor or arbitrarily specified in the request but a trait is not
implicitly available to all resources like it seems it is in Cinder. We
assume there could be a heterogeneous environment so without requesting
a trait there's no guarantee of getting it.

Nova capabilities are intended to answer the question of "as user Y with
resource X what can I do with it?" This is dependent on user
authorization, hardware "traits" where the resource lives, and service
version. I didn't see an analog to this in any of the proposals below.
And one major difference between this and the other proposals is that,
if possible, we would like the response to map to the API action that
will perform that capability. So if a user can perform a resize on their
instance the response might include 'POST .../servers//action -d
resize' or whatever form we come up with.

The Glance concept of value discovery maps closely to what Nova
capabilities are in intent in that it answers the question of "what
can I do in this API request that will be valid?" But the scope is
completely different in that it doesn't answer the question of which
API requests can be made, just what values can be used in this
specific call.

Given the above I find that I don't have the imagination required to
consolidate those into a consistent API concept that can be shared
across projects. Cinder capabilities and Nova traits could potentially
work, but the rest seem too different to me. And if we change traits-
>capabilities then we should find another name for what is currently
Nova capabilities.

-Andrew

>
> Cheers,
> Everett
>
> [1] https://review.openstack.org/#/c/306930/
> [2] https://review.openstack.org/#/c/350310/
> [3]  
> https://specs.openstack.org/openstack/glance-specs/specs/mitaka/approved/image-import/image-import-refactor.html#value-discovery
> [4] http://specs.openstack.org/openstack/api-wg/
>
>
>> On Aug 16, 2016, at 3:16 AM, Sylvain Bauza  wrote:
>>
>>
>>
>> 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 "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 semblance of sanity let's rename one or both of these
>  concepts.
>
>  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
>  capability will be determined by looking at policy rules in place
>  and
>  the capabilities of the host the instance is on. For instance an
>  upcoming volume multiattach feature may or may not be allowed
>  for an
>  instance depending on host support and the version of nova-
>  compute code
>  running on that host.
>
>  A host "capability" is a description of the hardware or software
>  on the
>  host that determines whether or not that host can fulfill the
>  needs of
>  an instance looking for a home. So SSD or x86 could be host
>

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

2016-08-25 Thread Everett Toews

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 "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 semblance of sanity let's rename one or both of these
concepts.

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
capability will be determined by looking at policy rules in place and
the capabilities of the host the instance is on. For instance an
upcoming volume multiattach feature may or may not be allowed for an
instance depending on host support and the version of nova-compute code
running on that host.

A host "capability" is a description of the hardware or software on the
host that determines whether or not that host can fulfill the needs of
an instance looking for a home. So SSD or x86 could be host
capabilities.
https://github.com/jaypipes/os-capabilities/blob/master/os_capabilities/const.py
has a list of some examples.

Some possible replacement terms that have been thrown out in discussions
are features, policies(already used), grants, faculties. But none of
those seemed to clearly fit one concept or the other, except policies.

Any thoughts on this hard problem?

I know, naming is damn hard, right? :)

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 policy-like things.

My vote is the following:

GET /capabilities <-- returns a set of *actions* or *abilities* that the
user is capable of performing

GET /traits <-- returns a set of *adjectives* or *attributes* that may
describe a provider of some resource

Traits sounds good to me.


Yeah, it wouldn't be dire, trait.


I can rename os-capabilities to os-traits, which would make Sean Mooney
happy I think and also clear up the terminology mismatch.

Thoughts?
-jay

__
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 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] [Nova][API] Need naming suggestions for "capabilities"

2016-08-15 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:
>>> 
 My vote is the following:
 
 GET /capabilities <-- returns a set of *actions* or *abilities* that the 
 user is capable of performing
>>> 
>>> Does this relate in any way to how DefCore already uses "capabilities”?
>> 
>> Only a bit, and not in a way I’d be deeply concerned about.
>> 
>> The Interoperability Working Group (née DefCore) points to a specific 
>> Tempest test which asserts that a service has a “capability” and determines 
>> if that capability is “core,” thus required to be provided in this way in 
>> order to claim that the underlying cloud is an OpenStack cloud.
> 
> Do you think that the meanings of "capability of a cloud" and
> "capability of a user of a cloud" are far enough apart to avoid
> confusion?

The two contexts are distinct enough and with little enough overlap that I 
believe the set of folks who might ever discuss both at the same time is less 
than twenty.

Unless Jay takes a sudden interest in DefCore. Then it might *equal* twenty. ;D

--j


__
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] [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 scheduler. As much fun as it would
> > be to have the same term mean two very different things in Nova to
> > retain some semblance of sanity let's rename one or both of these
> > concepts.
> >
> > 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
> > capability will be determined by looking at policy rules in place and
> > the capabilities of the host the instance is on. For instance an
> > upcoming volume multiattach feature may or may not be allowed for an
> > instance depending on host support and the version of nova-compute code
> > running on that host.
> >
> > A host "capability" is a description of the hardware or software on the
> > host that determines whether or not that host can fulfill the needs of
> > an instance looking for a home. So SSD or x86 could be host
> > capabilities.
> > https://github.com/jaypipes/os-capabilities/blob/master/os_capabilities/const.py
> > has a list of some examples.
> >
> > Some possible replacement terms that have been thrown out in discussions
> > are features, policies(already used), grants, faculties. But none of
> > those seemed to clearly fit one concept or the other, except policies.
> >
> > Any thoughts on this hard problem?
> 
> I know, naming is damn hard, right? :)
> 
> 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 policy-like things.
> 
> My vote is the following:
> 
> GET /capabilities <-- returns a set of *actions* or *abilities* that the 
> user is capable of performing
> 
> GET /traits <-- returns a set of *adjectives* or *attributes* that may 
> describe a provider of some resource

Traits sounds good to me.

> 
> I can rename os-capabilities to os-traits, which would make Sean Mooney 
> happy I think and also clear up the terminology mismatch.
> 
> Thoughts?
> -jay
> 
> __
> 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] [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* or *abilities* that the 
> >> user is capable of performing
> > 
> > Does this relate in any way to how DefCore already uses "capabilities”?
> 
> Only a bit, and not in a way I’d be deeply concerned about.
> 
> The Interoperability Working Group (née DefCore) points to a specific Tempest 
> test which asserts that a service has a “capability” and determines if that 
> capability is “core,” thus required to be provided in this way in order to 
> claim that the underlying cloud is an OpenStack cloud.

Do you think that the meanings of "capability of a cloud" and
"capability of a user of a cloud" are far enough apart to avoid
confusion?

Doug

__
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] [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 relate in any way to how DefCore already uses "capabilities”?

Only a bit, and not in a way I’d be deeply concerned about.

The Interoperability Working Group (née DefCore) points to a specific Tempest 
test which asserts that a service has a “capability” and determines if that 
capability is “core,” thus required to be provided in this way in order to 
claim that the underlying cloud is an OpenStack cloud.

> 
>> 
>> GET /traits <-- returns a set of *adjectives* or *attributes* that may 
>> describe a provider of some resource

+1 for where this is going.

—j

__
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] [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 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 semblance of sanity let's rename one or both of these
concepts.

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
capability will be determined by looking at policy rules in place and
the capabilities of the host the instance is on. For instance an
upcoming volume multiattach feature may or may not be allowed for an
instance depending on host support and the version of nova-compute code
running on that host.

A host "capability" is a description of the hardware or software on the
host that determines whether or not that host can fulfill the needs of
an instance looking for a home. So SSD or x86 could be host
capabilities.
https://github.com/jaypipes/os-capabilities/blob/master/os_capabilities/const.py
has a list of some examples.

Some possible replacement terms that have been thrown out in discussions
are features, policies(already used), grants, faculties. But none of
those seemed to clearly fit one concept or the other, except policies.

Any thoughts on this hard problem?


I know, naming is damn hard, right? :)

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 policy-like things.

My vote is the following:

GET /capabilities <-- returns a set of *actions* or *abilities* that the
user is capable of performing


Does this relate in any way to how DefCore already uses "capabilities"?


Sorry, I have no idea, Doug :( I don't really pay attention to defcore. 
Could you explain how defcore uses the term capabilities, please?


Thanks!
-jay

__
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] [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 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 semblance of sanity let's rename one or both of these
> > concepts.
> >
> > 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
> > capability will be determined by looking at policy rules in place and
> > the capabilities of the host the instance is on. For instance an
> > upcoming volume multiattach feature may or may not be allowed for an
> > instance depending on host support and the version of nova-compute code
> > running on that host.
> >
> > A host "capability" is a description of the hardware or software on the
> > host that determines whether or not that host can fulfill the needs of
> > an instance looking for a home. So SSD or x86 could be host
> > capabilities.
> > https://github.com/jaypipes/os-capabilities/blob/master/os_capabilities/const.py
> > has a list of some examples.
> >
> > Some possible replacement terms that have been thrown out in discussions
> > are features, policies(already used), grants, faculties. But none of
> > those seemed to clearly fit one concept or the other, except policies.
> >
> > Any thoughts on this hard problem?
> 
> I know, naming is damn hard, right? :)
> 
> 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 policy-like things.
> 
> My vote is the following:
> 
> GET /capabilities <-- returns a set of *actions* or *abilities* that the 
> user is capable of performing

Does this relate in any way to how DefCore already uses "capabilities"?

Doug

> 
> GET /traits <-- returns a set of *adjectives* or *attributes* that may 
> describe a provider of some resource
> 
> I can rename os-capabilities to os-traits, which would make Sean Mooney 
> happy I think and also clear up the terminology mismatch.
> 
> Thoughts?
> -jay
> 

__
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] [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/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 very different
> > things in Nova to retain some semblance of sanity let's rename one or
> > both of these concepts.
> >
> > 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 capability will be determined by looking at policy rules in
> place
> > and the capabilities of the host the instance is on. For instance an
> > upcoming volume multiattach feature may or may not be allowed for an
> > instance depending on host support and the version of nova-compute
> > code running on that host.
> >
> > A host "capability" is a description of the hardware or software on
> > the host that determines whether or not that host can fulfill the
> > needs of an instance looking for a home. So SSD or x86 could be host
> > capabilities.
> > https://github.com/jaypipes/os-
> capabilities/blob/master/os_capabilitie
> > s/const.py
> > has a list of some examples.
> >
> > Some possible replacement terms that have been thrown out in
> > discussions are features, policies(already used), grants, faculties.
> > But none of those seemed to clearly fit one concept or the other,
> except policies.
> >
> > Any thoughts on this hard problem?
> 
> I know, naming is damn hard, right? :)
> 
> 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 policy-like things.
> 
> My vote is the following:
> 
> GET /capabilities <-- returns a set of *actions* or *abilities* that
> the user is capable of performing
> 
> GET /traits <-- returns a set of *adjectives* or *attributes* that may
> describe a provider of some resource
> 
> I can rename os-capabilities to os-traits, which would make Sean Mooney
> happy I think and also clear up the terminology mismatch.
[Mooney, Sean K] yep I like that suggestion though I'm fine with either.
os-traits is nice and short and I like the delineation between attributes and 
abilities.
> 
> Thoughts?
> -jay
> 
> ___
> ___
> 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] [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 mailto:jaypi...@gmail.com>> 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 policy-like things.


My vote is the following:

GET /capabilities <-- returns a set of *actions* or *abilities* that
the user is capable of performing

GET /traits <-- returns a set of *adjectives* or *attributes* that
may describe a provider of some resource

I can rename os-capabilities to os-traits, which would make Sean
Mooney happy I think and also clear up the terminology mismatch.


/me didn't stop writing previous email to read this first...

I think traits may be preferable to what I wrote a minute ago (using
qualifiying words) as this definition maintains separation for the
semantics of 'what can I do' vs 'what am I like'.

Plus 'trait' is a word that if/when surfaced into the UI will not
collide with anything else yet (that I know of).  It is a lot like how
OSC uses 'property', but may not be totally incompatible.


Right, the difference being a property has a key/value structure whereas 
a trait in this context is a simple string tag structure.


Best,
-jay

__
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] [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 policy-like things.
>>
>
> My vote is the following:
>
> GET /capabilities <-- returns a set of *actions* or *abilities* that the
> user is capable of performing
>
> GET /traits <-- returns a set of *adjectives* or *attributes* that may
> describe a provider of some resource
>
> I can rename os-capabilities to os-traits, which would make Sean Mooney
> happy I think and also clear up the terminology mismatch.
>

/me didn't stop writing previous email to read this first...

I think traits may be preferable to what I wrote a minute ago (using
qualifiying words) as this definition maintains separation for the
semantics of 'what can I do' vs 'what am I like'.

Plus 'trait' is a word that if/when surfaced into the UI will not collide
with anything else yet (that I know of).  It is a lot like how OSC uses
'property', but may not be totally incompatible.

dt

-- 

Dean Troyer
dtro...@gmail.com
__
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] [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
> capability will be determined by looking at policy rules in place and
> the capabilities of the host the instance is on. For instance an
> upcoming volume multiattach feature may or may not be allowed for an
> instance depending on host support and the version of nova-compute code
> running on that host.
>
> A host "capability" is a description of the hardware or software on the
> host that determines whether or not that host can fulfill the needs of
> an instance looking for a home. So SSD or x86 could be host
> capabilities.
> https://github.com/jaypipes/os-capabilities/blob/master/
> os_capabilities/const.py
> has a list of some examples.
>

We have spent a good amount of time thinking about naming resources in
OpenStackClient and I think you have just stated what I would see as the
best compromise here, just qualifying 'capability' to get specific.  There
are far too many things in OpenStack to be able to use bare words to name
anymore, we passed that a while back.

Even though this hinges on using capability slightly differently (actions
vs properties), 'api capability' and 'host capability' are themselves a
good solution, if not ideal.

If the difference between action and property is too strong to overcome, I
would suggest just using 'host property' or 'host attribute'.  It looks
like that list will include a variety of specific things, all of which
though are intended to convey information about the host.

Also, if these terms get surfaces to the user-visible level, I would like
to see them fit existing usage as much as possible so we don't get another
version of the 'metadata' vs 'properties' debate.

dt

-- 

Dean Troyer
dtro...@gmail.com
__
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] [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 very different things in Nova to
retain some semblance of sanity let's rename one or both of these
concepts.

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
capability will be determined by looking at policy rules in place and
the capabilities of the host the instance is on. For instance an
upcoming volume multiattach feature may or may not be allowed for an
instance depending on host support and the version of nova-compute code
running on that host.

A host "capability" is a description of the hardware or software on the
host that determines whether or not that host can fulfill the needs of
an instance looking for a home. So SSD or x86 could be host
capabilities.
https://github.com/jaypipes/os-capabilities/blob/master/os_capabilities/const.py
has a list of some examples.

Some possible replacement terms that have been thrown out in discussions
are features, policies(already used), grants, faculties. But none of
those seemed to clearly fit one concept or the other, except policies.

Any thoughts on this hard problem?


I know, naming is damn hard, right? :)

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 policy-like things.


My vote is the following:

GET /capabilities <-- returns a set of *actions* or *abilities* that the 
user is capable of performing


GET /traits <-- returns a set of *adjectives* or *attributes* that may 
describe a provider of some resource


I can rename os-capabilities to os-traits, which would make Sean Mooney 
happy I think and also clear up the terminology mismatch.


Thoughts?
-jay

__
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] [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 semblance of sanity let's rename one or both of these
concepts.

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
capability will be determined by looking at policy rules in place and
the capabilities of the host the instance is on. For instance an
upcoming volume multiattach feature may or may not be allowed for an
instance depending on host support and the version of nova-compute code
running on that host.

A host "capability" is a description of the hardware or software on the
host that determines whether or not that host can fulfill the needs of
an instance looking for a home. So SSD or x86 could be host
capabilities.
https://github.com/jaypipes/os-capabilities/blob/master/os_capabilities/const.py
has a list of some examples.

Some possible replacement terms that have been thrown out in discussions
are features, policies(already used), grants, faculties. But none of
those seemed to clearly fit one concept or the other, except policies.

Any thoughts on this hard problem?

__
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] [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
associated routing, and that's exactly the problem below.


We shouldn't be implementing a WSGI server *at all*. The fact that one
cannot run Nova inside a true WSGI server (i.e. Apache/mod_wsgi, uwsgi,
etc) is a bad thing.


I certainly understand the concerns of adding yet another library. To be
honest, I tend to even agree with the statement that we could possibly
use Routes without explicitly use nova.wsgi, right ?

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 ?

If that is a problem for those, is there something we could improve,
instead of just getting rid of it ?


For the record, I'm very much in favor of the approach Chris has taken
in a framework-less implementation with nothing other than the (tiny)
selector library as a dependency. I'd like to see the work move forward.

Best,
-jay



It seems like choosing to avoid an existing framework is just going
to eventually result in another new framework evolving organically
as things like common aspects like error handling and transactions
are refactored out of of individual handlers.


WSGI frameworks shouldn't be handling transactions, IMHO. That's a ba d 
coupling problem.


And no, I don't believe this will result in a new framework being 
created, precisely for the reason that no such framework is needed...



Is it really so bad to just pick a tool already being used in some
portion of the rest of the community?


As I said, I'm OK with using Routes since it's already in g-r, but I 
just don't see a need for a WSGI framework, especially one that includes 
things like a WSGI server.


Best,
-jay

__
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] [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 exactly the problem below.
> 
> We shouldn't be implementing a WSGI server *at all*. The fact that one 
> cannot run Nova inside a true WSGI server (i.e. Apache/mod_wsgi, uwsgi, 
> etc) is a bad thing.
> 
> > I certainly understand the concerns of adding yet another library. To be
> > honest, I tend to even agree with the statement that we could possibly
> > use Routes without explicitly use nova.wsgi, right ?
> >
> > 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 ?
> >
> > If that is a problem for those, is there something we could improve,
> > instead of just getting rid of it ?
> 
> For the record, I'm very much in favor of the approach Chris has taken 
> in a framework-less implementation with nothing other than the (tiny) 
> selector library as a dependency. I'd like to see the work move forward.
> 
> Best,
> -jay
> 

It seems like choosing to avoid an existing framework is just going
to eventually result in another new framework evolving organically
as things like common aspects like error handling and transactions
are refactored out of of individual handlers.

Is it really so bad to just pick a tool already being used in some
portion of the rest of the community?

Doug

__
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] [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, and that's exactly the problem below.


We shouldn't be implementing a WSGI server *at all*. The fact that one
cannot run Nova inside a true WSGI server (i.e. Apache/mod_wsgi,
uwsgi, etc) is a bad thing.



Okay, fair point :-)
That still leaves the routing question up, tho :-)

I certainly understand the concerns of adding yet another library. To be
honest, I tend to even agree with the statement that we could possibly
use Routes without explicitly use nova.wsgi, right ?

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 ?

If that is a problem for those, is there something we could improve,
instead of just getting rid of it ?


For the record, I'm very much in favor of the approach Chris has taken
in a framework-less implementation with nothing other than the (tiny)
selector library as a dependency. I'd like to see the work move forward.



Okay, my open question (because I'm not expert in that) was rather to
understand why Routes was not possible to be something usable for the
new placement API, if that's something we use in Nova too.


Routes would indeed be possible to use. And I wouldn't have an issue 
using Routes, though I prefer selector due to its simplicity and 
documentation readability and that controllers are specified as actual 
callables, not strings.


-jay

__
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] [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 shouldn't be implementing a WSGI server *at all*. The fact that one 
cannot run Nova inside a true WSGI server (i.e. Apache/mod_wsgi, 
uwsgi, etc) is a bad thing.




Okay, fair point :-)
That still leaves the routing question up, tho :-)

I certainly understand the concerns of adding yet another library. To be
honest, I tend to even agree with the statement that we could possibly
use Routes without explicitly use nova.wsgi, right ?

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 ?

If that is a problem for those, is there something we could improve,
instead of just getting rid of it ?


For the record, I'm very much in favor of the approach Chris has taken 
in a framework-less implementation with nothing other than the (tiny) 
selector library as a dependency. I'd like to see the work move forward.




Okay, my open question (because I'm not expert in that) was rather to 
understand why Routes was not possible to be something usable for the 
new placement API, if that's something we use in Nova too.


-S


Best,
-jay

__ 


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] [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 all*. The fact that one 
cannot run Nova inside a true WSGI server (i.e. Apache/mod_wsgi, uwsgi, 
etc) is a bad thing.



I certainly understand the concerns of adding yet another library. To be
honest, I tend to even agree with the statement that we could possibly
use Routes without explicitly use nova.wsgi, right ?

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 ?

If that is a problem for those, is there something we could improve,
instead of just getting rid of it ?


For the record, I'm very much in favor of the approach Chris has taken 
in a framework-less implementation with nothing other than the (tiny) 
selector library as a dependency. I'd like to see the work move forward.


Best,
-jay

__
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] [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 other
>> projects we know, like Horizon ?
> 
> The implication of your question here is that it is okay to do HTTP
> incorrectly if people don't report problems with that lack of
> correctness?
>
>> If that is a problem for those, is there something we could improve,
>> instead of just getting rid of it ?
> 
> When I found the initial problem with Routes, it was because I was
> doing some intial nova testing (with gabbi-tempest[1]) and
> discovered it wasn't returning a 405 when it should. I made a bug
> 
> https://bugs.launchpad.net/nova/+bug/1567970
> 
> and tried to fix it but Routes fought me. If someone else can figure
> it out more power to them.
> 
> In any case selector's behavior in this case is just better. Better
> is better, right?

That's a Nova bug, is there an upstream Routes bug for that? I didn't
see one in looking around. While Routes isn't a super quick upstream,
they have merged our fixes in the past.

Better on what axis? This does add another way that people need to learn
to do this thing that they've all been doing another way. Largely to
address a set of issues that are theoretical to our consumers.
http://mcfunley.com/choose-boring-technology

-Sean

-- 
Sean Dague
http://dague.net

__
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] [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 API consumers, which are mostly client libraries that we
own and other projects we know, like Horizon ?


I feel a bit compelled to say that the assumption that the API 
consumers are mostly 'our code' is a faulty one and not true.  Just 
within the collection of client projects in the openstack/ repo 
namespace, there are at least 4 different codebases talking to compute 
endpoints.


I'm not picking on you Sylvain, this is just something that I think 
needs periodic reinforcement among our developer community.




No worries at all, Dean. Thanks for explaining your opinion. To be 
clear, I used "we" for saying "We are OpenStack", ie. an excellent 
ecosystem.




dt

--

Dean Troyer
dtro...@gmail.com 


__
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] [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 implication of your question here is that it is okay to do HTTP
incorrectly if people don't report problems with that lack of
correctness?

If that is a problem for those, is there something we could improve, instead 
of just getting rid of it ?


When I found the initial problem with Routes, it was because I was
doing some intial nova testing (with gabbi-tempest[1]) and
discovered it wasn't returning a 405 when it should. I made a bug

https://bugs.launchpad.net/nova/+bug/1567970

and tried to fix it but Routes fought me. If someone else can figure
it out more power to them.

In any case selector's behavior in this case is just better. Better
is better, right?


--
Chris Dent   (╯°□°)╯︵┻━┻http://anticdent.org/
freenode: cdent tw: @anticdent__
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] [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 we know,
> like Horizon ?
>

I feel a bit compelled to say that the assumption that the API consumers
are mostly 'our code' is a faulty one and not true.  Just within the
collection of client projects in the openstack/ repo namespace, there are
at least 4 different codebases talking to compute endpoints.

I'm not picking on you Sylvain, this is just something that I think needs
periodic reinforcement among our developer community.

dt

-- 

Dean Troyer
dtro...@gmail.com
__
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] [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 releases is because nothing was broken and he is
continuing to actively use and maintain it.

Idea. I absolutely agree with you about flask and his magic.
And if we want to start totally new it can be werkzeug or webob.
And if we go further I wonder why in nova we don't use
asynchronous approach. All these API calls which just transfer
from one point to another are perfect candidates.

In this particular case async would be overkill and out of place.
The changes being made in the requests are quick and in an important
transaction.

About gabbi. Could you please give several procs on declarative style
in yaml vs declarative style in python?

Rather than me describing it, perhaps have a look at
https://review.openstack.org/#/c/329151/10/nova/tests/functional/api/openstack/placement/gabbits/resource-provider.yaml
and then ask questions if you have any? I think that does a
relatively good job demonstrating the declarative style.

--
Chris Dent (╯°□°)╯︵┻━┻http://anticdent.org/
freenode: cdent tw: @anticdent__
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] [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 developed called the "Placement API".
The API will initially allow for the management of resource
providers. There are entities which provide classes of resources[2]
such as VPCU, DISK_GB, IPV4_ADDRESS.

At the Bristol mid-cycle it was decided that the placement api should
be developed in such a way that it will be easy™ to lift it into its
own project at some date in the future. In that future the placement
api will be able to help "place" lots of things, not just instances.

It was also decided that this lift and shift afforded an opportunity
to explore ways of hosting and testing an HTTP API that are different
from the modes originated in nova. Not for the sake of being different
but because the nova way has issues including inscrutability.

I started a WIP a few months back to start exploring this new
API. Recently it's been chunkified into smaller reviews[3].

For testing I've been using gabbi[4] because it does good TDD for
this kind of thing and also does a great job of satisfying the
declarative proposal in the api-wg testing guideline[5]. I hope this
is not controversial.

Where the controversy enters the picture has been in my choice of
how to structure the code that hosts the API. It's been clear from
the start that we want to use as little of the nova infrastructure
as possible. What's undecided is which of two strategies should be
followed. In broad strokes those strategies are:

* Go all in on a common framework, probably Flask[6], and use it in
its own

specific way.
* Don't use a framework at all. WSGI has never needed one. Just
compose some WSGI-apps, middleware and utilities and let them do
their work.

For now I've chosen the latter because it provides a level of
simplicity, inspectability, testability and control that I think is
lost when using a framework. I know for many people in the OpenStack
community not using a framework goes against the grain, but have a look
at the code[7], it's pretty simple Python.

+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.
That said, I'm not expert in that domain, just had a bit of experience
in that in the past. So, feel free to level my opinion by how you want :-)

One of the dependencies in this model is selector[8]. The discussion
around the review of getting it into global-requirements[9] is what
has prompted this email. Discussion there has suggested that the
resistance to the second strategy may be significant enough that we
should go with the first one. I think we need to decide that sooner
than later so this email is an invitation to join in the discussion,
either here or on the review of selector[9] or the initial API[3].

I certainly understand the concerns of adding yet another library. To be
honest, I tend to even agree with the statement that we could possibly
use Routes without explicitly use nova.wsgi, right ?

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 ?

If that is a problem for those, is there something we could improve,
instead of just getting rid of it ?

-Sylvain

From my standpoint, as the person writing the initial code, it would be
great to get this resolved soon. If we need to make a change, making
a simple WSGI app into a working Flask app is something other than
trivial, but I value us having consensus over how to do this over my
feelings about Flask and frameworks.

is lost behind implicit magic and you are stuck with it henceforth.
Implicit magic is absolutely horrible for long term maintenance,
especially in communities where many of the contributors come and go.
The code I've written in the WIP tries to break with many of code trends
that require readers to guess.

[1]
http://specs.openstack.org/openstack/nova-specs/specs/newton/approved/generic-resource-pools.html
[2]
http://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/resource-classes.html
[3] https://review.openstack.org/#/c/329149/ and its descendants [4]
https://gabbi.readthedocs.io/
[5]
http://specs.openstack.org/openstack/api-wg/guidelines/testing.html#proposals

[6] http://flask.pocoo.org/
[7]
https://review.openstack.org/#/c/329151/10/nova/api/openstack/placement/handlers/resou

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 at local community (openstack)
use it. I checked out several openstack projects (keystone, swift,
cinder) and it's Paste I think.
IMHO selector is too young in terms of version (0.1) and too old in
terms of updates (3 years ago).

Idea. I absolutely agree with you about flask and his magic.
And if we want to start totally new it can be werkzeug or webob.
And if we go further I wonder why in nova we don't use
asynchronous approach. All these API calls which just transfer
from one point to another are perfect candidates.

About API. It would be great for new service to have auto schema
description/validation and may be some optional stuff like duplicate
protection, call signature.

About gabbi. Could you please give several procs on declarative style
in yaml vs declarative style in python?

On Fri, Jun 17, 2016 at 1:55 PM, Chris Dent  wrote:

>
> 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 initially allow for the management of resource
> providers. There are entities which provide classes of resources[2]
> such as VPCU, DISK_GB, IPV4_ADDRESS.
>
> At the Bristol mid-cycle it was decided that the placement api should
> be developed in such a way that it will be easy™ to lift it into its
> own project at some date in the future. In that future the placement
> api will be able to help "place" lots of things, not just instances.
>
> It was also decided that this lift and shift afforded an opportunity
> to explore ways of hosting and testing an HTTP API that are different
> from the modes originated in nova. Not for the sake of being different
> but because the nova way has issues including inscrutability.
>
> I started a WIP a few months back to start exploring this new
> API. Recently it's been chunkified into smaller reviews[3].
>
> For testing I've been using gabbi[4] because it does good TDD for
> this kind of thing and also does a great job of satisfying the
> declarative proposal in the api-wg testing guideline[5]. I hope this
> is not controversial.
>
> Where the controversy enters the picture has been in my choice of
> how to structure the code that hosts the API. It's been clear from
> the start that we want to use as little of the nova infrastructure
> as possible. What's undecided is which of two strategies should be
> followed. In broad strokes those strategies are:
>
> * Go all in on a common framework, probably Flask[6], and use it in its own
>   specific way.
> * Don't use a framework at all. WSGI has never needed one. Just
>   compose some WSGI-apps, middleware and utilities and let them do
>   their work.
>
> For now I've chosen the latter because it provides a level of
> simplicity, inspectability, testability and control that I think is
> lost when using a framework. I know for many people in the OpenStack
> community not using a framework goes against the grain, but have a look
> at the code[7], it's pretty simple Python.
>
> One of the dependencies in this model is selector[8]. The discussion
> around the review of getting it into global-requirements[9] is what
> has prompted this email. Discussion there has suggested that the
> resistance to the second strategy may be significant enough that we
> should go with the first one. I think we need to decide that sooner
> than later so this email is an invitation to join in the discussion,
> either here or on the review of selector[9] or the initial API[3].
>
> From my standpoint, as the person writing the initial code, it would be
> great to get this resolved soon. If we need to make a change, making
> a simple WSGI app into a working Flask app is something other than
> trivial, but I value us having consensus over how to do this over my
> feelings about Flask and frameworks.
>
> To be clear: I don't like Flask, at all, it is too magic and too
> obscuring of the way HTTP works. You have to commit to it all the way
> to get the most benefit from it and when you do that a lot of
> inspectability
> is lost behind implicit magic and you are stuck with it henceforth.
> Implicit magic is absolutely horrible for long term maintenance,
> especially in communities where many of the contributors come and go.
> The code I've written in the WIP tries to break with many of code trends
> that require readers to guess.
>
> [1]
> http://specs.openstack.org/openstack/nova-specs/specs/newton/approved/generic-resource-pools.html
> [2]
> http://specs.openstack.org/openstack/nova-specs/specs/mitaka/implemented/resourc

[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:

I started a WIP a few months back to start exploring this new
API. Recently it's been chunkified into smaller reviews[3].

* Go all in on a common framework, probably Flask[6], and use it in its own
specific way.
* Don't use a framework at all. WSGI has never needed one. Just
compose some WSGI-apps, middleware and utilities and let them do
their work.

From my standpoint, as the person writing the initial code, it would be

great to get this resolved soon. If we need to make a change, making
a simple WSGI app into a working Flask app is something other than
trivial, but I value us having consensus over how to do this over my
feelings about Flask and frameworks.

To be clear: I don't like Flask, at all, it is too magic and too
obscuring of the way HTTP works. You have to commit to it all the way
to get the most benefit from it and when you do that a lot of inspectability
is lost behind implicit magic and you are stuck with it henceforth.
Implicit magic is absolutely horrible for long term maintenance,
especially in communities where many of the contributors come and go.
The code I've written in the WIP tries to break with many of code trends
that require readers to guess.

[5]
http://specs.openstack.org/openstack/api-wg/guidelines/testing.html#proposals
[6] http://flask.pocoo.org/
[7]
https://review.openstack.org/#/c/329151/10/nova/api/openstack/placement/handlers/resource_provider.py
[8] https://pypi.python.org/pypi/selector
[9] https://review.openstack.org/#/c/329386/

[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 realize that some folks might not have realized this is
happening.

So we've now got an over arching spec about how and why we're removing
the API extensions facility from Nova, and alternatives that exist for
folks -
https://specs.openstack.org/openstack/nova-specs/specs/newton/approved/api-no-more-extensions.html

This is informative for folks, please take a look if you think this will
impact you.

-Sean

-- 
Sean Dague
http://dague.net

__
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] [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 
>> changes to python-novaclient for each of these also).
>>
>> Also agree with using a single spec in the future, like Sean did with the 
>> API deprecation spec - deprecating multiple APIs but a single spec since the 
>> changes are the same.
> 
> I appreciate that Nova has a long and storied history around it's API. 
> Nonetheless, since it seems you're considering moving to  a new microversion, 
> we'd appreciate it if you would consider adhering to the Sorting guideline 
> [1] and helping drive consensus into the Pagination guideline [2].

Everett,

Could you be more specific as to what your complaints are? This response
is extremely vague, and mildly passive aggressive, so I don't even know
where to start on responses.

-Sean

-- 
Sean Dague
http://dague.net

__
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] [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).
> 
> Also agree with using a single spec in the future, like Sean did with the API 
> deprecation spec - deprecating multiple APIs but a single spec since the 
> changes are the same.

I appreciate that Nova has a long and storied history around it's API. 
Nonetheless, since it seems you're considering moving to  a new microversion, 
we'd appreciate it if you would consider adhering to the Sorting guideline [1] 
and helping drive consensus into the Pagination guideline [2].

Thanks,
Everett

[1] 
http://specs.openstack.org/openstack/api-wg/guidelines/pagination_filter_sort.html#sorting
[2] 
https://review.openstack.org/#/c/190743/21/guidelines/pagination_filter_sort.rst
__
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] [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 non-priority spec deadline is so close.

Thanks

On Tue, May 31, 2016 at 1:09 AM, Ken'ichi Ohmichi mailto:ken1ohmi...@gmail.com>> wrote:

2016-05-29 19:25 GMT-07:00 Alex Xu mailto:sou...@gmail.com>>:
>
>
> 2016-05-20 20:05 GMT+08:00 Sean Dague mailto:s...@dague.net>>:
>>
>> 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 - https://review.openstack.org/#/c/240401/
>> * hypervisors - https://review.openstack.org/#/c/240401/
>> * os-migrations - https://review.openstack.org/#/c/239869/
>>
>> I think that limit / marker is always a legit thing to add, and I almost
>> wish we just had a single spec which is "add limit / marker to the
>> following APIs in Newton"
>>
>
> Are you looking for code sharing or one microversion? For code sharing, it
> sounds ok if people have some co-work. Probably we need a common 
pagination
> supported model_query function for all of those. For one microversion, 
i'm a
> little hesitate, we should keep one small change, or enable all in one
> microversion. But if we have some base code for pagination support, we
> probably can make the pagination as default thing support for all list
> method?

It is nice to share some common code for this, that would be nice for
writing the api doc also to know what APIs support them.
And also nice to do it with a single microversion for the above
resources, because we can avoid microversion bumping conflict and all
of them don't seem a big change.

There is already common code for limit / marker.

I don't think these all need to be one microversion, they are honestly
easier to review if they are not.

However in future we should probably make 1 spec for all limit / marker
adds during a cycle. Just because the answer will be *yes* and seems
like more work to have everything be a dedicated spec.

-Sean

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).

Also agree with using a single spec in the future, like Sean did with 
the API deprecation spec - deprecating multiple APIs but a single spec 
since the changes are the same.

--

Thanks,

Matt Riedemann

__
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] [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.
> 
> Thanks
> 
> On Tue, May 31, 2016 at 1:09 AM, Ken'ichi Ohmichi  > wrote:
> 
> 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) -
> >>
> >> 
> https://github.com/openstack/nova-specs/blob/8d16fc11ee6d01b5a9fe1b8b7ab7fa6dff460e2a/specs/newton/approved/keypairs-pagination.rst#L2
> >> * os-instances-actions - https://review.openstack.org/#/c/240401/
> >> * hypervisors - https://review.openstack.org/#/c/240401/
> >> * os-migrations - https://review.openstack.org/#/c/239869/
> >>
> >> I think that limit / marker is always a legit thing to add, and I 
> almost
> >> wish we just had a single spec which is "add limit / marker to the
> >> following APIs in Newton"
> >>
> >
> > Are you looking for code sharing or one microversion? For code sharing, 
> it
> > sounds ok if people have some co-work. Probably we need a common 
> pagination
> > supported model_query function for all of those. For one microversion, 
> i'm a
> > little hesitate, we should keep one small change, or enable all in one
> > microversion. But if we have some base code for pagination support, we
> > probably can make the pagination as default thing support for all list
> > method?
> 
> It is nice to share some common code for this, that would be nice for
> writing the api doc also to know what APIs support them.
> And also nice to do it with a single microversion for the above
> resources, because we can avoid microversion bumping conflict and all
> of them don't seem a big change.

There is already common code for limit / marker.

I don't think these all need to be one microversion, they are honestly
easier to review if they are not.

However in future we should probably make 1 spec for all limit / marker
adds during a cycle. Just because the answer will be *yes* and seems
like more work to have everything be a dedicated spec.

-Sean

-- 
Sean Dague
http://dague.net

__
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] [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 Ohmichi 
wrote:

> 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) -
> >>
> >>
> https://github.com/openstack/nova-specs/blob/8d16fc11ee6d01b5a9fe1b8b7ab7fa6dff460e2a/specs/newton/approved/keypairs-pagination.rst#L2
> >> * os-instances-actions - https://review.openstack.org/#/c/240401/
> >> * hypervisors - https://review.openstack.org/#/c/240401/
> >> * os-migrations - https://review.openstack.org/#/c/239869/
> >>
> >> I think that limit / marker is always a legit thing to add, and I almost
> >> wish we just had a single spec which is "add limit / marker to the
> >> following APIs in Newton"
> >>
> >
> > Are you looking for code sharing or one microversion? For code sharing,
> it
> > sounds ok if people have some co-work. Probably we need a common
> pagination
> > supported model_query function for all of those. For one microversion,
> i'm a
> > little hesitate, we should keep one small change, or enable all in one
> > microversion. But if we have some base code for pagination support, we
> > probably can make the pagination as default thing support for all list
> > method?
>
> It is nice to share some common code for this, that would be nice for
> writing the api doc also to know what APIs support them.
> And also nice to do it with a single microversion for the above
> resources, because we can avoid microversion bumping conflict and all
> of them don't seem a big change.
>
> Thanks
>
> __
> 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] [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) -
>>
>> https://github.com/openstack/nova-specs/blob/8d16fc11ee6d01b5a9fe1b8b7ab7fa6dff460e2a/specs/newton/approved/keypairs-pagination.rst#L2
>> * os-instances-actions - https://review.openstack.org/#/c/240401/
>> * hypervisors - https://review.openstack.org/#/c/240401/
>> * os-migrations - https://review.openstack.org/#/c/239869/
>>
>> I think that limit / marker is always a legit thing to add, and I almost
>> wish we just had a single spec which is "add limit / marker to the
>> following APIs in Newton"
>>
>
> Are you looking for code sharing or one microversion? For code sharing, it
> sounds ok if people have some co-work. Probably we need a common pagination
> supported model_query function for all of those. For one microversion, i'm a
> little hesitate, we should keep one small change, or enable all in one
> microversion. But if we have some base code for pagination support, we
> probably can make the pagination as default thing support for all list
> method?

It is nice to share some common code for this, that would be nice for
writing the api doc also to know what APIs support them.
And also nice to do it with a single microversion for the above
resources, because we can avoid microversion bumping conflict and all
of them don't seem a big change.

Thanks

__
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] [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) -
>
> https://github.com/openstack/nova-specs/blob/8d16fc11ee6d01b5a9fe1b8b7ab7fa6dff460e2a/specs/newton/approved/keypairs-pagination.rst#L2
> * os-instances-actions - https://review.openstack.org/#/c/240401/
> * hypervisors - https://review.openstack.org/#/c/240401/
> * os-migrations - https://review.openstack.org/#/c/239869/
>
> I think that limit / marker is always a legit thing to add, and I almost
> wish we just had a single spec which is "add limit / marker to the
> following APIs in Newton"
>
>
Are you looking for code sharing or one microversion? For code sharing, it
sounds ok if people have some co-work. Probably we need a common pagination
supported model_query function for all of those. For one microversion, i'm
a little hesitate, we should keep one small change, or enable all in one
microversion. But if we have some base code for pagination support, we
probably can make the pagination as default thing support for all list
method?


> Most of these came in with sort_keys as well. We currently don't have
> schema enforcement on sort_keys, so I don't think we should add any more
> instances of it until we scrub it. Right now sort_keys is mostly a way
> to generate a lot of database load because users can sort by things not
> indexed in your DB. We really should close that issue in the future, but
> I don't think we should make it any worse. I have -1s on
> os-instance-actions and hypervisors for that reason.
>
> os-instances-actions and os-migrations are time based, so they are
> proposing a changes-since. That seems logical and fine. Date seems like
> the natural sort order for those anyway, so it's "almost" limit/marker,
> except from end not the beginning. I think that in general changes-since
> on any resource which is time based should be fine, as long as that
> resource is going to natural sort by the time field in question.
>
> So... I almost feel like this should just be soft policy at this point:
>
> limit / marker - always ok
> sort_* - no more until we have a way to scrub sort (and we fix weird
> sort key issues we have)
> changes-since - ok on any resource that will natural sort with the
> updated time
>
>
> That should make proposing these kinds of additions easier for folks,
>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> 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] [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 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) -
>>
>> https://github.com/openstack/nova-specs/blob/8d16fc11ee6d01b5a9fe1b8b7ab7fa6dff460e2a/specs/newton/approved/keypairs-pagination.rst#L2
>> * os-instances-actions - https://review.openstack.org/#/c/240401/
>> * hypervisors - https://review.openstack.org/#/c/240401/
>> * os-migrations - https://review.openstack.org/#/c/239869/
>>
>> I think that limit / marker is always a legit thing to add, and I almost
>> wish we just had a single spec which is "add limit / marker to the
>> following APIs in Newton"
>>
>> Most of these came in with sort_keys as well. We currently don't have
>> schema enforcement on sort_keys, so I don't think we should add any more
>> instances of it until we scrub it. Right now sort_keys is mostly a way
>> to generate a lot of database load because users can sort by things not
>> indexed in your DB. We really should close that issue in the future, but
>> I don't think we should make it any worse. I have -1s on
>> os-instance-actions and hypervisors for that reason.
>>
>> os-instances-actions and os-migrations are time based, so they are
>> proposing a changes-since. That seems logical and fine. Date seems like
>> the natural sort order for those anyway, so it's "almost" limit/marker,
>> except from end not the beginning. I think that in general changes-since
>> on any resource which is time based should be fine, as long as that
>> resource is going to natural sort by the time field in question.
>>
>> So... I almost feel like this should just be soft policy at this point:
>>
>> limit / marker - always ok
>> sort_* - no more until we have a way to scrub sort (and we fix weird
>> sort key issues we have)
>> changes-since - ok on any resource that will natural sort with the
>> updated time
>>
>>
>> That should make proposing these kinds of additions easier for folks,
>>
>> -Sean
>>
>>
> __
> 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] [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) -
https://github.com/openstack/nova-specs/blob/8d16fc11ee6d01b5a9fe1b8b7ab7fa6dff460e2a/specs/newton/approved/keypairs-pagination.rst#L2
* os-instances-actions - https://review.openstack.org/#/c/240401/
* hypervisors - https://review.openstack.org/#/c/240401/
* os-migrations - https://review.openstack.org/#/c/239869/

I think that limit / marker is always a legit thing to add, and I almost
wish we just had a single spec which is "add limit / marker to the
following APIs in Newton"

Most of these came in with sort_keys as well. We currently don't have
schema enforcement on sort_keys, so I don't think we should add any more
instances of it until we scrub it. Right now sort_keys is mostly a way
to generate a lot of database load because users can sort by things not
indexed in your DB. We really should close that issue in the future, but
I don't think we should make it any worse. I have -1s on
os-instance-actions and hypervisors for that reason.

os-instances-actions and os-migrations are time based, so they are
proposing a changes-since. That seems logical and fine. Date seems like
the natural sort order for those anyway, so it's "almost" limit/marker,
except from end not the beginning. I think that in general changes-since
on any resource which is time based should be fine, as long as that
resource is going to natural sort by the time field in question.

So... I almost feel like this should just be soft policy at this point:

limit / marker - always ok
sort_* - no more until we have a way to scrub sort (and we fix weird
sort key issues we have)
changes-since - ok on any resource that will natural sort with the
updated time

That should make proposing these kinds of additions easier for folks,

-Sean

[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 - https://review.openstack.org/#/c/240401/
* hypervisors - https://review.openstack.org/#/c/240401/
* os-migrations - https://review.openstack.org/#/c/239869/

I think that limit / marker is always a legit thing to add, and I almost
wish we just had a single spec which is "add limit / marker to the
following APIs in Newton"

Most of these came in with sort_keys as well. We currently don't have
schema enforcement on sort_keys, so I don't think we should add any more
instances of it until we scrub it. Right now sort_keys is mostly a way
to generate a lot of database load because users can sort by things not
indexed in your DB. We really should close that issue in the future, but
I don't think we should make it any worse. I have -1s on
os-instance-actions and hypervisors for that reason.

os-instances-actions and os-migrations are time based, so they are
proposing a changes-since. That seems logical and fine. Date seems like
the natural sort order for those anyway, so it's "almost" limit/marker,
except from end not the beginning. I think that in general changes-since
on any resource which is time based should be fine, as long as that
resource is going to natural sort by the time field in question.

So... I almost feel like this should just be soft policy at this point:

limit / marker - always ok
sort_* - no more until we have a way to scrub sort (and we fix weird
sort key issues we have)
changes-since - ok on any resource that will natural sort with the
updated time


That should make proposing these kinds of additions easier for folks,

-Sean

-- 
Sean Dague
http://dague.net

__
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] [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 patches not yet merged. Please review them, and if there are
>> issues feel free to fix them.
>>
>> Help create new API ref changes verifying some of the details -
>> https://wiki.openstack.org/wiki/NovaAPIRef
> 
> It's Monday, and work has dug in again. In order to make it a little
> easier here is an intermediate look at the file we're updating, and how
> far they've progressed (checked off if done, a review number if out for
> review, TODO if there is no change updated in the last 5 days for it).
> I'll get it into the burndown shortly, but it should help people pick
> the next targets.

This is now tracked in the main burndown http://burndown.dague.org/ and
the raw data can be fetched from http://burndown.dague.org/data.json (or
http://burndown.dague.org/data.txt for ludites) for anyone that wants it.

-Sean

-- 
Sean Dague
http://dague.net

__
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] [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 there are
> issues feel free to fix them.
> 
> Help create new API ref changes verifying some of the details -
> https://wiki.openstack.org/wiki/NovaAPIRef

It's Monday, and work has dug in again. In order to make it a little
easier here is an intermediate look at the file we're updating, and how
far they've progressed (checked off if done, a review number if out for
review, TODO if there is no change updated in the last 5 days for it).
I'll get it into the burndown shortly, but it should help people pick
the next targets.

File NameMethod  Param
Example   Body
diagnostics.inc   ✓  ✓
✓  ✓
extensions.inc✓  ✓
✓  ✓
flavors.inc   ✓   TODO
TODO   TODO
images.inc✓   TODO
TODO   TODO
ips.inc   ✓  ✓
✓   TODO
limits.inc✓ 315216
315714   TODO
metadata.inc  ✓   TODO
TODO   TODO
os-agents.inc ✓   TODO
TODO   TODO
os-aggregates.inc ✓ 315517
TODO   TODO
os-assisted-volume-snapshots.inc  ✓   TODO
TODO   TODO
os-availability-zone.inc  ✓   TODO
TODO   TODO
os-baremetal-nodes.inc✓   TODO
TODO   TODO
os-cells.inc   TODO   TODO
TODO   TODO
os-certificates.inc  314796   TODO
TODO   TODO
os-cloudpipe.inc  ✓   TODO
TODO   TODO
os-consoles.inc   ✓   TODO
TODO   TODO
os-fixed-ips.inc  ✓   TODO
TODO   TODO
os-flavor-access.inc  ✓ 316972
316972 316972
os-flavor-extra-specs.inc ✓   TODO
TODO   TODO
os-floating-ip-dns.inc✓   TODO
TODO   TODO
os-floating-ip-pools.inc  ✓  ✓
✓  ✓
os-floating-ips-bulk.inc  ✓   TODO
TODO   TODO
os-floating-ips.inc  311071   TODO
TODO   TODO
os-fping.inc  ✓   TODO
TODO   TODO
os-hosts.inc  ✓  ✓
✓  ✓
os-hypervisors.inc✓ 316681
TODO   TODO
os-instance-actions.inc   ✓   TODO
TODO   TODO
os-instance-usage-audit-log.inc   ✓   TODO
TODO   TODO
os-interface.inc  ✓ 315318
315934   TODO
os-keypairs.inc   ✓ 314502
314502 314502
os-migrations.inc ✓   TODO
TODO   TODO
os-networks.inc   ✓   TODO
TODO   TODO
os-quota-sets.inc ✓  ✓
TODO   TODO
os-security-group-default-rules.inc   ✓   TODO
TODO   TODO
os-security-group-rules.inc   ✓  ✓
TODO   TODO
os-security-groups.inc TODO   TODO
TODO   TODO
os-server-external-events.inc ✓  ✓
✓  ✓
os-server-groups.inc  ✓ 315394
TODO   TODO
os-server-password.inc✓   TODO
TODO   TODO
os-services.inc   ✓   TODO
TODO   TODO
os-simple-tenant-usage.inc✓   TODO
TODO   TODO
os-tenant-network.inc ✓   TODO
TODO   TODO
os-virtual-interfaces.inc ✓   TODO
TODO   TODO
os-volume-attachments.inc ✓  ✓
✓   TODO
os-volumes.inc✓   TODO
TODO   TODO
server-tags.inc   ✓  ✓
✓  ✓
servers-action-console-output.inc ✓  ✓
✓  ✓
servers-action-crash-dump.inc314566 314566
314566 314566
servers-action-deferred-delete.inc✓   TODO
TODO   TODO
servers-action-evacuate.inc  314776 314776
314776 314776
servers-action-fixed-ip.inc   ✓   TODO
TODO   TODO
servers-action-remote-consoles.inc✓   TODO
TODO   TOD

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 example:
>
> $nova hypervisor-list
> Response is OK.
> It should call the 'show' function of hypervisors.py in the nova.
> Response is coming from nova code at controller node.
>
> [Problem]
> There is hypervisors.py file present on both controller and compute node.
> Path is
> /usr/lib/python2.7/dist-packages/nova/api/openstack/compute/contrib/hypervisors.py
>
> I have put logs in the 'show' function in hypervisors.py file present on
> both controller and compute node.
> But, 'show' function called at controller side only. It is not invoking
> functions of hypervisors.py at compute node.
>
> Please let me know whether there is conf file parameters gaps in openstack
> modules (nova) or any other gap, which would allow my setup to call compute
> API code from compute node instead of controller when compute API is run
> from controller node.
>
> I am not able to get what is exact flow from nova at controller node to nova
> at compute node when compute API is called from controller node.
>
> Looking forward for your valuable inputs.
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

It sounds like everything is working correctly.
That API call just reads from the database.

Does this document help you?
http://docs.openstack.org/developer/nova/architecture.html

Thanks,
John

__
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] 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' function of hypervisors.py in the nova.
Response is coming from nova code at controller node.

[Problem]
There is hypervisors.py file present on both controller and compute node.
Path
is 
/usr/lib/python2.7/dist-packages/nova/api/openstack/compute/contrib/hypervisors.py

I have put logs in the 'show' function in hypervisors.py file present on
both controller and compute node.
But, 'show' function called at controller side only. It is not invoking
functions of hypervisors.py at compute node.

Please let me know whether there is conf file parameters gaps in openstack
modules (nova) or any other gap, which would allow my setup to call compute
API code from compute node instead of controller when compute API is run
from controller node.

I am not able to get what is exact flow from nova at controller node to
nova at compute node when compute API is called from controller node.

Looking forward for your valuable inputs.

-- 
Thanking you.

Regards,
Tarun
__
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] [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 merged. Please review them, and if there are
issues feel free to fix them.

Help create new API ref changes verifying some of the details -
https://wiki.openstack.org/wiki/NovaAPIRef


TGIF... was a long and great week it has been. We merged nearly 60
verifications this week - http://burndown.dague.org/ - there are still a
bunch to go, but each day of the process new faces showed up, and after
a couple of days and reviews people got better at the process and the
whole thing sped up.

I'll continue to start my day looking for api-ref patches to review.
Please keep up the good work, we've got about 150 verifications left, 22
patches in flight. With any luck by the end of next week we can be near
the finish line if people keep contributing so actively.

WARNING: if you had current outstanding patches, you'll need to rebase
them.

One of the things we discovered is that grouping and alphabetic order
helps keep tabs and reduces duplicates in parameters.yaml. So I just
merged enforcement of that - https://review.openstack.org/#/c/315617/ -
it required moving around about 50 parameters to get things right so
this is going to merge conflict with every outstanding patch. After it,
parameter adds to parameters.yaml will have to be in order or it's a
failure. "tox -e api-ref" should give you a pretty detailed warning
about it.

I also took some time to start the extraction of the sphinx extension to
a dedicated library -
http://git.openstack.org/cgit/openstack/os-api-ref/. Starting next week
some time we'll switch the Nova tree over to using it. It should have no
real impact on this work, will just make it easier for other project to
replicate it.

Thanks again to all the contributors to the Sprint.

Has proposed changes: 18
 - Alex Xu
 - Anusha Unnam
 - Augustina Ragwitz
 - Gage Hugo
 - Karen Bradshaw
 - Matt Riedemann
 - Pushkar Umaranikar
 - Ronald Bradford
 - Sarafraj Singh
 - Sean Dague
 - Sharat Sharma
 - Sivasathurappan Radhakrishnan
 - Sujitha
 - Sylvain Bauza
 - Takashi NATSUME
 - Timofey Durakov
 - Zhenyu Zheng
 - jichenjc

Has had changes merged: 13
 - Alex Xu
 - Anusha Unnam
 - Augustina Ragwitz
 - Karen Bradshaw
 - Matt Riedemann
 - Pushkar Umaranikar
 - Ronald Bradford
 - Sean Dague
 - Sharat Sharma
 - Sivasathurappan Radhakrishnan
 - Sujitha
 - Takashi NATSUME
 - jichenjc

Has reviewed changes: 22
 - Alex Xu
 - Andrew Laski
 - Atsushi SAKAI
 - Augustina Ragwitz
 - Gábor Antal
 - Jay Pipes
 - John Garbutt
 - Ken'ichi Ohmichi
 - Matt Riedemann
 - Pushkar Umaranikar
 - Ronald Bradford
 - Sarafraj Singh
 - Sean Dague
 - Sivasathurappan Radhakrishnan
 - Sujitha
 - Sylvain Bauza
 - Takashi NATSUME
 - Zhenyu Zheng
 - jichenjc
 - melissaml
 - venkatamahesh
 - yejiawei


-Sean



I just wanted to say thanks for staying on top of this and organizing 
it, and the updates on progress. This is cool to see.


And thanks to everyone that's been helping out.

--

Thanks,

Matt Riedemann


__
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] [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
issues feel free to fix them.

Help create new API ref changes verifying some of the details -
https://wiki.openstack.org/wiki/NovaAPIRef


TGIF... was a long and great week it has been. We merged nearly 60 
verifications this week - http://burndown.dague.org/ - there are still a 
bunch to go, but each day of the process new faces showed up, and after 
a couple of days and reviews people got better at the process and the 
whole thing sped up.


I'll continue to start my day looking for api-ref patches to review. 
Please keep up the good work, we've got about 150 verifications left, 22 
patches in flight. With any luck by the end of next week we can be near 
the finish line if people keep contributing so actively.


WARNING: if you had current outstanding patches, you'll need to rebase them.

One of the things we discovered is that grouping and alphabetic order 
helps keep tabs and reduces duplicates in parameters.yaml. So I just 
merged enforcement of that - https://review.openstack.org/#/c/315617/ - 
it required moving around about 50 parameters to get things right so 
this is going to merge conflict with every outstanding patch. After it, 
parameter adds to parameters.yaml will have to be in order or it's a 
failure. "tox -e api-ref" should give you a pretty detailed warning 
about it.


I also took some time to start the extraction of the sphinx extension to 
a dedicated library - 
http://git.openstack.org/cgit/openstack/os-api-ref/. Starting next week 
some time we'll switch the Nova tree over to using it. It should have no 
real impact on this work, will just make it easier for other project to 
replicate it.


Thanks again to all the contributors to the Sprint.

Has proposed changes: 18
 - Alex Xu
 - Anusha Unnam
 - Augustina Ragwitz
 - Gage Hugo
 - Karen Bradshaw
 - Matt Riedemann
 - Pushkar Umaranikar
 - Ronald Bradford
 - Sarafraj Singh
 - Sean Dague
 - Sharat Sharma
 - Sivasathurappan Radhakrishnan
 - Sujitha
 - Sylvain Bauza
 - Takashi NATSUME
 - Timofey Durakov
 - Zhenyu Zheng
 - jichenjc

Has had changes merged: 13
 - Alex Xu
 - Anusha Unnam
 - Augustina Ragwitz
 - Karen Bradshaw
 - Matt Riedemann
 - Pushkar Umaranikar
 - Ronald Bradford
 - Sean Dague
 - Sharat Sharma
 - Sivasathurappan Radhakrishnan
 - Sujitha
 - Takashi NATSUME
 - jichenjc

Has reviewed changes: 22
 - Alex Xu
 - Andrew Laski
 - Atsushi SAKAI
 - Augustina Ragwitz
 - Gábor Antal
 - Jay Pipes
 - John Garbutt
 - Ken'ichi Ohmichi
 - Matt Riedemann
 - Pushkar Umaranikar
 - Ronald Bradford
 - Sarafraj Singh
 - Sean Dague
 - Sivasathurappan Radhakrishnan
 - Sujitha
 - Sylvain Bauza
 - Takashi NATSUME
 - Zhenyu Zheng
 - jichenjc
 - melissaml
 - venkatamahesh
 - yejiawei


-Sean

--
Sean Dague
http://dague.net

__
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] [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 there are
> issues feel free to fix them.
> 
> Help create new API ref changes verifying some of the details -
> https://wiki.openstack.org/wiki/NovaAPIRef

We're still chugging along on content updates, current burndown has us
down to about 170 tags left: http://burndown.dague.org/

Things are starting to get backed up on reviewers now - 32 open reviews
at the moment. If you are nova core, review on these would be great, so
we can keep down the inflight reviews. We're starting to get duplication
of submissions because there is enough in flight:

Open reviews changing files: 32
 - https://review.openstack.org/310096 -
api-ref/source/os-hypervisors.inc, api-ref/source/parameters.yaml
 - https://review.openstack.org/310420 - api-ref/source/parameters.yaml,
api-ref/source/servers.inc
 - https://review.openstack.org/311071 - api-ref/source/os-floating-ips.inc
 - https://review.openstack.org/311727 - api-ref/source/parameters.yaml,
api-ref/source/servers-admin-action.inc
 - https://review.openstack.org/314101 - api-ref/source/extensions.inc,
api-ref/source/parameters.yaml
 - https://review.openstack.org/314133 - api-ref/source/flavors.inc,
api-ref/source/parameters.yaml
 - https://review.openstack.org/314268 - api-ref/source/images.inc
 - https://review.openstack.org/314320 - api-ref/source/ips.inc,
api-ref/source/parameters.yaml
 - https://review.openstack.org/314325 - api-ref/source/os-volumes.inc
 - https://review.openstack.org/314502 - api-ref/source/os-keypairs.inc,
api-ref/source/parameters.yaml
 - https://review.openstack.org/314566 -
api-ref/source/_static/api-site.css, api-ref/source/parameters.yaml,
api-ref/source/servers-action-crash-dump.inc
 - https://review.openstack.org/314776 - api-ref/source/parameters.yaml,
api-ref/source/servers-action-evacuate.inc
 - https://review.openstack.org/314796 - api-ref/source/os-certificates.inc
 - https://review.openstack.org/314833 -
api-ref/source/os-quota-sets.inc, api-ref/source/parameters.yaml
 - https://review.openstack.org/314932 -
api-ref/source/servers-admin-action.inc,
doc/api_samples/versions/v21-version-get-resp.json,
doc/api_samples/versions/versions-get-resp.json,
nova/api/openstack/api_version_request.py,
nova/api/openstack/compute/migrate_server.py,
nova/api/openstack/rest_api_version_history.rst, nova/conductor/manager.py
 - https://review.openstack.org/315126 -
api-ref/source/os-security-group-rules.inc, api-ref/source/parameters.yaml
 - https://review.openstack.org/315145 -
api-ref/source/servers-action-deferred-delete.inc
 - https://review.openstack.org/315199 -
api-ref/source/os-floating-ips-bulk.inc
 - https://review.openstack.org/315212 - api-ref/source/index.rst,
api-ref/source/os-server-external-events.inc,
api-ref/source/os-services.inc, api-ref/source/parameters.yaml
 - https://review.openstack.org/315216 - api-ref/source/limits.inc,
api-ref/source/parameters.yaml
 - https://review.openstack.org/315220 - api-ref/source/servers-actions.inc
 - https://review.openstack.org/315252 - api-ref/source/ips.inc
 - https://review.openstack.org/315284 -
api-ref/source/os-floating-ip-dns.inc
 - https://review.openstack.org/315289 -
api-ref/source/os-volume-attachments.inc
 - https://review.openstack.org/315318 -
api-ref/source/os-interface.inc, api-ref/source/parameters.yaml
 - https://review.openstack.org/315394 -
api-ref/source/os-server-groups.inc, api-ref/source/parameters.yaml
 - https://review.openstack.org/315517 -
api-ref/source/os-aggregates.inc, api-ref/source/parameters.yaml
 - https://review.openstack.org/315557 -
api-ref/source/os-security-group-default-rules.inc,
api-ref/source/parameters.yaml
 - https://review.openstack.org/315572 - api-ref/source/parameters.yaml,
api-ref/source/servers-action-evacuate.inc,
api-ref/source/servers-admin-action.inc,
doc/api_samples/os-evacuate/v2.27/server-evacuate-req.json,
doc/api_samples/os-migrate-server/v2.27/live-migrate-server.json,
doc/api_samples/versions/v21-version-get-resp.json,
doc/api_samples/versions/versions-get-resp.json,
nova/api/openstack/api_version_request.py,
nova/api/openstack/compute/evacuate.py,
nova/api/openstack/compute/migrate_server.py,
nova/api/openstack/compute/schemas/evacuate.py,
nova/api/openstack/compute/schemas/migrate_server.py,
nova/api/openstack/rest_api_version_history.rst, nova/compute/api.py,
nova/tests/functional/api_sample_tests/api_samples/os-evacuate/v2.27/server-evacuate-req.json.tpl,
nova/tests/functional/api_sample_tests/api_samples/os-migrate-server/v2.27/live-migrate-server.json.tpl,
nova/tests/functional/api_sample_tests/test_evacuate.py,
nova/tests/functional/api_sample_tests/test_migrate_server.py,
releasenotes/notes/check_destination_when_migrating-37b52ebe8b5

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 patches not yet merged. Please review them, and if there are
>> issues feel free to fix them.
>>
>> Help create new API ref changes verifying some of the details -
>> https://wiki.openstack.org/wiki/NovaAPIRef

Thus far, we've landed about 35 tag removals, and there are 27 reviews
outstanding that impact this (may remove one or more tags). Which while
it feel slow, you'll see in the burndown (http://burndown.dague.org/)
that things are accelerating as people get better at both creating and
reviewing the changes.

While the sprint officially is over today, I'm going to keep drumming up
on this through the rest of the week and see how far we can get. Thanks
again to everyone that's been helping out so far:

Has proposed changes: 16
 - Alex Xu
 - Anusha Unnam
 - Augustina Ragwitz
 - Karen Bradshaw
 - Matt Riedemann
 - Nikita Konovalov
 - Pushkar Umaranikar
 - Ronald Bradford
 - Sarafraj Singh
 - Sean Dague
 - Sharat Sharma
 - Sivasathurappan Radhakrishnan
 - Sujitha
 - Timofey Durakov
 - Zhenyu Zheng
 - jichenjc

Has had changes merged: 9
 - Alex Xu
 - Karen Bradshaw
 - Pushkar Umaranikar
 - Ronald Bradford
 - Sean Dague
 - Sharat Sharma
 - Sivasathurappan Radhakrishnan
 - Sujitha
 - jichenjc

Has reviewed changes: 18
 - Alex Xu
 - Andrew Laski
 - Atsushi SAKAI
 - Gábor Antal
 - Jay Pipes
 - John Garbutt
 - Ken'ichi Ohmichi
 - Matt Riedemann
 - Ronald Bradford
 - Sarafraj Singh
 - Sean Dague
 - Sivasathurappan Radhakrishnan
 - Sylvain Bauza
 - Takashi NATSUME
 - jichenjc
 - melissaml
 - venkatamahesh
 - yejiawei

Open reviews changing files: 27
 - https://review.openstack.org/310096 -
api-ref/source/os-hypervisors.inc, api-ref/source/parameters.yaml
 - https://review.openstack.org/310420 - api-ref/source/parameters.yaml,
api-ref/source/servers.inc
 - https://review.openstack.org/311071 - api-ref/source/os-floating-ips.inc
 - https://review.openstack.org/311727 - api-ref/source/parameters.yaml,
api-ref/source/servers-admin-action.inc
 - https://review.openstack.org/314101 - api-ref/source/extensions.inc,
api-ref/source/parameters.yaml
 - https://review.openstack.org/314133 - api-ref/source/flavors.inc,
api-ref/source/parameters.yaml
 - https://review.openstack.org/314198 - api-ref/source/os-networks.inc,
api-ref/source/parameters.yaml
 - https://review.openstack.org/314268 - api-ref/source/images.inc
 - https://review.openstack.org/314320 - api-ref/source/ips.inc,
api-ref/source/parameters.yaml
 - https://review.openstack.org/314325 - api-ref/source/os-volumes.inc
 - https://review.openstack.org/314502 - api-ref/source/os-keypairs.inc,
api-ref/source/parameters.yaml
 - https://review.openstack.org/314566 -
api-ref/source/_static/api-site.css, api-ref/source/parameters.yaml,
api-ref/source/servers-action-crash-dump.inc
 - https://review.openstack.org/314776 - api-ref/source/parameters.yaml,
api-ref/source/servers-action-evacuate.inc
 - https://review.openstack.org/314796 - api-ref/source/os-certificates.inc
 - https://review.openstack.org/314833 - api-ref/source/os-quota-sets.inc
 - https://review.openstack.org/314932 -
api-ref/source/servers-admin-action.inc,
doc/api_samples/versions/v21-version-get-resp.json,
doc/api_samples/versions/versions-get-resp.json,
nova/api/openstack/api_version_request.py,
nova/api/openstack/compute/migrate_server.py,
nova/api/openstack/rest_api_version_history.rst, nova/conductor/manager.py
 - https://review.openstack.org/315100 -
api-ref/source/servers-action-remote-consoles.inc
 - https://review.openstack.org/315103 - api-ref/ext/rest_parameters.py
 - https://review.openstack.org/315126 -
api-ref/source/os-security-group-rules.inc, api-ref/source/parameters.yaml
 - https://review.openstack.org/315127 -
api-ref/source/os-baremetal-nodes.inc
 - https://review.openstack.org/315145 -
api-ref/source/servers-action-deferred-delete.inc
 - https://review.openstack.org/315170 -
api-ref/source/os-instance-usage-audit-log.inc
 - https://review.openstack.org/315182 -
api-ref/source/os-server-external-events.inc
 - https://review.openstack.org/315199 -
api-ref/source/os-floating-ips-bulk.inc
 - https://review.openstack.org/315212 - api-ref/source/index.rst,
api-ref/source/os-server-external-events.inc,
api-ref/source/os-services.inc, api-ref/source/parameters.yaml
 - https://review.openstack.org/315216 - api-ref/source/limits.inc
 - https://review.openstack.org/315220 - api-ref/source/servers-actions.inc


-- 
Sean Dague
http://dague.net

__
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/openstac

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 there are
> issues feel free to fix them.
> 
> Help create new API ref changes verifying some of the details -
> https://wiki.openstack.org/wiki/NovaAPIRef

Here is our current status of folks contributing so far:

Has proposed changes
 - Alex Xu
 - Anusha Unnam
 - Augustina Ragwitz
 - Karen Bradshaw
 - Pushkar Umaranikar
 - Ronald Bradford
 - Sarafraj Singh
 - Sean Dague
 - Sharat Sharma
 - Sivasathurappan Radhakrishnan
 - Sujitha
 - Timofey Durakov
 - Zhenyu Zheng
 - jichenjc

Has had changes merged
 - Alex Xu
 - Ronald Bradford
 - Sean Dague
 - Sharat Sharma
 - Sivasathurappan Radhakrishnan
 - Sujitha
 - jichenjc

Has reviewed changes
 - Alex Xu
 - Andrew Laski
 - Atsushi SAKAI
 - Jay Pipes
 - John Garbutt
 - Ken'ichi Ohmichi
 - Matt Riedemann
 - Ronald Bradford
 - Sarafraj Singh
 - Sean Dague
 - Sivasathurappan Radhakrishnan
 - Takashi NATSUME
 - jichenjc
 - melissaml
 - venkatamahesh
 - yejiawei

Open reviews changing files
 - https://review.openstack.org/310420 -
[u'api-ref/source/parameters.yaml', u'api-ref/source/servers.inc']
 - https://review.openstack.org/310429 -
[u'api-ref/source/parameters.yaml', u'api-ref/source/servers.inc']
 - https://review.openstack.org/311070 -
[u'api-ref/source/os-floating-ip-pools.inc',
u'api-ref/source/parameters.yaml']
 - https://review.openstack.org/311727 -
[u'api-ref/source/servers-admin-action.inc']
 - https://review.openstack.org/314101 -
[u'api-ref/source/extensions.inc', u'api-ref/source/parameters.yaml']
 - https://review.openstack.org/314133 - [u'api-ref/source/flavors.inc',
u'api-ref/source/parameters.yaml']
 - https://review.openstack.org/314198 - [u'api-ref/source/os-networks.inc']
 - https://review.openstack.org/314268 - [u'api-ref/source/images.inc']
 - https://review.openstack.org/314320 - [u'api-ref/source/ips.inc',
u'api-ref/source/parameters.yaml']
 - https://review.openstack.org/314325 - [u'api-ref/source/os-volumes.inc']
 - https://review.openstack.org/314328 - [u'api-ref/source/ips.inc']
 - https://review.openstack.org/314502 -
[u'api-ref/source/os-keypairs.inc', u'api-ref/source/parameters.yaml']
 - https://review.openstack.org/314566 -
[u'api-ref/source/_static/api-site.css',
u'api-ref/source/parameters.yaml',
u'api-ref/source/servers-action-crash-dump.inc']
 - https://review.openstack.org/314629 -
[u'api-ref/source/servers-action-shelve.inc']
 - https://review.openstack.org/314748 -
[u'api-ref/source/servers-action-fixed-ip.inc']
 - https://review.openstack.org/314776 -
[u'api-ref/source/parameters.yaml',
u'api-ref/source/servers-action-evacuate.inc']
 - https://review.openstack.org/314783 -
[u'api-ref/source/os-cloudpipe.inc']
 - https://review.openstack.org/314794 -
[u'api-ref/source/os-floating-ips.inc']
 - https://review.openstack.org/314796 -
[u'api-ref/source/os-certificates.inc']
 - https://review.openstack.org/314798 -
[u'api-ref/source/os-floating-ip-pools.inc']
 - https://review.openstack.org/314802 -
[u'api-ref/source/os-assisted-volume-snapshots.inc']
 - https://review.openstack.org/314833 -
[u'api-ref/source/os-quota-sets.inc']
 - https://review.openstack.org/314924 -
[u'api-ref/source/os-hosts.inc', u'api-ref/source/parameters.yaml']
 - https://review.openstack.org/314932 -
[u'api-ref/source/servers-admin-action.inc',
u'doc/api_samples/versions/v21-version-get-resp.json',
u'doc/api_samples/versions/versions-get-resp.json',
u'nova/api/openstack/api_version_request.py',
u'nova/api/openstack/compute/migrate_server.py',
u'nova/api/openstack/rest_api_version_history.rst',
u'nova/conductor/manager.py']


Thanks to everyone contributing so far. Let's keep up the good work.

-Sean

-- 
Sean Dague
http://dague.net

__
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] [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 accidentally started work on several
> files that already have owners. Maybe if people could put the .inc
> filename in their commit message, or maybe we could agree on a
> consistent commit message for whichever phase we're on, it would be
> easier to tell, at a glance from the list, what's already being worked
> on. Other suggestions welcome, or if there's another list somewhere I
> don't know about, a link to that would be great.
> 
> This is the list I'm referring to:
> https://review.openstack.org/#/q/project:openstack/nova+file:api-ref+status:open

Also, while only a point in time, here are the currently open reviews,
and the files they touch:

Open reviews changing files
 - https://review.openstack.org/311070 -
[u'api-ref/source/os-floating-ip-pools.inc']
 - https://review.openstack.org/311727 -
[u'api-ref/source/servers-admin-action.inc']
 - https://review.openstack.org/313532 -
[u'api-ref/source/parameters.yaml', u'api-ref/source/servers.inc']
 - https://review.openstack.org/314085 - [u'api-ref/source/diagnostics.inc']
 - https://review.openstack.org/314101 -
[u'api-ref/source/extensions.inc', u'api-ref/source/parameters.yaml']
 - https://review.openstack.org/314133 - [u'api-ref/source/flavors.inc',
u'api-ref/source/parameters.yaml']
 - https://review.openstack.org/314198 - [u'api-ref/source/os-networks.inc']
 - https://review.openstack.org/314257 -
[u'api-ref/source/parameters.yaml',
u'api-ref/source/servers-action-console-output.inc']
 - https://review.openstack.org/314268 - [u'api-ref/source/images.inc']
 - https://review.openstack.org/314310 -
[u'api-ref/source/os-migrations.inc']
 - https://review.openstack.org/314320 - [u'api-ref/source/ips.inc']
 - https://review.openstack.org/314325 - [u'api-ref/source/os-volumes.inc']
 - https://review.openstack.org/314328 - [u'api-ref/source/ips.inc']
 - https://review.openstack.org/314502 -
[u'api-ref/source/os-keypairs.inc', u'api-ref/source/parameters.yaml']
 - https://review.openstack.org/314566 -
[u'api-ref/source/_static/api-site.css',
u'api-ref/source/parameters.yaml',
u'api-ref/source/servers-action-crash-dump.inc']
 - https://review.openstack.org/314629 -
[u'api-ref/source/servers-action-shelve.inc']

I've got some code to generate this, but it's a bit of a mess with hard
coded gerrit id/pass. I'll get it cleaned up and published by end of day
(hopefully).

-Sean

-- 
Sean Dague
http://dague.net

__
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] [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 there are
> issues feel free to fix them.
> 
> Help create new API ref changes verifying some of the details -
> https://wiki.openstack.org/wiki/NovaAPIRef

We made some reasonable progress yesterday, including discovering things
like the completely unexposed standardized diagnostics infrastructure
(which will get reproposed as a microversions). The current burndown
state is here: http://burndown.dague.org

Thanks to the following folks for contributing so far:

Has proposed changes
 - Alex Xu
 - Anusha Unnam
 - Augustina Ragwitz
 - Ronald Bradford
 - Sarafraj Singh
 - Sean Dague
 - Sivasathurappan Radhakrishnan
 - Sujitha
 - jichenjc

Has had changes merged
 - Alex Xu
 - Ronald Bradford
 - Sean Dague
 - Sivasathurappan Radhakrishnan
 - jichenjc

Has reviewed changes
 - Alex Xu
 - Andrew Laski
 - John Garbutt
 - Ken'ichi Ohmichi
 - Matt Riedemann
 - Ronald Bradford
 - Sarafraj Singh
 - Sean Dague
 - jichenjc
 - melissaml
 - yejiawei

Although today officially is a break day from the sprint, I encourage
folks to carry on. There is a lot to be done here to get us in a sane place.

-Sean

-- 
Sean Dague
http://dague.net

__
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] [nova] api-ref sprint today & wed

2016-05-10 Thread Sean Dague

Including the filename in the commit message seems like I good plan. I
started doing that now.

On 05/10/2016 08:58 AM, Chen CH Ji wrote:
> +1 to include .inc in the commit message, I also have to manually search
> in the open list
>  
>  
> 
> - Original message -
> From: Augustina Ragwitz 
> To: OpenStack Development Mailing List
>  (not for usage questions)
> Cc:
>     Subject: Re: [openstack-dev] [nova] api-ref sprint today & wed
> Date: Tue, May 10, 2016 12:29 AM
>  
> 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 owners. Maybe if people could put the .inc
> filename in their commit message, or maybe we could agree on a
> consistent commit message for whichever phase we're on, it would be
> easier to tell, at a glance from the list, what's already being worked
> on. Other suggestions welcome, or if there's another list somewhere I
> don't know about, a link to that would be great.
> 
> This is the list I'm referring to:
> 
> https://review.openstack.org/#/q/project:openstack/nova+file:api-ref+status:open
> 
> 
> Thanks!
> Augustina
> 
> 
> --
> Augustina Ragwitz
> Sr Systems Software Engineer, HPE Cloud
> Hewlett Packard Enterprise
> ---
> irc: auggy
> 
> __
> 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
> 


-- 
Sean Dague
http://dague.net

__
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] [nova] api-ref sprint today & wed

2016-05-10 Thread Chen CH Ji

+1 to include .inc in the commit message, I also have to manually search in the open list
 
 
- Original message -From: Augustina Ragwitz To: OpenStack Development Mailing List  (not for usage questions)Cc:Subject: Re: [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 commit messages, and I've accidentally started work on severalfiles that already have owners. Maybe if people could put the .incfilename in their commit message, or maybe we could agree on aconsistent commit message for whichever phase we're on, it would beeasier to tell, at a glance from the list, what's already being workedon. Other suggestions welcome, or if there's another list somewhere Idon't know about, a link to that would be great.This is the list I'm referring to:https://review.openstack.org/#/q/project:openstack/nova+file:api-ref+status:openThanks!Augustina--Augustina RagwitzSr Systems Software Engineer, HPE CloudHewlett Packard Enterprise---irc: auggy__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 
 


__
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] [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 owners. Maybe if people could put the .inc
filename in their commit message, or maybe we could agree on a
consistent commit message for whichever phase we're on, it would be
easier to tell, at a glance from the list, what's already being worked
on. Other suggestions welcome, or if there's another list somewhere I
don't know about, a link to that would be great.

This is the list I'm referring to:
https://review.openstack.org/#/q/project:openstack/nova+file:api-ref+status:open


Thanks!
Augustina


-- 
Augustina Ragwitz
Sr Systems Software Engineer, HPE Cloud
Hewlett Packard Enterprise
---
irc: auggy

__
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] [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 new API ref changes verifying some of the details -
https://wiki.openstack.org/wiki/NovaAPIRef

There is a burndown of the landed content here -
http://burndown.dague.org/ - we've started moving the needle, but there
is a long way to go.

Please pop up on #openstack-nova IRC if you have questions.

Thanks so far to our content contributors: Ronald Bradford, jichenjc,
Alex Xu, Sean Dague

And our reviewers: Alex Xu, Sean Dague

There is a ton of work to be done here, would love to have more
contributors dive in.

-Sean

-- 
Sean Dague
http://dague.net

__
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] [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 series to review is here [2].
> 
> [1]
> http://lists.openstack.org/pipermail/openstack-dev/2016-April/092936.html
> [2] https://review.openstack.org/#/q/status:open+topic:bp/api-ref-in-rst

This is both a content writing sprint and a content reviewing sprint.
We've got 57 files that need to get 4 phases of processing. For this
exercise we're going to focus on the first 3, which are:

* method verification (are all REST methods specified and in a
consistent order)
* parameter verification (are all parameters listed for request and
response, and are they correct)
* example verification (do all requests / responses with bodies have
examples, and are those explained what is going on).

https://wiki.openstack.org/wiki/NovaAPIRef explains what is needed at
each step in detail.

There is also a burndown graph for this effort here:
http://burndown.dague.org/ to be able to see the progress as we go (it's
updated hourly).

-Sean

-- 
Sean Dague
http://dague.net

__
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] [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] 
http://lists.openstack.org/pipermail/openstack-dev/2016-April/092936.html

[2] https://review.openstack.org/#/q/status:open+topic:bp/api-ref-in-rst

--

Thanks,

Matt Riedemann


__
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] [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
get out of date because there is no enforcement matching with the code
itself.

We rejected the giant tracking etherpad this time for that reason.

-Sean

-- 
Sean Dague
http://dague.net

__
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] [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. This patch is merging
a set of comments at the top of every file that they need 4 types of
verification - https://review.openstack.org/#/c/308569/ as described
here: https://wiki.openstack.org/wiki/NovaAPIRef

The expectation is that every file is going to see 4 (or more in
complicated cases) patches. I tried to break these up into pretty
concrete things to verify, so that they will be easy for content writers
and reviewers. They should be done in the 1, 2, 3, 4 order for each
file, but there is no need to a whole file to the end. You can do a
bunch of 1s on files, then some 2s, etc.

The idea is that in the patch in which you feel one of the verification
phases is complete, also delete the needs:x_verification for that phase.
That will let folks git grep for content that's not done yet.

Also, check open patches before taking a unit to try to avoid duplicate
effort with folks. This process will be a little slower, because it will
be good to cross reference the content with the code to make sure it's
right. For reviewers that are +1ing these patches, please just leave a
comment that you've done that cross check so we know who is looking deep
on these.


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...




We'll see how much progress we can make over the next couple of weeks,
then will try to finish it all up with a virtual doc sprint a couple
weeks after summit.

Thanks again to everyone that's been helping we've already merged a ton
of good fixes here -
https://review.openstack.org/#/q/status:merged+topic:bp/api-ref-in-rst

-Sean



__
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




--

Thanks,

Matt Riedemann


__
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] [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 the top of every file that they need 4 types of
verification - https://review.openstack.org/#/c/308569/ as described
here: https://wiki.openstack.org/wiki/NovaAPIRef

The expectation is that every file is going to see 4 (or more in
complicated cases) patches. I tried to break these up into pretty
concrete things to verify, so that they will be easy for content writers
and reviewers. They should be done in the 1, 2, 3, 4 order for each
file, but there is no need to a whole file to the end. You can do a
bunch of 1s on files, then some 2s, etc.

The idea is that in the patch in which you feel one of the verification
phases is complete, also delete the needs:x_verification for that phase.
That will let folks git grep for content that's not done yet.

Also, check open patches before taking a unit to try to avoid duplicate
effort with folks. This process will be a little slower, because it will
be good to cross reference the content with the code to make sure it's
right. For reviewers that are +1ing these patches, please just leave a
comment that you've done that cross check so we know who is looking deep
on these.

We'll see how much progress we can make over the next couple of weeks,
then will try to finish it all up with a virtual doc sprint a couple
weeks after summit.

Thanks again to everyone that's been helping we've already merged a ton
of good fixes here -
https://review.openstack.org/#/q/status:merged+topic:bp/api-ref-in-rst

-Sean

-- 
Sean Dague
http://dague.net



signature.asc
Description: OpenPGP digital signature
__
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] [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
>> inclusive to get agreement on things. I think we need to remain focused
>> on what API related work will have the highest impact on our users.
>> (some brain storming was here -
>> https://etherpad.openstack.org/p/newton-nova-api-ideas). Here is a
>> completely straw man proposal on priorities for the Newton cycle.
>>
>> * Top Priority Items *
>>
>> 1. API Reference docs in RST which include microversions (drivers: me,
>> auggy, annegentle) -
>> https://blueprints.launchpad.net/nova/+spec/api-ref-in-rst
>> 2. Discoverable Policy (drivers: laski, claudio) -
>> https://review.openstack.org/#/c/289405/
>> 3. ?? (TBD)
>>
>> I think realistically 3 priority items is about what we can sustain, and
>> I'd like to keep it there. Item #3 has a couple of options.
>>
>> * Lower Priority Background Work *
>>
>> - POC of Gabbi for additional API validation
>> - Microversion Testing in Tempest (underway)
>
> FWIW, the  framework for using microversions in tempest is done (and is part 
> of
> tempest.lib too) and the BP for that has been marked as implemented:
>
> http://specs.openstack.org/openstack/qa-specs/specs/tempest/implemented/api-microversions-testing-support.html
>
> All that's needed now is to actually start to leverage it by adding tests with
> microversions. IIRC there is only 1 right now, just a pro forma test for v2.2.
> The docs for using it are here:
>
> http://docs.openstack.org/developer/tempest/microversion_testing.html

Yea, now those tests can be implemented along with scenario tests with
other project microversion if available.

Along with version 2.2 tests running in gate, We have 2.10, 2.20 and
2.25 are up for review.

Plan is to cover as much as possible in N which should version most of
schema changes also and
makes tests implementation easy.

Nova functional tests will mostly cover Top, Bottom, change layer of
each microversion
https://blueprints.launchpad.net/nova/+spec/nova-microversion-functional-tests

>
>> - Some of the API WG recommendations
>>
>> * Things we shouldn't do this cycle *
>>
>> - Tasks API - not because it's not a good idea, but because I think
>> until we get ~ 3 core team members agreed that it's their number #1 item
>> for the cycle, it's just not going to get enough energy to go somewhere
>> useful. There are some other things on deck that we just need to clear
>> first.
>> - API wg changes for error codes - we should fix that eventually, but
>> that should come as a single microversion to minimize churn. That's
>> coordination we don't really have the bandwidth for this cycle.
>>
>> * Things we need to decide this cycle *
>>
>> - When are we deleting the legacy v2 code base in tree?
>
> I can get behind doing this. I think we've been running the 2.1 base compat
> as the default for long enough that there aren't gonna be any surprises if
> we drop the old v2 code in Newton.
>
>>
>> * Final priority item *
>>
>> For the #3 priority item one of the things that came up today was the
>> structured errors spec by the API working group. That would be really
>> nice... but in some ways really does need the entire new API reference
>> docs in place. And maybe is better in O.
>>
>> 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 a thing, and would slice our bread and julien
>> our fries, and solve all this. But it's a big thing to get right, and
>> JSON Home has an unclear future. And, we could server our users pretty
>> well with a much simpler take on capabilities. For instance
>>
>>  GET /servers/{id}/capabilities
>>
>> {
>> "capabilities" : {
>> "resize": True,
>> "live-resize": True,
>> "live-migrate": False
>> ...
>>  }
>> }
>>
>> Effectively an actions map for servers. Lots of details would have to be
>> sorted out on this one, clearly needs a spec, however I think that this
>> would help unstick some other things people would like in Nova, without
>> making our interop story terrible. This would need a driver for this effort.
>>
>> Every thing here is up for discussion. This is a summary of some of what
>> was in the meeting, plus some of my own thoughts. Please chime in on any
>> of this. It would be good to be of general agreement pre summit, so we
>> could focus conversation there more on the hows for getting things done.
>>
>>   -Sean
>>
>> --
>> Sean Dague
>> http://dague.net
>>
>
> __
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: openstack-dev-requ...@lists.openst

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 on this).

Yeah, gmann is working for this now. That is pretty good work.
Current coverage is just v2.2 only on Tempest side.
Nova v2.10 test patch is being reviewed now:
https://review.openstack.org/#/c/277763/

The difference between Tempest tests and novaclient tests is blocking
additional properties.
Tempest implements *response* body validation with JSON-Schema like
nova side, and additionalProperties is false for blocking unexpected
additional properties.
As microversion rule of nova, we need to add properties in a response
body with bumping a microversion.
So as the test, Tempest needs to block unexpected properties on the
existing microversions tests.

Thanks

__
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] [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 a thing, and would slice our bread and julien
> our fries, and solve all this. But it's a big thing to get right, and
> JSON Home has an unclear future. And, we could server our users pretty
> well with a much simpler take on capabilities. For instance
>
>  GET /servers/{id}/capabilities
>
> {
> "capabilities" : {
> "resize": True,
> "live-resize": True,
> "live-migrate": False
> ...
>  }
> }

Yeah, JSOM-Home is not an option for this kind of capabilities discovery.
Swagger is that instead. Clients can know available capabilities by
getting swagger definition via REST API.

Ex:

GET /swaggers
{
...
"/action": {
   "parameters": [
   {"name": "resize", "in": "body", ...},
   {"name": "os-start", "in": "body", ...},
   {"name": "os-stop", "in": "body", ...},
   ...
   }
}
}

Thanks

__
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] [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' option in newton so v2.1 can't be
> > disabled.
> >
> > And we need to think about logging a warning if you're using v2.0.
> >
> > That sets a timetable for removal of v2.0 in the O release at the
> > earliest.
> >
> >
> > If the target is O release, should we update v2.0 as 'DEPRECATED' in the
> > version API, then we have a release to deprecated it
> >
> > Currently it is still
> > 'SUPPORTED'
> https://github.com/openstack/nova/blob/master/doc/api_samples/versions/versions-get-resp.json#L11
>
> To be clear. We aren't actually deprecating v2.0 (though I guess we
> could do that as well). We're talking about deleting the 2.0 legacy
> code. The v2.1 on v2.0 compat layer would still be there.
>

Thanks, I got it now. Sorry for misunderstand the point.


>
> -Sean
>
> --
> Sean Dague
> http://dague.net
>
> __
> 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

1 2 3 4 >

1 - 100 of 306 matches

Mail list logo