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 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 >>>> >>> >>> >>> >>> -- >>> Best regards, >>> Nick Markov >>> >>> __________________________________________________________________________ >>> 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 > > > > -- > Best regards, > Nick Markov > > __________________________________________________________________________ > 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