Open Stack

+1

    The agent is a tool Ironic is using to take the place of a
    hypervisor to discover and prepare nodes to recieve workloads. For
    hardware, this includes more work -- such as firmware flashing, bios
    configuration, and disk imaging -- all of which must be done in an
    OOB manner. (This is also why deploy drivers that interact directly
    with the hardware when the supported - such as Seamicro or the
    proposed HP iLo driver - are good alternative approaches.)


-Jay Faulkner

On 4/4/2014 7:10 AM, Ling Gao wrote:
> Hello Vladimir,
>      I would prefer an agent-less node, meaning the agent is only used 
> under the ramdisk OS to collect hw info, to do firmware updates and to 
> install nodes etc. In this sense, the agent running as root is fine. 
> Once the node is installed, the agent should be out of the picture. I 
> have been working with HPC customers, in that environment they prefer 
> as less memory prints as possible. Even as a ordinary tenant, I do not 
> feel secure to have some agents running on my node. For the firmware 
> update on the fly, I do not know how many customers will trust us 
> doing it while their critical application is running. Even they do and 
> ready to do it, Ironic can then send an agent to the node through 
> scp/wget as admin/root and quickly do it and then kill the agent on 
> the node. Just my 2 cents.
>
> Ling Gao
>
>
>
>
> From: Vladimir Kozhukalov <vkozhukalov at mirantis.com>
> To: "OpenStack Development Mailing List (not for usage questions)" 
> <openstack-dev at lists.openstack.org>,
> Date: 04/04/2014 08:24 AM
> Subject: [openstack-dev] [Ironic][Agent]
> ------------------------------------------------------------------------
>
>
>
> Hello, everyone,
>
> I'd like to involve more people to express their opinions about the 
> way how we are going to run Ironic-python-agent. I mean should we run 
> it with root privileges or not.
>
> From the very beginning agent is supposed to run under ramdisk OS and 
> it is intended to make disk partitioning, RAID configuring, firmware 
> updates and other stuff according to installing OS. Looks like we 
> always will run agent with root privileges. Right? There are no 
> reasons to limit agent permissions.
>
> On the other hand, it is easy to imagine a situation when you want to 
> run agent on every node of your cluster after installing OS. It could 
> be useful to keep hardware info consistent (for example, many hardware 
> configurations allow one to add hard drives in run time). It also 
> could be useful for "on the fly" firmware updates. It could be useful 
> for "on the fly" manipulations with lvm groups/volumes and so on.
>
> Frankly, I am not even sure that we need to run agent with root 
> privileges even in ramdisk OS, because, for example, there are some 
> system default limitations such as number of connections, number of 
> open files, etc. which are different for root and ordinary user and 
> potentially can influence agent behaviour. Besides, it is possible 
> that some vulnerabilities will be found in the future and they 
> potentially could be used to compromise agent and damage hardware 
> configuration.
>
> Consequently, it is better to run agent under ordinary user even under 
> ramdisk OS and use rootwrap if agent needs to run commands with root 
> privileges. I know that rootwrap has some performance issues 
> _http://lists.openstack.org/pipermail/openstack-dev/2014-March/029017.html_but 
> it is still pretty suitable for ironic agent use case.
>
> It would be great to hear as many opinions as possible according to 
> this case.
>
>
> Vladimir Kozhukalov_______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140404/68cd74bb/attachment.html>