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-requ...@lists.openstack.org?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > __________________________________________________________________________ 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