On 03/16/2016 01:39 PM, Evgeniy L wrote:
Hi Dmitry,
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.
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.
Quick clarification: does it run on user instances? or does it run on
hardware while it's still not deployed to? The former is something that
Ironic tries not to do. There is an interest in the latter.
To summarise entire process:
1. After Fuel master node is installed, user restarts the nodes and they
get booted via PXE with bootstrap image.
2. Inside of bootstrap image Nailgun agent is configured and installed.
3. Cron runs Nailgun agent.
3. Information is collected by Nailgun agent.
4. Information is sent to Nailgun.
5. Nailgun creates new node, for which user using UI can define
partitioning schema and networks allocation.
6. After that provisioning/deployment can be run.
So it looks quite similar to ironic-inspector + IPA, except
introspection runs once. Rerunning it would not be impossible to
implement, though it will require some changes to inspector, so that it
can accept "updates" to a node after the introspection is finished.
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.
This is similar to IPA heartbeating, I guess.
With current implementation we have several problems (not all of them
should be addressed by HW discovery system only):
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).
Oh, I hear it. In the inspector world we are moving away from processing
things on the ramdisk side exactly for this reason: it's too hard to change.
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.
Hmm, interesting. Right now we have a plugin mechanism for the ramdisk.
We also have a plugin (extra-hardware) trying to collect as much
information as it's feasible (based on
https://github.com/redhat-cip/hardware).
On the other side, there is ongoing work to have an ansible-based deploy
ramdisk in Ironic, maybe inspector could benefit from it too. Didn't
think about it yet, would be interesting to discuss on the summit.
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.
This could probably done with a new ironic-inspector plugin.
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.
Very good question. Right now Inspector is using either BMC IP address
or MAC's.
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.
Not sure something like that should live within Ironic to be honest.
Also worth discussing in details.
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.
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.
We are thinking about using some DLM for that.. No specific plans
though, again a topic for the summit.
Will be glad to answer any questions you have, if there are any.
Thanks,
[0] https://github.com/openstack/fuel-nailgun-agent/blob/master/agent
[1] https://docs.chef.io/ohai.html
[2]
https://github.com/openstack/fuel-nailgun-agent/blob/master/agent#L46-L51
[3] https://wiki.openstack.org/wiki/Fuel/Plugins
On Wed, Mar 16, 2016 at 1:39 PM, Dmitry Tantsur <dtant...@redhat.com
<mailto:dtant...@redhat.com>> wrote:
On 03/15/2016 01:53 PM, Serge Kovaleff wrote:
Dear All,
Let's compare functional abilities of both solutions.
Till the recent Mitaka release Ironic-inspector had only
Introspection
ability.
Discovery part is proposed and implemented by Anton Arefiev. We
should
align expectations and current and future functionality.
Adding Tags to attract the Inspector community.
Hi!
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?
Cheers,
Serge Kovaleff
http://www.mirantis.com <http://www.mirantis.com/>
cell: +38 (063) 83-155-70
On Tue, Mar 15, 2016 at 2:07 PM, Alexander Saprykin
<asapry...@mirantis.com <mailto:asapry...@mirantis.com>
<mailto:asapry...@mirantis.com <mailto:asapry...@mirantis.com>>>
wrote:
Dear all,
Thank you for the opinions about this problem.
I would agree with Roman, that it is always better to reuse
solutions than re-inventing the wheel. We should investigate
possibility of using ironic-inspector and integrating it
into fuel.
Best regards,
Alexander Saprykin
2016-03-15 13:03 GMT+01:00 Sergii Golovatiuk
<sgolovat...@mirantis.com <mailto:sgolovat...@mirantis.com>
<mailto:sgolovat...@mirantis.com
<mailto:sgolovat...@mirantis.com>>>:
My strong +1 to drop off nailgun-agent completely in
favour of
ironic-inspector. Even taking into consideration we'lll
need to
extend ironic-inspector for fuel needs.
--
Best regards,
Sergii Golovatiuk,
Skype #golserge
IRC #holser
On Tue, Mar 15, 2016 at 11:06 AM, Roman Prykhodchenko
<m...@romcheg.me <mailto:m...@romcheg.me>
<mailto:m...@romcheg.me <mailto:m...@romcheg.me>>> wrote:
My opition on this is that we have too many re-invented
wheels in Fuel and it’s better think about
replacing them
with something we can re-use than re-inventing them
one more
time.
Let’s take a look at Ironic and try to figure out
how we can
use its features for the same purpose.
- romcheg
> 15 бер. 2016 р. о 10:38 Neil Jerram
<neil.jer...@metaswitch.com
<mailto:neil.jer...@metaswitch.com>
<mailto:neil.jer...@metaswitch.com
<mailto:neil.jer...@metaswitch.com>>> написав(ла):
>
> On 15/03/16 07:11, Vladimir Kozhukalov wrote:
>> Alexander,
>>
>> We have many other places where use Ruby
(astute, puppet
custom types,
>> etc.). I don't think it is a good reason to
re-write
something just
>> because it is written in Ruby. You are right about
tests, about plugins,
>> but let's look around. Ironic community has already
invented discovery
>> component (btw written in python) and I can't
see any
reason why we
>> should continue putting efforts in nailgun
agent and not
try to switch
>> to ironic-inspector.
>
> +1 in general terms. It's strange to me that
there are
so many
> OpenStack deployment systems that each do each
piece of
the puzzle in
> their own way (Fuel, Foreman, MAAS/Juju etc.) -
and which
also means
> that I need substantial separate learning in
order to use
all these
> systems. It would be great to see some
consolidation.
>
> Regards,
> Neil
>
>
>
__________________________________________________________________________
> OpenStack Development Mailing List (not for
usage questions)
> Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage
questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage
questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
<http://openstack-dev-requ...@lists.openstack.org?subject:unsubscribe>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
