Re: [openstack-dev] [Fuel] [UI] Deploy Changes dialog redesign
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
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
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
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
+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
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
+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
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
+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
[openstack-dev] [Fuel] [UI] Deploy Changes dialog redesign
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
