On 10/14/2015 12:18 PM, John Trowbridge wrote: > > > On 10/14/2015 10:57 AM, Ben Nemec wrote: >> On 10/14/2015 06:38 AM, Dmitry Tantsur wrote: >>> Hi OoO'ers :) >>> >>> It's going to be a long letter, fasten your seat-belts (and excuse my >>> bad, as usual, English)! >>> >>> In RDO Manager we used to have a feature called advanced profiles >>> matching. It's still there in the documentation at >>> http://docs.openstack.org/developer/tripleo-docs/advanced_deployment/profile_matching.html >>> >>> but the related code needed reworking and didn't quite make it upstream >>> yet. This mail is an attempt to restart the discussion on this topic. >>> >>> Short explanation for those unaware of this feature: we used detailed >>> data from introspection (acquired using hardware-detect utility [1]) to >>> provide scheduling hints, which we called profiles. A profile is >>> essentially a flavor, but calculated using much more data. E.g. you >>> could sat that a profile "foo" will be assigned to nodes with 1024 <= >>> RAM <= 4096 and with GPU devices present (an artificial example). >>> Profile was put on an Ironic as a capability as a result of >>> introspection. Please read the documentation linked above for more details. >>> >>> This feature had a bunch of problems with it, to name a few: >>> 1. It didn't have an API >>> 2. It required a user to modify files by hand to use it >>> 3. It was tied to a pretty specific syntax of the hardware [1] library >>> >>> So we decided to split this thing into 2 parts, which are of value one >>> their own: >>> >>> 1. Pluggable introspection ramdisk - so that we don't force dependency >>> on hardware-detect on everyone. >>> 2. User-defined introspection rules - some DSL that will allow a user to >>> define something like a specs file (see link above) via an API. The >>> outcome would be something, probably capabilit(y|ies) set on a node. >>> 3. Scheduler helper - an utility that will take capabilities set by the >>> previous step, and turn them into exactly one profile to use. >>> >>> Long story short, we got 1 and 2 implemented in appropriate projects >>> (ironic-python-agent and ironic-inspector) during the Liberty time >>> frame. Now it's time to figure out what we do in TripleO about this, namely: >>> >>> 1. Do we need some standard way to define introspection rules for >>> TripleO? E.g. a JSON file like we have for ironic nodes? >> >> Yes, please. >> >>> >>> 2. Do we need a scheduler helper at all? We could use only capabilities >>> for scheduling, but then we can end up with the following situation: >>> node1 has capabilities C1 and C2, node2 has capability C1. First we >>> deploy a flavor with capability C1, it goes to node1. Then we deploy a >>> flavor with capability C2 and it fails, despite us having 2 correct >>> nodes initially. This is what state files were solving in [1] (again, >>> please refer to the documentation). >> >> It sounds like the answer is yes. If the existing scheduler can't >> handle a valid use case then we need some sort of solution. >> >>> >>> 3. If we need, where does it go? tripleo-common? Do we need an HTTP API >>> for it, or do we just do it in place where we need it? After all, it's a >>> pretty trivial manipulation with ironic nodes.. >> >> I think that would depend on what the helper ends up being. I can't see >> it needing a REST API, but presumably it will have to plug into Nova >> somehow. If it's something that would be generally useful (which it >> sounds like it might be - Ironic capabilities aren't a TripleO-specific >> thing), then it belongs in Nova itself IMHO. >> >>> >>> 4. Finally, we need an option to tell introspection to use >>> python-hardware. I don't think it should be on by default, but it will >>> require rebuilding of IPA (due to a new dependency). >> >> Can we not just build it in always, but only use it when desired? Is >> the one extra dependency that much of a burden? > > It pulls in python-numpy and python-pandas, which are pretty large.
If yum is to be believed, those are a total of 8 additional MB. I think I'd rather eat that extra space than require people to rebuild an image for a configuration change. Maybe make it opt-out for people who really want a slightly smaller ramdisk image? > >> >>> >>> Looking forward to your opinions. >>> Dmitry. >>> >>> [1] https://github.com/redhat-cip/hardware >>> >>> __________________________________________________________________________ >>> 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