<html><body><p>Hi Adrian,<br><br>Right now, I think:<br><br>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)<br>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. <br><br><br>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)<br><br><br>Thanks<br><br>Best Wishes,<br>--------------------------------------------------------------------------------<br>Kai Qiang Wu (Î⿪ǿ Kennan£©<br>IBM China System and Technology Lab, Beijing<br><br>E-mail: wkqwu@cn.ibm.com<br>Tel: 86-10-82451647<br>Address: Building 28(Ring Building), ZhongGuanCun Software Park, <br> No.8 Dong Bei Wang West Road, Haidian District Beijing P.R.China 100193<br>--------------------------------------------------------------------------------<br>Follow your heart. You are miracle! <br><br><img width="16" height="16" src="cid:1__=8FBBF58DDF96A0358f9e8a93df938690918c8FB@" border="0" alt="Inactive hide details for Adrian Otto ---17/12/2015 07:00:37 am---Tom, > On Dec 16, 2015, at 9:31 AM, Cammann, Tom <tom.cammann"><font color="#424282">Adrian Otto ---17/12/2015 07:00:37 am---Tom, > On Dec 16, 2015, at 9:31 AM, Cammann, Tom <tom.cammann@hpe.com> wrote:</font><br><br><font size="2" color="#5F5F5F">From: </font><font size="2">Adrian Otto <adrian.otto@rackspace.com></font><br><font size="2" color="#5F5F5F">To: </font><font size="2">"OpenStack Development Mailing List (not for usage questions)" <openstack-dev@lists.openstack.org></font><br><font size="2" color="#5F5F5F">Date: </font><font size="2">17/12/2015 07:00 am</font><br><font size="2" color="#5F5F5F">Subject: </font><font size="2">Re: [openstack-dev] [magnum] Removing pod, rcs and service APIs</font><br><hr width="100%" size="2" align="left" noshade style="color:#8091A5; "><br><br><br><tt>Tom,<br><br>> On Dec 16, 2015, at 9:31 AM, Cammann, Tom <tom.cammann@hpe.com> wrote:<br>> <br>> I don¡¯t see a benefit from supporting the old API through a microversion <br>> when the same functionality will be available through the native API.<br><br>+1<br><br>[snip]<br><br>> Have we had any discussion on adding a v2 API and what changes (beyond <br>> removing pod, rc, service) we would include in that change. What sort of <br>> timeframe would we expect to remove the v1 API. I would like to move to a <br>> v2 in this cycle, then we can think about removing v1 in N.<br><br>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.<br><br>Adrian<br><br>> <br>> Tom<br>> <br>> <br>> <br>> On 16/12/2015, 15:57, "Hongbin Lu" <hongbin.lu@huawei.com> wrote:<br>> <br>>> Hi Tom,<br>>> <br>>> If I remember correctly, the decision is to drop the COE-specific API <br>>> (Pod, Service, Replication Controller) in the next API version. I think a <br>>> good way to do that is to put a deprecated warning in current API version <br>>> (v1) for the removed resources, and remove them in the next API version <br>>> (v2).<br>>> <br>>> An alternative is to drop them in current API version. If we decide to do <br>>> that, we need to bump the micro-version [1], and ask users to specify the <br>>> microversion as part of the requests when they want the removed APIs.<br>>> <br>>> [1] <br>>> </tt><tt><a href="http://docs.openstack.org/developer/nova/api_microversions.html#removing-a">http://docs.openstack.org/developer/nova/api_microversions.html#removing-a</a></tt><tt><br>>> n-api-method<br>>> <br>>> Best regards,<br>>> Hongbin<br>>> <br>>> -----Original Message-----<br>>> From: Cammann, Tom [</tt><tt><a href="mailto:tom.cammann@hpe.com">mailto:tom.cammann@hpe.com</a></tt><tt>] <br>>> Sent: December-16-15 8:21 AM<br>>> To: OpenStack Development Mailing List (not for usage questions)<br>>> Subject: [openstack-dev] [magnum] Removing pod, rcs and service APIs<br>>> <br>>> I have been noticing a fair amount of redundant work going on in magnum, <br>>> python-magnumclient and magnum-ui with regards to APIs we have been <br>>> intending to drop support for. During the Tokyo summit it was decided <br>>> that we should support for only COE APIs that all COEs can support which <br>>> means dropping support for Kubernetes specific APIs for Pod, Service and <br>>> Replication Controller.<br>>> <br>>> Egor has submitted a blueprint[1] ¡°Unify container actions between all <br>>> COEs¡± which has been approved to cover this work and I have submitted the <br>>> first of many patches that will be needed to unify the APIs.<br>>> <br>>> The controversial patches are here: <br>>> </tt><tt><a href="https://review.openstack.org/#/c/258485/">https://review.openstack.org/#/c/258485/</a></tt><tt> and <br>>> </tt><tt><a href="https://review.openstack.org/#/c/258454/">https://review.openstack.org/#/c/258454/</a></tt><tt><br>>> <br>>> These patches are more a forcing function for our team to decide how to <br>>> correctly deprecate these APIs as I mention there is a lot of redundant <br>>> work going on these APIs. Please let me know your thoughts.<br>>> <br>>> Tom<br>>> <br>>> [1] </tt><tt><a href="https://blueprints.launchpad.net/magnum/+spec/unified-containers">https://blueprints.launchpad.net/magnum/+spec/unified-containers</a></tt><tt><br>>> __________________________________________________________________________<br>>> OpenStack Development Mailing List (not for usage questions)<br>>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>>> </tt><tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></tt><tt><br>>> __________________________________________________________________________<br>>> OpenStack Development Mailing List (not for usage questions)<br>>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>>> </tt><tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></tt><tt><br>> __________________________________________________________________________<br>> OpenStack Development Mailing List (not for usage questions)<br>> Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br>> </tt><tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></tt><tt><br><br>__________________________________________________________________________<br>OpenStack Development Mailing List (not for usage questions)<br>Unsubscribe: OpenStack-dev-request@lists.openstack.org?subject:unsubscribe<br></tt><tt><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></tt><tt><br></tt><br><br><BR>
</body></html>