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
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
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
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
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
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
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
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
+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
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
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:
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
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
13 matches
Mail list logo
