[placement][nova][ptg] Protecting driver-provided traits
From the etherpad [0]:
* We might want to tighten up what the RP traits API allows as per https://pasteboard.co/I3iqqNm.jpg * although maybe this is better covered in a nova session? * If the mechanism is changing how nova-compute reports and manipulates traits, then yeah, nova. But if for some reason there is a need to change the actual API [1], placement; but I would hope that all avenues not involving changing the API were first disposed as either not possible, or really really terrible. This came up as part of the work on compute capabilities as traits [2] and questions about who owns what traits and how to manage them so that unexpected trait clobbering or trait addition happens. This is (hopefully) mostly a thing on the nova-compute side of the equation (when managing inventory), so hopefully someone with more insight into that situation can drive this thread. What needs to happen here? [0] https://etherpad.openstack.org/p/placement-ptg-train [1] There are degrees of change in the API. Adding a query parameter is much less of a big deal than adding or changing an attribute in a request or response body. Adding another method to a URI, while a big deal in some cases, is much less of a big deal than adding an entirely new URI. [2] https://review.openstack.org/#/c/538498/k -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
Today we've got the principle of "don't do that," which we've expressed in the docs: https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#c... Trying to enforce those principles programmatically beyond what we've already done is going to be tricky, and as long as operators behave and read the docs (even if it's after we've marked their bug report as Invalid with the above link), mork work than benefit. So I'm going to vote "do nothing for now". efried .
On Wed, 10 Apr 2019, Eric Fried wrote:
Today we've got the principle of "don't do that," which we've expressed in the docs:
https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#c...
Trying to enforce those principles programmatically beyond what we've already done is going to be tricky, and as long as operators behave and read the docs (even if it's after we've marked their bug report as Invalid with the above link), mork work than benefit.
So I'm going to vote "do nothing for now".
I'm kinda there too, but aspiers put the stuff on the etherpad and seemed to have some concerns, hopefully he'll join in here. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
Chris Dent <cdent+os@anticdent.org> wrote:
On Wed, 10 Apr 2019, Eric Fried wrote:
Today we've got the principle of "don't do that," which we've expressed in the docs:
https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#c...
Trying to enforce those principles programmatically beyond what we've already done is going to be tricky, and as long as operators behave and read the docs (even if it's after we've marked their bug report as Invalid with the above link), mork work than benefit.
So I'm going to vote "do nothing for now".
I'm kinda there too, but aspiers put the stuff on the etherpad and seemed to have some concerns, hopefully he'll join in here.
Not so much concerns as just trying to make sure we don't miss an opportunity to discuss something in person which seemed to cause multiple discussions / redesigns over many months. For example would it be worth considering tweaking the placement API so that only the driver can set/unset traits which it owns? This would avoid the corner case conflict we currently have where a naughty admin messes around with driver traits on RPs. But I'm also fine with "do nothing for now", if that's the current consensus. Although perhaps it would be better to at least spend 5 minutes finding a good place in the docs to insert the Venn diagram: https://pasteboard.co/I3iqqNm.jpg
be worth considering tweaking the placement API so that only the driver can set/unset traits which it owns?
This would entail placement tracking some kind of "owner" attribute (ahem, metadata) on traits. Or maintaining a list of driver-owned traits per resource provider. Or <your idea here>. And then a way to establish a different identity/policy for the virt driver than for the admin. And then a way for the admin to override that anyway because stuff happens. That ^, IMO, is the "more work than benefit" I led with. Happy to be convinced otherwise if there's a (*much*) simpler way to achieve the desired goal.
Although perhaps it would be better to at least spend 5 minutes finding a good place in the docs to insert the Venn diagram: https://pasteboard.co/I3iqqNm.jpg
Yes please. Bottom of [1] seems like the right place. But for heaven's sake, don't violate my privacy [2]. efried [1] https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#c... [2] http://lists.openstack.org/pipermail/openstack-discuss/2019-April/thread.htm...
[resend due to issues with our internal MTA] Eric Fried <openstack@fried.cc> wrote:
be worth considering tweaking the placement API so that only the driver can set/unset traits which it owns?
This would entail placement tracking some kind of "owner" attribute (ahem, metadata) on traits. Or maintaining a list of driver-owned traits per resource provider. Or <your idea here>. And then a way to establish a different identity/policy for the virt driver than for the admin. And then a way for the admin to override that anyway because stuff happens.
That ^, IMO, is the "more work than benefit" I led with. Happy to be convinced otherwise if there's a (*much*) simpler way to achieve the desired goal.
Just thinking out aloud, but how about something as stupid as just maintaining that list of driver-owned traits in os_traits, and exposing a simple trait_is_driver_owned() function which returns a boolean? Then the API implementation could simply check that and return 403 or whatever if the admin tries to mess with a driver-owned trait. Although I'm assuming that there is already some mechanism in there for the API service to distinguish between admin callers and driver callers; if that assumption is wrong then maybe it would take too much more effort to add that.
Although perhaps it would be better to at least spend 5 minutes finding a good place in the docs to insert the Venn diagram: https://pasteboard.co/I3iqqNm.jpg
Yes please. Bottom of [1] seems like the right place.
[1] https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#c...
That idea was already rejected, otherwise it would be there already: https://review.openstack.org/#/c/644293/2/doc/source/admin/configuration/sch...
But for heaven's sake, don't violate my privacy [2].
[2] http://lists.openstack.org/pipermail/openstack-discuss/2019-April/thread.htm...
Sure, no need for that here ;-) We can just add the raw .svg.
On Apr 11, 2019, at 9:10 AM, Adam Spiers <aspiers@suse.com> wrote:
Not so much concerns as just trying to make sure we don't miss an opportunity to discuss something in person which seemed to cause multiple discussions / redesigns over many months. For example would it be worth considering tweaking the placement API so that only the driver can set/unset traits which it owns? This would avoid the corner case conflict we currently have where a naughty admin messes around with driver traits on RPs.
The concept of “owning” particular traits isn’t in Placement. Rather, it is in the domain of the service that is using Placement. So any enforcement regarding which traits are acceptable has to be on the calling end, not in the Placement API. So yeah, “do nothing”. -- Ed Leafe
[resend due to issues with our internal MTA] Ed Leafe <ed@leafe.com> wrote:
The concept of “owning” particular traits isn’t in Placement. Rather, it is in the domain of the service that is using Placement. So any enforcement regarding which traits are acceptable has to be on the calling end, not in the Placement API.
That feels like a slight jump in logic to me: the API can enforce ownership without being the authoritative source of truth for that ownership. For example, as I just suggested elsewhere in this thread, (static) ownership of driver-provided traits could be tracked in os_traits. Maybe that's a dumb idea; I'm not sure. Having said that ...
So yeah, “do nothing”.
I'm totally fine with this too ;-) I only raised it because when I was developing the driver-owned capability traits code, people seemed somewhat concerned with the possibility of admins screwing things up. If the concern is minimal then I'm certainly not religious about adding extra safeguards.
participants (4)
-
Adam Spiers
-
Chris Dent
-
Ed Leafe
-
Eric Fried