Re: [openstack-dev] [Fuel] Storing deployment configuration before or after a successful deployment

[Bulat Gaifullin]

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  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-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-dev] [Fuel] Storing deployment configuration before or after a successful deployment

[Roman Prykhodchenko]

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



signature.asc
Description: Message signed with OpenPGP using GPGMail
__
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