Open Stack

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 at 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 at 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 <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
>>
>> __________________________________________________________________________
>> 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