January 2019 - openstack-discuss - lists.openstack.org

[sahara][qa][api-sig]Support for Sahara APIv2 in tempest tests, unversioned endpoints
by Luigi Toscano 10 Jan '19

10 Jan '19

Hi all, I'm working on adding support for APIv2 to the Sahara tempest plugin. If I get it correctly, there are two main steps 1) Make sure that that tempest client works with APIv2 (and don't regress with APIv1.1). This mainly mean implementing the tempest client for Sahara APIv2, which should not be too complicated. On the other hand, we hit an issue with the v1.1 client in an APIv2 environment. A change associated with API v2 is usage of an unversioned endpoint for the deployment (see https://review.openstack.org/#/c/622330/ , without the /v1,1/$ (tenant_id) suffix) which should magically work with both API variants, but it seems that the current tempest client fails in this case: http://logs.openstack.org/30/622330/1/check/sahara-tests-tempest/7e02114/jo… Does anyone know if this is an issue with the code of the tempest tests (which should maybe have some logic to build the expected endpoint when it's unversioned, like saharaclient does) or somewhere else? 2) fix the tests to support APIv2. Should I duplicate the tests for APIv1.1 and APIv2? Other projects which supports different APIs seems to do this. But can I freely move the existing tests under a subdirectory (sahara_tempest_plugins/tests/api/ -> sahara_tempest_plugins/tests/api/v1/), or are there any compatibility concerns? Are the test ID enough to ensure that everything works as before? And what about CLI tests currently under sahara_tempest_plugin/tests/cli/ ? They supports both API versions through a configuration flag. Should they be duplicated as well? Ciao (and happy new year if you have a new one in your calendar!) -- Luigi

3 2

[ironic] [qa] ironic-tempest-plugin CI bloat
by Dmitry Tantsur 10 Jan '19

10 Jan '19

Hi all and happy new year :) As you know, tempest plugins are branchless, so the CI of ironic-tempest-plugin has to run tests on all supported branches. Currently it amounts to 16 (!) voting devstack jobs. With each of them have some small probability of a random failure, it is impossible to land anything without at least one recheck, usually more. The bad news is, we only run master API tests job, and these tests are changed more often that the other. We already had a minor stable branch breakage because of it [1]. We need to run 3 more jobs: for Pike, Queens and Rocky. And I've just spotted a missing master multinode job, which is defined but does not run for some reason :( Here is my proposal to deal with gate bloat on ironic-tempest-plugin: 1. Do not run CI jobs at all for unsupported branches and branches in extended maintenance. For Ocata this has already been done in [2]. 2. Make jobs running with N-3 (currently Pike) and older non-voting (and thus remove them from the gate queue). I have a gut feeling that a change that breaks N-3 is very likely to break N-2 (currently Queens) as well, so it's enough to have N-2 voting. 3. Make the discovery and the multinode jobs from all stable branches non-voting. These jobs cover the tests that get changed very infrequently (if ever). These are also the jobs with the highest random failure rate. 4. Add the API tests, voting for Queens to master, non-voting for Pike (as proposed above). This should leave us with 20 jobs, but with only 11 of them voting. Which is still a lot, but probably manageable. The corresponding change is [3], please comment here or there. Dmitry [1] https://review.openstack.org/622177 [2] https://review.openstack.org/621537 [3] https://review.openstack.org/627955

3 5

[neutron] [upgrade] No meeting on Jan. 10th
by Lujin Luo 10 Jan '19

10 Jan '19

Hi everyone, Due to some personal reasons, I cannot hold the meeting tomorrow. Let's resume next week. Thanks, Lujin

1 0

[blazar] Nominating Tetsuro Nakamura for blazar-core
by Pierre Riteau 10 Jan '19

10 Jan '19

Hello, I would like to nominate Tetsuro Nakamura for membership in the blazar-core team. Tetsuro started contributing to Blazar last summer. He has been contributing great code for integrating Blazar with placement and participating actively in the project. He is also providing good feedback to the rest of the contributors via code review, including on code not related to placement. He would make a great addition to the core team. Unless there are objections, I will add him to the core team in a week's time. Pierre

2 1

[nova][dev] spec freeze is today/tomorrow Jan 10
by melanie witt 10 Jan '19

10 Jan '19

Hey all, Spec freeze is today/tomorrow, depending on your time zone. We've been tracking specs that are close to approval here: https://etherpad.openstack.org/p/nova-stein-blueprint-spec-freeze Thanks everyone for jumping in and getting so much review done ahead of s-2! Please take one more look and let's get those final approvals done before spec freeze at EOD Jan 10. Best, -melanie

1 0

[openstack-dev] [neutron] Cancelling the L3 meeting on January 10th
by Miguel Lavalle 10 Jan '19

10 Jan '19

Dear Neutron team, Several members of the L3 sub-team are attending internal company meetings, have medical appointments or have other personal commitments at the time of the weekly meeting on January 10th. As a consequence, we are cancelling this meeting and will resume on the 17th. Best regards Miguel

