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>: > 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> > 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> >> написав(ла): >> > >> > 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://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 > >
__________________________________________________________________________ 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