[Interop-wg] Question regarding DefCore 2016.08
Catherine Cuong Diep
cdiep at us.ibm.com
Thu Feb 16 18:47:29 UTC 2017
Hello Zhipeng,
Thank you so much for the investigation. I think this would be a good
topic for PTG discussion on test requirements i.e. testing of public
cloud end-user ( public) API vs non end-user API .
Catherine Diep
----- Forwarded by Catherine Cuong Diep/San Jose/IBM on 02/16/2017 10:31 AM
-----
From: Zhipeng Huang <zhipengh512 at gmail.com>
To: Catherine Cuong Diep/San Jose/IBM at IBMUS
Cc: Kurt Garloff <t-systems at garloff.de>,
interop-wg at lists.openstack.org, Mark Voelker
<mvoelker at vmware.com>
Date: 02/15/2017 07:41 PM
Subject: Re: [Interop-wg] Question regarding DefCore 2016.08
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:
1. 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.
2. 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>
wrote:
Hi Kurt,
There are 2 discussion points regarding volume attach/detach support:
1. Whether it is a common implementation that public cloud does not
allow users to attach/detach volume to an instant.
2. 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
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>
To: interop-wg at lists.openstack.org, Zhipeng Huang <zhipengh512 at gmail.com
>, Mark Voelker <mvoelker at vmware.com>
Cc: "interop-wg at lists.openstack.org" <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 (Bonn, PH51, G010)
+49 1515 1551 744 (Mobile)
E-Mail: kurt.garloff at t-systems.com
E-Mail: t-systems at garloff.de
http://t-systems.com/
Compulsory statement §35a GmbHG:
https://www.t-systems.com/compulsory-statement
Am 19. Januar 2017 16:42:28 MEZ schrieb Zhipeng Huang <
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
> wrote:
>
> On Jan 18, 2017, at 9:31 PM, Zhipeng Huang <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
>
>
> 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>
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
>
> 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> 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
>> Office: Huawei Industrial Base, Longgang, Shenzhen
>>
>> (Previous)
>> Research Assistant
>> Mobile Ad-Hoc Network Lab, Calit2
>> University of California, Irvine
>> Email: 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
>
>
>
>
> --
> Zhipeng (Howard) Huang
>
> Standard Engineer
> IT Standard & Patent/IT Prooduct Line
> Huawei Technologies Co,. Ltd
> Email: 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
> 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
--
Zhipeng (Howard) Huang
Standard Engineer
IT Standard & Patent/IT Prooduct Line
Huawei Technologies Co,. Ltd
Email: 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
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
--
Zhipeng (Howard) Huang
Standard Engineer
IT Standard & Patent/IT Prooduct Line
Huawei Technologies Co,. Ltd
Email: 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
Office: Calit2 Building Room 2402
OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/interop-wg/attachments/20170216/64babe54/attachment-0001.html>
More information about the Interop-wg
mailing list