Hi, Salvatore
It is totally correct that most Neutron resources have a sloppy status
management. Mostly because, as already pointed out, the 'status' for most
resource was conceived to be a 'network fabric' status rather than a resource
synchronisation status.
Exactly, I reckon that
On 23 May 2014 10:34, Salvatore Orlando sorla...@nicira.com wrote:
As most of you probably know already, this is one of the topics discussed
during the Juno summit [1].
I would like to kick off the discussion in order to move towards a concrete
design.
Preamble: Considering the meat that's
, 2014 4:36 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] Introducing task oriented workflows
On 23 May 2014 10:34, Salvatore Orlando sorla...@nicira.com wrote:
As most of you probably know already, this is one of the topics discussed
On 05/22/2014 08:16 PM, Nachi Ueno wrote:
Hi Salvatore
Thank you for your posting this.
IMO, this topic shouldn't be limited for Neutron only.
Users wants consistent API between OpenStack project, right?
In Nova, a server has task_state, so Neutron should do same way.
We're moving away
Hi Hirofumi,
I reckon this has been immediately recognised as a long term effort.
However, I just want to clarify that by long term I don't mean pushing it
back until we get to the next release cycle and we realize we are in the
same place where we are today!
It is totally correct that most
Hi, Salvatore
I think neutron needs the task management too.
IMO, the problem of neutron resource status should be discussed individually.
Task management enable neutron to roll back API operation and delete trash of
resource, try API operation again in one API process.
Of course, we can use
Nachi,
I will be glad if the solution was as easy as sticking a task_state
attribute to a resource! I'm afraid however that would be only the tip of
the iceberg, or the icing of the cake, if you want.
However, I agree with you that consistency across Openstack APIs is very
important; whether this
Hello,
I think the Mistral Project[1] aims the same goal, isn't it?
Regards,
jaume
[1]: https://wiki.openstack.org/wiki/Mistral
On 23 May 2014 09:28, Salvatore Orlando sorla...@nicira.com wrote:
Nachi,
I will be glad if the solution was as easy as sticking a task_state
attribute to a
I think Cinder has some of the same sauce ?
https://review.openstack.org/#/c/94742/
https://review.openstack.org/#/c/95037/
2014-05-23 10:57 GMT+02:00 Jaume Devesa devv...@gmail.com:
Hello,
I think the Mistral Project[1] aims the same goal, isn't it?
Regards,
jaume
[1]:
While Mistral is a service with its own REST API endpoint, taskflow is a
library (shoot me if I'm wrong here).
Also, mistral appears, in my opinion, to satisfy a set of use cases aimed
at cloud operators rather than for building tasks within an application.
These are the reasons for which I did
On 23/05/14 01:34, Salvatore Orlando wrote:
As most of you probably know already, this is one of the topics discussed
during the Juno summit [1].
I would like to kick off the discussion in order to move towards a concrete
design.
Preamble: Considering the meat that's already on the plate
Hi Salvatore
Thank you for your posting this.
IMO, this topic shouldn't be limited for Neutron only.
Users wants consistent API between OpenStack project, right?
In Nova, a server has task_state, so Neutron should do same way.
2014-05-22 15:34 GMT-07:00 Salvatore Orlando sorla...@nicira.com:
12 matches
Mail list logo
