[openstack-dev] [TripleO][Tuskar] Icehouse Requirements
jcoufal at redhat.com
Mon Dec 9 10:56:27 UTC 2013
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.
>> * 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
>> * 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,
>> * 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
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.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev