<html>
  <head>
    <meta content="text/html; charset=ISO-8859-1"
      http-equiv="Content-Type">
  </head>
  <body bgcolor="#FFFFFF" text="#000000">
    <div class="moz-cite-prefix">On 12/11/2013 08:54 PM, Jay Dobies
      wrote:<br>
    </div>
    <blockquote cite="mid:52A8C308.8050800@redhat.com" type="cite">
      <br>
      So glad we're hashing this out now. This will save a bunch of
      headaches in the future. Good call pushing this forward.
      <br>
      <br>
      On 12/11/2013 02:15 PM, Tzu-Mainn Chen wrote:
      <br>
      <blockquote type="cite">Hi,
        <br>
        <br>
        I'm trying to clarify the terminology being used for Tuskar,
        which may be helpful so that we're sure
        <br>
        that we're all talking about the same thing :)  I'm copying
        responses from the requirements thread
        <br>
        and combining them with current requirements to try and create a
        unified view.  Hopefully, we can come
        <br>
        to a reasonably rapid consensus on any desired changes; once
        that's done, the requirements can be
        <br>
        updated.
        <br>
        <br>
        * NODE a physical general purpose machine capable of running in
        many roles. Some nodes may have hardware layout that is
        particularly
        <br>
                useful for a given role.
        <br>
      </blockquote>
      <br>
      Do we ever need to distinguish between undercloud and overcloud
      nodes?
      <br>
      <br>
      <blockquote type="cite">      * REGISTRATION - the act of creating
        a node in Ironic
        <br>
      </blockquote>
      <br>
      DISCOVERY - The act of having nodes found auto-magically and added
      to Ironic with minimal user intervention.
      <br>
      <br>
      <blockquote type="cite">
        <br>
              * ROLE - a specific workload we want to map onto one or
        more nodes. Examples include 'undercloud control plane',
        'overcloud control
        <br>
                plane', 'overcloud storage', 'overcloud compute' etc.
        <br>
        <br>
                  * MANAGEMENT NODE - a node that has been mapped with
        an undercloud role
        <br>
                  * SERVICE NODE - a node that has been mapped with an
        overcloud role
        <br>
                     * COMPUTE NODE - a service node that has been
        mapped to an overcloud compute role
        <br>
                     * CONTROLLER NODE - a service node that has been
        mapped to an overcloud controller role
        <br>
                     * OBJECT STORAGE NODE - a service node that has
        been mapped to an overcloud object storage role
        <br>
                     * BLOCK STORAGE NODE - a service node that has been
        mapped to an overcloud block storage role
        <br>
        <br>
                  * UNDEPLOYED NODE - a node that has not been mapped
        with a role
        <br>
                       * another option - UNALLOCATED NODE - a node that
        has not been allocated through nova scheduler (?)
        <br>
                                            - (after reading lifeless's
        explanation, I agree that "allocation" may be a
        <br>
                                               misleading term under
        TripleO, so I personally vote for UNDEPLOYED)
        <br>
      </blockquote>
      <br>
      Undeployed still sounds a bit odd to me when paired with the word
      role. I could see deploying a workload "bundle" or something, but
      a role doesn't feel like a tangible thing that is pushed out
      somewhere.
      <br>
      <br>
      Unassigned? As in, it hasn't been assigned a role yet.
      <br>
      <br>
      <blockquote type="cite">      * INSTANCE - A role deployed on a
        node - this is where work actually happens.
        <br>
      </blockquote>
      <br>
      I'm fine with "instance", but the the phrasing "a role deployed on
      a node" feels odd to me in the same way "undeployed" does. Maybe a
      slight change to "A node that has been assigned a role", but that
      also may be me being entirely too nit-picky.
      <br>
      <br>
      To put it in context, on a scale of 1-10, my objection to this and
      "undeployed" is around a 2, so don't let me come off as
      strenuously objecting.
      <br>
      <br>
      <blockquote type="cite">* DEPLOYMENT
        <br>
        <br>
              * SIZE THE ROLES - the act of deciding how many nodes will
        need to be assigned to each role
        <br>
                    * another option - DISTRIBUTE NODES (?)
        <br>
                                          - (I think the former is more
        accurate, but perhaps there's a better way to say it?)
        <br>
        <br>
              * SCHEDULING - the process of deciding which role is
        deployed on which node
        <br>
      </blockquote>
      <br>
      I know this derives from a Nova term, but to me, the idea of
      "scheduling" carries a time-in-the-future connotation to it. The
      interesting part of what goes on here is the assignment of which
      roles go to which instances.
      <br>
      <br>
      <blockquote type="cite">      * SERVICE CLASS - a further
        categorization within a service role for a particular
        deployment.
        <br>
      </blockquote>
      <br>
      I don't understand this one, can you add a few examples?
      <br>
    </blockquote>
    <br>
    See wireframes [1] page 19, says "Compute Nodes" which is the
    default service class. Box below "Create New Compute Class" serves
    to creation of new service class. Nodes in Service Classes are
    differentiated by Node Profiles.<br>
    <br>
    [1]
    <meta http-equiv="content-type" content="text/html;
      charset=ISO-8859-1">
    <a
href="http://people.redhat.com/%7Ejcoufal/openstack/tripleo/2013-12-03_tripleo-ui_03-deployment.pdf">http://people.redhat.com/~jcoufal/openstack/tripleo/2013-12-03_tripleo-ui_03-deployment.pdf</a><br>
    <br>
    <blockquote cite="mid:52A8C308.8050800@redhat.com" type="cite">
      <br>
      <blockquote type="cite">           * NODE PROFILE - a set of
        requirements that specify what attributes a node must have in
        order to be mapped to
        <br>
                                    a service class
        <br>
      </blockquote>
      <br>
      Even without knowing what "service class" is, I like this one.  :)
      <br>
      <br>
      <blockquote type="cite">
        <br>
        <br>
        Does this seem accurate?  All feedback is appreciated!
        <br>
        <br>
        Mainn
        <br>
      </blockquote>
      <br>
      Thanks again  :D
      <br>
      <br>
       _______________________________________________
      <br>
      <blockquote type="cite">OpenStack-dev mailing list
        <br>
        <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
        <br>
<a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
        <br>
        <br>
        <br>
      </blockquote>
      <br>
      _______________________________________________
      <br>
      OpenStack-dev mailing list
      <br>
      <a class="moz-txt-link-abbreviated" href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a>
      <br>
      <a class="moz-txt-link-freetext" href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a>
      <br>
    </blockquote>
    Jirka<br>
  </body>
</html>