Re: [openstack-dev] [Fuel] [UI] Deploy Changes dialog redesign

2015-01-28 Thread Igor Kalnitsky
Nik,

 I'm now here and I don't agree that we need to remove changes
 attribute. On the opposite, I think this is the only attribute which
 should be looked at on UI and backend, and all these
 pending_addition and pending_someotherstuff are obsolete and
 needless.

You're absolutely right. It's better to have one field rather than
few. However, in current implementation this field (changes) is
completely unusable. It's not even extensible, since it has a
pre-defined values.

So, I propose to solve first tasks first. We can remove it for now (in
order to drop legacy) and introduce new implementation when we need.

Thanks,
Igor

On Tue, Jan 27, 2015 at 11:12 AM, Nikolay Markov nmar...@mirantis.com wrote:
 Guys,

 I'm now here and I don't agree that we need to remove changes
 attribute. On the opposite, I think this is the only attribute which
 should be looked at on UI and backend, and all these
 pending_addition and pending_someotherstuff are obsolete and
 needless.

 Just assume, that we'll soon have some plugin or just some tech which
 allows us to modify some settings on UI after environment was deployed
 and somehow apply it onto nodes (like, for example, we're planning
 such thing for VMWare). In this case there is no any
 pending_addition or some other stuff, these are just changes to
 apply on a node somehow, maybe just execute some script on them. And
 the same goes to a lot of cases with plugins, which do some services
 on target nodes configurable.

 Pending_addition flag, on the other hand, is useless, because all
 changes we should apply on node are already listed in changes
 attribute. We can even probably add provisioning and deployment
 into these pending changes do avoid logic duplication. But still, as
 for me, this is the only working mechanism we should consider and
 which will really help us to cver complex cases in the future.

 On Tue, Jan 27, 2015 at 10:52 AM, Mike Scherbakov
 mscherba...@mirantis.com wrote:
 +1, I do not think it's usable as how it is now. Let's think though if we
 can come up with better idea how to show what has been changed (or even
 otherwise, what was not touched - and so might bring a surprise later).
 We might want to think about it after wizard-like UI is implemented.

 On Mon, Jan 26, 2015 at 8:26 PM, Igor Kalnitsky ikalnit...@mirantis.com
 wrote:

 +1 for removing attribute.

 @Evgeniy, I'm not sure that this attribute really shows all changes
 that's going to be done.

 On Mon, Jan 26, 2015 at 7:11 PM, Evgeniy L e...@mirantis.com wrote:
  To be more specific, +1 for removing this information from UI, not from
  backend.
 
  On Mon, Jan 26, 2015 at 7:46 PM, Evgeniy L e...@mirantis.com wrote:
 
  Hi,
 
  I agree that this information is useless, but it's not really clear
  what
  you are going
  to show instead, will you completely remove the information about nodes
  for deployment?
  I think the list of nodes for deployment (without detailed list of
  changes) can be useful
  for the user.
 
  Thanks,
 
  On Mon, Jan 26, 2015 at 7:23 PM, Vitaly Kramskikh
  vkramsk...@mirantis.com wrote:
 
  +1 for removing changes attribute. It's useless now. If there are no
  plans to add something else there, let's remove it.
 
  2015-01-26 11:39 GMT+03:00 Julia Aranovich jkirnos...@mirantis.com:
 
  Hi All,
 
  Since we changed Deploy Changes pop-up and added processing of role
  limits and restrictions I would like to raise a question of it's
  subsequent
  refactoring.
 
  In particular, I mean 'changes' attribute of cluster model. It's
  displayed in Deploy Changes dialog in the following format:
 
  Changed disks configuration on the following nodes:
 
  node_name_list
 
  Changed interfaces configuration on the following nodes:
 
  node_name_list
 
  Changed network settings
  Changed OpenStack settings
 
  This list looks absolutely useless.
 
  It doesn't make any sense to display lists of new, not deployed nodes
  with changed disks/interfaces. It's obvious I think that new nodes
  attributes await deployment. At the same time user isn't able to
  change
  disks/interfaces on deployed nodes (at least in UI). So, such node
  name
  lists are definitely redundant.
  Networks and settings are also locked after deployment finished.
 
 
  I tend to get rid of cluster model 'changes' attribute at all.
 
  It is important for me to know your opinion, to make a final
  decision.
  Please feel free and share your ideas and concerns if any.
 
 
  Regards,
  Julia
 
  --
  Kind Regards,
  Julia Aranovich,
  Software Engineer,
  Mirantis, Inc
  +7 (905) 388-82-61 (cell)
  Skype: juliakirnosova
  www.mirantis.ru
  jaranov...@mirantis.com
 
 
 
  __
  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 

