Re: [openstack-dev] [ironic] [nova] traits discussion call - moved to Tue!!

[Eric Fried]

Here's the executive summary of the meeting:

Topic: How does Nova communicate to the Ironic virt driver that the user
wants a particular RAID setup or boot mode or whatever?

o Level set: Traits are an indication of capability, not state.  To be
clear: if a RP (e.g. ironic node) has traits indicating it's capable of
X, Y, Z (mutually exclusive), and you deploy and configure it to do Y,
you should *not* remove traits X and Z from it.  We all agree on this.
Vehemently.  Aggressively.  (But see [1].)

o It would be neat if we could indicate both things from one place,
rather than having to say, "I need a node that is capable of X,"
and also, separately, "Turn X on".

o Proposed: Config Template traits [2]
- A Config Template describes all the complex configuration parameters
  for e.g. a RAID setup.
- It is represented by a name.
- That name can map to a (custom) trait name.
- Now we can decorate any node capable of deploying that config template
  with that trait.
- Specify the trait just like any other in the flavor extra_specs.
- Ironic virt driver sends the trait to Ironic via instance_info.
- Ironic keys off of the trait to look up the Config Template and use it
  to configure the node.

o It was noted that this will wind up being too coarse; eventually
you'll want something more granular.  E.g. you need templates for
"RAID 5 with 4 disks", "RAID 5 with 7 disks", etc.  Ideally we would
pass this info from Nova to Ironic as a separate "thing" (not via a
trait - not even via flavor extra_specs at all).  But for now, Config
Template traits is workable.

o Traits will be set on nodes by Ironic in the same place/way as it sets
up custom per-node resource classes today.

o Specific scenarios were discussed:
  - RAID configurations.  These can be handled by Config Template
traits.
  - Boot modes.  This is tricky because some aspects of boot mode are
capabilities of the node; some are a function of the image; some are
a function of the flavor.  The end result is some combination of all
of these things.

o Note that this trait stuff happens early in the scheduling process.
Placement does the filtering based on traits and resources *first*.
Then stuff gets fed into filters, then weighers.  "Capabilities" will
not be removed short-term.

o Other specs, for reference: [3] [4].

o Action: Jay to propose os-traits for RAID levels and boot modes.

o It was Halloween.  There were costumes.  [5] [6].

