Open Stack

On 02/07/2015 12:09 PM, Dmitriy Shulyak wrote:
> 
> On Thu, Jan 15, 2015 at 6:20 PM, Vitaly Kramskikh 
> <vkramskikh at mirantis.com <mailto:vkramskikh at mirantis.com>> wrote:
> 
> I want to discuss possibility to add network verification status 
> field for environments. There are 2 reasons for this:
> 
> 1) One of the most frequent reasons of deployment failure is wrong 
> network configuration. In the current UI network verification is 
> completely optional and sometimes users are even unaware that this 
> feature exists. We can warn the user before the start of
> deployment if network check failed of wasn't performed.
> 
> 2) Currently network verification status is partially tracked by 
> status of the last network verification task. Sometimes its
> results become stale, and the UI removes the task. There are a few
> cases when the UI does this, like changing network settings, adding
> a new node, etc (you can grep "removeFinishedNetworkTasks" to see
> all the cases). This definitely should be done on backend.
> 
> 
> 
> Additional field on cluster like network_check_status? When it will
> be populated with result? I think it will simply duplicate
> task.status with network_verify name
> 
> Network check is not a single task.. Right now there is two, and 
> probably we will need one more right in this release (setup public 
> network and ping gateway). And AFAIK there is a need for other pre 
> deployment verifications..
> 
> I would prefer to make a separate tab with pre_deployment
> verifications, similar to ostf. But if you guys want to make smth
> right now, compute status of network verification based on task
> with name network_verify, if you deleted this task from UI (for
> some reason) just add warning that verification wasnt performed. If
> there is more than one task with network_verify for any given
> cluster - pick latest one.

Well, there are some problems with this solution:
1. No 'pick latest one with filtering to network_verify' handler is
available currently.
2. Tasks are ephemeral entities -- they get deleted here and there.
Look at nailgun/task/manager.py for example -- lines 83-88 or lines
108-120 and others
3. Just having network verification status as ready is NOT enough.
>From the UI you can fire off network verification for unsaved changes.
Some JSON request is made, network configuration validated by tasks
and RPC call made returing that all is OK for example. But if you
haven't saved your changes then in fact you haven't verified your
current configuration, just some other one. So in this case task
status 'ready' doesn't mean that current cluster config is valid. What
do you propose in this case? Fail the task on purpose? I only see a
solution to this by introducting a new flag and network_check_status
seems to be an appropriate one.

P.

> 
> 
> 
> __________________________________________________________________________
>
> 
OpenStack Development Mailing List (not for usage questions)
> Unsubscribe:
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe 
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>