1 0

[dev][goal][python3][qa][devstack][ptl] changing devstack's python 3 behavior
by Doug Hellmann 10 Jan '19

10 Jan '19

Today devstack requires each project to explicitly indicate that it can be installed under python 3, even when devstack itself is running with python 3 enabled. As part of the python3-first goal, I have proposed a change to devstack to modify that behavior [1]. With the change in place, when devstack runs with python3 enabled all services are installed under python 3, unless explicitly listed as not supporting python 3. If your project has a devstack plugin or runs integration or functional test jobs that use devstack, please test your project with the patch (you can submit a trivial change to your project and use Depends-On to pull in the devstack change). [1] https://review.openstack.org/#/c/622415/ -- Doug

4 9

[kayobe] IRC meetings
by Mark Goddard 09 Jan '19

09 Jan '19

Hi, The community has requested that we start holding regular IRC meetings for kayobe, and I agree. I suggest we start with meeting every other week, in the #openstack-kayobe channel. I've created a Doodle poll [1] with each hour between 2pm and 6pm UTC available every weekday. Please respond on the poll with your availability. Thanks, Mark [1] https://doodle.com/poll/6di3pddsahg6h66k

1 1

Re: Ironic ibmc driver for Huawei server
by Julia Kreger 09 Jan '19

09 Jan '19

Ironic does not have a deadline for merging specs. We will generally avoid landing large features the closer we get to the end of the cycle. If third party CI is up before the end of the cycle, I suspect it would just be a matter of iterating the driver code through review. You may wish to propose it sooner rather than later, and we can begin to give you feedback from there. -Julia On Tue, Jan 8, 2019 at 11:21 PM xmufive(a)qq.com <sokoban(a)foxmail.com> wrote: > > Hi Julia， > > When is the deadline of approving specs, I am afraid that huawei ibmc spec will be put off util next release. > > Thanks > Qianbiao NG > > > ------------------ 原始邮件 ------------------ > 发件人: "Julia Kreger"<juliaashleykreger(a)gmail.com>; > 发送时间: 2019年1月9日(星期三) 凌晨2:26 > 收件人: "xmufive(a)qq.com"<sokoban(a)foxmail.com>; > 抄送: "openstack-discuss"<openstack-discuss(a)lists.openstack.org>; > 主题: Re: Ironic ibmc driver for Huawei server > > Greetings Qianbiao.NG, > > Welcome to Ironic! > > The purpose and requirement of Third Party CI is to test drivers are > in working order with the current state of the code in Ironic and help > prevent the community from accidentally breaking an in-tree vendor > driver. Vendors do this by providing one or more physical systems in a > pool of hardware that is managed by a Zuul v3 or Jenkins installation > which installs ironic (typically in a virtual machine), and configures > it to perform a deployment upon the physical bare metal node. Upon > failure or successful completion of the test, the results are posted > back to OpenStack Gerrit. > > Ultimately this helps provide the community and the vendor with a > level of assurance in what is released by the ironic community. The > cinder project has a similar policy and I'll email you directly with > the contacts at Huawei that work with the Cinder community, as they > would be familiar with many of the aspects of operating third party > CI. > > You can find additional information here on the requirement and the > reasoning behind it: > > https://specs.openstack.org/openstack/ironic-specs/specs/approved/third-par… > > We may also be able to put you in touch with some vendors that have > recently worked on implementing third-party CI. I'm presently > inquiring with others if that will be possible. If you are able to > join Internet Relay Chat, our IRC channel (#openstack-ironic) has > several individual who have experience setting up and maintaining > third-party CI for ironic. > > Thanks, > > -Julia > > On Tue, Jan 8, 2019 at 8:54 AM xmufive(a)qq.com <sokoban(a)foxmail.com> wrote: > > > > Hi julia, > > > > According to the comment of story<https://storyboard.openstack.org/#!/story/2004635 >, > > 1. The spec for huawei ibmc drvier has been post here: https://storyboard.openstack.org/#!/story/2004635 , waiting for review. > > 2. About the third-party CI part, we provide mocked unittests for our driver's code. Not sure what third-party CI works for in this case. What else we should do? > > > > Thanks > > Qianbiao.NG

1 0

[Kolla] Queens for debian images
by Jan Vondra 09 Jan '19

09 Jan '19

Dear Kolla team, during project for one of our customers we have upgraded debian part of kolla project using a queens debian repositories (http://stretch-queens.debian.net/debian stretch-queens-backports) and we would like to share this work with community. I would like to ask what's the proper process of contributing since the patches affects both kolla and kolla-ansible repositories. Also any other comments regarding debian in kolla would be appriciated. Thanks, Jan Vondra Ultimum Technologies s.r.o. Na Poříčí 1047/26, 11000 Praha 1 Czech Republic http://ultimum.io

5 9