[openstack-dev] Implications of switching to entry points for scheduler filtering/weighing

Sandy Walsh sandy.walsh at rackspace.com
Thu Jan 3 14:51:49 UTC 2013

On 01/03/2013 10:27 AM, Monty Taylor wrote:
> On 01/03/2013 04:23 AM, Mark McLoughlin wrote:
>> On Thu, 2013-01-03 at 12:22 +0000, Mark McLoughlin wrote:
>>> Hey,
>>> There are some patches proposed for oslo-incubator which adds Nova's
>>> filter and weighing infrastructure so that it can be re-used by Cinder:
>>>   https://blueprints.launchpad.net/oslo/+spec/common-filters
>>> One part of this is that we would move to loading filters and weighers
>>> from entry points. I want to make sure Nova folks are aware of the
>>> implications of this before merging it into Oslo.
>> Bah, I forgot to include the link to the WIP patch for Nova:
>>   https://review.openstack.org/18718
>> And if anyone is thinking "didn't Monty have a patch to do this?",
>> you're thinking of a patch to switch to using entry points for the
>> scheduler driver and host manager:
>>   https://review.openstack.org/11557
> I, for one, welcome our new filters and weighers overlords.

Yep, having the shared filters/weighers sounds cool.

Is there a security concern about using the entry-point mechanism for
allowing untrusted code access to the rich scheduler data (host &
request info)?

For example, someone installs a sneaky python package on a scheduler
node that has an entry-point that the scheduler uses. We wouldn't want
that to suddenly being included in the filter chain.

The old filter driver mechanism, while clunky, was at least explicit. Or
am I missing something here?


More information about the OpenStack-dev mailing list