Open Stack

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