Open Stack

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

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/interop-wg/attachments/20170119/05f9682d/attachment-0001.html>