Re: [openstack-dev] [Fuel] [UI] Deploy Changes dialog redesign

2015-01-28 Thread Nikolay Markov
Igor,

But why can't we implement it properly on the first try? It doesn't
seem like a hard task and won't take much time.

On Wed, Jan 28, 2015 at 12:50 PM, Igor Kalnitsky
ikalnit...@mirantis.com wrote:
 Nik,

 I'm now here and I don't agree that we need to remove changes
 attribute. On the opposite, I think this is the only attribute which
 should be looked at on UI and backend, and all these
 pending_addition and pending_someotherstuff are obsolete and
 needless.

 You're absolutely right. It's better to have one field rather than
 few. However, in current implementation this field (changes) is
 completely unusable. It's not even extensible, since it has a
 pre-defined values.

 So, I propose to solve first tasks first. We can remove it for now (in
 order to drop legacy) and introduce new implementation when we need.

 Thanks,
 Igor

 On Tue, Jan 27, 2015 at 11:12 AM, Nikolay Markov nmar...@mirantis.com wrote:
 Guys,

 I'm now here and I don't agree that we need to remove changes
 attribute. On the opposite, I think this is the only attribute which
 should be looked at on UI and backend, and all these
 pending_addition and pending_someotherstuff are obsolete and
 needless.

 Just assume, that we'll soon have some plugin or just some tech which
 allows us to modify some settings on UI after environment was deployed
 and somehow apply it onto nodes (like, for example, we're planning
 such thing for VMWare). In this case there is no any
 pending_addition or some other stuff, these are just changes to
 apply on a node somehow, maybe just execute some script on them. And
 the same goes to a lot of cases with plugins, which do some services
 on target nodes configurable.

 Pending_addition flag, on the other hand, is useless, because all
 changes we should apply on node are already listed in changes
 attribute. We can even probably add provisioning and deployment
 into these pending changes do avoid logic duplication. But still, as
 for me, this is the only working mechanism we should consider and
 which will really help us to cver complex cases in the future.

 On Tue, Jan 27, 2015 at 10:52 AM, Mike Scherbakov
 mscherba...@mirantis.com wrote:
 +1, I do not think it's usable as how it is now. Let's think though if we
 can come up with better idea how to show what has been changed (or even
 otherwise, what was not touched - and so might bring a surprise later).
 We might want to think about it after wizard-like UI is implemented.

 On Mon, Jan 26, 2015 at 8:26 PM, Igor Kalnitsky ikalnit...@mirantis.com
 wrote:

 +1 for removing attribute.

 @Evgeniy, I'm not sure that this attribute really shows all changes
 that's going to be done.

 On Mon, Jan 26, 2015 at 7:11 PM, Evgeniy L e...@mirantis.com wrote:
  To be more specific, +1 for removing this information from UI, not from
  backend.
 
  On Mon, Jan 26, 2015 at 7:46 PM, Evgeniy L e...@mirantis.com wrote:
 
  Hi,
 
  I agree that this information is useless, but it's not really clear
  what
  you are going
  to show instead, will you completely remove the information about nodes
  for deployment?
  I think the list of nodes for deployment (without detailed list of
  changes) can be useful
  for the user.
 
  Thanks,
 
  On Mon, Jan 26, 2015 at 7:23 PM, Vitaly Kramskikh
  vkramsk...@mirantis.com wrote:
 
  +1 for removing changes attribute. It's useless now. If there are no
  plans to add something else there, let's remove it.
 
  2015-01-26 11:39 GMT+03:00 Julia Aranovich jkirnos...@mirantis.com:
 
  Hi All,
 
  Since we changed Deploy Changes pop-up and added processing of role
  limits and restrictions I would like to raise a question of it's
  subsequent
  refactoring.
 
  In particular, I mean 'changes' attribute of cluster model. It's
  displayed in Deploy Changes dialog in the following format:
 
  Changed disks configuration on the following nodes:
 
  node_name_list
 
  Changed interfaces configuration on the following nodes:
 
  node_name_list
 
  Changed network settings
  Changed OpenStack settings
 
  This list looks absolutely useless.
 
  It doesn't make any sense to display lists of new, not deployed nodes
  with changed disks/interfaces. It's obvious I think that new nodes
  attributes await deployment. At the same time user isn't able to
  change
  disks/interfaces on deployed nodes (at least in UI). So, such node
  name
  lists are definitely redundant.
  Networks and settings are also locked after deployment finished.
 
 
  I tend to get rid of cluster model 'changes' attribute at all.
 
  It is important for me to know your opinion, to make a final
  decision.
  Please feel free and share your ideas and concerns if any.
 
 
  Regards,
  Julia
 
  --
  Kind Regards,
  Julia Aranovich,
  Software Engineer,
  Mirantis, Inc
  +7 (905) 388-82-61 (cell)
  Skype: juliakirnosova
  www.mirantis.ru
  jaranov...@mirantis.com
 
 
 
  __
  OpenStack Development Mailing List (not 

Re: [openstack-dev] [Fuel] [UI] Deploy Changes dialog redesign

2015-01-28 Thread Igor Kalnitsky
Nik,

I'm sure it requires at least a spec, since there are things that
should be discussed. Who can do it in this release cycle? If there's a
person I'm +1 for refactoring; otherwise - I'd prefer to remove it to
make code more clear.

Thanks,
Igor

On Wed, Jan 28, 2015 at 12:44 PM, Nikolay Markov nmar...@mirantis.com wrote:
 Igor,

 But why can't we implement it properly on the first try? It doesn't
 seem like a hard task and won't take much time.

 On Wed, Jan 28, 2015 at 12:50 PM, Igor Kalnitsky
 ikalnit...@mirantis.com wrote:
 Nik,

 I'm now here and I don't agree that we need to remove changes
 attribute. On the opposite, I think this is the only attribute which
 should be looked at on UI and backend, and all these
 pending_addition and pending_someotherstuff are obsolete and
 needless.

 You're absolutely right. It's better to have one field rather than
 few. However, in current implementation this field (changes) is
 completely unusable. It's not even extensible, since it has a
 pre-defined values.

 So, I propose to solve first tasks first. We can remove it for now (in
 order to drop legacy) and introduce new implementation when we need.

 Thanks,
 Igor

 On Tue, Jan 27, 2015 at 11:12 AM, Nikolay Markov nmar...@mirantis.com 
 wrote:
 Guys,

 I'm now here and I don't agree that we need to remove changes
 attribute. On the opposite, I think this is the only attribute which
 should be looked at on UI and backend, and all these
 pending_addition and pending_someotherstuff are obsolete and
 needless.

 Just assume, that we'll soon have some plugin or just some tech which
 allows us to modify some settings on UI after environment was deployed
 and somehow apply it onto nodes (like, for example, we're planning
 such thing for VMWare). In this case there is no any
 pending_addition or some other stuff, these are just changes to
 apply on a node somehow, maybe just execute some script on them. And
 the same goes to a lot of cases with plugins, which do some services
 on target nodes configurable.

 Pending_addition flag, on the other hand, is useless, because all
 changes we should apply on node are already listed in changes
 attribute. We can even probably add provisioning and deployment
 into these pending changes do avoid logic duplication. But still, as
 for me, this is the only working mechanism we should consider and
 which will really help us to cver complex cases in the future.

 On Tue, Jan 27, 2015 at 10:52 AM, Mike Scherbakov
 mscherba...@mirantis.com wrote:
 +1, I do not think it's usable as how it is now. Let's think though if we
 can come up with better idea how to show what has been changed (or even
 otherwise, what was not touched - and so might bring a surprise later).
 We might want to think about it after wizard-like UI is implemented.

 On Mon, Jan 26, 2015 at 8:26 PM, Igor Kalnitsky ikalnit...@mirantis.com
 wrote:

 +1 for removing attribute.

 @Evgeniy, I'm not sure that this attribute really shows all changes
 that's going to be done.

 On Mon, Jan 26, 2015 at 7:11 PM, Evgeniy L e...@mirantis.com wrote:
  To be more specific, +1 for removing this information from UI, not from
  backend.
 
  On Mon, Jan 26, 2015 at 7:46 PM, Evgeniy L e...@mirantis.com wrote:
 
  Hi,
 
  I agree that this information is useless, but it's not really clear
  what
  you are going
  to show instead, will you completely remove the information about nodes
  for deployment?
  I think the list of nodes for deployment (without detailed list of
  changes) can be useful
  for the user.
 
  Thanks,
 
  On Mon, Jan 26, 2015 at 7:23 PM, Vitaly Kramskikh
  vkramsk...@mirantis.com wrote:
 
  +1 for removing changes attribute. It's useless now. If there are no
  plans to add something else there, let's remove it.
 
  2015-01-26 11:39 GMT+03:00 Julia Aranovich jkirnos...@mirantis.com:
 
  Hi All,
 
  Since we changed Deploy Changes pop-up and added processing of role
  limits and restrictions I would like to raise a question of it's
  subsequent
  refactoring.
 
  In particular, I mean 'changes' attribute of cluster model. It's
  displayed in Deploy Changes dialog in the following format:
 
  Changed disks configuration on the following nodes:
 
  node_name_list
 
  Changed interfaces configuration on the following nodes:
 
  node_name_list
 
  Changed network settings
  Changed OpenStack settings
 
  This list looks absolutely useless.
 
  It doesn't make any sense to display lists of new, not deployed nodes
  with changed disks/interfaces. It's obvious I think that new nodes
  attributes await deployment. At the same time user isn't able to
  change
  disks/interfaces on deployed nodes (at least in UI). So, such node
  name
  lists are definitely redundant.
  Networks and settings are also locked after deployment finished.
 
 
  I tend to get rid of cluster model 'changes' attribute at all.
 
  It is important for me to know your opinion, to make a final
  decision.
  Please feel free and share your ideas and concerns 

Re: [openstack-dev] [Fuel] [UI] Deploy Changes dialog redesign

2015-01-27 Thread Nikolay Markov
Guys,

I'm now here and I don't agree that we need to remove changes
attribute. On the opposite, I think this is the only attribute which
should be looked at on UI and backend, and all these
pending_addition and pending_someotherstuff are obsolete and
needless.

Just assume, that we'll soon have some plugin or just some tech which
allows us to modify some settings on UI after environment was deployed
and somehow apply it onto nodes (like, for example, we're planning
such thing for VMWare). In this case there is no any
pending_addition or some other stuff, these are just changes to
apply on a node somehow, maybe just execute some script on them. And
the same goes to a lot of cases with plugins, which do some services
on target nodes configurable.

Pending_addition flag, on the other hand, is useless, because all
changes we should apply on node are already listed in changes
attribute. We can even probably add provisioning and deployment
into these pending changes do avoid logic duplication. But still, as
for me, this is the only working mechanism we should consider and
which will really help us to cver complex cases in the future.

On Tue, Jan 27, 2015 at 10:52 AM, Mike Scherbakov
mscherba...@mirantis.com wrote:
 +1, I do not think it's usable as how it is now. Let's think though if we
 can come up with better idea how to show what has been changed (or even
 otherwise, what was not touched - and so might bring a surprise later).
 We might want to think about it after wizard-like UI is implemented.

 On Mon, Jan 26, 2015 at 8:26 PM, Igor Kalnitsky ikalnit...@mirantis.com
 wrote:

 +1 for removing attribute.

 @Evgeniy, I'm not sure that this attribute really shows all changes
 that's going to be done.

 On Mon, Jan 26, 2015 at 7:11 PM, Evgeniy L e...@mirantis.com wrote:
  To be more specific, +1 for removing this information from UI, not from
  backend.
 
  On Mon, Jan 26, 2015 at 7:46 PM, Evgeniy L e...@mirantis.com wrote:
 
  Hi,
 
  I agree that this information is useless, but it's not really clear
  what
  you are going
  to show instead, will you completely remove the information about nodes
  for deployment?
  I think the list of nodes for deployment (without detailed list of
  changes) can be useful
  for the user.
 
  Thanks,
 
  On Mon, Jan 26, 2015 at 7:23 PM, Vitaly Kramskikh
  vkramsk...@mirantis.com wrote:
 
  +1 for removing changes attribute. It's useless now. If there are no
  plans to add something else there, let's remove it.
 
  2015-01-26 11:39 GMT+03:00 Julia Aranovich jkirnos...@mirantis.com:
 
  Hi All,
 
  Since we changed Deploy Changes pop-up and added processing of role
  limits and restrictions I would like to raise a question of it's
  subsequent
  refactoring.
 
  In particular, I mean 'changes' attribute of cluster model. It's
  displayed in Deploy Changes dialog in the following format:
 
  Changed disks configuration on the following nodes:
 
  node_name_list
 
  Changed interfaces configuration on the following nodes:
 
  node_name_list
 
  Changed network settings
  Changed OpenStack settings
 
  This list looks absolutely useless.
 
  It doesn't make any sense to display lists of new, not deployed nodes
  with changed disks/interfaces. It's obvious I think that new nodes
  attributes await deployment. At the same time user isn't able to
  change
  disks/interfaces on deployed nodes (at least in UI). So, such node
  name
  lists are definitely redundant.
  Networks and settings are also locked after deployment finished.
 
 
  I tend to get rid of cluster model 'changes' attribute at all.
 
  It is important for me to know your opinion, to make a final
  decision.
  Please feel free and share your ideas and concerns if any.
 
 
  Regards,
  Julia
 
  --
  Kind Regards,
  Julia Aranovich,
  Software Engineer,
  Mirantis, Inc
  +7 (905) 388-82-61 (cell)
  Skype: juliakirnosova
  www.mirantis.ru
  jaranov...@mirantis.com
 
 
 
  __
  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 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 

Re: [openstack-dev] [Fuel] [UI] Deploy Changes dialog redesign

2015-01-26 Thread Vitaly Kramskikh
+1 for removing changes attribute. It's useless now. If there are no
plans to add something else there, let's remove it.

2015-01-26 11:39 GMT+03:00 Julia Aranovich jkirnos...@mirantis.com:

 Hi All,

 Since we changed Deploy Changes pop-up and added processing of role
 limits and restrictions https://review.openstack.org/#/c/126930/ I
 would like to raise a question of it's subsequent refactoring.

 In particular, I mean 'changes' attribute of cluster model. It's displayed
 in Deploy Changes dialog in the following format
 http://s2.postimg.org/ak9inonhl/deploy_changes_dialog.png:

- Changed disks configuration on the following nodes:
- node_name_list
- Changed interfaces configuration on the following nodes:
   - node_name_list
- Changed network settings
- Changed OpenStack settings

 This list looks absolutely useless.

 It doesn't make any sense to display lists of new, not deployed nodes with
 changed disks/interfaces. It's obvious I think that new nodes attributes
 await deployment. At the same time user isn't able to change
 disks/interfaces on deployed nodes (at least in UI). So, such node name
 lists are definitely redundant.
 Networks and settings are also locked after deployment finished.


 I tend to get rid of cluster model 'changes' attribute at all.

 It is important for me to know your opinion, to make a final decision.
 Please feel free and share your ideas and concerns if any.


 Regards,
 Julia

 --
 Kind Regards,
 Julia Aranovich,
 Software Engineer,
 Mirantis, Inc
 +7 (905) 388-82-61 (cell)
 Skype: juliakirnosova
 www.mirantis.ru
 jaranov...@mirantis.com jkirnos...@mirantis.com

 __
 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


Re: [openstack-dev] [Fuel] [UI] Deploy Changes dialog redesign

2015-01-26 Thread Evgeniy L
Hi,

I agree that this information is useless, but it's not really clear what
you are going
to show instead, will you completely remove the information about nodes for
deployment?
I think the list of nodes for deployment (without detailed list of changes)
can be useful
for the user.

Thanks,

On Mon, Jan 26, 2015 at 7:23 PM, Vitaly Kramskikh vkramsk...@mirantis.com
wrote:

 +1 for removing changes attribute. It's useless now. If there are no
 plans to add something else there, let's remove it.

 2015-01-26 11:39 GMT+03:00 Julia Aranovich jkirnos...@mirantis.com:

 Hi All,

 Since we changed Deploy Changes pop-up and added processing of role
 limits and restrictions https://review.openstack.org/#/c/126930/ I
 would like to raise a question of it's subsequent refactoring.

 In particular, I mean 'changes' attribute of cluster model. It's
 displayed in Deploy Changes dialog in the following format
 http://s2.postimg.org/ak9inonhl/deploy_changes_dialog.png:

- Changed disks configuration on the following nodes:
- node_name_list
- Changed interfaces configuration on the following nodes:
   - node_name_list
- Changed network settings
- Changed OpenStack settings

 This list looks absolutely useless.

 It doesn't make any sense to display lists of new, not deployed nodes
 with changed disks/interfaces. It's obvious I think that new nodes
 attributes await deployment. At the same time user isn't able to change
 disks/interfaces on deployed nodes (at least in UI). So, such node name
 lists are definitely redundant.
 Networks and settings are also locked after deployment finished.


 I tend to get rid of cluster model 'changes' attribute at all.

 It is important for me to know your opinion, to make a final decision.
 Please feel free and share your ideas and concerns if any.


 Regards,
 Julia

 --
 Kind Regards,
 Julia Aranovich,
 Software Engineer,
 Mirantis, Inc
 +7 (905) 388-82-61 (cell)
 Skype: juliakirnosova
 www.mirantis.ru
 jaranov...@mirantis.com jkirnos...@mirantis.com

 __
 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 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] [UI] Deploy Changes dialog redesign

