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

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

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

[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

[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

[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

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

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

-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 priorities in Newton

[Sean Dague]

On 03/30/2016 05:27 PM, Andrew Laski wrote:
> 
> 
> On Wed, Mar 30, 2016, at 04:47 PM, Adam Young wrote:
>> On 03/30/2016 04:16 PM, Andrew Laski wrote:
>>>
>>> On Wed, Mar 30, 2016, at 03:54 PM, Matt Riedemann wrote:

 On 3/30/2016 2:42 PM, Andrew Laski wrote:
>
> On Wed, Mar 30, 2016, at 03:26 PM, 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) -
 Selfishly I'd like Laski to be as focused on cells v2 as possible, but
 he does have a spec up related to this.
>>> At the midcycle I agreed to look into the oslo.policy work involved with
>>> this because I have some experience there. I wasn't planning to be much
>>> involved beyond that, and Claudiu has a spec up for the API side of it.
>>> But in my mind there's a chain backwards from capabilities API to
>>> discoverable policy and I want to move the oslo.policy work ahead
>>> quickly if I can to unblock that.
>>
>> There is a CLI that does something like what you want already:
>>
>> https://review.openstack.org/#/c/170978/
>>
>> You basically want a server based version of that that returns all the 
>> "true" values.
> 
> Exactly.
> 
> The shortcoming of the CLI is that not all policies are guaranteed to be
> defined in a policy.json file. It's entirely possible for there to be a
> policy check with no definition anywhere which will just fall back to a
> defined default rule. A big part of my policy
> proposal(https://review.openstack.org/#/c/290155/) is to require
> policies to be registered in code like configuration options are. This
> allows for an exhaustive check against all used policies. And will allow
> for policy file generation from services.

Ok, so I think the summary of this is we should forget about a #3
priority item, and figure out how to move discoverable policy forward in
a real way this cycle, as that unblocks discoverable capabilities, which
unblocks virt features that are likely to not be widely deployed.

We should definitely carve some time at summit for that one.

-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 priorities in Newton

[Chris Dent]

On Wed, 30 Mar 2016, Matt Riedemann wrote:


- POC of Gabbi for additional API validation


I'm assuming cdent would be driving this, and he's also working on the 
resource providers stuff for the scheduler, but might be a decent side 
project for him to stay sane.


As Jay points out Sergey Nikitin is going to be doing most the
gabbi-related work. For reference:

* A spec for using gabbi for functional testing of the API:
  https://review.openstack.org/#/c/291352/
* Sergey's WIP POC: https://review.openstack.org/#/c/293456/
* Some TDD in the placement API work, using gabbi:
  https://review.openstack.org/#/c/293104/

The spec is oriented towards replacing the api-samples tests with gabbi
because gabbi allows the request and response to be read (by a human) in
the same place. In conversation with Sean and others there's been some
concern expressed that trying to replace the samples wholesale will
cause too much churn. So presumably we'll want to come up with some area
of functionality that we can block out as a first phase.

Thanks for your concern about my sanity but it went years ago.

--
Chris Dent   (�s°□°)�s�喋擤ォ�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 priorities in Newton

[Alex Xu]

2016-03-31 5:36 GMT+08:00 Matt Riedemann :

>
>
> On 3/30/2016 2:26 PM, 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)
>> - 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?
>>
>
> 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



>
> We also talked about fixing bugs in v2.0 today and I plan on putting up a
> patch to the nova devref policy section about bug fixes for v2.0. Basically
> latent bugs won't be fixed unless they are blocking some other effort
> (NovaObjectDictCompat removal comes to mind) or fixes a security issue. And
> we shouldn't introduce new 500 errors in the v2.0 API.
>
>
>> * 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
>>
>>
>>
>> __
>> 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: 

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

[Matt Riedemann]

On 3/30/2016 2:26 PM, 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)
- 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?


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.

We also talked about fixing bugs in v2.0 today and I plan on putting up 
a patch to the nova devref policy section about bug fixes for v2.0. 
Basically latent bugs won't be fixed unless they are blocking some other 
effort (NovaObjectDictCompat removal comes to mind) or fixes a security 
issue. And we shouldn't introduce new 500 errors in the v2.0 API.




* 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



__
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

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

[Andrew Laski]

On Wed, Mar 30, 2016, at 04:47 PM, Adam Young wrote:
> On 03/30/2016 04:16 PM, Andrew Laski wrote:
> >
> > On Wed, Mar 30, 2016, at 03:54 PM, Matt Riedemann wrote:
> >>
> >> On 3/30/2016 2:42 PM, Andrew Laski wrote:
> >>>
> >>> On Wed, Mar 30, 2016, at 03:26 PM, 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) -
> >> Selfishly I'd like Laski to be as focused on cells v2 as possible, but
> >> he does have a spec up related to this.
> > At the midcycle I agreed to look into the oslo.policy work involved with
> > this because I have some experience there. I wasn't planning to be much
> > involved beyond that, and Claudiu has a spec up for the API side of it.
> > But in my mind there's a chain backwards from capabilities API to
> > discoverable policy and I want to move the oslo.policy work ahead
> > quickly if I can to unblock that.
> 
> There is a CLI that does something like what you want already:
> 
> https://review.openstack.org/#/c/170978/
> 
> You basically want a server based version of that that returns all the 
> "true" values.

