Open Stack

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