Open Stack

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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/interop-wg/attachments/20170119/75248ee1/attachment-0001.html>