Yes, this topic is a good one for a spec. What I am planning to do here is copy the content from the BP to an etherpad in spec format, and iterating on that in a fluid way to begin with. I will clear the BP whiteboard, and simplify the description to cover the intent and principles of the change. Once that gels a little we can contribute that for review as a spec and have more structured debate.
When we finish, we will have a concise blueprint, history of our debate in Gerrit, a merged spec, and then we can code it. The timing of this is unfortunate because several key stakeholders may be away for holidays over the next couple of weeks. We should proceed with caution. Adrian On Dec 16, 2015, at 5:11 PM, Kai Qiang Wu <wk...@cn.ibm.com<mailto:wk...@cn.ibm.com>> wrote: 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: wk...@cn.ibm.com<mailto:wk...@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! <graycol.gif>Adrian Otto ---17/12/2015 07:00:37 am---Tom, > On Dec 16, 2015, at 9:31 AM, Cammann, Tom <tom.camm...@hpe.com<mailto:tom.camm...@hpe.com>> wrote: From: Adrian Otto <adrian.o...@rackspace.com<mailto:adrian.o...@rackspace.com>> To: "OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org<mailto:openstack-dev@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.camm...@hpe.com<mailto:tom.camm...@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...@huawei.com<mailto:hongbin...@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.camm...@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-requ...@lists.openstack.org<mailto:openstack-dev-requ...@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-requ...@lists.openstack.org<mailto:openstack-dev-requ...@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-requ...@lists.openstack.org<mailto:openstack-dev-requ...@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-requ...@lists.openstack.org<mailto:openstack-dev-requ...@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-requ...@lists.openstack.org<mailto:openstack-dev-requ...@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-requ...@lists.openstack.org?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
