- openstack-discuss - lists.openstack.org

[nova] Change of interface in nova.virt.driver.ComputeDriver
by Jose Castro Leon 07 Mar '19

07 Mar '19

Dear all, In the context of the addition of online resizing of libvirt network volumes (RBD), we have added a new parameter in the extend_volume function. Although we have adapted all the drivers in nova codebase to support this new parameter, out of tree drivers could be affected by this change. This is the interface with the new parameter "requested_size" def extend_volume(self, connection_info, instance, requested_size): """Extend the disk attached to the instance. :param dict connection_info: The connection for the extended volume. :param nova.objects.instance.Instance instance: The instance whose volume gets extended. :param int requested_size The requested new size of the volume in bytes :return: None """ Here is the link with the change: https://review.openstack.org/#/c/613039/ Cheers, Jose Castro Leon CERN Cloud Infrastructure Service

1 0

[neutron] [upgrade] No meeting on Mar. 7th
by Lujin Luo 07 Mar '19

07 Mar '19

Hi team, We do not have much updates since last week. Let's skip this week's meeting and resume next week! Best regards, Lujin

1 0

[ptl][charms][election] Chris MacNaughton's candidacy for OpenStack Charms PTL
by Chris MacNaughton 07 Mar '19

07 Mar '19

Hello all, I would like to announce my candidacy for PTL of the OpenStack Charms project[1]. Through my time contributing to the OpenStack Charms project as a core team member, I have experienced working on many of the charms in both a bug-fix and new feature capacity. Additionally, I have made upstream contributions as needed. The OpenStack Charms project has an increasing community both consuming the charms, as well as contributing to them, and I think that it is important to actively nurture this community. In addition to our user community, it is important for OpenStack Charms members to integrate more widely in the wider OpenStack community. Some areas of focus for the Train cycle include: - Expanded functional test coverage - Evaluate the use of upstream gate functionality to run tests - Great progress was made in the Stein cycle towards improving our new test framework, and that should continue - New scope should be added to track features available in tooling, allowing tests of new features, such as cross-model relations (CMR) - Faster deployments - Tooling should be developed to track timings of deployments - Functional testing should be timed, allowing us to track and improve, resulting in less waiting to deploy a cloud - [Multi-cycle] Continue to explore possibilities and methodologies for Classic -> layered Reactive Charm migrations [1]: https://review.openstack.org/#/c/641571/ -- Chris MacNaughton

1 0

[dev][qa] Remove admin test_l3_agent_scheduler API test
by Ghanshyam Mann 07 Mar '19

07 Mar '19

Hello Everyone, Tempest test test_l3_agent_scheduler[1] is going to be removed in this patch[2]. We have the same test coverage in neutron-tempest-plugin [3] which is an appropriate place for this test. As per Tempest test removal process[4], I have pushed the patches to remove the usage of this test which seems more in doc or backlist files[5]. And this ML to notify about the test removal. Please let us know in case of any objection on this test removal. [1] http://git.openstack.org/cgit/openstack/tempest/tree/tempest/api/network/ad… [2] https://review.openstack.org/#/c/640767/ [3] http://git.openstack.org/cgit/openstack/neutron-tempest-plugin/tree/neutron… [4] https://docs.openstack.org/tempest/latest/REVIEWING.html#test-removal-and-r… [5] https://review.openstack.org/#/q/topic:remove_l3_agent_scheduler_tests+(sta… -gmann

1 0

[qa][ptl][election] Quality Assurance PTL Candidacy for Train
by Ghanshyam Mann 07 Mar '19

07 Mar '19

