<div dir="ltr">Excellent, nice to know that we're on the same page about this.<div><br></div><div>Thank you!</div><div><br></div><div>--</div><div>Best regards,</div><div>Oleg Gelbukh</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Wed, May 27, 2015 at 12:22 PM, Roman Prykhodchenko <span dir="ltr"><<a href="mailto:me@romcheg.me" target="_blank">me@romcheg.me</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Oleg,<div><br></div><div>Thanks for the feedback. I have the following as a response:</div><div><br></div><div>1. This spec is just an excerpt for scoping in the proposed improvement to the 7.0 release plan. If it get’s scope the full specification will go through a standard review process so it will be possible to discuss names along with the rest of details then.</div><div><br></div><div>2. It’s already noticed in the spec the status is is generated using an aggregate query like you described so I don’t propose to store it. Storing that data will require sophisticated algorithms to work with it and also will lead to more locks or race conditions in the database. So yes, it’s going to be a method.</div><div><br></div><div><br></div><div>- romcheg</div><div><br></div><div><br><div><blockquote type="cite"><div>27 трав. 2015 о 08:19 Oleg Gelbukh <<a href="mailto:ogelbukh@mirantis.com" target="_blank">ogelbukh@mirantis.com</a>> написав(ла):</div><div><div class="h5"><br><div><div dir="ltr">Roman,<div><br></div><div>This looks like a great solution to me, and I like your proposal very much. The status of cluster derived directly from statuses of nodes is exactly what I was thinking about.</div><div><br></div><div>I have to notes to the proposal, and I can copy them to etherpad if you think they deserve it:</div><div><br></div><div>1) status name 'operational' seem a bit unclear to me, as it sounds more like something Monitoring should report: it implies that the actual OpenStack environment is operational, which might or might not be a case, and Fuel has no way to tell. I would really prefer if that status name was 'Deployed' or something along those lines.</div><div><br></div><div>2) I'm not sure if we need to keep the complex status of the cluster explicitly in 'cluster' table in the format you suggest. This information can be taken directly from 'nodes' table in Nailgun DB. For example, getting it in the second form you propose is as simple as: </div><div><br></div><div>nailgun=> SELECT status,count(status) FROM nodes GROUP BY status;</div><div>discover|1</div><div>ready|5<br></div><div><br></div><div>What do you think about making it a method rather then an element of data model? Or that's exactly the complexity you want to get rid of?</div><div><br></div><div>--</div><div>Best regards,</div><div>Oleg Gelbukh</div><div><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, May 26, 2015 at 4:16 PM, Roman Prykhodchenko <span dir="ltr"><<a href="mailto:me@romcheg.me" target="_blank">me@romcheg.me</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div style="word-wrap:break-word">Oleg,<div><br></div><div>Aleksander also proposed a nice proposed a nice solution [1] which is to have a complex status for cluster. That, however, looks like a BP so I’ve created an excerpt [2] for it and we will try to discuss it scope it for 7.0, if there is a consensus.</div><div><br></div><div><br></div><div>References:</div><div><br></div><div>1. <a href="http://lists.openstack.org/pipermail/openstack-dev/2015-May/064670.html" target="_blank">http://lists.openstack.org/pipermail/openstack-dev/2015-May/064670.html</a></div><div>2. <a href="https://etherpad.openstack.org/p/fuel-cluster-complex-status" target="_blank">https://etherpad.openstack.org/p/fuel-cluster-complex-status</a></div><div><br></div><div><br></div><div>- romcheg</div><div><br><div><blockquote type="cite"><div>22 трав. 2015 о 22:32 Oleg Gelbukh <<a href="mailto:ogelbukh@mirantis.com" target="_blank">ogelbukh@mirantis.com</a>> написав(ла):</div><div><div><br><div><div dir="ltr">Roman,<div><br></div><div>I'm totally for fixing Nailgun. However, the status of environment is not simply function of statuses of nodes in it. Ideally, it should depend on whether appropriate number of nodes of certain roles are in 'ready' status. For the meantime, it would be enough if environment was set to 'operational' when all nodes in it become 'ready', no matter how they were deployed (i.e. via Web UI or CLI).</div><div><br></div><div>--</div><div>Best regards,</div><div>Oleg Gelbukh</div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, May 22, 2015 at 5:33 PM, Roman Prykhodchenko <span dir="ltr"><<a href="mailto:me@romcheg.me" target="_blank">me@romcheg.me</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi folks!<br>
<br>
Recently I encountered an issue [1] that the Deploy Changes button in the web ui is still active when a provisioning of single node is started using the command line client.<br>
The background for that issue is that the provisioning task does not seem to update the cluster status correctly and Nailgun’s API returns it as NEW even while some of the node are been provisioned.<br>
<br>
The reason for raising this thread in the mailing list is that provisioning a node is a feature for developers and basically end-users should not do that. What is the best solution for that: fix Nailgun to set the correct status, or make this provisioning feature available only for developers?<br>
<br>
1. <a href="https://bugs.launchpad.net/fuel/7.0.x/+bug/1449086" target="_blank">https://bugs.launchpad.net/fuel/7.0.x/+bug/1449086</a><br>
<br>
<br>
- romcheg<br>
<br>
<br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br></div></div></div></blockquote></div><br></div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>
__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" target="_blank">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br></div></div></div></blockquote></div><br></div></div><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>