Sorry for append another email for something I missed to say. Alex Xu <sou...@gmail.com> 于2018年9月29日周六 上午10:01写道：
> > > Jay Pipes <jaypi...@gmail.com> 于2018年9月29日周六 上午5:51写道： > >> On 09/28/2018 04:42 PM, Eric Fried wrote: >> > 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. >> >> That's correct, because you're encoding >1 piece of information into the >> single string (the fact that it's a temperature *and* the value of that >> temperature are the two pieces of information encoded into the single >> string). >> >> Now that there's multiple pieces of information encoded in the string >> the reader of the trait string needs to know how to decode those bits of >> information, which is exactly what we're trying to avoid doing (because >> we can see from the ComputeCapabilitiesFilter, the extra_specs mess, and >> the giant hairball that is the NUMA and CPU pinning "metadata requests" >> how that turns out). >> > > May I understand the one of Jay's complain is about metadata API > undiscoverable? That is extra_spec mess and ComputeCapabilitiesFilter mess? > If yes, then we resolve the discoverable by the "/Traits" API. > > Another complain is about the information in the string. Agree with that > TEMPERATURE_<specific_number> is terriable. > I prefer the way I used in nvdimm proposal now, I don't want to use Trait > NVDIMM_DEVICE_500GB, NVDIMM_DEVICE_1024GB. I want to put them into the > different resource provider, and use min_size, max_size limit the > allocation. And the user will request with resource class like > RC_NVDIMM_GB=512. > TEMPERATURE_<specific_number> is wrong, as the way using it. But I don't thing the version of BIOS is wrong, I don't expect the end user to ready the information from the trait directly, there should document from the admin to explain more. The version of BIOS should be a thing understand by the admin, then it is enough. > >> >> > 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..." >> > >> > "-I >> >> I believe I've articulated a number of times why traits should remain >> unary pieces of information, and not just said "because that's what we >> intended when we created traits". >> >> I'm tough on this because I've seen the garbage code and unmaintainable >> mess that not having structurally sound data modeling concepts and >> information interpretation rules leads to in Nova and I don't want to >> encourage any more of it. >> >> -jay >> >> >> __________________________________________________________________________ >> 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
