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
On 02/09/2015 01:18 PM, Dmitriy Shulyak wrote:
>
> On Mon, Feb 9, 2015 at 1:35 PM, Przemyslaw Kaminski
> 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
On Mon, Feb 9, 2015 at 1:35 PM, Przemyslaw Kaminski
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 t
On 02/09/2015 12:06 PM, Dmitriy Shulyak wrote:
>
> On Mon, Feb 9, 2015 at 12:51 PM, Przemyslaw Kaminski
> 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.
>
On Mon, Feb 9, 2015 at 12:51 PM, Przemyslaw Kaminski 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
On 02/07/2015 12:09 PM, Dmitriy Shulyak wrote:
>
> On Thu, Jan 15, 2015 at 6:20 PM, Vitaly Kramskikh
> 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 fr
On Thu, Jan 15, 2015 at 6:20 PM, Vitaly Kramskikh
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 net
Guys, definitely we shouldn't delete tasks.
+1 for warning.
On Fri, Jan 16, 2015 at 3:58 PM, Evgeniy L 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
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 :
> Hi,
>
> 1) +1 for w
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
+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
Big +1, it would save me a lot of debugging time :)
On Thu, Jan 15, 2015 at 5:20 PM, Vitaly Kramskikh
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
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
13 matches
Mail list logo
