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

Reply via email to