Open Stack

Hi
We need to take into account that the tenant is well aware to the LBaaS provider (driver) that he is working with.  After all when the tenant create Pool he needs to select a provider.
Can you please change the bug status? https://bugs.launchpad.net/neutron/+bug/1248423
The current status is "Incomplete" which is wrong. A much better status would be:
"Opinion"   OR "Confirmed"

Thanks
Avishay

From: Salvatore Orlando [mailto:sorlando at nicira.com]
Sent: Tuesday, November 19, 2013 7:50 PM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Neutron] - Vendor specific erros

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<mailto: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<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<mailto: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<mailto: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<mailto: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/20131120/16880c0a/attachment.html>