Re: [openstack-dev] [nova] Should we delete the (unexposed) os-pci API?
On 3/17/2017 3:23 PM, Sean Dague wrote: Yes... with fire. Realistically this was about the pinnacle of the extensions on extensions API changes, which is why we didn't even let it into v2 in the first place. Here it is: https://review.openstack.org/457854 -- Thanks, Matt __ 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] [nova] Should we delete the (unexposed) os-pci API?
On Mar 17, 2017, at 3:23 PM, Sean Dague wrote: >> So I move that we delete the (dead) code. Are there good reasons not to? > > Yes... with fire. > > Realistically this was about the pinnacle of the extensions on > extensions API changes, which is why we didn't even let it into v2 in > the first place. Fire does not seem strong enough. -- Ed Leafe signature.asc Description: Message signed with OpenPGP __ 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] [nova] Should we delete the (unexposed) os-pci API?
On 03/17/2017 04:23 PM, Sean Dague wrote: On 03/17/2017 04:19 PM, Matt Riedemann wrote: I was working on writing a spec for a blueprint [1] that would have touched on the os-pci API [2] and got to documenting about how it's not even documented [3] when Alex pointed out that the API is not even enabled [4][5]. It turns out that the os-pci API was added in the Nova V3 API and pulled back out, and [5] was a tracking bug to add it back in with a microversion, and that never happened. Given the ugliness described in [3], and that I think our views on exposing this type of information have changed [6] since it was originally added, I'm proposing that we just delete the API code. The API code itself was added back in Icehouse [7]. I tend to think if someone cared about needing this information in the REST API, they would have asked for it by now. As it stands, it's just technical debt and even if we did expose it, there are existing issues in the API, like the fact that the os-hypervisors extension just takes the compute_nodes.pci_stats dict and dumps it to json out of the REST API with no control over the keys in the response. That means if we ever change the fields in the PciDevicePool object, we implicitly introduce a backward incompatible change in the REST API. So I move that we delete the (dead) code. Are there good reasons not to? [1] https://blueprints.launchpad.net/nova/+spec/service-hyper-pci-uuid-in-api [2] https://github.com/openstack/nova/blob/15.0.0/nova/api/openstack/compute/pci.py [3] https://bugs.launchpad.net/nova/+bug/1673869 [4] https://github.com/openstack/nova/blob/15.0.0/setup.cfg#L132 [5] https://bugs.launchpad.net/nova/+bug/1426241 [6] https://docs.openstack.org/developer/nova/policies.html?highlight=metrics#metrics-gathering [7] https://review.openstack.org/#/c/51135/ Yes... with fire. Realistically this was about the pinnacle of the extensions on extensions API changes, which is why we didn't even let it into v2 in the first place. ++ -jay __ 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] [nova] Should we delete the (unexposed) os-pci API?
On 03/17/2017 04:19 PM, Matt Riedemann wrote: > I was working on writing a spec for a blueprint [1] that would have > touched on the os-pci API [2] and got to documenting about how it's not > even documented [3] when Alex pointed out that the API is not even > enabled [4][5]. > > It turns out that the os-pci API was added in the Nova V3 API and pulled > back out, and [5] was a tracking bug to add it back in with a > microversion, and that never happened. > > Given the ugliness described in [3], and that I think our views on > exposing this type of information have changed [6] since it was > originally added, I'm proposing that we just delete the API code. > > The API code itself was added back in Icehouse [7]. > > I tend to think if someone cared about needing this information in the > REST API, they would have asked for it by now. As it stands, it's just > technical debt and even if we did expose it, there are existing issues > in the API, like the fact that the os-hypervisors extension just takes > the compute_nodes.pci_stats dict and dumps it to json out of the REST > API with no control over the keys in the response. That means if we ever > change the fields in the PciDevicePool object, we implicitly introduce a > backward incompatible change in the REST API. > > So I move that we delete the (dead) code. Are there good reasons not to? > > [1] > https://blueprints.launchpad.net/nova/+spec/service-hyper-pci-uuid-in-api > [2] > https://github.com/openstack/nova/blob/15.0.0/nova/api/openstack/compute/pci.py > > [3] https://bugs.launchpad.net/nova/+bug/1673869 > [4] https://github.com/openstack/nova/blob/15.0.0/setup.cfg#L132 > [5] https://bugs.launchpad.net/nova/+bug/1426241 > [6] > https://docs.openstack.org/developer/nova/policies.html?highlight=metrics#metrics-gathering > > [7] https://review.openstack.org/#/c/51135/ > Yes... with fire. Realistically this was about the pinnacle of the extensions on extensions API changes, which is why we didn't even let it into v2 in the first place. -Sean -- Sean Dague http://dague.net __ 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] [nova] Should we delete the (unexposed) os-pci API?
I was working on writing a spec for a blueprint [1] that would have touched on the os-pci API [2] and got to documenting about how it's not even documented [3] when Alex pointed out that the API is not even enabled [4][5]. It turns out that the os-pci API was added in the Nova V3 API and pulled back out, and [5] was a tracking bug to add it back in with a microversion, and that never happened. Given the ugliness described in [3], and that I think our views on exposing this type of information have changed [6] since it was originally added, I'm proposing that we just delete the API code. The API code itself was added back in Icehouse [7]. I tend to think if someone cared about needing this information in the REST API, they would have asked for it by now. As it stands, it's just technical debt and even if we did expose it, there are existing issues in the API, like the fact that the os-hypervisors extension just takes the compute_nodes.pci_stats dict and dumps it to json out of the REST API with no control over the keys in the response. That means if we ever change the fields in the PciDevicePool object, we implicitly introduce a backward incompatible change in the REST API. So I move that we delete the (dead) code. Are there good reasons not to? [1] https://blueprints.launchpad.net/nova/+spec/service-hyper-pci-uuid-in-api [2] https://github.com/openstack/nova/blob/15.0.0/nova/api/openstack/compute/pci.py [3] https://bugs.launchpad.net/nova/+bug/1673869 [4] https://github.com/openstack/nova/blob/15.0.0/setup.cfg#L132 [5] https://bugs.launchpad.net/nova/+bug/1426241 [6] https://docs.openstack.org/developer/nova/policies.html?highlight=metrics#metrics-gathering [7] https://review.openstack.org/#/c/51135/ -- Thanks, Matt __ 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
