Open Stack

Sorry for append another email for something I missed to say.

Alex Xu <soulxu at gmail.com> 于2018年9月29日周六 上午10:01写道：

>
>
> Jay Pipes <jaypipes at 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 <openstack at 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-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20180929/4803096c/attachment.html>