Re: [openstack-dev] [api] API recommendation

2014-10-20 Thread Adam Young
On 10/15/2014 11:49 AM, Kevin L. Mitchell wrote: Now that we have an API working group forming, I'd like to kick off some discussion over one point I'd really like to see our APIs using (and I'll probably drop it in to the repo once that gets fully set up): the difference between synchronous and

Re: [openstack-dev] [api] API recommendation

2014-10-18 Thread Jay Pipes
Sorry for top-posting, but Salvatore and Dean, you might find my proposed "vNext" Compute API interesting, since it does what you are describing you'd like to see with regards to task-based APIs: http://docs.oscomputevnext.apiary.io/ Specifically, the schemas and endpoints for tasks and subtas

Re: [openstack-dev] [api] API recommendation

2014-10-17 Thread Peter Balland
On Oct 16, 2014 8:24 AM, "Dean Troyer" wrote: > > > > On Thu, Oct 16, 2014 at 4:57 AM, Salvatore Orlando wrote: >> >> From an API guideline viewpoint, I understand that https://review.openstack.org/#/c/86938/ proposes the introduction of a rather simple endpoint to query active tasks and filter t

Re: [openstack-dev] [api] API recommendation

2014-10-16 Thread Dean Troyer
On Thu, Oct 16, 2014 at 4:57 AM, Salvatore Orlando wrote: > From an API guideline viewpoint, I understand that > https://review.openstack.org/#/c/86938/ proposes the introduction of a > rather simple endpoint to query active tasks and filter them by resource > uuid or state, for example. > That

Re: [openstack-dev] [api] API recommendation

2014-10-16 Thread Alex Xu
2014-10-16 17:57 GMT+08:00 Salvatore Orlando : > In an analysis we recently did for managing lifecycle of neutron > resources, it also emerged that task (or operation) API are a very useful > resource. > Indeed several neutron resources introduced the (in)famous PENDING_XXX > operational statuses

Re: [openstack-dev] [api] API recommendation

2014-10-16 Thread Salvatore Orlando
In an analysis we recently did for managing lifecycle of neutron resources, it also emerged that task (or operation) API are a very useful resource. Indeed several neutron resources introduced the (in)famous PENDING_XXX operational statuses to note the fact that an operation is in progress and its

Re: [openstack-dev] [api] API recommendation

2014-10-15 Thread Christopher Yeoh
On Thu, Oct 16, 2014 at 7:19 AM, Kevin L. Mitchell < kevin.mitch...@rackspace.com> wrote: > On Wed, 2014-10-15 at 12:39 -0400, Andrew Laski wrote: > > On 10/15/2014 11:49 AM, Kevin L. Mitchell wrote: > > > Now that we have an API working group forming, I'd like to kick off > some > > > discussion

Re: [openstack-dev] [api] API recommendation

2014-10-15 Thread Kevin L. Mitchell
On Wed, 2014-10-15 at 12:39 -0400, Andrew Laski wrote: > On 10/15/2014 11:49 AM, Kevin L. Mitchell wrote: > > Now that we have an API working group forming, I'd like to kick off some > > discussion over one point I'd really like to see our APIs using (and > > I'll probably drop it in to the repo on

Re: [openstack-dev] [api] API recommendation

2014-10-15 Thread Sam Harwell
Hi Kevin, In an asynchronous environment that may have multiple clients sending commands to the same resource in a service, an "operation"-type resource is a fundamental prerequisite to creating client applications which report the status of ongoing operations. Without this resource, there is n

Re: [openstack-dev] [api] API recommendation

2014-10-15 Thread Michael McCune
- Original Message - > Thoughts? I like this idea. From my experience with the Sahara project I think there is definite opportunity for this mechanic especially with regards to cluster creation and job executions. regards, mike ___ OpenSta

Re: [openstack-dev] [api] API recommendation

2014-10-15 Thread Andrew Laski
On 10/15/2014 11:49 AM, Kevin L. Mitchell wrote: Now that we have an API working group forming, I'd like to kick off some discussion over one point I'd really like to see our APIs using (and I'll probably drop it in to the repo once that gets fully set up): the difference between synchronous and