2015-01-26 Thread Igor Kalnitsky
+1 for removing attribute.

@Evgeniy, I'm not sure that this attribute really shows all changes
that's going to be done.

On Mon, Jan 26, 2015 at 7:11 PM, Evgeniy L e...@mirantis.com wrote:
 To be more specific, +1 for removing this information from UI, not from
 backend.

 On Mon, Jan 26, 2015 at 7:46 PM, Evgeniy L e...@mirantis.com wrote:

 Hi,

 I agree that this information is useless, but it's not really clear what
 you are going
 to show instead, will you completely remove the information about nodes
 for deployment?
 I think the list of nodes for deployment (without detailed list of
 changes) can be useful
 for the user.

 Thanks,

 On Mon, Jan 26, 2015 at 7:23 PM, Vitaly Kramskikh
 vkramsk...@mirantis.com wrote:

 +1 for removing changes attribute. It's useless now. If there are no
 plans to add something else there, let's remove it.

 2015-01-26 11:39 GMT+03:00 Julia Aranovich jkirnos...@mirantis.com:

 Hi All,

 Since we changed Deploy Changes pop-up and added processing of role
 limits and restrictions I would like to raise a question of it's subsequent
 refactoring.

 In particular, I mean 'changes' attribute of cluster model. It's
 displayed in Deploy Changes dialog in the following format:

 Changed disks configuration on the following nodes:

 node_name_list

 Changed interfaces configuration on the following nodes:

 node_name_list

 Changed network settings
 Changed OpenStack settings

 This list looks absolutely useless.

 It doesn't make any sense to display lists of new, not deployed nodes
 with changed disks/interfaces. It's obvious I think that new nodes
 attributes await deployment. At the same time user isn't able to change
 disks/interfaces on deployed nodes (at least in UI). So, such node name
 lists are definitely redundant.
 Networks and settings are also locked after deployment finished.


 I tend to get rid of cluster model 'changes' attribute at all.

 It is important for me to know your opinion, to make a final decision.
 Please feel free and share your ideas and concerns if any.


 Regards,
 Julia

 --
 Kind Regards,
 Julia Aranovich,
 Software Engineer,
 Mirantis, Inc
 +7 (905) 388-82-61 (cell)
 Skype: juliakirnosova
 www.mirantis.ru
 jaranov...@mirantis.com


 __
 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 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] [UI] Deploy Changes dialog redesign

