Re: [openstack-dev] [Neutron] - Vendor specific erros
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:sorla...@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 avish...@radware.commailto:avish...@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:sorla...@nicira.commailto:sorla...@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 avish...@radware.commailto:avish...@radware.com wrote: Hi Some of the DB entities in the LBaaS domain inherit from HasStatusDescriptionhttps://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@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Neutron] - Vendor specific erros
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:sorla...@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 avish...@radware.commailto:avish...@radware.com wrote: Hi Some of the DB entities in the LBaaS domain inherit from HasStatusDescriptionhttps://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@lists.openstack.orgmailto:OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 avish...@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:sorla...@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 avish...@radware.com wrote: Hi Some of the DB entities in the LBaaS domain inherit from HasStatusDescriptionhttps://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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
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 avish...@radware.com wrote: Hi Some of the DB entities in the LBaaS domain inherit from HasStatusDescriptionhttps://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@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
