<div dir="ltr"><div>Hi Przemek,<br><br>Thanks for detailed description of the issues you faced.<br><br>+1 for this approach, let's keep pure-UI implementation for 6.1 - it will work for 99% of the cases.<br><br></div></div><div class="gmail_extra"><br><div class="gmail_quote">2015-02-26 21:35 GMT+07:00 Przemyslaw Kaminski <span dir="ltr"><<a href="mailto:pkaminski@mirantis.com" target="_blank">pkaminski@mirantis.com</a>></span>:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hello,<br>
<br>
Recently I've been asked to implement Python side of a simple feature:<br>
before deployment tell the UI user that network verification for current<br>
cluster configuration has not been performed. Moreover, on the UI side<br>
it's possible to do network checking on usaved cluster data -- in that<br>
case treat is as no network checking was performed. Unfortunately it<br>
turned out to be not at all that simple to implement on the backend and<br>
I'll try to explain why.<br>
<br>
I ended up with the implementation [1] that added a tri-valued flag to<br>
the Cluster model. What's surprising I got stuck at the idempotency test<br>
of network configuration: I've sent a GET request on network config,<br>
then sent a PUT with the received data and asserted that nothing<br>
changed. What's strange in about 1/4 cases this test failed because some<br>
ips got assigned differently. I wasn't able to explain why (I had other<br>
tasks to do and this one was somewhat of a side-project). BTW, it turned<br>
out that we have at least 2 functions that are used to deeply compare 2<br>
objects, both unnecessary IMHO as there are 3rd party libs for this,<br>
like [3].<br>
<br>
Another issue was that network configuration PUT returns a task while<br>
actually there is no asynchronicity there at all, it's just a huge<br>
validator that executes everything synchronously. This was already<br>
heavily commented in [2] and it's proposed to remove that task<br>
completely. Moreover Nova and Neutron backends returned different<br>
statuses albeit their verification code was almost the same. A<br>
unification of these 2 handlers was proposed in [1].<br>
<br>
Another issue is that we have to somehow invalidate the flag that says<br>
cluster verification is done. It is not difficult to overwrite the save<br>
method for Cluster so that any change in cluster invalidates network<br>
checking. But it's not that simple. First of all -- not all cluster's<br>
changes should invalidate the network checking. Second -- not only<br>
cluster changes invalidate that -- adding nodes to cluster, for example,<br>
invalidates network checking too. Adding triggers all over the code that<br>
check this don't seem to be a good solution.<br>
<br>
So what I proposed is to instead of having a simple flag like in [1] to<br>
actually store the whole JSON object with serialized network<br>
configuration. The UI, upon deployment, will ask the API about cluster<br>
and there we will return an additional key called 'network_status_check'<br>
that is 'failed', 'passed' or 'not_performed'. The API will determine<br>
that flag by getting that saved JSON object and comparing it with a<br>
freshly serialized object. This way we don't need to alter the flag upon<br>
save or anything, we just compute if it was changed on demand.<br>
<br>
I guess this change grew out so big that it requires a blueprint and can<br>
be done for 7.0. The feature can be implemented on the UI side only that<br>
covers most (but not all of) the problems and is "good enough" for 6.1.<br>
<br>
[1] <a href="https://review.openstack.org/153556" target="_blank">https://review.openstack.org/153556</a><br>
[2]<br>
<a href="https://review.openstack.org/#/c/137642/15/nailgun/nailgun/api/v1/handlers/network_configuration.py" target="_blank">https://review.openstack.org/#/c/137642/15/nailgun/nailgun/api/v1/handlers/network_configuration.py</a><br>
[3] <a href="https://github.com/inveniosoftware/dictdiffer" target="_blank">https://github.com/inveniosoftware/dictdiffer</a><br>
<br>
P.<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>
</blockquote></div><br><br clear="all"><br>-- <br><div class="gmail_signature"><div dir="ltr"><div><div dir="ltr">Vitaly Kramskikh,<br>Fuel UI Tech Lead,<br>Mirantis, Inc.</div></div></div></div>
</div>