[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