Open Stack

Thanks Avishay.

I think the status description error was introduced with this aim.
Whether vendor-specific error descriptions can make sense to a tenant,
that's a good question.
Personally, I feel like as a tenant that information would not be a lot
useful to me, as I would not be able to do any debug or maintenance on the
appliance where the error was generated; on the other hand, as a deployer I
might find that message very useful, but probably I would look for it in
the logs rather than in API responses; furthermore, as a deployer I might
find more convenient to not provide tenants any detail about the peculiar
driver being used.

On this note however, this is just my personal opinion. I'm sure there are
plenty of valid use cases for giving tenants vendor-specific error messages.

Salvatore


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

>  Hi Salvatore
>
> I think you are mixing between the state machine (ACTIVE,PENDEING_XYZ,etc)
>  and the status description
>
> All I want to do is to write a vendor specific error message when the
> state is ERROR.
>
> I DO NOT want to touch the state machine.
>
>
>
> See: https://bugs.launchpad.net/neutron/+bug/1248423
>
>
>
> Thanks
>
>
>
> Avishay
>
>
>
> *From:* Salvatore Orlando [mailto:sorlando at nicira.com]
> *Sent:* Thursday, November 14, 2013 1:15 PM
> *To:* OpenStack Development Mailing List (not for usage questions)
> *Subject:* Re: [openstack-dev] [Neutron] - Vendor specific erros
>
>
>
> 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
>
>
>
> _______________________________________________
> 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/20131119/fe539ef0/attachment.html>