[openstack-dev] [ironic] [inspector] Auto discovery extension for Ironic Inspector

Dmitry Tantsur dtantsur at redhat.com
Wed Nov 18 13:27:19 UTC 2015


I have to admin I forgot about this thread. Please find comments inline.

On 11/06/2015 05:25 PM, Bruno Cornec wrote:
> Hello,
>
> Pavlo Shchelokovskyy said on Tue, Nov 03, 2015 at 09:41:51PM +0000:
>> For auto-setting driver options on enrollment, I would vote for option 2
>> with default being fake driver + optional CMDB integration. This would
>> ease
>> managing a homogeneous pool of BMs, but still (using fake driver or data
>> from CMDB) work reasonably well in heterogeneous case.

Using fake driver means we need a manual step to set it to something 
non-fake :) and the current introspection process already has 1 manual 
step (enrolling nodes), so I'd like autodiscovery to require 0 of them 
(at least for the majority of users).

>>
>> As for setting a random password, CMDB integration is crucial IMO. Large
>> deployments usually have some sort of it already, and it must serve as a
>> single source of truth for the deployment. So if inspector is changing
>> the
>> ipmi password, it should not only notify/update Ironic's knowledge on
>> that
>> node, but also notify/update the CMDB on that change - at least there
>> must
>> be a possibility (a ready-to-use plug point) to do that before we roll
>> out
>> such feature.

Well, if we have a CMDB, we probably don't need to set credentials. Or 
at least we should rely on the CMDB as a primary source. This "setting 
random password" thing is more about people without CMDB (aka using 
ironic as a CMDB ;). I'm not sure it's a compelling enough use case.

Anyway, it could be interesting to talk about some generic 
OpenStack-CMDB interface, which might something proposed below.

>
> wrt interaction with CMDB, we have investigating around some ideas tha
> we have gathered at https://github.com/uggla/alexandria/wiki

Oh, that's interesting. I see some potential overlap with ironic and 
ironic-inspector. Would be cool to chat on it the next summit.

>
> Some code has been written to try to model some of these aspects, but
> having more contributors and patches to enhance that integration would
> be great ! Similarly available at https://github.com/uggla/alexandria
>
> We had planned to talk about these ideas at the previous OpenStack
> summit but didn't get enough votes it seems. So now aiming at preenting
> to the next one ;-)

+100, would love to hear.

>
> HTH,
> Bruno.




More information about the OpenStack-dev mailing list