On 2013/09/12 21:22, Robert Collins wrote:
Ironic today will want IPMI address + MAC for each NIC + disk/cpu/memory
stats
For registration it is just Management MAC address which is needed right? Or
does Ironic need also IP? I think that MAC address might be enough, we can
display IP in details of node later on.
Ironic needs all the details I listed today. Management MAC is not
currently used at all, but would be needed in future when we tackle
IPMI IP managed by Neutron.
OK, I will reflect that in wireframes for UI.
> * Auto-discovery during undercloud install process (M)
* Monitoring
* assignment, availability, status
* capacity, historical statistics (M)
Why is this under 'nodes'? I challenge the idea that it should be
there. We will need to surface some stuff about nodes, but the
underlying idea is to take a cloud approach here - so we're monitoring
services, that happen to be on nodes. There is room to monitor nodes,
as an undercloud feature set, but lets be very very specific about
what is sitting at what layer.
We need both - we need to track services but also state of nodes (CPU, RAM,
Network bandwidth, etc). So in node detail you should be able to track both.
Those are instance characteristics, not node characteristics. An
instance is software running on a Node, and the amount of CPU/RAM/NIC
utilisation is specific to that software while it's on that Node, not
to future or past instances running on that Node.
I think this is minor detail. Node has certain CPU/RAM/NIC capacity and
instance is consuming it. Either way it is important for us to display
this utilization in the UI as well as service statistics.
* Resource nodes
^ nodes is again confusing layers - nodes are
what things are deployed to, but they aren't the entry point
Can you, please be a bit more specific here? I don't understand this note.
By the way, can you get your email client to insert > before the text
you are replying to rather than HTML | marks? Hard to tell what I
wrote and what you did :).
Oh right, sure, sorry. Should be fixed ;)
By that note I meant, that Nodes are not resources, Resource instances
run on Nodes. Nodes are the generic pool of hardware we can deploy
things onto.
Well right, this is the terminology. From my point of view, resources
for overcloud are the instances which are running on Nodes. Once we
deploy the nodes with appropriate software they become Resource Nodes
(from unallocated pool). If this terminology is confusing already then
we should fix it. Any suggestions for improvements?
* Unallocated nodes
This implies an 'allocation' step, that we don't have - how about
'Idle nodes' or something.
It can be auto-allocation. I don't see problem with 'unallocated' term.
Ok, it's not a biggy. I do think it will frame things poorly and lead
to an expectation about how TripleO works that doesn't match how it
does, but we can change it later if I'm right, and if I'm wrong, well
it won't be the first time :).
I think we will figure it out in the other thread (where we talk about
allocation). Anyway - I am interested in how differently would you
formulate Unallocated / Resource / Management Nodes? Maybe your is better :)
-- Jarda
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