Hi Everyone, I would like to announce my candidacy for Quality Assurance PTL role for Train cycle. It was a great experience while serving QA PTL for the last two cycles. As QA team, we are keeping our pace of providing and maintaining the tooling for upstream stability. Though we have only few active resources in QA compare to the previous cycle, but I really appreciate the people who are still doing the QA contribution even in small extent. Upstream is not their first job in their organization now, but they do review, feedback which is really helpful. In Stein Cycle, we planned fewer items as compared to any previous cycle. Main focus or theme in Stein was to improve the document, stability and best practice for plugins, Stability of CLIs, Patrole Stable release. Many of the items are still in progress, and the team is trying their best to provide the more stable interfaces, and so does a stable gate. Another part we did in Stein is to migrating the gate jobs to Bionic, zuulv3 jobs are done, and legacy jobs are in progress. Overall it was a good cycle for QA, where we kept our flag high for any help required from any project side. But there are few things which I feel we should finish soon to make QA life little easy, - Stabilize the Tempest Plugins with correctly using stable interfaces. Few of such improvements are already in progress. In addition, few of ideas are: - service_availabiilty option setting and its usage. [bug# 1743688] - stable interface from plugins for cross project testing - CI/CD setup for all plugins doing for stable branches also - improvement in installation and setup of plugins by adding the dependent plugin in requirement.txt - Start RBAC testing via Patrole jobs on the project side gate. - Update and centralize the QA release process responsibilities and other todo tasks like distro migration etc. We do have release todo in wiki which we need to update as a more streamlined way or if we can automate few of them, - Encourage and mentor new contributors for QA contribution. This can be a good start for new contributors To learn about the projects. Starting from testing is always the first best place to learn about any software. All the momentum and activities rolling are motivating me to continue another term as QA PTL to explore and showcase more challenges. Thanks for reading and consideration my candidacy for Train cycle. -gmann

1 0

[ptl][freezer][election] It's time to add your candidacy for Freezer PTL
by Trinh Nguyen 07 Mar '19

07 Mar '19

Hi team, This week (5-12 Mar.) is for you to add your candidacy for Freezer PTL. Please follow this guide [1] to do that, (e.g, [2]). Bests, [1] https://governance.openstack.org/election/#how-to-submit-a-candidacy [2] https://review.openstack.org/#/c/641193/ -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

1 0

[ptl] [Cyborg] [election] Sundar Nadathur's candidacy for Cyborg PTL
by Nadathur, Sundar 07 Mar '19

07 Mar '19

Hello Stackers, I'd like to announce my candidacy for PTL role of Cyborg for the Train cycle. Cyborg got to a rolling start in 2018 led by Howard (Zhipeng) Huang. Under his leadership, we established the basic infrastructure for sustained growth, resulting in our official release in Rocky. During the Stein release, with Li Liu as the PTL, we have made substantial progress, particularly in defining a clean database schema and device model that will form the basis for future work. In both cycles, we had several illuminating discussions with Nova developers to define how Cyborg would interact with Nova. As we move forward, there is considerable potential in Cyborg, as evidenced by the interest shown by cloud/telco operators around the world. To realize this potential and deliver real-world use cases, here's what we'll aim to accomplish in the Train cycle: * Complete the integration with Nova, so that we can launch VMs with accelerators attached to them. * Enable consumption of accelerators either as raw devices or as offloaded functions. * Support a variety of devices, by enabling Cyborg drivers for them. * Lay the groundwork for features, such as performance monitoring and health monitoring, to enable usage in production. Thanks. Best Regards, Sundar Nadathur

3 2

[Cyborg] PTL Non-Candidacy
by Li Liu 07 Mar '19

07 Mar '19

Hi team, The PTL self-nomination is starting this week[0]. I want to announce that I will not be running for Cyborg PTL for next term. It's been a great pleasure to work as a PTL with you guys and I will continue being around as core contributor for the foreseeable future. [0] https://releases.openstack.org/stein/schedule.html#t-ptl-nominations -- Thank you Regards Li Liu

2 1

[oslo][ptl][election] PTL Candidacy
by Ben Nemec 06 Mar '19

06 Mar '19

I'm not putting my name in the subject because Oslo is all about reducing duplication and I'm quite certain every reasonable mail client already displays my name near the subject anyway. :-P Anyway, here's what I submitted to the election repo[0]: """ I am running for Oslo PTL in the Train cycle. I have been Oslo PTL for around a year now, and in that time we've been able to address a number of longstanding user requests, such as the removal of plaintext secrets from config files and a validator for config files. However, that doesn't mean our job is done. Here are some things I want to focus on for the next cycle: * Mentor new contributors. In the past cycle we had a number of our most experienced contributors pulled away to other projects, either in part or in total. The good news is we have some newer contributors who I believe can step in to fill those gaps. We need to make sure to help them along as much as possible. * Support cycle goals. In Stein we were able to add an Oslo library to make the goal implementation easier for all of the other OpenStack projects. We should continue to look for such opportunities with the new cycle goals for Train. * Storyboard migration. We've been discussing this pretty much since I became PTL, and I know some progress was made in Stein toward addressing some of my concerns with this. I think this is likely to be the cycle where we can go ahead with the move. * oslo.limit. I still very much want this to be a thing and will do whatever I can to help make it happen. I think that's it for now, but as always I am open to suggestions on things Oslo can do to make everyone's life easier. """ Thanks. -Ben 0: https://review.openstack.org/#/c/641503/

1 0

[neutron][devstack] Using git source for networking devstack based jobs
by Boden Russell 06 Mar '19

06 Mar '19

If your networking project uses required projects (aka "Siblings") [1], please read on. It's recently come to our attention [2][3][4] that some required networking projects are not being pulled from git source in devstack based jobs. As a result, a number of networking gate jobs were impacted [3]. While we have a short term fix in place, it doesn't solve the issue longer term. Today it's still not clear why some dependencies are coming from source and others aren't [2]. However, before digging deeper, we should probably step back and ensure we are heading down the right path. The question is; do we want these devstack jobs using their dependencies from git source, or should they be using tagged branches/releases of them instead?? Using git source seems to increase development velocity; not having to wait/coordinate on a tagged dependency, but at the same time it's also a moving target. My personal vote is to use git source; it will help maintain the velocity of neutron-lib and other cross-project efforts. It would be helpful to get some feedback from the other networking teams on what approach they think would work best. Thanks [1] https://docs.openstack.org/infra/manual/zuulv3.html#installation-of-sibling… [2] https://bugs.launchpad.net/devstack/+bug/1817555 [3] https://bugs.launchpad.net/tricircle/+bug/1816644 [4] http://lists.openstack.org/pipermail/openstack-discuss/2019-February/003010…

3 6