<div dir="ltr">Hi Dmitry,<div><br></div><div>I can try to provide you description on what current Nailgun agent is, and what are potential requirements we may need from HW discovery system.</div><div><br></div><div>Nailgun agent is a one-file Ruby script [0] which is periodically run under cron. It collects information about HW using ohai [1], plus it does custom parsing, filtration, retrieval of HW information. After the information is collected, it is sent to Nailgun, that is how node gets discovered in Fuel.</div><div><br></div><div>To summarise entire process:</div><div>1. After Fuel master node is installed, user restarts the nodes and they get booted via PXE with bootstrap image.</div><div>2. Inside of bootstrap image Nailgun agent is configured and installed.</div><div>3. Cron runs Nailgun agent.</div><div>3. Information is collected by Nailgun agent.</div><div>4. Information is sent to Nailgun.</div><div>5. Nailgun creates new node, for which user using UI can define partitioning schema and networks allocation.</div><div>6. After that provisioning/deployment can be run.</div><div><br></div><div>Every time Nailgun agent sends a request, we submit information about the time last request from agent was done, if there was no request for time N, we mark the node as offline.</div><div><br></div><div>With current implementation we have several problems (not all of them should be addressed by HW discovery system only):</div><div><br></div><div>1. A lot of things are hardcoded on the agent's side, which does additional filtration based on pre-hardcoded parameters [2], the less hardcoded logic in agent we have the easier it's to do upgrades and deliver fixes (upgrade one service is simpler than hundreds of agents).</div><div><br></div><div>2. In order to get additional HW information user has to continue hardcoding it right in Ruby code, as the result, there is no way for Fuel plugin [3], to get additional hardware specific information, we need data-driven mechanism to be able to describe, what/how/where information to get from the node.</div><div><br></div><div>3. Hardware gets changed, we have cases when NICs, HDDs, Motherboards are replaced/removed/added, as the result we should have a tool which would allow us to see these changes and when they were performed, based on that we want to be able to notify the user and provide suggestions how to proceed with these changes.</div><div><br></div><div>4. With 3rd real-world cases, we have a problem of node identification, when HW gets changed and automatic matching doesn't happen (when we cannot say for sure that this is the node which we've already had), user should be able to say, that new node X is in fact offline node Y.</div><div><br></div><div>5. Different source of HW information, we want to have a system which would allow us to have hardware discovery from IPMI, CSV file, Cobbler, CMDB, etc at the same time.</div><div><br></div><div>6. Not only hardware gets changed, but operating system (with kernel versions), for example when we used CentOS as a bootstrap (in bootstrap we do provisioning/partitioning + initial configuration) and Ubuntu for running OpenStack, we were getting wide range of weird problems, from NICs renaming to Disks' ids duplication and deduplication. There should be a way to track these problems (3rd item), and we should be able to add operating system specific system to get HW information.</div><div><br></div><div>7. Cron + Agent based mechanism to define if node is offline is not the best, since it adds race conditions and in fact it only says if there is connectivity between Nailgun and Nailgun agent.</div><div><br></div><div>Will be glad to answer any questions you have, if there are any.</div><div><br></div><div>Thanks,</div><div><br></div><div>[0] <a href="https://github.com/openstack/fuel-nailgun-agent/blob/master/agent" target="_blank">https://github.com/openstack/fuel-nailgun-agent/blob/master/agent</a></div><div>[1] <a href="https://docs.chef.io/ohai.html" target="_blank">https://docs.chef.io/ohai.html</a></div><div>[2] <a href="https://github.com/openstack/fuel-nailgun-agent/blob/master/agent#L46-L51" target="_blank">https://github.com/openstack/fuel-nailgun-agent/blob/master/agent#L46-L51</a></div><div>[3] <a href="https://wiki.openstack.org/wiki/Fuel/Plugins" target="_blank">https://wiki.openstack.org/wiki/Fuel/Plugins</a></div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Mar 16, 2016 at 1:39 PM, Dmitry Tantsur <span dir="ltr"><<a href="mailto:dtantsur@redhat.com" target="_blank">dtantsur@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 03/15/2016 01:53 PM, Serge Kovaleff wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Dear All,<br>
<br>
Let's compare functional abilities of both solutions.<br>
<br>
Till the recent Mitaka release Ironic-inspector had only Introspection<br>
ability.<br>
<br>
Discovery part is proposed and implemented by Anton Arefiev. We should<br>
align expectations and current and future functionality.<br>
<br>
Adding Tags to attract the Inspector community.<br>
</blockquote>
<br></span>
Hi!<br>
<br>
It would be great to see what we can do to fit the nailgun use case. Unfortunately, I don't know much about it right now. What are you missing?<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
Cheers,<br>
Serge Kovaleff<br>
<a href="http://www.mirantis.com" rel="noreferrer" target="_blank">http://www.mirantis.com</a> <<a href="http://www.mirantis.com/" rel="noreferrer" target="_blank">http://www.mirantis.com/</a>><span class=""><br>
cell: +38 (063) 83-155-70<br>
<br>
On Tue, Mar 15, 2016 at 2:07 PM, Alexander Saprykin<br></span><span class="">
<<a href="mailto:asaprykin@mirantis.com" target="_blank">asaprykin@mirantis.com</a> <mailto:<a href="mailto:asaprykin@mirantis.com" target="_blank">asaprykin@mirantis.com</a>>> wrote:<br>
<br>
Dear all,<br>
<br>
Thank you for the opinions about this problem.<br>
<br>
I would agree with Roman, that it is always better to reuse<br>
solutions than re-inventing the wheel. We should investigate<br>
possibility of using ironic-inspector and integrating it into fuel.<br>
<br>
Best regards,<br>
Alexander Saprykin<br>
<br>
2016-03-15 13:03 GMT+01:00 Sergii Golovatiuk<br></span>
<<a href="mailto:sgolovatiuk@mirantis.com" target="_blank">sgolovatiuk@mirantis.com</a> <mailto:<a href="mailto:sgolovatiuk@mirantis.com" target="_blank">sgolovatiuk@mirantis.com</a>>>:<span class=""><br>
<br>
My strong +1 to drop off nailgun-agent completely in favour of<br>
ironic-inspector. Even taking into consideration we'lll need to<br>
extend ironic-inspector for fuel needs.<br>
<br>
--<br>
Best regards,<br>
Sergii Golovatiuk,<br>
Skype #golserge<br>
IRC #holser<br>
<br>
On Tue, Mar 15, 2016 at 11:06 AM, Roman Prykhodchenko<br></span><span class="">
<<a href="mailto:me@romcheg.me" target="_blank">me@romcheg.me</a> <mailto:<a href="mailto:me@romcheg.me" target="_blank">me@romcheg.me</a>>> wrote:<br>
<br>
My opition on this is that we have too many re-invented<br>
wheels in Fuel and it’s better think about replacing them<br>
with something we can re-use than re-inventing them one more<br>
time.<br>
<br>
Let’s take a look at Ironic and try to figure out how we can<br>
use its features for the same purpose.<br>
<br>
<br>
- romcheg<br>
> 15 бер. 2016 р. о 10:38 Neil Jerram<br>
<<a href="mailto:Neil.Jerram@metaswitch.com" target="_blank">Neil.Jerram@metaswitch.com</a><br></span>
<mailto:<a href="mailto:Neil.Jerram@metaswitch.com" target="_blank">Neil.Jerram@metaswitch.com</a>>> написав(ла):<div><div class="h5"><br>
><br>
> On 15/03/16 07:11, Vladimir Kozhukalov wrote:<br>
>> Alexander,<br>
>><br>
>> We have many other places where use Ruby (astute, puppet<br>
custom types,<br>
>> etc.). I don't think it is a good reason to re-write<br>
something just<br>
>> because it is written in Ruby. You are right about<br>
tests, about plugins,<br>
>> but let's look around. Ironic community has already<br>
invented discovery<br>
>> component (btw written in python) and I can't see any<br>
reason why we<br>
>> should continue putting efforts in nailgun agent and not<br>
try to switch<br>
>> to ironic-inspector.<br>
><br>
> +1 in general terms. It's strange to me that there are<br>
so many<br>
> OpenStack deployment systems that each do each piece of<br>
the puzzle in<br>
> their own way (Fuel, Foreman, MAAS/Juju etc.) - and which<br>
also means<br>
> that I need substantial separate learning in order to use<br>
all these<br>
> systems. It would be great to see some consolidation.<br>
><br>
> Regards,<br>
> Neil<br>
><br>
><br>
><br>
__________________________________________________________________________<br>
> OpenStack Development Mailing List (not for usage questions)<br>
> Unsubscribe:<br></div></div>
<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><span class=""><br>
><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>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe:<br></span>
<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a> <<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><span class=""><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>
<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe:<br>
<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></span>
<<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><span class=""><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>
<br>
<br>
<br>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe:<br>
<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></span>
<<a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a>><span class=""><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>
<br>
<br>
<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>
<br>
</span></blockquote><div class="HOEnZb"><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>