settingsLogin | Registersettings

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

0 votes

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:
  • Changed interfaces configuration on the following nodes:

  • 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
jaranovich@mirantis.com jkirnosova@mirantis.com


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
asked Jan 26, 2015 in openstack-dev by Julia_Aranovich (800 points)   2
retagged Mar 19, 2015 by admin

9 Responses

0 votes

+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 jkirnosova@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
:

  • Changed disks configuration on the following nodes:
  • Changed interfaces configuration on the following nodes:

  • 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
jaranovich@mirantis.com jkirnosova@mirantis.com


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jan 26, 2015 by Vitaly_Kramskikh (3,480 points)   2 4
0 votes

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 vkramskikh@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 jkirnosova@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
:

  • Changed disks configuration on the following nodes:
  • Changed interfaces configuration on the following nodes:

  • 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
jaranovich@mirantis.com jkirnosova@mirantis.com


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@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-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jan 26, 2015 by Evgeniy_L (8,580 points)   1 2 4
0 votes

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 eli@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 <vkramskikh@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 jkirnosova@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
:

  • Changed disks configuration on the following nodes:
  • Changed interfaces configuration on the following nodes:

  • 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
jaranovich@mirantis.com jkirnosova@mirantis.com


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@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-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jan 26, 2015 by Evgeniy_L (8,580 points)   1 2 4
0 votes

+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 eli@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 eli@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
vkramskikh@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 jkirnosova@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:

Changed interfaces configuration on the following nodes:

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
jaranovich@mirantis.com


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@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-request@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-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jan 26, 2015 by Igor_Kalnitsky (8,940 points)   1 2 4
0 votes

+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 ikalnitsky@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 eli@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 eli@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
vkramskikh@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 jkirnosova@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:

Changed interfaces configuration on the following nodes:

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
jaranovich@mirantis.com


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@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-request@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-request@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-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jan 27, 2015 by Mike_Scherbakov (9,460 points)   1 4 6
0 votes

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
"pendingaddition" and "pendingsomeotherstuff" 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
mscherbakov@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 ikalnitsky@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 eli@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 eli@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
vkramskikh@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 jkirnosova@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:

Changed interfaces configuration on the following nodes:

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
jaranovich@mirantis.com


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@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-request@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-request@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-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Best regards,
Nick Markov


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jan 27, 2015 by Nikolay_Markov (1,260 points)   1 2
0 votes

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
"pendingaddition" and "pendingsomeotherstuff" 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 nmarkov@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
"pendingaddition" and "pendingsomeotherstuff" 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
mscherbakov@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 ikalnitsky@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 eli@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 eli@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
vkramskikh@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 jkirnosova@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:

Changed interfaces configuration on the following nodes:

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
jaranovich@mirantis.com


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@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-request@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-request@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-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Best regards,
Nick Markov


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jan 28, 2015 by Igor_Kalnitsky (8,940 points)   1 2 4
0 votes

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
ikalnitsky@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
"pendingaddition" and "pendingsomeotherstuff" 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 nmarkov@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
"pendingaddition" and "pendingsomeotherstuff" 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
mscherbakov@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 ikalnitsky@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 eli@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 eli@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
vkramskikh@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 jkirnosova@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:

Changed interfaces configuration on the following nodes:

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
jaranovich@mirantis.com


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@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-request@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-request@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-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Best regards,
Nick Markov


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Best regards,
Nick Markov


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jan 28, 2015 by Nikolay_Markov (1,260 points)   1 2
0 votes

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 nmarkov@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
ikalnitsky@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
"pendingaddition" and "pendingsomeotherstuff" 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 nmarkov@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
"pendingaddition" and "pendingsomeotherstuff" 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
mscherbakov@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 ikalnitsky@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 eli@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 eli@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
vkramskikh@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 jkirnosova@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:

Changed interfaces configuration on the following nodes:

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
jaranovich@mirantis.com


OpenStack Development Mailing List (not for usage questions)
Unsubscribe:
OpenStack-dev-request@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-request@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-request@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-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Best regards,
Nick Markov


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

--
Best regards,
Nick Markov


OpenStack Development Mailing List (not for usage questions)
Unsubscribe: OpenStack-dev-request@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-request@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
responded Jan 28, 2015 by Igor_Kalnitsky (8,940 points)   1 2 4
...