<div dir="ltr">Hi,<div><br><div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">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).</blockquote></div><div>Exactly. I recognize that our purpose of auto-discovery is eradicating manual steps.</div><div><br></div><div>I prefer option 2, but as Sam said, it's not suitable for mixed driver environment.</div><div>Then, is it impossible that detecting(judging?) driver from node info?</div><div>For example, if Vendor is XXX and Product Name is YYY, then driver is ZZZ. What do you think?</div><div><br></div><div>Best Regards,</div><div>Yuiko Takada</div><div><br></div><div class="gmail_extra"><br><div class="gmail_quote">2015-11-18 22:27 GMT+09:00 Dmitry Tantsur <span dir="ltr"><<a href="mailto:dtantsur@redhat.com" target="_blank">dtantsur@redhat.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">I have to admin I forgot about this thread. Please find comments inline.<span class=""><br>
<br>
On 11/06/2015 05:25 PM, Bruno Cornec wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Hello,<br>
<br>
Pavlo Shchelokovskyy said on Tue, Nov 03, 2015 at 09:41:51PM +0000:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
For auto-setting driver options on enrollment, I would vote for option 2<br>
with default being fake driver + optional CMDB integration. This would<br>
ease<br>
managing a homogeneous pool of BMs, but still (using fake driver or data<br>
from CMDB) work reasonably well in heterogeneous case.<br>
</blockquote></blockquote>
<br></span>
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).<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
As for setting a random password, CMDB integration is crucial IMO. Large<br>
deployments usually have some sort of it already, and it must serve as a<br>
single source of truth for the deployment. So if inspector is changing<br>
the<br>
ipmi password, it should not only notify/update Ironic's knowledge on<br>
that<br>
node, but also notify/update the CMDB on that change - at least there<br>
must<br>
be a possibility (a ready-to-use plug point) to do that before we roll<br>
out<br>
such feature.<br>
</blockquote></blockquote>
<br></span>
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.<br>
<br>
Anyway, it could be interesting to talk about some generic OpenStack-CMDB interface, which might something proposed below.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
wrt interaction with CMDB, we have investigating around some ideas tha<br>
we have gathered at <a href="https://github.com/uggla/alexandria/wiki" rel="noreferrer" target="_blank">https://github.com/uggla/alexandria/wiki</a><br>
</blockquote>
<br></span>
Oh, that's interesting. I see some potential overlap with ironic and ironic-inspector. Would be cool to chat on it the next summit.<span class=""><br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
Some code has been written to try to model some of these aspects, but<br>
having more contributors and patches to enhance that integration would<br>
be great ! Similarly available at <a href="https://github.com/uggla/alexandria" rel="noreferrer" target="_blank">https://github.com/uggla/alexandria</a><br>
<br>
We had planned to talk about these ideas at the previous OpenStack<br>
summit but didn't get enough votes it seems. So now aiming at preenting<br>
to the next one ;-)<br>
</blockquote>
<br></span>
+100, would love to hear.<br>
<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
HTH,<br>
Bruno.<br>
</blockquote><div class=""><div class="h5">
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div></div></div>