[1] (In the future, there may be weigher things, like "preferred" and
"non-preferred".  E.g. my node may have traits RAID5 and
FASTPATH_RAID5 (meaning it can configure itself as RAID-5 faster than some
node that just has RAID5).  I can say
required=RAID5,preferred=FASTPATH_RAID5 and I'll get a node with
RAID5+FASTPATH_RAID5 if available; else just RAID5.

There may also be a "negative trait" concept, so I could say
forbidden=CUSTOM_X,
and the scheduler would *avoid* any node with CUSTOM_X.  This *would* be
a scheduler thing, not a weigher thing.

[2] Config Template traits (ironic-specs):
https://review.openstack.org/#/c/504952/
[3] Support traits in the Ironic driver (nova-specs):
https://review.openstack.org/#/c/507052/
[4] Traits on Ironic Nodes (ironic-specs):
https://review.openstack.org/#/c/504531/
[5] https://leafe.com/tmp/fried.jpg
[6] http://www.taylorbjj.com/wp-content/uploads/2017/11/TheJulia.jpg

On 11/02/2017 12:01 PM, Dmitry Tantsur wrote:
> On 11/02/2017 04:14 PM, Ed Leafe wrote:
>> On Nov 2, 2017, at 4:17 AM, Dmitry Tantsur  wrote:
>>>
>>> The recording of the call is https://bluejeans.com/s/K3wZZ
>>
>> Ugh: "To watch the video, you need Adobe Flash Player 10.1 or higher"
> 
> I know :( There is a way to download them somewhere there. Look for a
> small download sign appearing when you hover the chapter image below.
> 
>>
>>
>> -- Ed Leafe
>>
>>
>>
>>
>>
>>
>> __
>>
>> 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

Re: [openstack-dev] [ironic] [nova] traits discussion call - moved to Tue!!

[Dmitry Tantsur]

On 11/02/2017 04:14 PM, Ed Leafe wrote:

On Nov 2, 2017, at 4:17 AM, Dmitry Tantsur  wrote:


The recording of the call is https://bluejeans.com/s/K3wZZ


Ugh: "To watch the video, you need Adobe Flash Player 10.1 or higher"


I know :( There is a way to download them somewhere there. Look for a small 
download sign appearing when you hover the chapter image below.





-- Ed Leafe






__
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

Re: [openstack-dev] [ironic] [nova] traits discussion call - moved to Tue!!

[Ed Leafe]

On Nov 2, 2017, at 4:17 AM, Dmitry Tantsur  wrote:
> 
> The recording of the call is https://bluejeans.com/s/K3wZZ

Ugh: "To watch the video, you need Adobe Flash Player 10.1 or higher"


-- Ed Leafe






__
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

Re: [openstack-dev] [ironic] [nova] traits discussion call - moved to Tue!!

[Dmitry Tantsur]

Hi all,

The recording of the call is https://bluejeans.com/s/K3wZZ

On 10/30/2017 03:32 PM, Dmitry Tantsur wrote:
It seems that the new time works for the most of key people, so let's move it to 
tomorrow (Tue), the same time, the same bluejeans.


Apologies to those who won't be able to attend, and sorry for the late notice.

On 10/30/2017 03:13 PM, Jay Pipes wrote:
I'd prefer to have you on the call, Dima. How about we push it back to 
tomorrow at the same time?


Can everyone make it then?

-jay

On 10/30/2017 10:11 AM, Dmitry Tantsur wrote:
Aaaand sorry again, but due to sudden errands I won't be able to attend. 
Please feel free to use my bluejeans room anyway. I think my position on 
traits is more or less clear from previous discussions with John, Sam and Eric.


2017-10-24 18:07 GMT+02:00 Dmitry Tantsur >:


    Sigh, sorry. I forgot that we're moving back to winter time this
    weekend. I *think* the time is 3pm UTC then. It seems to be 11am
    eastern US:
https://www.timeanddate.com/worldclock/converter.html?iso=20171030T15=37=tz_et 

. 




    On 10/24/2017 06:00 PM, Dmitry Tantsur wrote:

    And the winner is Mon, 30 Oct, 2pm UTC!

    The bluejeans ID is https://bluejeans.com/757528759
    
    (works without plugins in recent FF and Chrome; if it asks to
    install an app, ignore it and look for a link saying "join with
    browser")

    On 10/23/2017 05:02 PM, Dmitry Tantsur wrote:

    Hi all!

    I'd like to invite you to the discussion of the way to
    implement traits in
    ironic and the ironic virt driver. Please vote for the time at
    https://doodle.com/poll/ts43k98kkvniv8uz
    . Please vote by
    EOD tomorrow.

    Note that it's going to be a technical discussion - please
    make sure you
    understand what traits are and why ironic cares about them.
    See below for more
    context.

    We'll probably use my bluejeans account, as it works without
    plugins in modern
    browsers. I'll post a meeting ID when we pick the date.


    On 10/23/2017 04:09 PM, Eric Fried wrote:

    We discussed this a little bit further in IRC [1]. 
    We're all in

    agreement, but it's worth being precise on a couple of
    points:

    * We're distinguishing between a "feature" and the
    "trait" that
    represents it in placement.  For the sake of this
    discussion, a
    "feature" can (maybe) be switched on or off, but a
    "trait" can either be
    present or absent on a RP.
    * It matters *who* can turn a feature on/off.
 * If it can be done by virt at spawn time, then it
    makes sense to have
    the trait on the RP, and you can switch the feature
    on/off via a
    separate extra_spec.
 * But if it's e.g. an admin action, and spawn has
    no control, then the
    trait needs to be *added* whenever the feature is *on*,
    and *removed*
    whenever the feature is *off*.

    [1]
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-10-23.log.html#t2017-10-23T13:12:13 

 




    On 10/23/2017 08:15 AM, Sylvain Bauza wrote:



    On Mon, Oct 23, 2017 at 2:54 PM, Eric Fried
    >> wrote:

   I agree with Sean.  In general terms:

   * A resource provider should be marked with a
    trait if that feature
 * Can be turned on or off (whether it's
    currently on or not); or
 * Is always on and can't ever be turned off.


    No, traits are not boolean. If a resource provider
    stops providing a
    capability, then the existing related trait should
    just be removed,
    that's it.
    If you see a trait, that's just means that the
    related capability for
    the Resource Provider is supported, that's it too.

    MHO.

    -Sylvain



   * A consumer wanting that feature present
 

Re: [openstack-dev] [ironic] [nova] traits discussion call - moved to Tue!!

[Matt Riedemann]

On 10/30/2017 9:32 AM, Dmitry Tantsur wrote:

the same bluejeans.


Forever in bluejeans?

--

Thanks,

Matt

__
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

Re: [openstack-dev] [ironic] [nova] traits discussion call

[Dmitry Tantsur]

It's a holiday here tomorrow, but I don't have any specific plans, so I think 
I'll be able to make it.


On 10/30/2017 03:13 PM, Jay Pipes wrote:
I'd prefer to have you on the call, Dima. How about we push it back to tomorrow 
at the same time?


Can everyone make it then?

-jay

On 10/30/2017 10:11 AM, Dmitry Tantsur wrote:
Aaaand sorry again, but due to sudden errands I won't be able to attend. 
Please feel free to use my bluejeans room anyway. I think my position on 
traits is more or less clear from previous discussions with John, Sam and Eric.


2017-10-24 18:07 GMT+02:00 Dmitry Tantsur >:


    Sigh, sorry. I forgot that we're moving back to winter time this
    weekend. I *think* the time is 3pm UTC then. It seems to be 11am
    eastern US:

https://www.timeanddate.com/worldclock/converter.html?iso=20171030T15=37=tz_et 


. 




    On 10/24/2017 06:00 PM, Dmitry Tantsur wrote:

    And the winner is Mon, 30 Oct, 2pm UTC!

    The bluejeans ID is https://bluejeans.com/757528759
    
    (works without plugins in recent FF and Chrome; if it asks to
    install an app, ignore it and look for a link saying "join with
    browser")

    On 10/23/2017 05:02 PM, Dmitry Tantsur wrote:

    Hi all!

    I'd like to invite you to the discussion of the way to
    implement traits in
    ironic and the ironic virt driver. Please vote for the time at
    https://doodle.com/poll/ts43k98kkvniv8uz
    . Please vote by
    EOD tomorrow.

    Note that it's going to be a technical discussion - please
    make sure you
    understand what traits are and why ironic cares about them.
    See below for more
    context.

    We'll probably use my bluejeans account, as it works without
    plugins in modern
    browsers. I'll post a meeting ID when we pick the date.


    On 10/23/2017 04:09 PM, Eric Fried wrote:

    We discussed this a little bit further in IRC [1]. 
    We're all in

    agreement, but it's worth being precise on a couple of
    points:

    * We're distinguishing between a "feature" and the
    "trait" that
    represents it in placement.  For the sake of this
    discussion, a
    "feature" can (maybe) be switched on or off, but a
    "trait" can either be
    present or absent on a RP.
    * It matters *who* can turn a feature on/off.
 * If it can be done by virt at spawn time, then it
    makes sense to have
    the trait on the RP, and you can switch the feature
    on/off via a
    separate extra_spec.
 * But if it's e.g. an admin action, and spawn has
    no control, then the
    trait needs to be *added* whenever the feature is *on*,
    and *removed*
    whenever the feature is *off*.

    [1]

http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-10-23.log.html#t2017-10-23T13:12:13 


 




    On 10/23/2017 08:15 AM, Sylvain Bauza wrote:



    On Mon, Oct 23, 2017 at 2:54 PM, Eric Fried
    >> wrote:

   I agree with Sean.  In general terms:

   * A resource provider should be marked with a
    trait if that feature
 * Can be turned on or off (whether it's
    currently on or not); or
 * Is always on and can't ever be turned off.


    No, traits are not boolean. If a resource provider
    stops providing a
    capability, then the existing related trait should
    just be removed,
    that's it.
    If you see a trait, that's just means that the
    related capability for
    the Resource Provider is supported, that's it too.

    MHO.

    -Sylvain



   * A consumer wanting that feature present
    (doesn't matter whether it's
   on or off) should specify it as a required
    *trait*.
   * A consumer wanting 

Re: [openstack-dev] [ironic] [nova] traits discussion call

[Jay Pipes]

I'd prefer to have you on the call, Dima. How about we push it back to 
tomorrow at the same time?


Can everyone make it then?

-jay

On 10/30/2017 10:11 AM, Dmitry Tantsur wrote:
Aaaand sorry again, but due to sudden errands I won't be able to attend. 
Please feel free to use my bluejeans room anyway. I think my position on 
traits is more or less clear from previous discussions with John, Sam 
and Eric.


2017-10-24 18:07 GMT+02:00 Dmitry Tantsur >:


Sigh, sorry. I forgot that we're moving back to winter time this
weekend. I *think* the time is 3pm UTC then. It seems to be 11am
eastern US:

https://www.timeanddate.com/worldclock/converter.html?iso=20171030T15=37=tz_et

.


On 10/24/2017 06:00 PM, Dmitry Tantsur wrote:

And the winner is Mon, 30 Oct, 2pm UTC!

The bluejeans ID is https://bluejeans.com/757528759

(works without plugins in recent FF and Chrome; if it asks to
install an app, ignore it and look for a link saying "join with
browser")

On 10/23/2017 05:02 PM, Dmitry Tantsur wrote:

Hi all!

I'd like to invite you to the discussion of the way to
implement traits in
ironic and the ironic virt driver. Please vote for the time at
https://doodle.com/poll/ts43k98kkvniv8uz
. Please vote by
EOD tomorrow.

Note that it's going to be a technical discussion - please
make sure you
understand what traits are and why ironic cares about them.
See below for more
context.

We'll probably use my bluejeans account, as it works without
plugins in modern
browsers. I'll post a meeting ID when we pick the date.


On 10/23/2017 04:09 PM, Eric Fried wrote:

We discussed this a little bit further in IRC [1]. 
We're all in

agreement, but it's worth being precise on a couple of
points:

* We're distinguishing between a "feature" and the
"trait" that
represents it in placement.  For the sake of this
discussion, a
"feature" can (maybe) be switched on or off, but a
"trait" can either be
present or absent on a RP.
* It matters *who* can turn a feature on/off.
 * If it can be done by virt at spawn time, then it
makes sense to have
the trait on the RP, and you can switch the feature
on/off via a
separate extra_spec.
 * But if it's e.g. an admin action, and spawn has
no control, then the
trait needs to be *added* whenever the feature is *on*,
and *removed*
whenever the feature is *off*.

[1]

http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-10-23.log.html#t2017-10-23T13:12:13




On 10/23/2017 08:15 AM, Sylvain Bauza wrote:



On Mon, Oct 23, 2017 at 2:54 PM, Eric Fried
>> wrote:

   I agree with Sean.  In general terms:

   * A resource provider should be marked with a
trait if that feature
 * Can be turned on or off (whether it's
currently on or not); or
 * Is always on and can't ever be turned off.


No, traits are not boolean. If a resource provider
stops providing a
capability, then the existing related trait should
just be removed,
that's it.
If you see a trait, that's just means that the
related capability for
the Resource Provider is supported, that's it too.

MHO.

-Sylvain



   * A consumer wanting that feature present
(doesn't matter whether it's
   on or off) should specify it as a required
*trait*.
   * A consumer wanting that feature present and
turned on should
 * Specify it as a required trait; AND
 

Re: [openstack-dev] [ironic] [nova] traits discussion call

[Dmitry Tantsur]

Aaaand sorry again, but due to sudden errands I won't be able to attend.
Please feel free to use my bluejeans room anyway. I think my position on
traits is more or less clear from previous discussions with John, Sam and
Eric.

2017-10-24 18:07 GMT+02:00 Dmitry Tantsur :

> Sigh, sorry. I forgot that we're moving back to winter time this weekend.
> I *think* the time is 3pm UTC then. It seems to be 11am eastern US:
> https://www.timeanddate.com/worldclock/converter.html?iso=20
> 171030T15=37=tz_et.
>
>
> On 10/24/2017 06:00 PM, Dmitry Tantsur wrote:
>
>> And the winner is Mon, 30 Oct, 2pm UTC!
>>
>> The bluejeans ID is https://bluejeans.com/757528759
>> (works without plugins in recent FF and Chrome; if it asks to install an
>> app, ignore it and look for a link saying "join with browser")
>>
>> On 10/23/2017 05:02 PM, Dmitry Tantsur wrote:
>>
>>> Hi all!
>>>
>>> I'd like to invite you to the discussion of the way to implement traits
>>> in
>>> ironic and the ironic virt driver. Please vote for the time at
>>> https://doodle.com/poll/ts43k98kkvniv8uz. Please vote by EOD tomorrow.
>>>
>>> Note that it's going to be a technical discussion - please make sure you
>>> understand what traits are and why ironic cares about them. See below
>>> for more
>>> context.
>>>
>>> We'll probably use my bluejeans account, as it works without plugins in
>>> modern
>>> browsers. I'll post a meeting ID when we pick the date.
>>>
>>>
>>> On 10/23/2017 04:09 PM, Eric Fried wrote:
>>>
 We discussed this a little bit further in IRC [1].  We're all in
 agreement, but it's worth being precise on a couple of points:

 * We're distinguishing between a "feature" and the "trait" that
 represents it in placement.  For the sake of this discussion, a
 "feature" can (maybe) be switched on or off, but a "trait" can either be
 present or absent on a RP.
 * It matters *who* can turn a feature on/off.
 * If it can be done by virt at spawn time, then it makes sense to
 have
 the trait on the RP, and you can switch the feature on/off via a
 separate extra_spec.
 * But if it's e.g. an admin action, and spawn has no control, then
 the
 trait needs to be *added* whenever the feature is *on*, and *removed*
 whenever the feature is *off*.

 [1]
 http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%
 23openstack-nova.2017-10-23.log.html#t2017-10-23T13:12:13

 On 10/23/2017 08:15 AM, Sylvain Bauza wrote:

>
>
> On Mon, Oct 23, 2017 at 2:54 PM, Eric Fried  > wrote:
>
>   I agree with Sean.  In general terms:
>
>   * A resource provider should be marked with a trait if that
> feature
> * Can be turned on or off (whether it's currently on or not);
> or
> * Is always on and can't ever be turned off.
>
>
> No, traits are not boolean. If a resource provider stops providing a
> capability, then the existing related trait should just be removed,
> that's it.
> If you see a trait, that's just means that the related capability for
> the Resource Provider is supported, that's it too.
>
> MHO.
>
> -Sylvain
>
>
>
>   * A consumer wanting that feature present (doesn't matter
> whether it's
>   on or off) should specify it as a required *trait*.
>   * A consumer wanting that feature present and turned on should
> * Specify it as a required trait; AND
> * Indicate that it be turned on via some other mechanism (e.g.
> a
>   separate extra_spec).
>
>   I believe this satisfies Dmitry's (Ironic's) needs, but also
> Jay's drive
>   for placement purity.
>
>   Please invite me to the hangout or whatever.
>
>   Thanks,
>   Eric
>
>   On 10/23/2017 07:22 AM, Mooney, Sean K wrote:
>   >
>   >
>   >
>   >
>   > *From:*Jay Pipes [mailto:jaypi...@gmail.com
>   ]
>   > *Sent:* Monday, October 23, 2017 12:20 PM
>   > *To:* OpenStack Development Mailing List
>      >
>   > *Subject:* Re: [openstack-dev] [ironic] ironic and traits
>   >
>   >
>   >
>   > Writing from my phone... May I ask that before you proceed
> with any plan
>   > that uses traits for state information that we have a hangout
> or
>   > videoconference to discuss this? Unfortunately today and
> tomorrow I'm
>   > not able to do a hangout but I can do one on Wednesday any
> time of the day.
>   >
>   >
>   >
>   > */[Mooney, Sean K] on the uefi boot topic I did bring up at the
>   ptg 

Re: [openstack-dev] [ironic] [nova] traits discussion call

[Dmitry Tantsur]

Sigh, sorry. I forgot that we're moving back to winter time this weekend. I 
*think* the time is 3pm UTC then. It seems to be 11am eastern US: 
https://www.timeanddate.com/worldclock/converter.html?iso=20171030T15=37=tz_et.


On 10/24/2017 06:00 PM, Dmitry Tantsur wrote:

And the winner is Mon, 30 Oct, 2pm UTC!

The bluejeans ID is https://bluejeans.com/757528759
(works without plugins in recent FF and Chrome; if it asks to install an app, 
ignore it and look for a link saying "join with browser")


On 10/23/2017 05:02 PM, Dmitry Tantsur wrote:

Hi all!

I'd like to invite you to the discussion of the way to implement traits in
ironic and the ironic virt driver. Please vote for the time at
https://doodle.com/poll/ts43k98kkvniv8uz. Please vote by EOD tomorrow.

Note that it's going to be a technical discussion - please make sure you
understand what traits are and why ironic cares about them. See below for more
context.

We'll probably use my bluejeans account, as it works without plugins in modern
browsers. I'll post a meeting ID when we pick the date.


On 10/23/2017 04:09 PM, Eric Fried wrote:

We discussed this a little bit further in IRC [1].  We're all in
agreement, but it's worth being precise on a couple of points:

* We're distinguishing between a "feature" and the "trait" that
represents it in placement.  For the sake of this discussion, a
"feature" can (maybe) be switched on or off, but a "trait" can either be
present or absent on a RP.
* It matters *who* can turn a feature on/off.
    * If it can be done by virt at spawn time, then it makes sense to have
the trait on the RP, and you can switch the feature on/off via a
separate extra_spec.
    * But if it's e.g. an admin action, and spawn has no control, then the
trait needs to be *added* whenever the feature is *on*, and *removed*
whenever the feature is *off*.

[1]
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-10-23.log.html#t2017-10-23T13:12:13 



On 10/23/2017 08:15 AM, Sylvain Bauza wrote:



On Mon, Oct 23, 2017 at 2:54 PM, Eric Fried > wrote:

  I agree with Sean.  In general terms:

  * A resource provider should be marked with a trait if that feature
    * Can be turned on or off (whether it's currently on or not); or
    * Is always on and can't ever be turned off.


No, traits are not boolean. If a resource provider stops providing a
capability, then the existing related trait should just be removed,
that's it.
If you see a trait, that's just means that the related capability for
the Resource Provider is supported, that's it too.

MHO.

-Sylvain



  * A consumer wanting that feature present (doesn't matter whether it's
  on or off) should specify it as a required *trait*.
  * A consumer wanting that feature present and turned on should
    * Specify it as a required trait; AND
    * Indicate that it be turned on via some other mechanism (e.g. a
  separate extra_spec).

  I believe this satisfies Dmitry's (Ironic's) needs, but also Jay's drive
  for placement purity.

  Please invite me to the hangout or whatever.

  Thanks,
  Eric

  On 10/23/2017 07:22 AM, Mooney, Sean K wrote:
  >
  >
  >
  >
  > *From:*Jay Pipes [mailto:jaypi...@gmail.com
  ]
  > *Sent:* Monday, October 23, 2017 12:20 PM
  > *To:* OpenStack Development Mailing List
  >
  > *Subject:* Re: [openstack-dev] [ironic] ironic and traits
  >
  >
  >
  > Writing from my phone... May I ask that before you proceed with any 
plan

  > that uses traits for state information that we have a hangout or
  > videoconference to discuss this? Unfortunately today and tomorrow I'm
  > not able to do a hangout but I can do one on Wednesday any time of 
the day.

  >
  >
  >
  > */[Mooney, Sean K] on the uefi boot topic I did bring up at the
  ptg that
  > we wanted to standardizes tratis for “verified boot” /*
  >
  > */that included a trait for uefi secure boot enabled and to
  indicated a
  > hardware root of trust, e.g. intel boot guard or similar/*
  >
  > */we distinctly wanted to be able to tag nova compute hosts with those
  > new traits so we could require that vms that request/*
  >
  > */a host with uefi secure boot enabled and a hardware root of
  trust are
  > scheduled only to those nodes. /*
  >
  > */ /*
  >
  > */There are many other examples that effect both vms and bare
  metal such
  > as, ecc/interleaved memory, cluster on die, /*
  >
  > */l3 cache code and data prioritization, vt-d/vt-c, HPET, Hyper
  > threading, power states … all of these feature may be present on the
  > platform/*
  >
  > */but I also need to know if they are 

Re: [openstack-dev] [ironic] [nova] traits discussion call

[Dmitry Tantsur]

And the winner is Mon, 30 Oct, 2pm UTC!

The bluejeans ID is https://bluejeans.com/757528759
(works without plugins in recent FF and Chrome; if it asks to install an app, 
ignore it and look for a link saying "join with browser")


On 10/23/2017 05:02 PM, Dmitry Tantsur wrote:

Hi all!

I'd like to invite you to the discussion of the way to implement traits in
ironic and the ironic virt driver. Please vote for the time at
https://doodle.com/poll/ts43k98kkvniv8uz. Please vote by EOD tomorrow.

Note that it's going to be a technical discussion - please make sure you
understand what traits are and why ironic cares about them. See below for more
context.

We'll probably use my bluejeans account, as it works without plugins in modern
browsers. I'll post a meeting ID when we pick the date.


On 10/23/2017 04:09 PM, Eric Fried wrote:

We discussed this a little bit further in IRC [1].  We're all in
agreement, but it's worth being precise on a couple of points:

* We're distinguishing between a "feature" and the "trait" that
represents it in placement.  For the sake of this discussion, a
"feature" can (maybe) be switched on or off, but a "trait" can either be
present or absent on a RP.
* It matters *who* can turn a feature on/off.
* If it can be done by virt at spawn time, then it makes sense to have
the trait on the RP, and you can switch the feature on/off via a
separate extra_spec.
* But if it's e.g. an admin action, and spawn has no control, then the
trait needs to be *added* whenever the feature is *on*, and *removed*
whenever the feature is *off*.

[1]
http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.2017-10-23.log.html#t2017-10-23T13:12:13

On 10/23/2017 08:15 AM, Sylvain Bauza wrote:



On Mon, Oct 23, 2017 at 2:54 PM, Eric Fried > wrote:

  I agree with Sean.  In general terms:

  * A resource provider should be marked with a trait if that feature
* Can be turned on or off (whether it's currently on or not); or
* Is always on and can't ever be turned off.


No, traits are not boolean. If a resource provider stops providing a
capability, then the existing related trait should just be removed,
that's it.
If you see a trait, that's just means that the related capability for
the Resource Provider is supported, that's it too.

MHO.

-Sylvain



  * A consumer wanting that feature present (doesn't matter whether it's
  on or off) should specify it as a required *trait*.
  * A consumer wanting that feature present and turned on should
* Specify it as a required trait; AND
* Indicate that it be turned on via some other mechanism (e.g. a
  separate extra_spec).

  I believe this satisfies Dmitry's (Ironic's) needs, but also Jay's drive
  for placement purity.

  Please invite me to the hangout or whatever.

  Thanks,
  Eric

  On 10/23/2017 07:22 AM, Mooney, Sean K wrote:
  >
  >
  >
  >
  > *From:*Jay Pipes [mailto:jaypi...@gmail.com
  ]
  > *Sent:* Monday, October 23, 2017 12:20 PM
  > *To:* OpenStack Development Mailing List
  >
  > *Subject:* Re: [openstack-dev] [ironic] ironic and traits
  >
  >
  >
  > Writing from my phone... May I ask that before you proceed with any plan
  > that uses traits for state information that we have a hangout or
  > videoconference to discuss this? Unfortunately today and tomorrow I'm
  > not able to do a hangout but I can do one on Wednesday any time of the 
day.
  >
  >
  >
  > */[Mooney, Sean K] on the uefi boot topic I did bring up at the
  ptg that
  > we wanted to standardizes tratis for “verified boot” /*
  >
  > */that included a trait for uefi secure boot enabled and to
  indicated a
  > hardware root of trust, e.g. intel boot guard or similar/*
  >
  > */we distinctly wanted to be able to tag nova compute hosts with those
  > new traits so we could require that vms that request/*
  >
  > */a host with uefi secure boot enabled and a hardware root of
  trust are
  > scheduled only to those nodes. /*
  >
  > */ /*
  >
  > */There are many other examples that effect both vms and bare
  metal such
  > as, ecc/interleaved memory, cluster on die, /*
  >
  > */l3 cache code and data prioritization, vt-d/vt-c, HPET, Hyper
  > threading, power states … all of these feature may be present on the
  > platform/*
  >
  > */but I also need to know if they are turned on. Ruling out state in
  > traits means all of this logic will eventually get pushed to scheduler
  > filters/*
  >
  > */which will be suboptimal long term as more state is tracked.
  Software
  > defined infrastructure may be the future but