<div dir="ltr"><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Feb 9, 2015 at 1:35 PM, Przemyslaw Kaminski <span dir="ltr"><<a href="mailto:pkaminski@mirantis.com" target="_blank">pkaminski@mirantis.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>> Well i think there should be finished_at field anyway, why not to<br>
> add it for this purpose?<br>
<br>
</span>So you're suggesting to add another column and modify all tasks for<br>
this one feature?</blockquote><div><br></div><div>Such things as time stamps should be on all tasks anyway.</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
><br>
> I dont actually recall what was the reason to delete them, but if<br>
> it happens imo it is ok to show right now that network verification<br>
> wasnt performed.<br>
<br>
</span>Is this how one does predictible and easy to understand software?<br>
Sometimes we'll say that verification is OK, othertimes that it wasn't<br>
performed?<br>
<span><br></span></blockquote><div>In my opinion the questions that needs to be answered - what is the reason or event to remove verify_networks tasks history?</div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span>
><br>
> 3. Just having network verification status as ready is NOT enough.<br>
> From the UI you can fire off network verification for unsaved<br>
> changes. Some JSON request is made, network configuration validated<br>
> by tasks and RPC call made returing that all is OK for example. But<br>
> if you haven't saved your changes then in fact you haven't verified<br>
> your current configuration, just some other one. So in this case<br>
> task status 'ready' doesn't mean that current cluster config is<br>
> valid. What do you propose in this case? Fail the task on purpose?<br><br>
</span>Issue #3 I described is still valid -- what is your solution in this case?<br><br></blockquote><div>Ok, sorry.</div><div>What do you think if in such case we will remove old tasks?</div><div>It seems to me that is correct event in which old verify_networks is invalid anyway,</div><div>and there is no point to store history.</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<br>
As far as I understand, there's one supertask 'verify_networks'<br>
(called in nailgu/task/manager.py line 751). It spawns other tasks<br>
that do verification. When all is OK verify_networks calls RPC's<br>
'verify_networks_resp' method and returns a 'ready' status and at that<br>
point I can inject code to also set the DB column in cluster saying<br>
that network verification was OK for the saved configuration. Adding<br>
other tasks should in no way affect this behavior since they're just<br>
subtasks of this task -- or am I wrong?</blockquote><div> </div></div>It is not that smooth, but in general yes - it can be done when state of verify_networks is changed.</div><div class="gmail_extra">But lets say we have some_settings_verify task? Would be it valid to add one more field on cluster model, like some_settings_status?</div><div class="gmail_extra"><br></div><div class="gmail_extra"><br><br></div></div>