<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 01/15/2014 10:53 AM, Jaromir Coufal
wrote:<br>
</div>
<blockquote cite="mid:52D65AB1.8080506@redhat.com" type="cite">On
2014/13/01 13:15, Ladislav Smola wrote:
<br>
<blockquote type="cite">
<blockquote type="cite">The usage of roles is new metric which
doesn't exist. It is the most
<br>
consumed HW resource (which means if CPU is consumed by 60 %
and RAM
<br>
or disk are less, then the role usage is 60 %). It would be
great to
<br>
have such a metric from Ceilometer. However, I don't know how
much
<br>
support they will give us. We can get partial metrics (CPU,
RAM, Disk)
<br>
from Ceilometer, but the final Role usage is questionable.
<br>
</blockquote>
<br>
We will be able to get 3 meters avg. in one query, so we should
be able
<br>
to easily determine which metrics we want to show. As I am
thinking
<br>
about it, I would like to show what metric we are showing
anyway. Cause
<br>
naming 'capacity' as max(CPU, RAM, Disk) might be confusing.
<br>
</blockquote>
Those 3 meters are correct. And exposing those 3 metrics at one
overview page for quick glance is overwhelming for user. Important
for him is to see, how much resources is left for my
deployment/role. Showing them 3 graphs instead of one is too much
information if I don't want to look at detailed data.
<br>
<br>
That's why I think that 'role capacity' is important to show. And
not just actual consumption but also historical data.
<br>
<br>
</blockquote>
<br>
Sure but still I would show capacity(cpu), capacity(memory) and
later allow to click on that to show all meters. Otherwise people
will ask: What is the capacity in this case? Just saying.<br>
<br>
<blockquote cite="mid:52D65AB1.8080506@redhat.com" type="cite">
<blockquote type="cite">
<blockquote type="cite">
<blockquote type="cite">- When a role is edited, if it has
existing nodes deployed with the old
<br>
version, are the automatically/immediately updated? If not,
how do we
<br>
reflect that there's a difference between how the role is
currently
<br>
configured and the nodes that were previously created from
it?
<br>
</blockquote>
I would expect any Role change to be applied immediately. If
there is
<br>
some change where I want to keep older nodes how they are set
up and
<br>
apply new settings only to new added nodes, I would create new
Role then.
<br>
<br>
</blockquote>
<br>
Hmm, I would rather see preview page, because it's quite
dangerous
<br>
operation. Though that's future talking.
<br>
</blockquote>
Well - yes. But what we are talking at the moment is Icehouse
timeframe and we don't have anything where to store the
information about changes at the moment. And it would be pretty
expensive operation. So that's why I said - focus on allow
changes, apply immediately. Of course, the direction should go the
way of preview all the changes and apply all together.
<br>
<br>
</blockquote>
<br>
ok<br>
<br>
<blockquote cite="mid:52D65AB1.8080506@redhat.com" type="cite">
<br>
<blockquote type="cite">"If there is some change where I want to
keep older nodes how they are
<br>
set up and apply new settings only to new added nodes" this
should not
<br>
be ever possible. All nodes under the Role has to be the same.
<br>
</blockquote>
That is incorrect. Nodes can be heterogeneous. You can have
multiple node profiles, you can have higher hw spec then spec of
the node profile (flavor), so that node can be chosen as well,
etc.
<br>
<br>
</blockquote>
<br>
I believe tripleo count with one baremetal flavor for I. So that
would mean homogeneous hardware. 'All nodes under the Role has to be
the same' within one group they will use the same image and will be
the same.<br>
<br>
<blockquote cite="mid:52D65AB1.8080506@redhat.com" type="cite">
<blockquote type="cite">
<br>
I believe Jay was asking about the preview page. So if it won't
be
<br>
immediately updated, you would store what you want to update.
Then you
<br>
could even see it all summarized on a preview page before you
hit 'update'.
<br>
</blockquote>
Nope, I believe it was about keeping nodes with different settings
in. I hope I answered the question before.
<br>
<br>
</blockquote>
<br>
So, I am not really sure about what are you talking about. :-) The
stack will be always updated due to template.<br>
<br>
<blockquote cite="mid:52D65AB1.8080506@redhat.com" type="cite">
<br>
<blockquote type="cite">
<blockquote type="cite">Related question is - when send heat
change, are the nodes immediately
<br>
ready for use once each node is provisioned? Or... when node
is
<br>
provisioned, it waits for the heat template to get finished
and then
<br>
they all get to operation together?
<br>
<br>
</blockquote>
<br>
I would say that it depends on node. E.g. once compute node is
<br>
registered to overcloud nova scheduler, you can start to use it.
So it
<br>
should be similar for others. This applies only for
stack-update.
<br>
</blockquote>
I am asking in general. When I am doing my first deployment, are
the nodes coming up being ready one by one or all at the same time
once the process is finished?
<br>
<br>
When doing heat template change and changing number of nodes, are
the nodes coming up one by one when they are ready? Or do they
appear ready only after stack-update is finished?
<br>
<br>
(talking about all roles, not just compute)
<br>
</blockquote>
<br>
When you do stack-create, you need to do initialization after (step
8
<meta http-equiv="content-type" content="text/html;
charset=ISO-8859-1">
<a
href="http://docs.openstack.org/developer/tripleo-incubator/devtest_undercloud.html">http://docs.openstack.org/developer/tripleo-incubator/devtest_undercloud.html</a>)
so you can't use overcloud until that is done.<br>
<br>
With heat stack-update, you should be able to use nodes as they are
being registered to overcloud controllers. I believe the is no final
step that would prevent it from working.<br>
<br>
<br>
<blockquote cite="mid:52D65AB1.8080506@redhat.com" type="cite">
<br>
-- Jarda
<br>
<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>
<br>
</body>
</html>