Open Stack

Hi Adrian,

Right now, I think:

for the unify-COE-container actions bp, it needs more discussion and good
design to make it  happen. ( I think spec is needed for this)
And for the k8s related objects deprecation, it needs backup  instead of
directly dropped it. Especially when we not have any spec or design come
out for unify-COE-container bp.


Right now, the work now mostly happen on UI part, I think for UI, it can
have discussion if need to implement those views or not.(instead we
directly drop API part while not come out a consistent design on
unify-COE-container actions bp)


Thanks

Best Wishes,
--------------------------------------------------------------------------------
Kai Qiang Wu (吴开强  Kennan）
IBM China System and Technology Lab, Beijing

E-mail: wkqwu at cn.ibm.com
Tel: 86-10-82451647
Address: Building 28(Ring Building), ZhongGuanCun Software Park,
         No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China
100193
--------------------------------------------------------------------------------
Follow your heart. You are miracle!



From:	Adrian Otto <adrian.otto at rackspace.com>
To:	"OpenStack Development Mailing List (not for usage questions)"
            <openstack-dev at lists.openstack.org>
Date:	17/12/2015 07:00 am
Subject:	Re: [openstack-dev] [magnum] Removing pod, rcs and service APIs



Tom,

> On Dec 16, 2015, at 9:31 AM, Cammann, Tom <tom.cammann at hpe.com> wrote:
>
> I don’t see a benefit from supporting the old API through a microversion
> when the same functionality will be available through the native API.

+1

[snip]

> Have we had any discussion on adding a v2 API and what changes (beyond
> removing pod, rc, service) we would include in that change. What sort of
> timeframe would we expect to remove the v1 API. I would like to move to a

> v2 in this cycle, then we can think about removing v1 in N.

Yes, when we drop functionality from the API that’s a contract breaking
change, and requires a new API major version. We can drop the v1 API in N
if we set expectations in advance. I’d want that plan to be supported with
some evidence that maintaining the v1 API was burdensome in some way.
Because adoption is limited, deprecation of v1 is not likely to be a
contentious issue.

Adrian

>
> Tom
>
>
>
> On 16/12/2015, 15:57, "Hongbin Lu" <hongbin.lu at huawei.com> wrote:
>
>> Hi Tom,
>>
>> If I remember correctly, the decision is to drop the COE-specific API
>> (Pod, Service, Replication Controller) in the next API version. I think
a
>> good way to do that is to put a deprecated warning in current API
version
>> (v1) for the removed resources, and remove them in the next API version
>> (v2).
>>
>> An alternative is to drop them in current API version. If we decide to
do
>> that, we need to bump the micro-version [1], and ask users to specify
the
>> microversion as part of the requests when they want the removed APIs.
>>
>> [1]
>>
http://docs.openstack.org/developer/nova/api_microversions.html#removing-a
>> n-api-method
>>
>> Best regards,
>> Hongbin
>>
>> -----Original Message-----
>> From: Cammann, Tom [mailto:tom.cammann at hpe.com]
>> Sent: December-16-15 8:21 AM
>> To: OpenStack Development Mailing List (not for usage questions)
>> Subject: [openstack-dev] [magnum] Removing pod, rcs and service APIs
>>
>> I have been noticing a fair amount of redundant work going on in magnum,

>> python-magnumclient and magnum-ui with regards to APIs we have been
>> intending to drop support for. During the Tokyo summit it was decided
>> that we should support for only COE APIs that all COEs can support which

>> means dropping support for Kubernetes specific APIs for Pod, Service and

>> Replication Controller.
>>
>> Egor has submitted a blueprint[1] “Unify container actions between all
>> COEs” which has been approved to cover this work and I have submitted
the
>> first of many patches that will be needed to unify the APIs.
>>
>> The controversial patches are here:
>> https://review.openstack.org/#/c/258485/ and
>> https://review.openstack.org/#/c/258454/
>>
>> These patches are more a forcing function for our team to decide how to
>> correctly deprecate these APIs as I mention there is a lot of redundant
>> work going on these APIs. Please let me know your thoughts.
>>
>> Tom
>>
>> [1] https://blueprints.launchpad.net/magnum/+spec/unified-containers
>>
__________________________________________________________________________
>> 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

__________________________________________________________________________
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


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151217/68d005fa/attachment.html>
-------------- next part --------------
A non-text attachment was scrubbed...
Name: graycol.gif
Type: image/gif
Size: 105 bytes
Desc: not available
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151217/68d005fa/attachment.gif>