Re: [placement][nova][ptg] Protecting driver-provided traits
On Thu, 11 Apr 2019, Adam Spiers wrote:
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.
It's not a dumb idea, but it's not really an idea we want to pursue. We've made an effort to keep both os-traits and os-resource-classes as dumb and "symbol only" as possible, minimizing code and metadata. Indicating ownership would require metadata. Enforcing it would require some form of code.
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.
Seeing as there's no huge drive for action on this topic, I've marked this topic as decided ("do nothing") on the etherpad [1] and we can ignore this thread henceforth. If people have additional ideas and thoughts please feel free to keep it alive. [1] https://etherpad.openstack.org/p/placement-ptg-train -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
Chris Dent <cdent+os@anticdent.org> wrote:
On Thu, 11 Apr 2019, Adam Spiers wrote:
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.
It's not a dumb idea, but it's not really an idea we want to pursue. We've made an effort to keep both os-traits and os-resource-classes as dumb and "symbol only" as possible, minimizing code and metadata. Indicating ownership would require metadata.
I was thinking of something like DRIVER_TRAITS = [ ot.COMPUTE_FOO, ot.COMPUTE_BAR, ... ] which seems to me more like data than metadata, and would presumably meet the requirement to be dumb and "symbol only". In fact, even without that we could just test for the COMPUTE_ prefix and that would cover all but one segment of the Venn diagram https://pasteboard.co/I3iqqNm.jpg i.e. the "Should be unset if set by admin (but we're not there yet)" bit.
Enforcing it would require some form of code.
Sure. I don't understand the policy code yet, but at a wild guess it would need separate policies for human admins vs. nova.
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.
Seeing as there's no huge drive for action on this topic, I've marked this topic as decided ("do nothing") on the etherpad [1] and we can ignore this thread henceforth.
Well, there's still the small matter of where to include the Venn diagram. As I wrote in a previous email (which you may have not seen; for some reason it didn't show up in the list archives yet), the idea of putting it at the bottom of https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#c... was already rejected, otherwise it would have been there already: https://review.openstack.org/#/c/644293/2/doc/source/admin/configuration/sch... But other than that, I'm fine with "do nothing".
Well, there's still the small matter of where to include the Venn diagram. As I wrote in a previous email (which you may have not seen; for some reason it didn't show up in the list archives yet),
Hm, no, didn't show up in my inbox either.
the idea of putting it at the bottom of https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#c...
was already rejected, otherwise it would have been there already: https://review.openstack.org/#/c/644293/2/doc/source/admin/configuration/sch...
Oh, I see. I get Matt's point, though I'm not sure I agree. I suppose the diagram is most useful for developers rather than admins. If there's a way we can put it somewhere permanent (that doesn't have ads) we could link it from code comments? Or find the spec that talks about this and link it from there? E
Eric Fried <openstack@fried.cc> wrote:
Adam Spiers <aspiers@suse.com> wrote:
Well, there's still the small matter of where to include the Venn diagram.
[snipped]
the idea of putting it at the bottom of https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#c...
was already rejected, otherwise it would have been there already: https://review.openstack.org/#/c/644293/2/doc/source/admin/configuration/sch...
Oh, I see. I get Matt's point, though I'm not sure I agree. I suppose the diagram is most useful for developers rather than admins. If there's a way we can put it somewhere permanent (that doesn't have ads) we could link it from code comments?
I really think it belongs in one of our repos rather than an external SaaS which we can't rely on long-term. After all it's only a small SVG. Code comments could of course refer to an SVG within the repo, but I suspect that would be too well hidden to be particularly useful. Perhaps at the PTG we can find somewhere appropriate within the developer docs. In fact maybe this is a reasonable location? https://docs.openstack.org/nova/latest/reference/update-provider-tree.html
Or find the spec that talks about this and link it from there?
I think I already did that but realistically I don't think that's discoverable enough to be useful to anyone except a tiny handful who are occasionally inclined to perform some archaeology ;-)
In fact maybe this is a reasonable location? https://docs.openstack.org/nova/latest/reference/update-provider-tree.html
I'm not sure that's any more discoverable than the spec (you may be overestimating the readership of our reference docs :), but sure. And I don't see a problem putting the .svg file in-repo - is there an issue with that, anyone? efried .
On Wed, 2019-04-24 at 17:54 -0500, Eric Fried wrote:
In fact maybe this is a reasonable location? https://docs.openstack.org/nova/latest/reference/update-provider-tree.html
I'm not sure that's any more discoverable than the spec (you may be overestimating the readership of our reference docs :), but sure.
And I don't see a problem putting the .svg file in-repo - is there an issue with that, anyone? we already have a bunch of them https://github.com/openstack/nova/tree/master/doc/source/figures
efried .
Sean Mooney <smooney@redhat.com> wrote:
On Wed, 2019-04-24 at 17:54 -0500, Eric Fried wrote:
In fact maybe this is a reasonable location? https://docs.openstack.org/nova/latest/reference/update-provider-tree.html
I'm not sure that's any more discoverable than the spec (you may be overestimating the readership of our reference docs :), but sure.
And I don't see a problem putting the .svg file in-repo - is there an issue with that, anyone?
we already have a bunch of them https://github.com/openstack/nova/tree/master/doc/source/figures
OK then, now submitted: https://review.opendev.org/#/c/656032/
Chris Dent <cdent+os@anticdent.org> wrote:
On Thu, 11 Apr 2019, Adam Spiers wrote:
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.
It's not a dumb idea, but it's not really an idea we want to pursue. We've made an effort to keep both os-traits and os-resource-classes as dumb and "symbol only" as possible, minimizing code and metadata. Indicating ownership would require metadata.
I was thinking of something like
DRIVER_TRAITS = [ ot.COMPUTE_FOO, ot.COMPUTE_BAR, ... ] a simple list like this seams resonable to me but im not conviced this shoudl live in os-traits. this set would vary per driver.
On Fri, 2019-04-12 at 13:57 +0100, Adam Spiers wrote: the virdrivers dont just set traits that are confied to the COMPUTE_ prefix and i dont think the drivers should own everything in the hardware namespace. https://github.com/openstack/os-traits/tree/master/os_traits/hw
which seems to me more like data than metadata, and would presumably meet the requirement to be dumb and "symbol only".
In fact, even without that we could just test for the COMPUTE_ prefix and that would cover all but one segment of the Venn diagram
so to not shoot ourselves in the foot in the future im not sure we want to assume that everything under the compute namespace would never be added by and by an operator. but on the other had looking at the traits in https://github.com/openstack/os-traits/tree/master/os_traits/compute i think all the current ones are things that likely only the virt driver would set. if we want to enforce that restion it would be betteer to start now before we add somethign that could be reused for a differnt usecase.
https://pasteboard.co/I3iqqNm.jpg
i.e. the "Should be unset if set by admin (but we're not there yet)" bit.
Enforcing it would require some form of code.
Sure. I don't understand the policy code yet, but at a wild guess it would need separate policies for human admins vs. nova.
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.
Seeing as there's no huge drive for action on this topic, I've marked this topic as decided ("do nothing") on the etherpad [1] and we can ignore this thread henceforth.
Well, there's still the small matter of where to include the Venn diagram. As I wrote in a previous email (which you may have not seen; for some reason it didn't show up in the list archives yet), the idea of putting it at the bottom of
https://docs.openstack.org/nova/latest/admin/configuration/schedulers.html#c...
was already rejected, otherwise it would have been there already:
https://review.openstack.org/#/c/644293/2/doc/source/admin/configuration/sch...
But other than that, I'm fine with "do nothing".
participants (4)
-
Adam Spiers
-
Chris Dent
-
Eric Fried
-
Sean Mooney