<html>
<head>
<meta content="text/html; charset=UTF-8" http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#333333">
<br>
<div class="moz-cite-prefix">On 2013/06/12 21:26, Tzu-Mainn Chen
wrote:<br>
</div>
<blockquote
cite="mid:1303970730.3402119.1386361562712.JavaMail.root@redhat.com"
type="cite"> * can be allocated as one of four node types
<blockquote type="cite">
<pre wrap="">
It's pretty clear by the current verbiage but I'm going to ask anyway:
"one and only one"?
</pre>
</blockquote>
<pre wrap="">
Yep, that's right!</pre>
</blockquote>
Confirming. One and only one.<br>
<br>
<blockquote
cite="mid:1303970730.3402119.1386361562712.JavaMail.root@redhat.com"
type="cite">
<blockquote type="cite">
<pre wrap="">My gut reaction is that we want to bite this off sooner rather than
later. This will have data model and API implications that, even if we
don't commit to it for Icehouse, should still be in our minds during it,
so it might make sense to make it a first class thing to just nail down now.
</pre>
</blockquote>
<pre wrap="">
That is entirely correct, which is one reason it's on the list of requirements. The
forthcoming API design will have to account for it. Not recreating the entire data
model between releases is a key goal :)</pre>
</blockquote>
Well yeah, that's why we should try to think in a longer-term and
wireframes are covering also a bit more than might land in Icehouse.
So that we are aware of future direction and we don't have to
completely rebuild underlying models later on.<br>
<br>
<blockquote
cite="mid:1303970730.3402119.1386361562712.JavaMail.root@redhat.com"
type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""> * optional node profile for a resource class (M)
* acts as filter for nodes that can be allocated to that
class (M)
</pre>
</blockquote>
<pre wrap="">
To my understanding, once this is in Icehouse, we'll have to support
upgrades. If this filtering is pushed off, could we get into a situation
where an allocation created in Icehouse would no longer be valid in
Icehouse+1 once these filters are in place? If so, we might want to make
it more of a priority to get them in place earlier and not eat the
headache of addressing these sorts of integrity issues later.
</pre>
</blockquote>
</blockquote>
Hm, can you be a bit more specific about how the allocation created
in I might no longer be valid in I+1?<br>
<br>
<blockquote
cite="mid:1303970730.3402119.1386361562712.JavaMail.root@redhat.com"
type="cite">
<pre wrap="">
That's true. The problem is that to my understanding, the filters we'd
need in nova-scheduler are not yet fully in place.</pre>
</blockquote>
I think at the moment there are 'extra params' which we might use to
some level. But yes, AFAIK there is missing part for filtered
scheduling in nova.<br>
<blockquote
cite="mid:1303970730.3402119.1386361562712.JavaMail.root@redhat.com"
type="cite">
<pre wrap="">
I also think that this is an issue that we'll need to address no matter what.
Even once filters exist, if a user applies a filter *after* nodes are allocated,
we'll need to do something clever if the already-allocated nodes don't meet the
filter criteria.</pre>
</blockquote>
Well here is a thing. Once nodes are allocated, you can get warning,
that those nodes in the resource class are not fulfilling the
criteria (if they were changed) but that's all. It will be up to
user's decision if he wants to keep them in or unallocate them. The
profiles are important when a decision 'which node can get in' is
being made. <br>
<br>
<blockquote
cite="mid:1303970730.3402119.1386361562712.JavaMail.root@redhat.com"
type="cite">
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""> * nodes can be viewed by node types
* additional group by status, hardware specification
* controller node type
* each controller node will run all openstack services
* allow each node to run specified service (F)
* breakdown by workload (percentage of cpu used per node) (M)
* Unallocated nodes
</pre>
</blockquote>
<pre wrap="">
Is there more still being flushed out here? Things like:
* Listing unallocated nodes
* Unallocating a previously allocated node (does this make it a
vanilla resource or does it retain the resource type? is this the only
way to change a node's resource type?)</pre>
</blockquote>
</blockquote>
If we use policy based approach then yes this is correct. First
unallocate a node and then increase number of resources in other
class.<br>
<br>
But I believe that we need keep control over your infrastructure and
not to relay only on policies. So I hope we can get into something
like 'reallocate'/'allocate manually' which will force a node to be
part of specific class.<br>
<br>
<blockquote
cite="mid:1303970730.3402119.1386361562712.JavaMail.root@redhat.com"
type="cite">
<blockquote type="cite">
<pre wrap="">
* Unregistering nodes from Tuskar's inventory (I put this under
unallocated under the assumption that the workflow will be an explicit
unallocate before unregister; I'm not sure if this is the same as
"archive" below).
</pre>
</blockquote>
<pre wrap="">
Ah, you're entirely right. I'll add these to the list.
</pre>
<blockquote type="cite">
<blockquote type="cite">
<pre wrap=""> * Archived nodes (F)
</pre>
</blockquote>
<pre wrap="">
Can you elaborate a bit more on what this is?
</pre>
</blockquote>
<pre wrap="">
To be honest, I'm a bit fuzzy about this myself; Jarda mentioned that there was
an OpenStack service in the process of being planned that would handle this
requirement. Jarda, can you detail a bit?</pre>
</blockquote>
So the thing is based on historical data. At the moment, there is no
service which would keep this type of data (might be new project?).
Since Tuskar will not be only deploying but also monitoring your
deployment, it is important to have historical data available. If
user removes some nodes from infrastructure, he would lose all the
data and we would not be able to generate graphs.That's why archived
nodes = nodes which were registered in past but are no longer
available.<br>
<br>
-- Jarda<br>
</body>
</html>