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. --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