Open Stack

Dan-

On 10/01/2018 10:06 AM, Dan Smith wrote:
> I was out when much of this conversation happened, so I'm going to
> summarize my opinion here.
> 
>> 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 agree with what Chris holds sacred here, which is that placement
> shouldn't ever care about what the trait names are or what they mean to
> someone else. That also extends to me hoping we never implement a
> generic key=value store on resource providers in placement.
> 
>>> 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 definitely agree with what Jay holds sacred here, which is that
> abusing the data model to encode key=value information into single trait
> strings is bad (which is what you're doing with something like
> PCI_ADDRESS_01_AB_23_CD).
> 
> I don't want placement (the code) to try to put any technical
> restrictions on the meaning of trait names, in an attempt to try to
> prevent the above abuse. I agree that means people _can_ abuse it if
> they wish, which I think is Chris' point. However, I think it _is_
> important for the placement team (the people) to care about how
> consumers (nova, etc) use traits, and thus provide guidance on that is
> necessary. Not everyone will follow that guidance, but we should provide
> it. Projects with history-revering developers on both sides of the fence
> can help this effort if they lead by example.
> 
> If everyone goes off and implements their way around the perceived
> restriction of not being able to ask placement for RAID_LEVEL>=5, we're
> going to have a much larger mess than the steaming pile of extra specs
> in nova that we're trying to avoid.

Sorry, I'm having a hard time understanding where you're landing here.

It sounds like you might be saying, "I would rather not see encoded
trait names OR a new key/value primitive; but if the alternative is
ending up with 'a much larger mess', I would accept..." ...which?

Or is it, "We should not implement a key/value primitive, nor should we
implement restrictions on trait names; but we should continue to
discourage (ab)use of trait names by steering placement consumers to..."
...do what?

The restriction is real, not perceived. Without key/value (either
encoded or explicit), how should we steer placement consumers to satisfy
e.g., "Give me disk from a provider with RAID5"?

(Put aside the ability to do comparisons other than straight equality -
so limiting the discussion to RAID_LEVEL=5, ignoring RAID_LEVEL>=5. Also
limiting the discussion to what we want out of GET /a_c - so this
excludes, "And then go configure RAID5 on my storage.")

> 
> --Dan
> 
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>