Open Stack

Just check we have removed deprecated methods in
https://review.openstack.org/#/c/241179/ for Nova.  So current there is no
work from Nova side now.


2015-12-22 13:53 GMT+08:00 ChangBo Guo <glongwave at gmail.com>:

>
>
> 2015-12-22 3:42 GMT+08:00 Matt Riedemann <mriedem at linux.vnet.ibm.com>:
>
>>
>>
>> On 12/21/2015 1:22 PM, Davanum Srinivas wrote:
>>
>>> Rob,
>>>
>>> Can we set some goals for the server projects too?
>>>
>>> Say anything deprecated in liberty timeframe in oslo libs or any other
>>> libs we consume should be fixed by milestone2 in mitaka? At the moment
>>> the burden is entirely on oslo and hence unfair.
>>>
>>> Thanks,
>>> Dims
>>>
>>> On Mon, Dec 21, 2015 at 2:15 PM, Robert Collins
>>> <robertc at robertcollins.net> wrote:
>>>
>>>> On 21 December 2015 at 04:57, Davanum Srinivas <davanum at gmail.com>
>>>> wrote:
>>>>
>>>>> Nova folks,
>>>>>
>>>>> We have this review in oslo.utils:
>>>>> https://review.openstack.org/#/c/252898/
>>>>>
>>>>> There were failed effort in the past to cleanup in Nova:
>>>>> https://review.openstack.org/#/c/164753/
>>>>> https://review.openstack.org/#/c/197601/
>>>>>
>>>>> What do we do? Suggestions please.
>>>>>
>>>>
>>>> We don't remove it yet. Not till liberty-eol at the earliest, or if we
>>>> don't get users migrated early enough, mitaka-eol.
>>>>
>>>> We would benefit from an automated thing in place to tell projects
>>>> like Nova that they are using deprecated things during CI (without
>>>> bloating deployer logs) -  whether a keystone API, an oslo config
>>>> option or function, or $whatever. We would also benefit from a thing
>>>> to rollup such information from consuming projects back to the
>>>> deprecating project, so we can tell whether we're ready to cleanup old
>>>> things.
>>>>
>>>> I think in general that there needs to be a balance around effort on
>>>> migrations: if oslo deprecates something - anything - we're creating
>>>> work for consumers of oslo. Its unfair for us to do that unilaterally.
>>>> Conversely, if projects don't migrate away from poor APIs onto newer
>>>> better ones, they create long term maintenance work for oslo: so we
>>>> all need to work together to coordinate such things.
>>>>
>>>> https://review.openstack.org/#/c/226157/12 is part of this - it is an
>>>> effort to bring consistency in expectations and process/patterns here.
>>>>
>>>> -Rob
>>>>
>>>> --
>>>> Robert Collins <rbtcollins at hpe.com>
>>>> Distinguished Technologist
>>>> HP Converged Cloud
>>>>
>>>>
>>>> __________________________________________________________________________
>>>> 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
>>>>
>>>
>>>
>>>
>>>
>> Nova also needs an Oslo liaison [1]. That used to be Joe Gordon, but he's
>> gone now. That would really be the person in Nova driving the Oslo changes
>> and review priorities.
>>
>> [1] https://wiki.openstack.org/wiki/CrossProjectLiaisons#Oslo
>>
>> --
>>
>
>   Matt, I would like to take the liaison for Nova,  I worked on both Nova
> and Oslo,  as Oslo core reviewer I attend  Oslo weekly meeting and will
>   help Nova and Oslo team work together smoothly.   I would like to submit
> new commit to  removing  deprecated method for Nova.
>
>>
>> Thanks,
>>
>> Matt Riedemann
>>
>>
>>
>> __________________________________________________________________________
>> 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
>>
>
>
>
> --
> ChangBo Guo(gcb)
>



-- 
ChangBo Guo(gcb)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151222/307e8740/attachment.html>