Exactly.

The shortcoming of the CLI is that not all policies are guaranteed to be
defined in a policy.json file. It's entirely possible for there to be a
policy check with no definition anywhere which will just fall back to a
defined default rule. A big part of my policy
proposal(https://review.openstack.org/#/c/290155/) is to require
policies to be registered in code like configuration options are. This
allows for an exhaustive check against all used policies. And will allow
for policy file generation from services.


> 
> >
> >
>  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.
> >> Agree to keep the priority list as small as possible, because this is
> >> just a part of our overall backlog of priorities.
> >>
>  * Lower Priority Background Work *
> 
>  - POC of Gabbi for additional API validation
> >> I'm assuming cdent would be driving this, and he's also working on the
> >> resource providers stuff for the scheduler, but might be a decent side
> >> project for him to stay sane.
> >>
>  - 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).
> >>
>  - 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.
> >>> Agreed. I would love to drive this forward but there are just too many
> >>> other areas to focus on right now.
> >> +1
> >>
> >>>
>  - 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.
> >> +1
> >>
>  * Things we need to decide this cycle *
> 
>  - When are we deleting the legacy v2 code base in tree?
> >> Do you have some high-level milestone thoughts here? I thought there was
> >> talk about not even thinking about this until Barcelona?
> >>
>  * 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, 

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

[Adam Young]

On 03/30/2016 04:16 PM, Andrew Laski wrote:


On Wed, Mar 30, 2016, at 03:54 PM, Matt Riedemann wrote:


On 3/30/2016 2:42 PM, Andrew Laski wrote:


On Wed, Mar 30, 2016, at 03:26 PM, 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) -

Selfishly I'd like Laski to be as focused on cells v2 as possible, but
he does have a spec up related to this.

At the midcycle I agreed to look into the oslo.policy work involved with
this because I have some experience there. I wasn't planning to be much
involved beyond that, and Claudiu has a spec up for the API side of it.
But in my mind there's a chain backwards from capabilities API to
discoverable policy and I want to move the oslo.policy work ahead
quickly if I can to unblock that.


There is a CLI that does something like what you want already:

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

You basically want a server based version of that that returns all the 
"true" values.






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.

Agree to keep the priority list as small as possible, because this is
just a part of our overall backlog of priorities.


* Lower Priority Background Work *

- POC of Gabbi for additional API validation

I'm assuming cdent would be driving this, and he's also working on the
resource providers stuff for the scheduler, but might be a decent side
project for him to stay sane.


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


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

Agreed. I would love to drive this forward but there are just too many
other areas to focus on right now.

+1




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

+1


* Things we need to decide this cycle *

- When are we deleting the legacy v2 code base in tree?

Do you have some high-level milestone thoughts here? I thought there was
talk about not even thinking about this until Barcelona?


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

I think this ties directly into the discoverable policy item above. I
may be misunderstanding this proposal but I would expect that it has
some link with what a user is allowed to do. Without some improvements
to the policy handling within Nova this is not currently possible.

Agree with Laski here.




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 

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

[Sean Dague]

On 03/30/2016 04:17 PM, Jay Pipes wrote:
> On 03/30/2016 12:54 PM, Matt Riedemann wrote:
 - POC of Gabbi for additional API validation
>>
>> I'm assuming cdent would be driving this, and he's also working on the
>> resource providers stuff for the scheduler, but might be a decent side
>> project for him to stay sane.
> 
> Actually, Sergey Nikitin can be responsible for driving this effort,
> with guidance from Chris.
> 
 - 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).
> 
> I would prefer to see gabbits validating Nova's API back-microversions
> and instead focus on Tempest validating only the latest microversion API.
> 
> The validation of all the various microversion variations should IMHO be
> the purview of in-tree functional tests within Nova.

