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 <[email protected]> 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 <[email protected]> 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 >> <[email protected]> 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 <[email protected]> >>> 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 <[email protected]> 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 <[email protected]> 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 >>>> >> <[email protected]> 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 <[email protected]>: >>>> >>>> >>>> >>>> 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 >>>> >>>> [email protected] >>>> >>>> >>>> >>>> >>>> >>>> >>>> >>>> __________________________________________________________________________ >>>> >>>> OpenStack Development Mailing List (not for usage questions) >>>> >>>> Unsubscribe: >>>> >>>> [email protected]?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: >>>> >>> [email protected]?subject:unsubscribe >>>> >>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> >>> >>>> >> >>>> > >>>> > >>>> > >>>> > __________________________________________________________________________ >>>> > OpenStack Development Mailing List (not for usage questions) >>>> > Unsubscribe: >>>> > [email protected]?subject:unsubscribe >>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>>> > >>>> >>>> __________________________________________________________________________ >>>> OpenStack Development Mailing List (not for usage questions) >>>> Unsubscribe: [email protected]?subject:unsubscribe >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev >>> >>> >>> >>> >>> -- >>> Mike Scherbakov >>> #mihgen >>> >>> >>> __________________________________________________________________________ >>> OpenStack Development Mailing List (not for usage questions) >>> Unsubscribe: [email protected]?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: [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?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: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
