On 09/28/2018 07:23 PM, Mohammed Naser wrote:
> On Fri, Sep 28, 2018 at 7:17 PM Chris Dent wrote:
>>
>> On Fri, 28 Sep 2018, melanie witt wrote:
>>
>>> I'm concerned about a lot of repetition here and maintenance headache for
>>> operators. That's where the thoughts about whether we should
Hi All,
I'm quite late to the discussion, because I'm on vacation and I missed
the beginning of this thread, but let me share a few thoughts.
On Fri, Sep 28, 2018 at 6:13 PM Jay Pipes wrote:
> * Does the provider belong to physical network "corpnet" and also
> support creation of virtual NICs
>> I still want to use something like "Is capable of RAID5" and/or "Has
>> RAID5 already configured" as part of a scheduling and placement
>> decision. Being able to have the GET /a_c response filtered down to
>> providers with those, ahem, traits is the exact purpose of that operation.
>
> And
On 10/01/2018 01:20 PM, Eric Fried wrote:
I agree that we should not overload placement as a mechanism to pass
configuration information ("set up RAID5 on my storage, please") to the
driver. So let's put that aside. (Looking forward to that spec.)
ack.
I still want to use something like "Is
On 09/29/2018 10:40 AM, Jay Pipes wrote:
> On 09/28/2018 04:36 PM, Eric Fried 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
> It sounds like you might be saying, "I would rather not see encoded
> trait names OR a new key/value primitive; but if the alternative is
> ending up with 'a much larger mess', I would accept..." ...which?
>
> Or is it, "We should not implement a key/value primitive, nor should we
> implement
Dan-
On 10/01/2018 10:06 AM, Dan Smith wrote:
> 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
>>
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
> 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".
Right, but words have meanings, and everyone is better off if that
meaning is common amongst everyone doing the talking. So if
On 28/09/18 1:19 PM, Chris Dent wrote:
They aren't arbitrary. They are there for a reason: a trait is a
boolean capability. It describes something that either a provider is
capable of supporting or it isn't.
This is somewhat (maybe even only slightly) different from what I
think the
On Sat, 29 Sep 2018, Jay Pipes wrote:
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
On Sat, Sep 29, 2018 at 12:02 PM Ed Leafe wrote:
> On Sep 28, 2018, at 12:19 PM, Chris Dent wrote:
> > I don't think placement should be concerned about temporal aspects
> > of traits. If we can't write a web service that can handle setting
> > lots of traits every second of every day, we
On Sep 28, 2018, at 12:19 PM, Chris Dent wrote:
>
> I don't think placement should be concerned about temporal aspects
> of traits. If we can't write a web service that can handle setting
> lots of traits every second of every day, we should go home. If
> clients of placement want to set weird
On Sep 29, 2018, at 10:40 AM, Jay Pipes 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
On 09/28/2018 04:36 PM, Eric Fried 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:
On Fri, 28 Sep 2018 at 22:07, melanie witt wrote:
> On Fri, 28 Sep 2018 15:42:23 -0500, 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 wrote:
> >>> It's time somebody said this.
> >>>
> >>> Every time we turn a
To add some context around what I suspect is the reason for the most recent
incarnation of this debate, many Ironic users have a requirement to be able
to influence the configuration of a server at deploy time, beyond the
existing supported mechanisms. The classic example is hardware RAID - the
Sorry for append another email for something I missed to say.
Alex Xu 于2018年9月29日周六 上午10:01写道：
>
>
> Jay Pipes 于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
>> wrote:
Jay Pipes 于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 wrote:
> >>> It's time somebody said this.
> >>>
> >>> Every time we turn a corner or look under a rug, we find
Chris Dent 于2018年9月29日周六 上午1:19写道：
> On Fri, 28 Sep 2018, Jay Pipes wrote:
>
> > On 09/28/2018 09:25 AM, Eric Fried wrote:
> >> It's time somebody said this.
>
> Yes, a useful topic, I think.
>
++, I'm interesting this topic also, since it confuses me for a long time...
>
> >> Every time we
On Fri, Sep 28, 2018 at 7:17 PM Chris Dent wrote:
>
> On Fri, 28 Sep 2018, melanie witt wrote:
>
> > I'm concerned about a lot of repetition here and maintenance headache for
> > operators. That's where the thoughts about whether we should provide
> > something like a key-value construct to API
On Fri, 28 Sep 2018, melanie witt wrote:
I'm concerned about a lot of repetition here and maintenance headache for
operators. That's where the thoughts about whether we should provide
something like a key-value construct to API callers where they can instead
say:
* OWNER=CINDER
* RAID=10
*
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 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
On Fri, 28 Sep 2018 15:42:23 -0500, 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 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.
On 09/28/2018 09:41 AM, Balázs Gibizer wrote:
>
>
> On Fri, Sep 28, 2018 at 3:25 PM, Eric Fried 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
On 09/28/2018 12:19 PM, Chris Dent wrote:
> On Fri, 28 Sep 2018, Jay Pipes wrote:
>
>> On 09/28/2018 09:25 AM, Eric Fried wrote:
>>> It's time somebody said this.
>
> Yes, a useful topic, I think.
>
>>> Every time we turn a corner or look under a rug, we find another use
>>> case for provider
On Fri, 28 Sep 2018, Jay Pipes wrote:
On 09/28/2018 09:25 AM, Eric Fried wrote:
It's time somebody said this.
Yes, a useful topic, I think.
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
On 09/28/2018 09:25 AM, Eric Fried 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"
On 28/09/18 9:25 AM, Eric Fried 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
On Fri, Sep 28, 2018 at 3:25 PM, Eric Fried 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
Eric,
Very well said, I completely agree with you. We should not hold
ourselves back based upon perceptions of original intended purpose.
Things do change. We have to accept that. We must normalize this fact
in our actions moving forward.
That being said, I'm not entirely sure I'm personally
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
32 matches
Mail list logo
