Re: [openstack-dev] [Fuel] [nailgun] [UI] network_check_status fleild for environments
On 02/07/2015 12:09 PM, Dmitriy Shulyak wrote: On Thu, Jan 15, 2015 at 6:20 PM, Vitaly Kramskikh vkramsk...@mirantis.com mailto:vkramsk...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] [nailgun] [UI] network_check_status fleild for environments
On 02/09/2015 12:06 PM, Dmitriy Shulyak wrote: On Mon, Feb 9, 2015 at 12:51 PM, Przemyslaw Kaminski pkamin...@mirantis.com mailto:pkamin...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] [nailgun] [UI] network_check_status fleild for environments
On Mon, Feb 9, 2015 at 12:51 PM, Przemyslaw Kaminski pkamin...@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? 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. 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? __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] [nailgun] [UI] network_check_status fleild for environments
Hi, my opinion on this: Yes, it is technically possible to implement this feature using only tasks. This may require adding new field to tasks to distinguish whether task was run for saved or unsaved changes. But I'm against this approach because: 1) It will require handling more than 1 task of a single type which automatically leads to increase of complexity of the code. We will need 2 tasks in the following case: there are 1 task for unsaved data and 1 for saved. We need to show result of the first task on the network tab and use status of the second task to determine whether the network check was performed. 2) We have 2 similar tasks: for deploying a cluster and settings up a release. Both cluster and release models have status field which represent status of these entities so we don't perform complex checks with tasks. So I think the same approach should be used for network verification status. As for tasks deletion, there are 2 reasons for this: 1) If we don't delete old tasks, it increases the traffic between backend and UI. There are still no way to fetch the latest task or 2 latest tasks using our API. 2) We delete tasks manually when their results are not needed anymore or become invalid. For example, when user adds another node, we remove network check task as its result is not valid anymore. Yet another example - when user clicks X button on the message with deployment result, we remove this task so it won't be shown anymore. If you want us not to delete these tasks, please provide us with another way to cover these cases. 2015-02-09 15:51 GMT+03:00 Przemyslaw Kaminski pkamin...@mirantis.com: On 02/09/2015 01:18 PM, Dmitriy Shulyak wrote: On Mon, Feb 9, 2015 at 1:35 PM, Przemyslaw Kaminski pkamin...@mirantis.com mailto:pkamin...@mirantis.com wrote: 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? Such things as time stamps should be on all tasks anyway. 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? In my opinion the questions that needs to be answered - what is the reason or event to remove verify_networks tasks history? 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? Issue #3 I described is still valid -- what is your solution in this case? Ok, sorry. What do you think if in such case we will remove old tasks? It seems to me that is correct event in which old verify_networks is invalid anyway, and there is no point to store history. Well, not exactly. Configure networks, save settings, do network check all assume that all went fine. Now change one thing without saving, check settings, didn't pass but it doesn't affect the flag because that's some different configuration from the saved one. And your original cluster is OK still. So in this case user will have to yet again run the original check. The plus of the network_check_status column is actually you don't need to store any history -- task can be deleted or whatever and still last checked saved configuration matters. User can perform other checks 'for free' and is not required to rerun the working configuration checks. With data depending on tasks you actually have to store a lot of history because you need to keep last working saved configuration -- otherwise user will have to rerun original configuration. So from usability point of view this is a worse solution. 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? It is not that smooth, but in general yes - it can be done when state of verify_networks is changed. But lets say we have some_settings_verify task? Would be it valid to add one more field
Re: [openstack-dev] [Fuel] [nailgun] [UI] network_check_status fleild for environments
On Mon, Feb 9, 2015 at 1:35 PM, Przemyslaw Kaminski pkamin...@mirantis.com wrote: 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? Such things as time stamps should be on all tasks anyway. 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? In my opinion the questions that needs to be answered - what is the reason or event to remove verify_networks tasks history? 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? Issue #3 I described is still valid -- what is your solution in this case? Ok, sorry. What do you think if in such case we will remove old tasks? It seems to me that is correct event in which old verify_networks is invalid anyway, and there is no point to store history. 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? It is not that smooth, but in general yes - it can be done when state of verify_networks is changed. 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? __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] [nailgun] [UI] network_check_status fleild for environments
On 02/09/2015 01:18 PM, Dmitriy Shulyak wrote: On Mon, Feb 9, 2015 at 1:35 PM, Przemyslaw Kaminski pkamin...@mirantis.com mailto:pkamin...@mirantis.com wrote: 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? Such things as time stamps should be on all tasks anyway. 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? In my opinion the questions that needs to be answered - what is the reason or event to remove verify_networks tasks history? 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? Issue #3 I described is still valid -- what is your solution in this case? Ok, sorry. What do you think if in such case we will remove old tasks? It seems to me that is correct event in which old verify_networks is invalid anyway, and there is no point to store history. Well, not exactly. Configure networks, save settings, do network check all assume that all went fine. Now change one thing without saving, check settings, didn't pass but it doesn't affect the flag because that's some different configuration from the saved one. And your original cluster is OK still. So in this case user will have to yet again run the original check. The plus of the network_check_status column is actually you don't need to store any history -- task can be deleted or whatever and still last checked saved configuration matters. User can perform other checks 'for free' and is not required to rerun the working configuration checks. With data depending on tasks you actually have to store a lot of history because you need to keep last working saved configuration -- otherwise user will have to rerun original configuration. So from usability point of view this is a worse solution. 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? It is not that smooth, but in general yes - it can be done when state of verify_networks is changed. 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? Well, why not? Cluster deployment is a task and it's status is saved in cluster colum and not fetched from tasks. As you see the logic of network task verification is not simply based on ready/error status reading but more subtle. What other settings you have in mind? I guess when we have more of them one can create a separate table to keep them, but for now I don't see a point in doing this. P. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] [nailgun] [UI] network_check_status fleild for environments
On Thu, Jan 15, 2015 at 6:20 PM, Vitaly Kramskikh vkramsk...@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. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] [nailgun] [UI] network_check_status fleild for environments
Guys, definitely we shouldn't delete tasks. +1 for warning. On Fri, Jan 16, 2015 at 3:58 PM, Evgeniy L e...@mirantis.com wrote: Hi, 1) +1 for warning 2) I don't think that we should delete tasks, it's a history which can be useful, for example for stats feature, also it's useful for debugging, but each task should have created_at and updated_at fields, and from api you will be able to get the latest tasks for specific env. Thanks, On Thu, Jan 15, 2015 at 7:20 PM, Vitaly Kramskikh vkramsk...@mirantis.com wrote: Folks, 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. What is your opinion on this? -- Vitaly Kramskikh, Software Engineer, Mirantis, Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] [nailgun] [UI] network_check_status fleild for environments
+1, It will be very helpful to warn user. Not all configurations (which can be set via UI/CLI w/o yaml editing) are supported by network checker. It should be taken into account. And we could recommend to run the check when user-defined configuration is uploaded but warn that given configuration might be not supported by network checker. Agree, this should be done on backend. Aleksey Kasatkin On Thu, Jan 15, 2015 at 10:54 PM, Lukasz Oles lo...@mirantis.com wrote: Big +1, it would save me a lot of debugging time :) On Thu, Jan 15, 2015 at 5:20 PM, Vitaly Kramskikh vkramsk...@mirantis.com wrote: Folks, 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. What is your opinion on this? -- Vitaly Kramskikh, Software Engineer, Mirantis, Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Łukasz Oleś __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] [nailgun] [UI] network_check_status fleild for environments
Hi, 1) +1 for warning 2) I don't think that we should delete tasks, it's a history which can be useful, for example for stats feature, also it's useful for debugging, but each task should have created_at and updated_at fields, and from api you will be able to get the latest tasks for specific env. Thanks, On Thu, Jan 15, 2015 at 7:20 PM, Vitaly Kramskikh vkramsk...@mirantis.com wrote: Folks, 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. What is your opinion on this? -- Vitaly Kramskikh, Software Engineer, Mirantis, Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] [nailgun] [UI] network_check_status fleild for environments
Evgeniy, Yes, we shouldn't delete tasks, but for now it is the only way to mark verification results as obsolete and remove them. When we implement this new field, we can easily get rid of task deletion in favour of setting this field. 2015-01-16 15:58 GMT+03:00 Evgeniy L e...@mirantis.com: Hi, 1) +1 for warning 2) I don't think that we should delete tasks, it's a history which can be useful, for example for stats feature, also it's useful for debugging, but each task should have created_at and updated_at fields, and from api you will be able to get the latest tasks for specific env. Thanks, On Thu, Jan 15, 2015 at 7:20 PM, Vitaly Kramskikh vkramsk...@mirantis.com wrote: Folks, 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. What is your opinion on this? -- Vitaly Kramskikh, Software Engineer, Mirantis, Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Vitaly Kramskikh, Fuel UI Tech Lead, Mirantis, Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Fuel] [nailgun] [UI] network_check_status fleild for environments
Folks, 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. What is your opinion on this? -- Vitaly Kramskikh, Software Engineer, Mirantis, Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Fuel] [nailgun] [UI] network_check_status fleild for environments
Big +1, it would save me a lot of debugging time :) On Thu, Jan 15, 2015 at 5:20 PM, Vitaly Kramskikh vkramsk...@mirantis.com wrote: Folks, 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. What is your opinion on this? -- Vitaly Kramskikh, Software Engineer, Mirantis, Inc. __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Łukasz Oleś __ OpenStack Development Mailing List (not for usage questions) Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
