Open Stack

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 <dtantsur at redhat.com> 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-request at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev