[Interop-wg] Question regarding DefCore 2016.08
Chris Hoge
chris at openstack.org
Sun Apr 2 18:18:14 UTC 2017
My apologies for the late reply about the outcomes of this meeting. As
discussed, the Cinder API as described in the active guidelines is
required for the OpenStack Powered Compute and OpenStack Powered
Platform trademarks. The Nova/Cinder proxy API is not sufficient, and
the direct Cinder API is required for the following reasons:
1) It is not the future direction of the Cinder API. [1]
2) The Nova volume extension API is deprecated. [2]
3) Projects other than Nova, such as Kubernetes, may want to consume
the Cinder API as a provider plugin. [3]
4) There was no demonstration of any inherent vulnerabilities from
direct use of the Cinder API.
Thanks,
Chris Hoge
Interop Enginner
OpenStack Foundation
[1] http://git.openstack.org/cgit/openstack/governance/tree/resolutions/20160504-defcore-proxy-tests.rst
[2] https://developer.openstack.org/api-ref/compute/
[3] https://github.com/kubernetes/kubernetes/blob/master/pkg/cloudprovider/providers/openstack/openstack.go
> On Feb 20, 2017, at 9:12 AM, Chris Hoge <chris at openstack.org> wrote:
>
> We will be continuing this discussion in person at the PTG. Please join us on Wednesday
> morning from 9-10 AM in the Savannah 3 room. We will follow up with the outcomes in
> this thread.
>
> Thanks,
>
> Chris Hoge
> Interop Engineer
> OpenStack Foundation
>
>> On Feb 16, 2017, at 8:10 PM, Zhipeng Huang <zhipengh512 at gmail.com <mailto:zhipengh512 at gmail.com>> wrote:
>>
>> Hi Chris,
>>
>> Thanks for the reference, the word "proxy" reminds me the time when we proposed Tricircle :P
>>
>> My point of view is that we have an implementation (fully functioning and running) in a public cloud product environment with (at least I believe) good justification for the choice we have made re that implementation.
>>
>> I believe the TC guideline on defcore proxy should apply for most of the cases, however there should be adjustments for real commercial use cases. Otherwise we are strictly adhere to a scripture part of which might not serve well for the ever-wider commercial adoption of OpenStack.
>>
>> I understand the TC resolution is a result of a heated debate, so let's discuss the issue I proposed on PTG and if team member reckon it is a necessity we should make a proposal to the TC to have an amendment. If not then let's figure out another way to solve the problem : )
>>
>> On Fri, Feb 17, 2017 at 8:28 AM, Chris Hoge <chris at openstack.org <mailto:chris at openstack.org>> wrote:
>>
>>> On Feb 16, 2017, at 4:19 PM, Zhipeng Huang <zhipengh512 at gmail.com <mailto:zhipengh512 at gmail.com>> wrote:
>>>
>>> Hi Mark,
>>>
>>> To be honest my "investigation" was far from either definitive or conclusive, but a subjective deduction by myself. However as Catherine said this should be an interesting topic that we could follow up on the PTG meeting.
>>>
>>> I think Interop WG should start to formalize testing requirements for vertical use cases, such as public cloud, nfv, finance, etc. For public cloud, there always will be different implementations of whether or not to have a api-gateway or how to construct such functionality, we should have specific requirements for each scenarios so that public cloud provider folks know exactly which method they should use for testing. ( Put my publiccloud wg co-chair hat on for a little bit :) )
>>>
>>> Beside the issue mentioned above, I want to ask if everyone at the moment thinks the volume_action flagging is a reasonable proposal ? I want to explain the reason again here that user could use nova api for the attach/detach operations without explicitly calling cinder api, and if user is able to directly use the cider attach/detach api they might change the volume status (quite often) and affect the normal usage of the volume provided by the OpenStack public cloud.
>>
>> This was discussed at length in the adoption of the direct APIs
>> and the deprecation of the Nova APIs as part of the guideline.
>> The TC passed a resolution that strongly discourages using
>> the proxy APIs[1], and we adopted that guidance.
>>
>> The future direction of OpenStack is to not use the proxy APIs,
>> which is the primary reason we do not test for the Nova API for
>> volume attach and detach any longer and instead require the
>> direct Cinder APIs.
>>
>> [1] https://governance.openstack.org/tc/resolutions/20160504-defcore-proxy-tests.html <https://governance.openstack.org/tc/resolutions/20160504-defcore-proxy-tests.html>
>>
>>
>>>
>>> If folks think the topic is reasonable enough then I will submit a patch, if not let's discuss more on the ML :)
>>>
>>>
>>> On Fri, Feb 17, 2017 at 2:54 AM, Mark Voelker <mvoelker at vmware.com <mailto:mvoelker at vmware.com>> wrote:
>>> Zhipeng,
>>>
>>> Thanks for following up on this! To me your findings sound very concerning. The implication here seems to be that since the tests were not conducted through the public gateway, users of the cloud aren’t getting the same experience that they would be lead to expect from a cloud that bears the Powered logo (because the tests weren’t conducted through the gateway that users must traverse). Am I interpreting this finding correctly? If so it sounds like we may need to follow up with the CTC folks to ensure that their cloud is being tested appropriately.
>>>
>>> At Your Service,
>>>
>>> Mark T. Voelker
>>>
>>> > On Feb 15, 2017, at 10:40 PM, Zhipeng Huang <zhipengh512 at gmail.com <mailto:zhipengh512 at gmail.com>> wrote:
>>> >
>>> > Hi Catherine and Kurt,
>>> >
>>> > After some investigation I find out that the CTC conducted their defcore testing without going through its public cloud api gateway, therefore the volume_action testing called the native Cinder apis and it passed the tests without problems.
>>> >
>>> > The problems for OTC is that our defcore 2016.08 tests are conducted through the api gateway and api gateway maps all the volume related requests to the EVS (elastic volume service) which currently only allows user to do some scaling operations but not actions like attach/detach. This is why I reported the volume_action issue.
>>> >
>>> > I think this is a common public cloud implementation choice that although we provide all the volume_action related APIs, when calling EVS for public cloud volume services, the user privilege only gets you the scaling operations.
>>> >
>>> > In another word to answer your question:
>>> > • Whether it is a common implementation that public cloud does not allow users to attach/detach volume to an instant.
>>> > • User could perform this action through EVS, but not by calling the Cinder attach/detach API directly.
>>> > • Volume detach/attach support is via Nova or Cinder.
>>> > • It is provided Nova, and Nova calls Cinder for the specific operation. Again this is why most of the cinder volume_action api is not opened for the user privilege in public cloud, it is just for internal usage by Nova.
>>> > Hope I have made this topic more clearer :)
>>> >
>>> > On Fri, Jan 20, 2017 at 3:50 AM, Catherine Cuong Diep <cdiep at us.ibm.com <mailto:cdiep at us.ibm.com>> wrote:
>>> > Hi Kurt,
>>> >
>>> > There are 2 discussion points regarding volume attach/detach support:
>>> > • Whether it is a common implementation that public cloud does not allow users to attach/detach volume to an instant.
>>> > • Volume detach/attach support is via Nova or Cinder.
>>> >
>>> > Your note indicates that your public cloud does allow users to attach/detach volume to an instant. Seems like CT Cloud Platform [1] (an other public cloud) also supports this feature since it passed the 2017.08 guideline.
>>> >
>>> > [1] https://www.openstack.org/marketplace/public-clouds/china-telecom/ct-cloud-platform <https://www.openstack.org/marketplace/public-clouds/china-telecom/ct-cloud-platform>
>>> >
>>> > Catherine Diep
>>> > ----- Forwarded by Catherine Cuong Diep/San Jose/IBM on 01/19/2017 11:22 AM -----
>>> >
>>> > From: Kurt Garloff <t-systems at garloff.de <mailto:t-systems at garloff.de>>
>>> > To: interop-wg at lists.openstack.org <mailto:interop-wg at lists.openstack.org>, Zhipeng Huang <zhipengh512 at gmail.com <mailto:zhipengh512 at gmail.com>>, Mark Voelker <mvoelker at vmware.com <mailto:mvoelker at vmware.com>>
>>> > Cc: "interop-wg at lists.openstack.org <mailto:interop-wg at lists.openstack.org>" <interop-wg at lists.openstack.org <mailto:interop-wg at lists.openstack.org>>
>>> > Date: 01/19/2017 11:01 AM
>>> > Subject: Re: [Interop-wg] Question regarding DefCore 2016.08
>>> >
>>> >
>>> >
>>> > Hi,
>>> >
>>> > Just to provide a data point.
>>> >
>>> > OTC would currently have the same issue. Volume detach/attach is supported via nova but not cinder.
>>> > I do not see a fundamental reason why this would need to be that way though in our public cloud, currently, but we just started to investigate...
>>> >
>>> > Best,
>>> > --
>>> > Kurt Garloff
>>> >
>>> > T-SYSTEMS INTERNATIONAL GMBH
>>> > IT Div | Global IT Ops | OTC
>>> > Kurt Garloff
>>> > OpenStack ☁ Architect
>>> > +49 228 181 45646 <tel:%2B49%20228%20181%2045646> (Bonn, PH51, G010)
>>> > +49 1515 1551 744 <tel:%2B49%201515%201551%20744> (Mobile)
>>> > E-Mail: kurt.garloff at t-systems.com <mailto:kurt.garloff at t-systems.com>
>>> > E-Mail: t-systems at garloff.de <mailto:t-systems at garloff.de>
>>> > http://t-systems.com/ <http://t-systems.com/>
>>> >
>>> > Compulsory statement §35a GmbHG: https://www.t-systems.com/compulsory-statement <https://www.t-systems.com/compulsory-statement>
>>> >
>>> > Am 19. Januar 2017 16:42:28 MEZ schrieb Zhipeng Huang <zhipengh512 at gmail.com <mailto:zhipengh512 at gmail.com>>:
>>> > Hi Mark,
>>> >
>>> > Thank you very much for the detailed response, I will raise a flag for the network-l2-CRUD problem.
>>> >
>>> > Regarding our volumes_action problem, I think the rationale for our choice of implementation is that as a public cloud provider, operations such as mount/unmount are ok to be provided to the users, but operations like "attach, detach, reserve" are better used internally (hiding behind for example "Elastice Volume Service" which is provided by the public cloud). As I understand this is not a deliberate bypassing of the basic defcore requirements, but rather a common public cloud implementation choice.
>>> >
>>> > Would the above explanation sound reasonable to you ?
>>> >
>>> > On Thu, Jan 19, 2017 at 12:49 PM, Mark Voelker <mvoelker at vmware.com <mailto:mvoelker at vmware.com>> wrote:
>>> > >
>>> > > On Jan 18, 2017, at 9:31 PM, Zhipeng Huang <zhipengh512 at gmail.com <mailto:zhipengh512 at gmail.com>> wrote:
>>> > >
>>> > > Resend the information about our problems to the list.
>>> >
>>> > Thanks for sending this.
>>> >
>>> > >
>>> > > The problem we found is regarding networking part in 2016.08 and probably also in 2017.01, specifically:
>>> > >
>>> > > 1. networks-l2-CRUD:
>>> > > • tempest.api.network.test_ports.PortsTestJSON.test_create_port_with_no_securitygroups
>>> > > • tempest.api.network.test_ports.PortsTestJSON.test_create_show_delete_port_user_defined_mac
>>> > >
>>> > > Our problem is that in our public cloud implementation, we mandate that port creation must have security groups designated, and at the moment all the mac address are pre-allocated and not up to the user to define.
>>> >
>>> > While I’m not aware of other clouds that enforce such restrictions, I could see an argument being made for this on security grounds and it seems like a reasonable discussion for us as a community to have. I’d suggest submitting a flag request on these tests if you’d like to get that conversation going. The process for doing so is described here (please let us know if you need help):
>>> >
>>> > http://git.openstack.org/cgit/openstack/defcore/tree/HACKING.rst#n85 <http://git.openstack.org/cgit/openstack/defcore/tree/HACKING.rst#n85>
>>> >
>>> > >
>>> > >
>>> > > 2. volumes_action related rules:
>>> > > • tempest.api.volume.test_volumes_actions.VolumesV2ActionsTest.test_attach_detach_volume_to_instance
>>> > > • tempest.api.volume.test_volumes_actions.VolumesV2ActionsTest.test_get_volume_attachment
>>> > > • tempest.api.volume.test_volumes_actions.VolumesV2ActionsTest.test_reserve_unreserve_volume
>>> > > • tempest.api.volume.test_volumes_actions.VolumesV2ActionsTest.test_volume_bootable
>>> > > • tempest.api.volume.test_volumes_actions.VolumesV2ActionsTest.test_volume_readonly_update
>>> > > The problem for us is that in our public cloud implementation, volumes_action related operations are only internally used for inter-module calls (e.g between Nova and Cinder) or Admin ops, but not for directly usage by the tenants/users.
>>> >
>>> >
>>> > Things like attaching and detaching a volume from an instance or getting attachment status of a volume feel like really basic operations that most users of OpenStack clouds (and most clients/toolkits they’re using) would expect to be present and functioning. I don’t think I’ve encountered other clouds that don’t support these fundamental volume operations. This would lead me to think that your cloud is, in fact, not interoperable with most other OpenStack Powered clouds in this respect. It seems like an implementation choice you’ve made to deliberately not expose block storage functionality, which differs substantially from the choices of other OpenStack Powered clouds (public and private). While I’d like to understand the rationale behind that choice, this feels like a case where I’d have a hard time being convinced that the tests should be flagged.
>>> >
>>> > At Your Service,
>>> >
>>> > Mark T. Voelker
>>> >
>>> > >
>>> > >
>>> > > In summary our problems have to do with our public cloud requirements, i'm not sure if these are reasonable questions for defcore guideline as well as if these are suit for flagging ?
>>> > >
>>> > > On Wed, Jan 18, 2017 at 3:46 AM, Chris Hoge <chris at openstack.org <mailto:chris at openstack.org>> wrote:
>>> > > The 2017.01 guideline will be going to the board for final approval
>>> > > at the end of this month. 2016.08 is finalized, but problematic
>>> > > tests can be flagged. We have our weekly working group
>>> > > meetings on Wednesdays, and we’d be happy to consider
>>> > > isses as part of our agenda. You can add an agenda item to the
>>> > > meeting etherpad:
>>> > >
>>> > > https://etherpad.openstack.org/p/DefCoreRoble.9 <https://etherpad.openstack.org/p/DefCoreRoble.9>
>>> > >
>>> > > It’s also useful to raise issues on this mailing list to give the wider
>>> > > community a chance to comment.
>>> > >
>>> > > Thanks,
>>> > > Chris Hoge
>>> > > Interop Engineer
>>> > > OpenStack Foundation
>>> > >
>>> > >
>>> > >> On Jan 17, 2017, at 6:53 AM, Zhipeng Huang <zhipengh512 at gmail.com <mailto:zhipengh512 at gmail.com>> wrote:
>>> > >>
>>> > >> Hi team,
>>> > >>
>>> > >> Is there still time for us to provide feedback for the 2016.08 defcore guideline or it is too late ?
>>> > >>
>>> > >> --
>>> > >> Zhipeng (Howard) Huang
>>> > >>
>>> > >> Standard Engineer
>>> > >> IT Standard & Patent/IT Prooduct Line
>>> > >> Huawei Technologies Co,. Ltd
>>> > >> Email: huangzhipeng at huawei.com <mailto:huangzhipeng at huawei.com>
>>> > >> Office: Huawei Industrial Base, Longgang, Shenzhen
>>> > >>
>>> > >> (Previous)
>>> > >> Research Assistant
>>> > >> Mobile Ad-Hoc Network Lab, Calit2
>>> > >> University of California, Irvine
>>> > >> Email: zhipengh at uci.edu <mailto:zhipengh at uci.edu>
>>> > >> Office: Calit2 Building Room 2402
>>> > >>
>>> > >> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
>>> > >> _______________________________________________
>>> > >> Interop-wg mailing list
>>> > >> Interop-wg at lists.openstack.org <mailto:Interop-wg at lists.openstack.org>
>>> > >> http://lists.openstack.org/cgi-bin/mailman/listinfo/interop-wg <http://lists.openstack.org/cgi-bin/mailman/listinfo/interop-wg>
>>> > >
>>> > >
>>> > >
>>> > >
>>> > > --
>>> > > Zhipeng (Howard) Huang
>>> > >
>>> > > Standard Engineer
>>> > > IT Standard & Patent/IT Prooduct Line
>>> > > Huawei Technologies Co,. Ltd
>>> > > Email: huangzhipeng at huawei.com <mailto:huangzhipeng at huawei.com>
>>> > > Office: Huawei Industrial Base, Longgang, Shenzhen
>>> > >
>>> > > (Previous)
>>> > > Research Assistant
>>> > > Mobile Ad-Hoc Network Lab, Calit2
>>> > > University of California, Irvine
>>> > > Email: zhipengh at uci.edu <mailto:zhipengh at uci.edu>
>>> > > Office: Calit2 Building Room 2402
>>> > >
>>> > > OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
>>> > > _______________________________________________
>>> > > Interop-wg mailing list
>>> > > Interop-wg at lists.openstack.org <mailto:Interop-wg at lists.openstack.org>
>>> > > http://lists.openstack.org/cgi-bin/mailman/listinfo/interop-wg <http://lists.openstack.org/cgi-bin/mailman/listinfo/interop-wg>
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > Zhipeng (Howard) Huang
>>> >
>>> > Standard Engineer
>>> > IT Standard & Patent/IT Prooduct Line
>>> > Huawei Technologies Co,. Ltd
>>> > Email: huangzhipeng at huawei.com <mailto:huangzhipeng at huawei.com>
>>> > Office: Huawei Industrial Base, Longgang, Shenzhen
>>> >
>>> > (Previous)
>>> > Research Assistant
>>> > Mobile Ad-Hoc Network Lab, Calit2
>>> > University of California, Irvine
>>> > Email: zhipengh at uci.edu <mailto:zhipengh at uci.edu>
>>> > Office: Calit2 Building Room 2402
>>> >
>>> > OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado_______________________________________________
>>> > Interop-wg mailing list
>>> > Interop-wg at lists.openstack.org <mailto:Interop-wg at lists.openstack.org>
>>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/interop-wg <http://lists.openstack.org/cgi-bin/mailman/listinfo/interop-wg>
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> > --
>>> > Zhipeng (Howard) Huang
>>> >
>>> > Standard Engineer
>>> > IT Standard & Patent/IT Prooduct Line
>>> > Huawei Technologies Co,. Ltd
>>> > Email: huangzhipeng at huawei.com <mailto:huangzhipeng at huawei.com>
>>> > Office: Huawei Industrial Base, Longgang, Shenzhen
>>> >
>>> > (Previous)
>>> > Research Assistant
>>> > Mobile Ad-Hoc Network Lab, Calit2
>>> > University of California, Irvine
>>> > Email: zhipengh at uci.edu <mailto:zhipengh at uci.edu>
>>> > Office: Calit2 Building Room 2402
>>> >
>>> > OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
>>>
>>>
>>>
>>>
>>> --
>>> Zhipeng (Howard) Huang
>>>
>>> Standard Engineer
>>> IT Standard & Patent/IT Prooduct Line
>>> Huawei Technologies Co,. Ltd
>>> Email: huangzhipeng at huawei.com <mailto:huangzhipeng at huawei.com>
>>> Office: Huawei Industrial Base, Longgang, Shenzhen
>>>
>>> (Previous)
>>> Research Assistant
>>> Mobile Ad-Hoc Network Lab, Calit2
>>> University of California, Irvine
>>> Email: zhipengh at uci.edu <mailto:zhipengh at uci.edu>
>>> Office: Calit2 Building Room 2402
>>>
>>> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
>>> _______________________________________________
>>> Interop-wg mailing list
>>> Interop-wg at lists.openstack.org <mailto:Interop-wg at lists.openstack.org>
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/interop-wg <http://lists.openstack.org/cgi-bin/mailman/listinfo/interop-wg>
>>
>> _______________________________________________
>> Interop-wg mailing list
>> Interop-wg at lists.openstack.org <mailto:Interop-wg at lists.openstack.org>
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/interop-wg <http://lists.openstack.org/cgi-bin/mailman/listinfo/interop-wg>
>>
>>
>>
>>
>> --
>> Zhipeng (Howard) Huang
>>
>> Standard Engineer
>> IT Standard & Patent/IT Prooduct Line
>> Huawei Technologies Co,. Ltd
>> Email: huangzhipeng at huawei.com <mailto:huangzhipeng at huawei.com>
>> Office: Huawei Industrial Base, Longgang, Shenzhen
>>
>> (Previous)
>> Research Assistant
>> Mobile Ad-Hoc Network Lab, Calit2
>> University of California, Irvine
>> Email: zhipengh at uci.edu <mailto:zhipengh at uci.edu>
>> Office: Calit2 Building Room 2402
>>
>> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
>
> _______________________________________________
> Interop-wg mailing list
> Interop-wg at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/interop-wg
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/interop-wg/attachments/20170402/fea66dab/attachment-0001.html>
More information about the Interop-wg
mailing list