[openstack-dev] [TripleO] UI Wireframes - close to implementation start

Jaromir Coufal jcoufal at redhat.com
Fri Dec 6 10:46:43 UTC 2013


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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20131206/3a22de9c/attachment.html>


More information about the OpenStack-dev mailing list