On Sep 29, 2018, at 10:40 AM, Jay Pipes <jaypi...@gmail.com> wrote: > >> So here it is. Two of the top influencers in placement, one saying we >> shouldn't overload traits, the other saying we shouldn't add a primitive >> that would obviate the need for that. Historically, this kind of >> disagreement seems to result in an impasse: neither thing happens and >> those who would benefit are forced to find a workaround or punt. >> Frankly, I don't particularly care which way we go; I just want to be >> able to do the things. > > 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. > > 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 that there is huge difference between the Placement service stating "this is how you use this service" and actively preventing others from doing dumb things with Placement. If we, as a team, tell others that it is OK to manage state, or use a trait name to encode multiple bits of information, then others will be more likely to do just that, and end up with an unreadable mess around their part of the code that works with placement. The result will be a perception among others along the lines of "placement sucks". If we state clearly that this is not a good way to work with Placement, and they do so anyway, well, that's on them. So we shouldn't enforce anything about trait names except the custom namespace and the length. If other service want to be overly clever and try to overload a trait name, it's up to them to deal with the resulting mess. But in no way should we *ever* encourage, even tacitly, this approach. -- Ed Leafe
signature.asc
Description: Message signed with OpenPGP
__________________________________________________________________________ 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