2015-01-26 Thread Evgeniy L
To be more specific, +1 for removing this information from UI, not from
backend.

On Mon, Jan 26, 2015 at 7:46 PM, Evgeniy L e...@mirantis.com wrote:

 Hi,

 I agree that this information is useless, but it's not really clear what
 you are going
 to show instead, will you completely remove the information about nodes
 for deployment?
 I think the list of nodes for deployment (without detailed list of
 changes) can be useful
 for the user.

 Thanks,

 On Mon, Jan 26, 2015 at 7:23 PM, Vitaly Kramskikh vkramsk...@mirantis.com
  wrote:

 +1 for removing changes attribute. It's useless now. If there are no
 plans to add something else there, let's remove it.

 2015-01-26 11:39 GMT+03:00 Julia Aranovich jkirnos...@mirantis.com:

 Hi All,

 Since we changed Deploy Changes pop-up and added processing of role
 limits and restrictions https://review.openstack.org/#/c/126930/ I
 would like to raise a question of it's subsequent refactoring.

 In particular, I mean 'changes' attribute of cluster model. It's
 displayed in Deploy Changes dialog in the following format
 http://s2.postimg.org/ak9inonhl/deploy_changes_dialog.png:

- Changed disks configuration on the following nodes:
- node_name_list
- Changed interfaces configuration on the following nodes:
   - node_name_list
