<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>