Open Stack

IMO: 
Because we do not have the versioning for all settings, the discard button shall reset to last deployed state(in case if last deployed state exists, otherwise the discard button should not be available).
Now the availability of discard button calculates according to state of cluster, but this is not correct way, because the first deployment may fail, the cluster will be in ‘error state’, but it does not have last successfully deployed configuration.

Regards,at
Bulat Gaifullin
Mirantis Inc.



> On 25 May 2016, at 15:05, Roman Prykhodchenko <me at romcheg.me> wrote:
> 
> Folks,
> 
> Recently we were investigating an issue [1] when a user configured a cluster to cause deployment to fail and then expected a discard button will allow to reset changes made after that failure. As Julia mentioned in her comment on the bug, basically what we’ve got is that users actually perceive the meaning of a cluster.deployed attribute as a snapshot to a latest deployment configuration while it was designed to keep the latest configuration of a successful deployment. Should we re-consider the meaning of that attribute and therefore features and the action of the Discard button?
> 
> 
> References:
> 
> 1. https://bugs.launchpad.net/fuel/+bug/1584681
> 
> __________________________________________________________________________
> 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