On 2013/07/12 01:59, Robert Collins wrote:
* Creation
* Manual registration
* hardware specs from Ironic based on mac address (M)
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.
* IP auto populated from Neutron (F)
Do you mean IPMI IP ? I'd say IPMI address managed by Neutron here.
+1
* 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.
* Management node (where triple-o is installed)
This should be plural :) - TripleO isn't a single service to be
installed - We've got Tuskar, Ironic, Nova, Glance, Keystone, Neutron,
etc.
* created as part of undercloud install process
* can create additional management nodes (F)
* 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.
* searchable by status, name, cpu, memory, and all attributes from
ironic
* can be allocated as one of four node types
Not by users though. We need to stop thinking of this as 'what we do
to nodes' - Nova/Ironic operate on nodes, we operate on Heat
templates.
Discussed in other threads, but I still believe (and I am not alone)
that we need to allow 'force nodes'.
* 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.
* defaulted, with no option to change
* allow modification (F)
* review distribution map (F)
* notification when a deployment is ready to go or whenever something
changes
Is this an (M) ?
Might be M but with higher priority. I see it in the middle. But if we
have to decide, it can be M.
-- Jarda
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
