Open Stack

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.otto at 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 <wkqwu at 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: 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!
>
> <graycol.gif>Adrian Otto ---17/12/2015 07:00:37 am---Tom, > On Dec 16,
> 2015, at 9:31 AM, Cammann, Tom <tom.cammann at hpe.com> wrote:
>
> 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 <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
>
>
>
> __________________________________________________________________________
> 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
>
>


-- 
Thanks,

Jay Lau (Guangya Liu)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151221/85f3cae2/attachment.html>