Open Stack

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