On 10 December 2013 09:55, Tzu-Mainn Chen <tzuma...@redhat.com> wrote:
* created as part of undercloud install process
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.
I don't think "resource nodes" is intended to imply that nodes are
resources; rather, it's supposed to
indicate that it's a node where a resource instance runs. It's supposed to
separate it from "management node"
and "unallocated node".
So the question is are we looking at /nodes/ that have a /current
role/, or are we looking at /roles/ that have some /current nodes/.
My contention is that the role is the interesting thing, and the nodes
is the incidental thing. That is, as a sysadmin, my hierarchy of
concerns is something like:
A: are all services running
B: are any of them in a degraded state where I need to take prompt
action to prevent a service outage [might mean many things: - software
update/disk space criticals/a machine failed and we need to scale the
cluster back up/too much load]
C: are there any planned changes I need to make [new software deploy,
feature request from user, replacing a faulty machine]
D: are there long term issues sneaking up on me [capacity planning,
machine obsolescence]
If we take /nodes/ as the interesting thing, and what they are doing
right now as the incidental thing, it's much harder to map that onto
the sysadmin concerns. If we start with /roles/ then can answer:
A: by showing the list of roles and the summary stats (how many
machines, service status aggregate), role level alerts (e.g. nova-api
is not responding)
B: by showing the list of roles and more detailed stats (overall
load, response times of services, tickets against services
and a list of in trouble instances in each role - instances with
alerts against them - low disk, overload, failed service,
early-detection alerts from hardware
C: probably out of our remit for now in the general case, but we need
to enable some things here like replacing faulty machines
D: by looking at trend graphs for roles (not machines), but also by
looking at the hardware in aggregate - breakdown by age of machines,
summary data for tickets filed against instances that were deployed to
a particular machine
C: and D: are (F) category work, but for all but the very last thing,
it seems clear how to approach this from a roles perspective.
I've tried to approach this using /nodes/ as the starting point, and
after two terrible drafts I've deleted the section. I'd love it if
someone could show me how it would work:)
* 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'm interested in what the distinction you're making here is. I'd rather
get things
defined correctly the first time, and it's very possible that I'm missing a
fundamental
definition here.
So we have:
- node - a physical general purpose machine capable of running in
many roles. Some nodes may have hardware layout that is particularly
useful for a given role.
- role - a specific workload we want to map onto one or more nodes.
Examples include 'undercloud control plane', 'overcloud control
plane', 'overcloud storage', 'overcloud compute' etc.
- instance - A role deployed on a node - this is where work actually
happens.
- scheduling - the process of deciding which role is deployed on which node.
The way TripleO works is that we defined a Heat template that lays out
policy: 5 instances of 'overcloud control plane please', '20
hypervisors' etc. Heat passes that to Nova, which pulls the image for
the role out of Glance, picks a node, and deploys the image to the
node.
Note in particular the order: Heat -> Nova -> Scheduler -> Node chosen.
The user action is not 'allocate a Node to 'overcloud control plane',
it is 'size the control plane through heat'.
So when we talk about 'unallocated Nodes', the implication is that
users 'allocate Nodes', but they don't: they size roles, and after
doing all that there may be some Nodes that are - yes - unallocated,
or have nothing scheduled to them. So... I'm not debating that we
should have a list of free hardware - we totally should - I'm debating
how we frame it. 'Available Nodes' or 'Undeployed machines' or
whatever. I just want to get away from talking about something
([manual] allocation) that we don't offer.
-Rob
--
Robert Collins <rbtcoll...@hp.com>
Distinguished Technologist
HP Converged Cloud
_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
