From: Jim Rollenhagen [mailto:[email protected]]
Sent: Tuesday, April 08, 2014 9:17 AM
To: OpenStack Development Mailing List (not for usage questions)
Subject: Re: [openstack-dev] [Ironic][Agent]
Guys, thank you very much for your comments,
I thought a lot about why we need to be so limited in IPA use cases. Now it
much clearer for me. Indeed, having some kind of agent running inside host OS
is not what many people want to see. And now I'd rather agree with that.
But there are still some questions which are difficult to answer for me.
0) There are a plenty of old hardware which does not have IPMI/ILO at all. How
Ironic is supposed to power them off and on? Ssh? But Ironic is not supposed to
interact with host OS.
I’m not sure about this yet. I’m inclined to say “we don’t support such
hardware”, at least in the short-term. How does Ironic handle hardware without
a power management interface today?
[Dickson, Mike (HP Servers)] I’d be inclined to agree. Server class hardware
would have a BMC of some sort. I suppose you could alternatively do a driver
for a smart PDU and let it control power brute force. But irregardless I
don’t think relying on OS level power control is enough so essentially any
“server” without some sort of power control outside of the OS is sort of a non
starter.
1) We agreed that Ironic is that place where we can store hardware info
('extra' field in node model). But many modern hardware configurations support
hot pluggable hard drives, CPUs, and even memory. How Ironic will know that
hardware configuration is changed? Does it need to know about hardware changes
at all? Is it supposed that some monitoring agent (NOT ironic agent) will be
used for that? But if we already have discovering extension in Ironic agent,
then it sounds rational to use this extension for monitoring as well. Right?
I believe that hardware changes should not be made while an instance is
deployed to a node (except maybe swapping a dead stick of RAM or something). If
a user wants a node with more RAM (for example), they should provision a new
node and destroy the old one, just like they would do with VMs provisioned by
Nova.
[Dickson, Mike (HP Servers)] I think this would depend on the driver in use.
iLO for instance can get many hardware details real time and I don’t see a
reason why a driver couldn’t support that. Maybe some attributes that describe
the drivers capabilities? In the absence of that you could run a ram disk and
inventory the server on reboots. It wouldn’t catch hot plug changes until a
reboot occurred of course.
Mike
2) When I deal with some kind of hypervisor, I can always use 'virsh list
--all' command in order to know which nodes are running and which aren't. How
am I supposed to know which nodes are still alive in case of Ironic? IPMI?
Again IPMI is not always available. And if IPMI is available, then why do we
need heartbeat in Ironic agent?
Every power driver today has some sort of “power status” command that Ironic
relies on to tell if the node is alive, and I think we can continue to rely on
this. We have a heartbeat in the agent to ensure that the agent process is
still alive and reachable, as the agent might run for a long time before an
instance is deployed to the node, and bugs happen.
Is that helpful?
// jim
Vladimir Kozhukalov
On Fri, Apr 4, 2014 at 9:46 PM, Ezra Silvera
<[email protected]<mailto:[email protected]>> wrote:
> Ironic's responsibility ends where the host OS begins. Ironic is a bare metal
> provisioning service, not a configuration management service.
I agree with the above, but just to clarify I would say that Ironic shouldn't
*interact* with the host OS once it booted. Obviously it can still perform BM
tasks underneath the OS (while it's up and running) if needed (e.g., force
shutdown through IPMI, etc..)
Ezra
_______________________________________________
OpenStack-dev mailing list
[email protected]<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]<mailto:[email protected]>
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
_______________________________________________
OpenStack-dev mailing list
[email protected]
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
