[openstack-dev] [TripleO][Tuskar] Icehouse Requirements

Jaromir Coufal 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 
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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131209/761da249/attachment.html>

More information about the OpenStack-dev mailing list