fuel-dev team mailing list archive

[Oleg Gelbukh <ogelbukh@xxxxxxxxxxxx>]

Vladimir,

I might be wrong, but I heard directly from Devananda that Ironic don't
plan to have Discovery as a part of it's scope. Things might have changed
since then (it was at HK summit), but general idea was that Ironic won't
serve as hosts directory or CMDB, and nodes will be enrolled to it from
some external source.

However, I think it is natural that discovery capabilities should be
supported by a unified agent used by Ironic and hypothetical Discovery
service (e.g. Nailgun).

--
Best regards,
Oleg


On Wed, Mar 19, 2014 at 11:49 AM, Vladimir Kozhukalov <
vkozhukalov@xxxxxxxxxxxx> wrote:

> My suggestion is to stop inventing discovering mechanism on our own.
> Openstack is supposed to use Ironic for provisioning, discovering, firmware
> updates, RAID configuring, power management. In Ironic project there is a
> blueprint for utility ramdisk (it is similar to Fuel bootstrap)
> https://blueprints.launchpad.net/ironic/+spec/utility-ramdisk. Our
> current activities in substituting Cobbler with Ironic include contributing
> in python ironic agent https://wiki.openstack.org/wiki/Ironic-python-agent.
> We discussed the general architecture of this agent and agreed that it
> should expose REST API and every piece of its functionality needs to be
> implemented as pluggable driver.
>
> Discovery flow could be implemented as a series of http requests to these
> agents running on nodes. Discovery will be just a part of full
> functionality of these agents. The list of IP addresses where we need to
> send discovery requests could be known from the list of  leased addresses
> from DHCP server.
>
>
>
> Vladimir Kozhukalov
>
>
> On Tue, Mar 18, 2014 at 4:25 PM, Mike Scherbakov <mscherbakov@xxxxxxxxxxxx
> > wrote:
>
>> Looks like it's still open question.
>> Andrew, can you respond please on Eugene's question in the doc?
>>
>> My personal opinion: refactor the current approach in the way so it's
>> more performant (reduce amount of data), as it will be required anyway. See
>> how it works. If we still have issues, go further, perhaps with
>> re-implementation to use polling of servers instead, whether using tiny
>> REST services on nodes or AMQP or anything else.
>>
>> Basically, let's eliminate issues step by step.
>> Thanks,
>>
>>
>> On Mon, Mar 3, 2014 at 12:46 PM, Evgeniy L <eli@xxxxxxxxxxxx> wrote:
>>
>>> Hi,
>>>
>>> We had a discussion about nailgun agent which some of us want to rewrite
>>> in python, I don't think that we need to rewrite nailgun agent one-to-one
>>> to solve a single problem.
>>> I tried to describe problems which we have and how we can solve them. [0]
>>>
>>> Comments are welcome.
>>>
>>> [0]
>>> https://docs.google.com/a/mirantis.com/document/d/1zqV58LZBLQ-0gllb_i3MyIKIMj-Qx8ELJohjcWs459s/edit#
>>>
>>> --
>>> Mailing list: https://launchpad.net/~fuel-dev
>>> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~fuel-dev
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>>
>> --
>> Mike Scherbakov
>> #mihgen
>>
>> --
>> Mailing list: https://launchpad.net/~fuel-dev
>> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~fuel-dev
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
> --
> Mailing list: https://launchpad.net/~fuel-dev
> Post to     : fuel-dev@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~fuel-dev
> More help   : https://help.launchpad.net/ListHelp
>
>