Hey Matt,

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

On 2013/05/12 20:32, Matt Wagner wrote:
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?
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


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

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.

Cheers
-- Jarda

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to