Open Stack

In general, an error state make sense.
I think you might want to send more details about how this state plugs into
the load balancer state machine, but I reckon it is a generally
non-recoverable state which could be reached by any other state; in that
case it would be a generic enough case which might be supported by all
drivers.

It is good to point out that driver-specific state transitions however, in
my opinion, are to avoid; application using the Neutron API will become
non-portable, or at least users of the Neutron API would need to be aware
that an entity might have a different state machine from driver to driver,
which I reckon would be bad enough for a developer to decide to switch over
to Cloudstack or AWS APIs!

Salvatore

PS: On the last point I am obviously joking, but not so much.



On 12 November 2013 08:00, Avishay Balderman <AvishayB at radware.com> wrote:

>
>
> Hi
>
> Some of the DB entities in the LBaaS domain inherit from
> HasStatusDescription<https://github.com/openstack/neutron/blob/master/neutron/db/models_v2.py#L40>
>
> With this we can set the entity status (ACTIVE, PENDING_CREATE,etc) and a
> description for the status.
>
> There are flows in the Radware LBaaS driver that the  driver needs to set
> the entity status to ERROR and it is able to set the description of the
> error –  the description is Radware specific.
>
> My question is:  Does it make sense to do that?
>
> After all the tenant is aware to the fact that he works against Radware
> load balancer -  the tenant selected Radware as the lbaas provider in the
> UI.
>
> Any reason not to do that?
>
>
>
> This is a generic issue/question and does not relate  to a specific plugin
> or driver.
>
>
>
> Thanks
>
>
>
> Avishay
>
> _______________________________________________
> 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/20131114/22e05326/attachment.html>