Open Stack

Hi,

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).

Exactly. I recognize that our purpose of auto-discovery is eradicating
manual steps.

I prefer option 2, but as Sam said, it's not suitable for mixed driver
environment.
Then, is it impossible that detecting(judging?) driver from node info?
For example, if Vendor is XXX and Product Name is YYY, then driver is ZZZ.
What do you think?

Best Regards,
Yuiko Takada


2015-11-18 22:27 GMT+09:00 Dmitry Tantsur <dtantsur at redhat.com>:

> 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.
>>
>
>
> __________________________________________________________________________
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> 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/20151119/9eaa3c95/attachment.html>