Open Stack

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> wrote:

>
> On Feb 16, 2017, at 4:19 PM, Zhipeng Huang <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
>
>
>
> 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> 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>
>> 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>
>> 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/chin
>> a-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
>>
>>
>
>
> --
> 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
>
>
>
> _______________________________________________
> 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/20170217/dacc6b4e/attachment-0001.html>