- Changed network settings
- Changed OpenStack settings

 This list looks absolutely useless.

 It doesn't make any sense to display lists of new, not deployed nodes
 with changed disks/interfaces. It's obvious I think that new nodes
 attributes await deployment. At the same time user isn't able to change
 disks/interfaces on deployed nodes (at least in UI). So, such node name
 lists are definitely redundant.
 Networks and settings are also locked after deployment finished.


 I tend to get rid of cluster model 'changes' attribute at all.

 It is important for me to know your opinion, to make a final decision.
 Please feel free and share your ideas and concerns if any.


 Regards,
 Julia

 --
 Kind Regards,
 Julia Aranovich,
 Software Engineer,
 Mirantis, Inc
 +7 (905) 388-82-61 (cell)
 Skype: juliakirnosova
 www.mirantis.ru
 jaranov...@mirantis.com jkirnos...@mirantis.com


 __
 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 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] [UI] Deploy Changes dialog redesign

2015-01-26 Thread Mike Scherbakov
+1, I do not think it's usable as how it is now. Let's think though if we
can come up with better idea how to show what has been changed (or even
otherwise, what was not touched - and so might bring a surprise later).
We might want to think about it after wizard-like UI is implemented.

On Mon, Jan 26, 2015 at 8:26 PM, Igor Kalnitsky ikalnit...@mirantis.com
wrote:

 +1 for removing attribute.

 @Evgeniy, I'm not sure that this attribute really shows all changes
 that's going to be done.

 On Mon, Jan 26, 2015 at 7:11 PM, Evgeniy L e...@mirantis.com wrote:
  To be more specific, +1 for removing this information from UI, not from
  backend.
 
  On Mon, Jan 26, 2015 at 7:46 PM, Evgeniy L e...@mirantis.com wrote:
 
  Hi,
 
  I agree that this information is useless, but it's not really clear what
  you are going
  to show instead, will you completely remove the information about nodes
  for deployment?
  I think the list of nodes for deployment (without detailed list of
  changes) can be useful
  for the user.
 
  Thanks,
 
  On Mon, Jan 26, 2015 at 7:23 PM, Vitaly Kramskikh
  vkramsk...@mirantis.com wrote:
 
  +1 for removing changes attribute. It's useless now. If there are no
  plans to add something else there, let's remove it.
 
  2015-01-26 11:39 GMT+03:00 Julia Aranovich jkirnos...@mirantis.com:
 
  Hi All,
 
  Since we changed Deploy Changes pop-up and added processing of role
  limits and restrictions I would like to raise a question of it's
 subsequent
  refactoring.
 
  In particular, I mean 'changes' attribute of cluster model. It's
  displayed in Deploy Changes dialog in the following format:
 
  Changed disks configuration on the following nodes:
 
  node_name_list
 
  Changed interfaces configuration on the following nodes:
 
  node_name_list
 
  Changed network settings
  Changed OpenStack settings
 
  This list looks absolutely useless.
 
  It doesn't make any sense to display lists of new, not deployed nodes
  with changed disks/interfaces. It's obvious I think that new nodes
  attributes await deployment. At the same time user isn't able to
 change
  disks/interfaces on deployed nodes (at least in UI). So, such node
 name
  lists are definitely redundant.
  Networks and settings are also locked after deployment finished.
 
 
  I tend to get rid of cluster model 'changes' attribute at all.
 
  It is important for me to know your opinion, to make a final decision.
  Please feel free and share your ideas and concerns if any.
 
 
  Regards,
  Julia
 
  --
  Kind Regards,
  Julia Aranovich,
  Software Engineer,
  Mirantis, Inc
  +7 (905) 388-82-61 (cell)
  Skype: juliakirnosova
  www.mirantis.ru
  jaranov...@mirantis.com
 
 
 
 __
  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 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




-- 
Mike Scherbakov
#mihgen
__
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