That's largely the way it is today, and how I see it going forward (in
tree testing for full coverage, a representative cross section in
Tempest). There are details on the way Tempest works against all
versions of OpenStack that mean that what is in Tempest is really a
baseline set of tests, plus some tests which test integration
functionality at particular microversions if they are available in the
target.

-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 priorities in Newton

[Andrew Laski]

On Wed, Mar 30, 2016, at 03:54 PM, Matt Riedemann wrote:
> 
> 
> On 3/30/2016 2:42 PM, Andrew Laski wrote:
> >
> >
> > On Wed, Mar 30, 2016, at 03:26 PM, 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) -
> 
> Selfishly I'd like Laski to be as focused on cells v2 as possible, but 
> he does have a spec up related to this.

At the midcycle I agreed to look into the oslo.policy work involved with
this because I have some experience there. I wasn't planning to be much
involved beyond that, and Claudiu has a spec up for the API side of it.
But in my mind there's a chain backwards from capabilities API to
discoverable policy and I want to move the oslo.policy work ahead
quickly if I can to unblock that.


> 
> >> 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.
> 
> Agree to keep the priority list as small as possible, because this is 
> just a part of our overall backlog of priorities.
> 
> >>
> >> * Lower Priority Background Work *
> >>
> >> - POC of Gabbi for additional API validation
> 
> I'm assuming cdent would be driving this, and he's also working on the 
> resource providers stuff for the scheduler, but might be a decent side 
> project for him to stay sane.
> 
> >> - 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).
> 
> >> - 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.
> >
> > Agreed. I would love to drive this forward but there are just too many
> > other areas to focus on right now.
> 
> +1
> 
> >
> >
> >> - 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.
> 
> +1
> 
> >>
> >> * Things we need to decide this cycle *
> >>
> >> - When are we deleting the legacy v2 code base in tree?
> 
> Do you have some high-level milestone thoughts here? I thought there was 
> talk about not even thinking about this until Barcelona?
> 
> >>
> >> * 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.
> >
> > I think this ties directly into the discoverable policy item above. I
> > may be misunderstanding this proposal but I would expect that it has
> > some link with what a user is allowed to do. Without some improvements
> > to the policy handling within Nova this is not currently 

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

[Jay Pipes]

On 03/30/2016 12:54 PM, Matt Riedemann wrote:

- POC of Gabbi for additional API validation


I'm assuming cdent would be driving this, and he's also working on the
resource providers stuff for the scheduler, but might be a decent side
project for him to stay sane.


Actually, Sergey Nikitin can be responsible for driving this effort, 
with guidance from Chris.



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


I would prefer to see gabbits validating Nova's API back-microversions 
and instead focus on Tempest validating only the latest microversion API.


The validation of all the various microversion variations should IMHO be 
the purview of in-tree functional tests within Nova.


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 priorities in Newton

[Matt Riedemann]

On 3/30/2016 2:42 PM, Andrew Laski wrote:



On Wed, Mar 30, 2016, at 03:26 PM, 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) -


Selfishly I'd like Laski to be as focused on cells v2 as possible, but 
he does have a spec up related to this.



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.


Agree to keep the priority list as small as possible, because this is 
just a part of our overall backlog of priorities.




* Lower Priority Background Work *

- POC of Gabbi for additional API validation


I'm assuming cdent would be driving this, and he's also working on the 
resource providers stuff for the scheduler, but might be a decent side 
project for him to stay sane.



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



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


Agreed. I would love to drive this forward but there are just too many
other areas to focus on right now.


+1





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


+1



* Things we need to decide this cycle *

- When are we deleting the legacy v2 code base in tree?


Do you have some high-level milestone thoughts here? I thought there was 
talk about not even thinking about this until Barcelona?




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


I think this ties directly into the discoverable policy item above. I
may be misunderstanding this proposal but I would expect that it has
some link with what a user is allowed to do. Without some improvements
to the policy handling within Nova this is not currently possible.


Agree with Laski here.






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.


Thanks for writing this up. I'm trying to get all of the nova subteam 
meetings on my calendar, but this one is hard for me to to make on time 
given daycare duties each morning.




-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
Email had 1 attachment:
+ 

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

[Matthew Treinish]

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

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


signature.asc
Description: PGP 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

[Andrew Laski]

On Wed, Mar 30, 2016, at 03:26 PM, 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)
> - 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.

Agreed. I would love to drive this forward but there are just too many
other areas to focus on right now.


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

I think this ties directly into the discoverable policy item above. I
may be misunderstanding this proposal but I would expect that it has
some link with what a user is allowed to do. Without some improvements
to the policy handling within Nova this is not currently possible.


> 
> 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.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> Email had 1 attachment:
> + signature.asc
>   1k (application/pgp-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