We also need to consider a lot for Magnum UI part as the UI part is highly depend on those APIs. Thanks.
On Thu, Dec 17, 2015 at 9:21 AM, Adrian Otto <adrian.o...@rackspace.com> wrote: > 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> 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 > 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> wrote: > > From: Adrian Otto <adrian.o...@rackspace.com> > To: "OpenStack Development Mailing List (not for usage questions)" < > 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> 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> 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 <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 > ?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 > > > __________________________________________________________________________ > > 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 > > __________________________________________________________________________ > 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 > > > > __________________________________________________________________________ > 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 > > > __________________________________________________________________________ > 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 > > -- Thanks, Jay Lau (Guangya Liu)
__________________________________________________________________________ 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