<div dir="ltr">Hi Mark,<div><br></div><div>Thank you very much for the detailed response, I will raise a flag for the network-l2-CRUD problem.</div><div><br></div><div>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.</div><div><br></div><div>Would the above explanation sound reasonable to you ? </div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Jan 19, 2017 at 12:49 PM, Mark Voelker <span dir="ltr"><<a href="mailto:mvoelker@vmware.com" target="_blank">mvoelker@vmware.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">><br>
> On Jan 18, 2017, at 9:31 PM, Zhipeng Huang <<a href="mailto:zhipengh512@gmail.com">zhipengh512@gmail.com</a>> wrote:<br>
><br>
> Resend the information about our problems to the list.<br>
<br>
</span>Thanks for sending this.<br>
<span class=""><br>
><br>
> The problem we found is regarding networking part in 2016.08 and probably also in 2017.01, specifically:<br>
><br>
> 1. networks-l2-CRUD:<br>
>       • tempest.api.network.test_<wbr>ports.PortsTestJSON.test_<wbr>create_port_with_no_<wbr>securitygroups<br>
>       • tempest.api.network.test_<wbr>ports.PortsTestJSON.test_<wbr>create_show_delete_port_user_<wbr>defined_mac<br>
><br>
> 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.<br>
<br>
</span>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):<br>
<br>
<a href="http://git.openstack.org/cgit/openstack/defcore/tree/HACKING.rst#n85" rel="noreferrer" target="_blank">http://git.openstack.org/cgit/<wbr>openstack/defcore/tree/<wbr>HACKING.rst#n85</a><br>
<span class=""><br>
><br>
><br>
> 2. volumes_action related rules:<br>
>       • tempest.api.volume.test_<wbr>volumes_actions.<wbr>VolumesV2ActionsTest.test_<wbr>attach_detach_volume_to_<wbr>instance<br>
>       • tempest.api.volume.test_<wbr>volumes_actions.<wbr>VolumesV2ActionsTest.test_get_<wbr>volume_attachment<br>
>       • tempest.api.volume.test_<wbr>volumes_actions.<wbr>VolumesV2ActionsTest.test_<wbr>reserve_unreserve_volume<br>
>       • tempest.api.volume.test_<wbr>volumes_actions.<wbr>VolumesV2ActionsTest.test_<wbr>volume_bootable<br>
>       • tempest.api.volume.test_<wbr>volumes_actions.<wbr>VolumesV2ActionsTest.test_<wbr>volume_readonly_update<br>
> 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.<br>
<br>
<br>
</span>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.<br>
<br>
At Your Service,<br>
<br>
Mark T. Voelker<br>
<div class="HOEnZb"><div class="h5"><br>
><br>
><br>
> 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 ?<br>
><br>
> On Wed, Jan 18, 2017 at 3:46 AM, Chris Hoge <<a href="mailto:chris@openstack.org">chris@openstack.org</a>> wrote:<br>
> The 2017.01 guideline will be going to the board for final approval<br>
> at the end of this month. 2016.08 is finalized, but problematic<br>
> tests can be flagged. We have our weekly working group<br>
> meetings on Wednesdays, and we’d be happy to consider<br>
> isses as part of our agenda. You can add an agenda item to the<br>
> meeting etherpad:<br>
><br>
> <a href="https://etherpad.openstack.org/p/DefCoreRoble.9" rel="noreferrer" target="_blank">https://etherpad.openstack.<wbr>org/p/DefCoreRoble.9</a><br>
><br>
> It’s also useful to raise issues on this mailing list to give the wider<br>
> community a chance to comment.<br>
><br>
> Thanks,<br>
> Chris Hoge<br>
> Interop Engineer<br>
> OpenStack Foundation<br>
><br>
><br>
>> On Jan 17, 2017, at 6:53 AM, Zhipeng Huang <<a href="mailto:zhipengh512@gmail.com">zhipengh512@gmail.com</a>> wrote:<br>
>><br>
>> Hi team,<br>
>><br>
>> Is there still time for us to provide feedback for the 2016.08 defcore guideline or it is too late ?<br>
>><br>
>> --<br>
>> Zhipeng (Howard) Huang<br>
>><br>
>> Standard Engineer<br>
>> IT Standard & Patent/IT Prooduct Line<br>
>> Huawei Technologies Co,. Ltd<br>
>> Email: <a href="mailto:huangzhipeng@huawei.com">huangzhipeng@huawei.com</a><br>
>> Office: Huawei Industrial Base, Longgang, Shenzhen<br>
>><br>
>> (Previous)<br>
>> Research Assistant<br>
>> Mobile Ad-Hoc Network Lab, Calit2<br>
>> University of California, Irvine<br>
>> Email: <a href="mailto:zhipengh@uci.edu">zhipengh@uci.edu</a><br>
>> Office: Calit2 Building Room 2402<br>
>><br>
>> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado<br>
>> ______________________________<wbr>_________________<br>
>> Interop-wg mailing list<br>
>> <a href="mailto:Interop-wg@lists.openstack.org">Interop-wg@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/interop-wg" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>interop-wg</a><br>
><br>
><br>
><br>
><br>
> --<br>
> Zhipeng (Howard) Huang<br>
><br>
> Standard Engineer<br>
> IT Standard & Patent/IT Prooduct Line<br>
> Huawei Technologies Co,. Ltd<br>
> Email: <a href="mailto:huangzhipeng@huawei.com">huangzhipeng@huawei.com</a><br>
> Office: Huawei Industrial Base, Longgang, Shenzhen<br>
><br>
> (Previous)<br>
> Research Assistant<br>
> Mobile Ad-Hoc Network Lab, Calit2<br>
> University of California, Irvine<br>
> Email: <a href="mailto:zhipengh@uci.edu">zhipengh@uci.edu</a><br>
> Office: Calit2 Building Room 2402<br>
><br>
> OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado<br>
> ______________________________<wbr>_________________<br>
> Interop-wg mailing list<br>
> <a href="mailto:Interop-wg@lists.openstack.org">Interop-wg@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/interop-wg" rel="noreferrer" target="_blank">http://lists.openstack.org/<wbr>cgi-bin/mailman/listinfo/<wbr>interop-wg</a><br>
<br>
</div></div></blockquote></div><br><br clear="all"><div><br></div>-- <br><div class="gmail_signature" data-smartmail="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr">Zhipeng (Howard) Huang</div><div dir="ltr"><br></div><div dir="ltr">Standard Engineer</div><div>IT Standard & Patent/IT Prooduct Line</div><div dir="ltr">Huawei Technologies Co,. Ltd</div><div dir="ltr">Email: <a href="mailto:huangzhipeng@huawei.com" target="_blank">huangzhipeng@huawei.com</a></div><div dir="ltr">Office: Huawei Industrial Base, Longgang, Shenzhen</div><div dir="ltr"><br></div><div dir="ltr">(Previous)<br><div>Research Assistant</div><div>Mobile Ad-Hoc Network Lab, Calit2</div><div>University of California, Irvine</div><div>Email: <a href="mailto:zhipengh@uci.edu" target="_blank">zhipengh@uci.edu</a></div><div>Office: Calit2 Building Room 2402</div><div><br></div><div>OpenStack, OPNFV, OpenDaylight, OpenCompute Aficionado</div></div></div></div></div></div></div>
</div>