<html>

  <head>

    <meta content="text/html; charset=UTF-8" http-equiv="Content-Type">

  </head>

  <body bgcolor="#FFFFFF" text="#333333">

    Hey Matt,<br>

    <br>

    thanks for the comments, I'll try to reply below:<br>

    <br>

    <div class="moz-cite-prefix">On 2013/05/12 20:32, Matt Wagner wrote:<br>

    </div>

    <blockquote cite="mid:52A0D4E5.6080502@redhat.com" type="cite">

      <pre wrap="">On Tue Dec  3 06:53:04 2013, Jaromir Coufal wrote:

I've somehow overlooked the 'Node tags' previously. I'm curious what

format these would take, or if this is something we've discussed. I

remember hearing us kick around an idea for key-value pairs for storing

arbitrary information, maybe ram=64g or rack=c6. Is that what the tags

you have are intended for?</pre>

    </blockquote>

    Not exactly. This is not key-value approach but more like an

    arbitrary information (or grouping), what user can enter in. It can

    be very efficient way for the user to express various

    meta-information about the node if he cares. For example from the

    beginning, when we are missing some functionality from Ironic (like

    location, rack information, etc), we can use manual tagging instead.

    This might be already part of Ironic, so we just need to check if

    that's correct<br>

    <br>

    <br>

    <blockquote cite="mid:52A0D4E5.6080502@redhat.com" type="cite">

      <pre wrap="">

One thing I notice here -- and I really hope I'm not opening a can of

worms -- is that this seems to require that you manage many nodes. I

know that's our focus, and I entirely agree with it. But with the way

things are represented in this, it doesn't seem like it would be

possible for a user to set up an all-in-one system (say, for testing)

that ran compute and storage on the same node.

I think it would be very fair to say that's just something we're not

focusing on at this point, and that to start out we're just going to

handle the simple case of wanting to install many nodes, each with only

one distinct type. But I just wanted to clarify that we are, indeed,

making that decision?</pre>

    </blockquote>

    I am convinced that this was never scope of our efforts. We are

    focusing not just about installation of overcloud but also about

    monitoring and furthermore easy *scaling*. Mixing compute and

    storage services at one node would be very inefficient and for vast

    majority of deployments unrealistic scenario.<br>

    <br>

    Though, in the future if we find out that there are multiple cases

    of this being a way how people setup their deployments, we might

    reconsider to support this approach. But I have never heard about

    that so far and I don't think that it will happen.<br>

    <br>

    Cheers<br>

    -- Jarda<br>

    <blockquote cite="mid:52A0D4E5.6080502@redhat.com" type="cite">

    </blockquote>

    <br>

  </body>

</html>