<div dir="ltr">Folks<div><br></div><div>As I generally support the idea of getting rid of cluster status, this requires thorough design. My opinion here is that we should leave it as a function of nodes state until we come up with a variant of better calculation of cluster status. Nevertheless it is true that cluster status is actually a function of other primary data and should be calculated on the client side. I suggest that we move towards more fine-grained component-based architecture (simplest example is OpenStack Fuel vs non-OpenStack Fuel) and figure out a way of calculating each component's status. Then we should calculate each component's status and then a cluster status should be an aggregate of those. For example, we could say that the only components we have right now are nodes and the aggregate is based on the nodes status and whether they are critical or not.</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Mar 15, 2016 at 9:16 PM, Andrew Woodward <span dir="ltr"><<a href="mailto:xarses@gmail.com" target="_blank">xarses@gmail.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div><br></div><br><div class="gmail_quote"><span class=""><div dir="ltr">On Tue, Mar 15, 2016 at 4:04 AM Roman Prykhodchenko <<a href="mailto:me@romcheg.me" target="_blank">me@romcheg.me</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Fuelers,<br>
<br>
I would like to continue the series of "Getting rid of …" emails. This time I’d like to talk about statuses of clusters.<br>
<br>
The issues with that attribute is that it is not actually related to real world very much and represents nothing. A few month ago I proposed to make it more real-world-like [1] by replacing a simple string by an aggregated value. However, after task based deployment was introduced even that approach lost its connection to the real world.<br>
<br>
My idea is to get rid of that attribute from a cluster and start working with status of every single node in it. Nevertheless, we only have tasks that are executed on nodes now, so we cannot apply the "status" term to them. What if we replace that with a sort of boolean value called maintenance_mode (or similar) that we will use to tell if the node is operational or not. After that we will be able to use an aggregated property for cluster and check, if there are any nodes that are under a progress of performing some tasks on them.<br></blockquote><div><br></div></span><div>Yes, we still need an operations attribute, I'm not sure a bool is enough, but you are quite correct, setting the status of the cluster after operational == True based on the result of a specific node failing, is in practice invalid. </div><div><br></div><div>At the same time, operational == True is not necessarily deployment succeeded, its more along the line of deployment validated, which may be further testing passing like ostf, or more manual in the operator wants to do more testing their own prior to changing the state. </div><div><br></div><div>As we adventure in to the LCM flow, we actually need status of each component in addition of the general status of the cluster to determine the proper course of action the on the next operation.</div><div><br></div><div>For example nova-compute</div><div>if the cluster is not operational, then we can provision compute nodes, and have them enabled, or active in the scheduler automatically. However if the cluster is operational, a new compute node must be disabled, or otherwise blocked from the default scheduler until the node has received validation. In this case the interpretation of operational is quite simple</div><div><br></div><div>For example ceph</div><div>Here we care less about the status of the cluster (slightly, this example ignores ceph's impact on nova-compute), and more about the status of the service. In the case that we deploy ceph-osd's when their are not replica factor osd hosts online (3) the we can provision the OSD's similar to nova-compute,  in that we can bring them all online and active and data could be placed to them immediately (more or less). but if the ceph status is operational, then we have to take a different action, the OSD's have to be brought in disabled, and gradually(probably by the operator) have their data weight increased so they don't clog the network with data peering which causes the clients may woes. </div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">
Thoughts, ideas?<br>
<br>
<br>
References:<br>
<br>
1. <a href="https://blueprints.launchpad.net/fuel/+spec/complex-cluster-status" rel="noreferrer" target="_blank">https://blueprints.launchpad.net/fuel/+spec/complex-cluster-status</a><br>
<br>
<br>
- romcheg<br></span>
__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><span class="HOEnZb"><font color="#888888"><br>
</font></span></blockquote></div></div><span class="HOEnZb"><font color="#888888"><div dir="ltr">-- <br></div><div dir="ltr"><p dir="ltr">--</p><p dir="ltr"><span style="font-size:13.1999998092651px">Andrew Woodward</span></p><p dir="ltr"><span style="font-size:13.1999998092651px">Mirantis</span></p><p dir="ltr"><span style="font-size:13.1999998092651px">Fuel Community Ambassador</span></p><p dir="ltr"><span style="font-size:13.1999998092651px">Ceph Community</span></p>
</div>
</font></span><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">Yours Faithfully,<br>Vladimir Kuklin,<br>Fuel Library Tech Lead,<br>Mirantis, Inc.<br>+7 (495) 640-49-04<br>+7 (926) 702-39-68<br>Skype kuklinvv<br>35bk3, Vorontsovskaya Str.<br>Moscow, Russia,<br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.com</a><br><a href="http://www.mirantis.ru/" target="_blank">www.mirantis.ru</a><br><a href="mailto:vkuklin@mirantis.com" target="_blank">vkuklin@mirantis.com</a></div></div></div></div>
</div>