[openstack-dev] [nova][ironic] BaremetalHostManager unused?

Devananda van der Veen devananda.vdv at gmail.com
Fri Apr 4 15:32:55 UTC 2014


Hi Matt!

I've looked into this a bit now, too, and don't have a conclusive answer as
to how (or even whether) it's working today.

Instead, I'd like to point out that Ironic is aiming to deprecate
nova.virt.baremetal and nova.scheduler.baremetal_host_manager, in favor of
nova.virt.ironic and nova.scheduler.ironic_host_manager, both of which
currently live in Ironic's git tree. These were initially based on the
baremetal code that you're looking at, and so probably inherited this
problem (if it is a problem). Let's fix it in Ironic.

Thanks!
-Devananda



On Fri, Apr 4, 2014 at 7:46 AM, Matthew Booth <mbooth at redhat.com> wrote:

> Whilst looking at something unrelated in HostManager, I noticed that
> HostManager.service_states appears to be unused, and decided to remove
> it. This seems to have a number of implications:
>
> 1. capabilities in HostManager.get_all_host_states will always be None.
> 2. capabilities passed to host_state_cls() will always be None
> (host_state_cls doesn't appear to be used anywhere else)
> 3. baremetal_host_manager.new_host_state() capabilities will always be
> None.
> 4. cap will always be {}, so will never contain 'baremetal_driver'
> 5. BaremetalNodeState will never be instantiated
> 6. BaremetalHostManager is a no-op
>
> possibly resulting in
>
> 7. The filter scheduler could try to put multiple instances on a single
> bare metal host
>
> This was going to be a 3 line cleanup, but it looks like a can of worms
> so I'm going to drop it. It's entirely possible that I've missed another
> entry point in to this code, but it might be worth a quick look.
> Incidentally, the tests seem to populate service_states in fake, so the
> behaviour of the automated tests probably isn't reliable.
>
> Matt
> --
> Matthew Booth, RHCA, RHCSS
> Red Hat Engineering, Virtualisation Team
>
> GPG ID:  D33C3490
> GPG FPR: 3733 612D 2D05 5458 8A8A 1600 3441 EA19 D33C 3490
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140404/4bf71bd7/attachment.html>


More information about the OpenStack-dev mailing list