On Sat, 29 Sep 2018, Jay Pipes wrote:
I don't think that's a fair statement. You absolutely *do* care which way we go. You want to encode multiple bits of information into a trait string -- such as "PCI_ADDRESS_01_AB_23_CD" -- and leave it up to the caller to have to understand that this trait string has multiple bits of information encoded in it (the fact that it's a PCI device and that the PCI device is at 01_AB_23_CD).You don't see a problem encoding these variants inside a string. Chris doesn't either.
Lest I be misconstrued, I'd like to clarify: What I was trying to say elsewhere in the thread was that placement should never be aware of _anything_ that is in the trait string (except CUSTOM_* when validating ones that are added, and MISC_SHARES[...] for sharing providers). On the placement server side, input is compared solely for equality with stored data and nothing else, and we should never allow value comparisons, string fragments, regex, etc. So from a code perspective _placement_ is completely agnostic to whether a trait is "PCI_ADDRESS_01_AB_23_CD", "STORAGE_DISK_SSD", or "JAY_LIKES_CRUNCHIE_BARS". However, things which are using traits (e.g., nova, ironic) need to make their own decisions about how the value of traits are interpreted. I don't have a strong position on that except to say that _if_ we end up in a position of there being lots of traits willy nilly, people who have chosen to do that need to know that the contract presented by traits right now (present or not present, no value comprehension) is fixed.
I *do* see a problem with it, based on my experience in Nova where this kind of thing leads to ugly, unmaintainable, and incomprehensible code as I have pointed to in previous responses.
I think there are many factors that have led to nova being incomprehensible and indeed bad representations is one of them, but I think reasonable people can disagree on which factors are the most important and with sufficient discussion come to some reasonable compromises. I personally feel that while the bad representations (encoding stuff in strings or json blobs) thing is a big deal, another major factor is a predilection to make new apis, new abstractions, and new representations rather than working with and adhering to the constraints of the existing ones. This leads to a lot of code that encodes business logic in itself (e.g., several different ways and layers of indirection to think about allocation ratios) rather than working within strong and constraining contracts.
From my standpoint there isn't much to talk about here from a
placement code standpoint. We should clearly document the functional contract (and stick to it) and we should come up with exemplars for how to make the best use of traits. I think this conversation could allow us to find those examples. I don't, however, want placement to be a traffic officer for how people do things. In the context of the orchestration between nova and ironic and how that interaction happens, nova has every right to set some guidelines if it needs to. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent
__________________________________________________________________________ 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
