[openstack-dev] [ironic] [nova] traits discussion call - moved to Tue!!
openstack at fried.cc
Thu Nov 2 21:54:01 UTC 2017
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 .)
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 
- 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
- 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:  .
o Action: Jay to propose os-traits for RAID levels and boot modes.
o It was Halloween. There were costumes.  .
 (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
and the scheduler would *avoid* any node with CUSTOM_X. This *would* be
a scheduler thing, not a weigher thing.
 Config Template traits (ironic-specs):
 Support traits in the Ironic driver (nova-specs):
 Traits on Ironic Nodes (ironic-specs):
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)
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev