On 09/28/2018 09:41 AM, Balázs Gibizer wrote: > > > On Fri, Sep 28, 2018 at 3:25 PM, Eric Fried <openst...@fried.cc> wrote: >> It's time somebody said this. >> >> Every time we turn a corner or look under a rug, we find another use >> case for provider traits in placement. But every time we have to have >> the argument about whether that use case satisfies the original >> "intended purpose" of traits. >> >> That's only reason I've ever been able to glean: that it (whatever "it" >> is) wasn't what the architects had in mind when they came up with the >> idea of traits. We're not even talking about anything that would require >> changes to the placement API. Just, "Oh, that's not a *capability* - >> shut it down." >> >> Bubble wrap was originally intended as a textured wallpaper and a >> greenhouse insulator. Can we accept the fact that traits have (many, >> many) uses beyond marking capabilities, and quit with the arbitrary >> restrictions? > > How far are we willing to go? Does an arbitrary (key: value) pair > encoded in a trait name like key_`str(value)` (e.g. CURRENT_TEMPERATURE: > 85 encoded as CUSTOM_TEMPERATURE_85) something we would be OK to see in > placement?
Great question. Perhaps TEMPERATURE_DANGEROUSLY_HIGH is okay, but TEMPERATURE_<specific_number> is not. This thread isn't about setting these parameters; it's about getting us to a point where we can discuss a question just like this one without running up against: "That's a hard no, because you shouldn't encode key/value pairs in traits." "Oh, why's that?" "Because that's not what we intended when we created traits." "But it would work, and the alternatives are way harder." "-1" "But..." "-1" > > Cheers, > gibi > >> >> __________________________________________________________________________ >> >> 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 __________________________________________________________________________ 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
