Open Stack

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