Open Stack

On 02/09/2015 12:06 PM, Dmitriy Shulyak wrote:
> 
> On Mon, Feb 9, 2015 at 12:51 PM, Przemyslaw Kaminski 
> <pkaminski at mirantis.com <mailto:pkaminski at mirantis.com>> wrote:
> 
> Well, there are some problems with this solution: 1. No 'pick
> latest one with filtering to network_verify' handler is available
> currently.
> 
> 
> Well i think there should be finished_at field anyway, why not to
> add it for this purpose?

So you're suggesting to add another column and modify all tasks for
this one feature?

> 
> 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
> 
> 
> I dont actually recall what was the reason to delete them, but if
> it happens imo it is ok to show right now that network verification
> wasnt performed.

Is this how one does predictible and easy to understand software?
Sometimes we'll say that verification is OK, othertimes that it wasn't
performed?

> 
> 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.
> 
> 
> My point that it has very limited UX. Right now network check is: -
> l2 with vlans verication - dhcp verification
> 
> When we will have time we will add: - multicast routing
> verification - public gateway Also there is more stuff that
> different users was asking about.
> 
> Then i know that vmware team also wants to implement
> pre_deployment verifications.
> 
> So what this net_check_status will refer to at that point?

Issue #3 I described is still valid -- what is your solution in this case?

If someone implements pre-deployment network verifications and doesn't
add the procedures to network verification task then really no
solution can prevent the user from being able to deploy a cluster with
some invalid configuration. It's not an issue with providing info that
network checks were or weren't made.

As far as I understand, there's one supertask 'verify_networks'
(called in nailgu/task/manager.py line 751). It spawns other tasks
that do verification. When all is OK verify_networks calls RPC's
'verify_networks_resp' method and returns a 'ready' status and at that
point I can inject code to also set the DB column in cluster saying
that network verification was OK for the saved configuration. Adding
other tasks should in no way affect this behavior since they're just
subtasks of this task -- or am I wrong?

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
>