Open Stack

To add more context to what Nachi quoted, in general the operational status
of a virtual advanced network service depends on the drivers that
implements it.
So far, the drivers being developed for firewall, VPN, and possibly even
Load Balancing all implement the same architecture. In my opinion it would
therefore make sense to adopt the same approach for all of them, but I do
not regard this as a strict requirement.

>From the API users perspective, it is important to provide a consistent
behaviour. This behaviour, if I get the architecture right, is that it
should not be possible to operate on resources in 'PENDING' state, and this
is what should be enforced as a requirement in all these API extensions.
Summarizing the 'state machine' for these resources is not required to be
exactly the same - but it is important that API users have a consistent
experience.

Then it might be argued that ideally there should be no PENDING state - API
requests should always be accepted and executed; but it looks like that
with the current architecture this would have required work for queueing
requests on drivers, which is probably too much for this release.

Salvatore




On 27 July 2013 00:27, Nachi Ueno <nachi at ntti3.com> wrote:

> Hi folks
>
> I got review comment from Salvatore about FSM management of resources
>
> ### Quote ####
>
>  management of PENDING statuses. It would be great if we find an
> agreement across the LB, VPN, and FW extensions to handle them in the
> same way. Doing it differently for each extension might confuse users.
> Note that the approach is similar to FW but there are subtle
> difference, such as in the FW extension one is not allowed to update a
> firewall rule is an update is already in progess
>
> #############
>
> Thanks!  Salvatore, I think this is very good topic.
>
> I'm +1 for current FWaaS design.
>
> I wrote FSM matrix here.
>
>
> https://docs.google.com/spreadsheet/ccc?key=0Ap9P99ymj9wLdEt0NTN3cV80cDJqaXdONS1jMWNDQnc#gid=0
>
> It is great if we can agree on this.
> so any comment is appreciated.
>
> Thanks
> Nachi
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20130727/27d6c179/attachment.html>