Re: [openstack-dev] [Fuel] Restrictions in Fuel API: nova-network
I'm fine with removing the related code from Fuel then, but I'm not Ok with introducing limitations code. If we don't want to remove the code (and I believe we don't because of backward compatibility reasons), then why don't we just add a warning that this is deprecated / unsopported? And QA will not focus their efforts on this then? On Wed, Jul 29, 2015 at 11:02 AM Sheena Gregson sgreg...@mirantis.com wrote: We restricted this because allowing nova-network to be used as an underlay for all possible combinations added QA time and effort to supporting a soon to be deprecated option. As nova-network is being deprecated upstream and will relatedly be deprecated in Fuel – AFAIK, there is a goal to deprecate nova-network entirely in Fuel 8.0 - we should reduce the number of customers who are even able to use this as the networking underlay to only reflect customers who absolutely require it. There is not sufficient value in supporting nova-network for other use cases. *From:* Mike Scherbakov [mailto:mscherba...@mirantis.com] *Sent:* Wednesday, July 29, 2015 12:47 PM *To:* OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org *Subject:* [openstack-dev] [Fuel] Restrictions in Fuel API: nova-network Folks, why do we even want to introduce restrictions? Please see https://bugs.launchpad.net/fuel/+bug/1470488 about locking nova-network. We already suffer from locked Settings tab in our API. Instead, we just need to introduce a warning, that this option is deprecated and it's on risk of a user to use it. We want Fuel to be flexible, and not too prescriptive. Thanks, -- Mike Scherbakov #mihgen __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mike Scherbakov #mihgen __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Restrictions in Fuel API: nova-network
We restricted this because allowing nova-network to be used as an underlay for all possible combinations added QA time and effort to supporting a soon to be deprecated option. As nova-network is being deprecated upstream and will relatedly be deprecated in Fuel – AFAIK, there is a goal to deprecate nova-network entirely in Fuel 8.0 - we should reduce the number of customers who are even able to use this as the networking underlay to only reflect customers who absolutely require it. There is not sufficient value in supporting nova-network for other use cases. *From:* Mike Scherbakov [mailto:mscherba...@mirantis.com] *Sent:* Wednesday, July 29, 2015 12:47 PM *To:* OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org *Subject:* [openstack-dev] [Fuel] Restrictions in Fuel API: nova-network Folks, why do we even want to introduce restrictions? Please see https://bugs.launchpad.net/fuel/+bug/1470488 about locking nova-network. We already suffer from locked Settings tab in our API. Instead, we just need to introduce a warning, that this option is deprecated and it's on risk of a user to use it. We want Fuel to be flexible, and not too prescriptive. Thanks, -- Mike Scherbakov #mihgen __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] Restrictions in Fuel API: nova-network
I think it becomes challenging to communicate to users why some of the nova-network flows show a warning and are not tested while others appear to work without issue. For example, a customer using multi-HV would see a successful nova-network selection, but if they change to using only KVM/QEMU, it would show a warning. This seems weird to me from a user perspective. That’s not to say we can’t do it, I’m just not sure I see the value we are providing to users by providing unsupported and/or untested flows that are difficult to message correctly. *From:* Mike Scherbakov [mailto:mscherba...@mirantis.com] *Sent:* Wednesday, July 29, 2015 1:14 PM *To:* OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org *Subject:* Re: [openstack-dev] [Fuel] Restrictions in Fuel API: nova-network I'm fine with removing the related code from Fuel then, but I'm not Ok with introducing limitations code. If we don't want to remove the code (and I believe we don't because of backward compatibility reasons), then why don't we just add a warning that this is deprecated / unsopported? And QA will not focus their efforts on this then? On Wed, Jul 29, 2015 at 11:02 AM Sheena Gregson sgreg...@mirantis.com wrote: We restricted this because allowing nova-network to be used as an underlay for all possible combinations added QA time and effort to supporting a soon to be deprecated option. As nova-network is being deprecated upstream and will relatedly be deprecated in Fuel – AFAIK, there is a goal to deprecate nova-network entirely in Fuel 8.0 - we should reduce the number of customers who are even able to use this as the networking underlay to only reflect customers who absolutely require it. There is not sufficient value in supporting nova-network for other use cases. *From:* Mike Scherbakov [mailto:mscherba...@mirantis.com] *Sent:* Wednesday, July 29, 2015 12:47 PM *To:* OpenStack Development Mailing List (not for usage questions) openstack-dev@lists.openstack.org *Subject:* [openstack-dev] [Fuel] Restrictions in Fuel API: nova-network Folks, why do we even want to introduce restrictions? Please see https://bugs.launchpad.net/fuel/+bug/1470488 about locking nova-network. We already suffer from locked Settings tab in our API. Instead, we just need to introduce a warning, that this option is deprecated and it's on risk of a user to use it. We want Fuel to be flexible, and not too prescriptive. Thanks, -- Mike Scherbakov #mihgen __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Mike Scherbakov #mihgen __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Fuel] Restrictions in Fuel API: nova-network
Folks, why do we even want to introduce restrictions? Please see https://bugs.launchpad.net/fuel/+bug/1470488 about locking nova-network. We already suffer from locked Settings tab in our API. Instead, we just need to introduce a warning, that this option is deprecated and it's on risk of a user to use it. We want Fuel to be flexible, and not too prescriptive. Thanks, -- Mike Scherbakov #mihgen __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
