- openstack-discuss - lists.openstack.org

[horizon] team meeting cancelled in the holiday season
by Akihiro Motoki 21 Dec '19

21 Dec '19

Hi, Horizon team cancel the team meetings at Dec 25, 2019 and Jan 1, 2020. See you all in new year and enjoy holidays! Thanks, Akihiro Motoki (irc: amotoki)

1 0

State of the Gate
by Matt Riedemann 20 Dec '19

20 Dec '19

Things are great! Surprise! I just wanted to let everyone know. Later! . . . . . Now that you've been tricked, on Halloween no less, I'm here to tell you that things suck right now. This is your periodic digest of issues. Grab some fun-sized candy bars and read on. I think right now we have three major issues. 1. http://status.openstack.org/elastic-recheck/index.html#1763070 This has resurfaced and I'm not sure why, nor do I think we ever had a great handle on what is causing this or how to work around it so if anyone has new ideas please chip in. 2. http://status.openstack.org/elastic-recheck/index.html#1844929 I've done some digging into this one and my notes are in the bug report. It mostly affects grenade jobs but is not entirely restricted to grenade jobs. It's also mostly on OVH and FortNebula nodes but not totally. From looking at the mysql logs in the grenade jobs, mysqld is (re)started three times. I think (1) for initial package install, (2) for stacking devstack on the old side, and (3) for stacking devstack on the new side. After the last restart, there are a lot of aborted connection messages in the msyql error log. It's around then that grenade is running post-upgrade smoke tests to create a server and the nova-scheduler times out communicating with the nova_cell1 database. I have a few patches up to grenade/devstack [1] to try some things and get more msyql logs but so far they aren't really helpful. We need someone with some more mysql debugging experience to help here, maybe zzzeek or mordred? 3. CirrOS guest SSH issues There are several (some might be duplicates): http://status.openstack.org/elastic-recheck/index.html#1848078 http://status.openstack.org/elastic-recheck/index.html#1808010 (most hits) http://status.openstack.org/elastic-recheck/index.html#1463631 http://status.openstack.org/elastic-recheck/index.html#1849857 http://status.openstack.org/elastic-recheck/index.html#1737039 http://status.openstack.org/elastic-recheck/index.html#1840355 http://status.openstack.org/elastic-recheck/index.html#1843610 A few notes here. a) We're still using CirrOS 0.4.0 since Stein: https://review.opendev.org/#/c/521825/ And that image was published nearly 2 years ago and there are no newer versions on the CirrOS download site so we can't try a newer image to see if that fixes things. b) Some of the issues above are related to running out of disk in the guest. I'm not sure what is causing that, but I have posted a devstack patch that is related: https://review.opendev.org/#/c/690991 tl;dr before Stein the tempest flavors we used had disk=0 so nova would fit the root disk to the size of the image. Since Stein the tempest flavors specify root disk size (1GiB for the CirrOS images). My patch pads an extra 1GiB to the root disk on the tempest flavors. One side effect of that is the volumes tempest creates will go from 1GiB to 2GiB which could be a problem if a lot of tempest volume tests run at the same time, though we do have a volume group size of 24GB in gate runs so I think we're OK for now. I'm not sure my patch would help, but it's an idea. As for the other key generation and dhcp lease failures, I don't know what to do about those. We need more eyes on these issues to generate some ideas or see if we're doing something wrong in our tests, e.g. generating too much data for the config drive? Not using config drive in some cases? Metadata API server is too slow (note we cache the metadata since [2])? Other ideas on injecting logs for debug? [1] https://review.opendev.org/#/q/topic:bug/1844929+status:open [2] https://review.opendev.org/#/q/I9082be077b59acd3a39910fa64e29147cb5c2dd7 -- Thanks, Matt

7 23

Is there a limit on the number of VMs returned by "openstack server list --all-projects" ?
by Albert Braden 20 Dec '19

20 Dec '19

2 4

[fuel][fuel-ccp] Retire Fuel and fuel-ccp repositories
by Andreas Jaeger 20 Dec '19

20 Dec '19

The fuel project has been removed from from OpenStack in 2017 and has no action for some time, the fuel-ccp repositories are dead as well. I've talked with Sergey from Mirantis and he confirmed now that those can be retired. I'll take care of retiring these repositories now and will retire all fuel repos in OpenStack namespace as well as the fuel-ccp repositories in the x namespace. I'll use topic retire-fuel for the changes, Andreas P.S. full list of repos: openstack/fuel-agent openstack/fuel-astute openstack/fuel-dev-tools openstack/fuel-devops openstack/fuel-docs openstack/fuel-library openstack/fuel-main openstack/fuel-menu openstack/fuel-mirror openstack/fuel-nailgun-agent openstack/fuel-nailgun-extension-cluster-upgrade openstack/fuel-nailgun-extension-converted-serializers openstack/fuel-nailgun-extension-iac openstack/fuel-octane openstack/fuel-ostf openstack/fuel-plugin-murano openstack/fuel-plugin-murano-tests openstack/fuel-plugins openstack/fuel-qa openstack/fuel-specs openstack/fuel-stats openstack/fuel-ui openstack/fuel-upgrade openstack/fuel-virtualbox openstack/fuel-web openstack/python-fuelclient x/fuel-ccp x/fuel-ccp-ceph x/fuel-ccp-ci-config x/fuel-ccp-cinder x/fuel-ccp-debian-base x/fuel-ccp-designate x/fuel-ccp-elasticsearch x/fuel-ccp-entrypoint x/fuel-ccp-etcd x/fuel-ccp-galera x/fuel-ccp-glance x/fuel-ccp-grafana x/fuel-ccp-heat x/fuel-ccp-horizon x/fuel-ccp-installer x/fuel-ccp-ironic x/fuel-ccp-keystone x/fuel-ccp-mariadb x/fuel-ccp-memcached x/fuel-ccp-murano x/fuel-ccp-neutron x/fuel-ccp-nginx x/fuel-ccp-nova x/fuel-ccp-openstack-base x/fuel-ccp-rabbitmq x/fuel-ccp-rally x/fuel-ccp-sahara x/fuel-ccp-searchlight x/fuel-ccp-specs x/fuel-ccp-stacklight x/fuel-ccp-tests x/fuel-ccp-zmq -- Andreas Jaeger aj(a)suse.com Twitter: jaegerandi SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D 90409 Nürnberg (HRB 36809, AG Nürnberg) GF: Felix Imendörffer GPG fingerprint = EF18 1673 38C4 A372 86B1 E699 5294 24A3 FF91 2ACB

2 9

[kolla] broken images pushed
by Marcin Juszkiewicz 20 Dec '19

20 Dec '19

We have merged publisher for aarch64 images and it turned out that it was done wrong way. Today both x86-64 and aarch64 images got published at same time so "kolla/debian-source-*" images are broken: 08:55 (0s) hrw@puchatek:~$ docker run --rm -it kolla/debian-source-heat-engine:master bash standard_init_linux.go:211: exec user process caused "exec format error" This is result of aarch64 image overwriting x86-64 one. We reverted arm64 publisher and will work on it in January. Sorry for potential problem.

1 1

[Horizon][Designate][Tacker][Tobiko][OSH][Ironic] Flaky jobs and retries
by Clark Boylan 20 Dec '19

20 Dec '19

Hello, Zuulv3 has a feature where it will rerun jobs that it thinks failed due to infrastructure problems up to some configured limit. For us the limit is 3 job attempts. The circumstances where Zuul thinks it has infrastructure issues are when pre-run playbooks fail (because these are expected to be stable), and when Ansible returns with an exit code signifying network connectivity issues. Recently I updated Zuul to report the job attempt in job inventories and am using that to report this data into logstash and elasticsearch. Now I can use queries like: 'zuul_attempts:"3" AND filename:"job-output.txt" AND message:"Job console starting"' to see which jobs are flaky and reattempting. I'm writing this email to report on some of what I've found in the hopes that the problems we have can be fixed and hopefully result in better jobs across the board. Designate Horizon Dashboard The nodejs jobs for stable/rocky expect to run against nodejs4 but run on Bionic which has no nodejs 4 packaging. This causes the pre-run to fail as it cannot install the requested package, https://zuul.opendev.org/t/openstack/build/498ebb052e2b4a3393b0939820ee8927…. Fix in progress here, https://review.opendev.org/#/c/699241/1, to pin to Xenial. Thank you! Horizon projects and dashboards may want to double check they don't have similar problems with nodejs version and node mismatches. Tacker tacker-functional-devstack-multinode-python3 (and possibly other tacker devstack jobs) attempt to download an openwrt image during devstack runs and the server isn't responding. This fails in pre-run, http://zuul.openstack.org/build/27ff514c77724250968d60469923f613/log/contro…, and results in the job being retried. I am not aware of a fix for this, but you'll likely need to find a new image host. Let the infra team know if we can help. Tobiko tobiko-devstack-faults-centos-7 is failing because this job runs on CentOS 7 using python2 but Nova needs python3.6 now. This fails in pre-run, https://zuul.opendev.org/t/openstack/build/8071780e7ba748169b447f1d42e069fc…, and forces the job to be rerun. I'm not sure what the best fix is here. Maybe run your jobs on Ubuntu until CentOS 8 is supported by devstack? OpenStack Helm Ansible has decided that become_user is not valid on include_role tasks. https://opendev.org/openstack/openstack-helm-infra/src/branch/master/roles/… seems to be the issue. This causes Airship's deckhand functional docker jobs to fail in pre-run, https://zuul.opendev.org/t/openstack/build/7493038ee1744465b2387b44e067d029…, and the jobs are retried. It is possible this is fallout from Zuul's default ansible version being bumped to 2.8 from 2.7. This also seems to affect OSH's kubernetes keystone auth job, https://zuul.opendev.org/t/openstack/build/68d937b3e5e3449cb6fe2e6947bbf0db… Ironic The Ironic example is a bit different and runs into some fun Ansible behaviors. Ironic's IPA multinode jobs (possibly others too) are filling the root disk of the test nodes on some clouds, http://paste.openstack.org/show/787641/. Ansible uses /tmp to bootstrap its ssh connectivity and when /tmp is on / and / is full that results in Ansible returning a network failure error code. This then causes Zuul to rerun the job. Unfortunately because Ansible thinks networking is broken we have to do special things in a Zuul cleanup playbook to double check disk usage and that info is only available on the Zuul executors. But I've double checked for you and can confirm this is what is happening. The fix here is to use the ephemeral disk which is mounted on /opt and contains much more disk space. Another option would be to reduce the size of Ironic's fake baremetal images. In any case they are aware of this and we should expect a fix soon. There are likely more cases I haven't found yet, but I wanted to point out this Zuul behavior to people. The intent is that it handle exceptional cases and not paper over failures that happen often or even 100% of the time. We should do our best to fix these problems when they pop up. Thank you to everyone that has already stepped up to help fix some of these! Clark

2 2

[glance] no meeting on 26 December 2019
by Abhishek Kekane 20 Dec '19

20 Dec '19

As discussed during yesterday's meeting, we will not hold the glance weekly meeting on 26th December 2019. The next meeting will be on 2 January 2020. Wish you all a happy christmas and new year in advance. Thanks & Best Regards, Abhishek Kekane

1 0

[ironic] - automated cleaning
by fsbiz＠yahoo.com 20 Dec '19

20 Dec '19

We have enabled automatic cleaning and I have noticed that our UEFI enabled nodes most often end up in "clean failed" state. Basic troubleshooting reveals that PXE correctly boots IPXE, but the IPXE goes and boots the OS instead of downloading the deployed_kernel / ramdisk. Here's the timeline of events.Dec 18 12:19:39 sc-ironic04 Node 56e58642-12ac-4455-bc95-2a328198f845 moved to provision state "cleaning"Dec 18 12:20:32 sc-ironic04 Successfully set node 56e58642-12ac-4455-bc95-2a328198f845 power state to power onDec 18 12:21:14 DHCPACK(ns-601d0738-39) 10.33.23.7 6c:b3:11:4f:8b:18 (PXE Boot gets IP: 10.33.23.7)Dec 18 12:21:15 sc-ironic04 in.tftpd[367896]: Client 10.33.23.7 finished ipxe_x86_64.efi (TFTP of IPXE is complete)Dec 18 12:21:23 DHCPACK(ns-261f35c5-7e) 10.33.23.7 6c:b3:11:4f:8b:18 host-10-33-23-7 (IPXE acquires IP: 10.33.23.7)NO HTTP request for deploy_kernel Instead:Dec 18 12:22:40 sc-control04 dnsmasq-dhcp[3508449]: 3990148443 DHCPREQUEST(ns-261f35c5-7e) 10.33.22.188 6c:b3:11:4f:8b:18Dec 18 12:22:40 sc-control04 dnsmasq-dhcp[3508449]: 3990148443 DHCPNAK(ns-261f35c5-7e) 10.33.22.188 6c:b3:11:4f:8b:18 wrong address When the OS was running it had IP address of 10.33.22.188. The OS came up and tries to renew its lease for 10.33.22.188 which was NAKed by the DHCP server. The OS then did a full DHCP (DISCOVER, etc.), got a valid IP address, did a cloud-init, etc. Is this a known issue that has been fixed ? Any pointers would be appreciated. thanks,Farad.

1 0

[magnum] Next weekly team meeting will be on 22 Jan 2020
by Feilong Wang 19 Dec '19

19 Dec '19

Hi team, We just had a good year and we deserve some rest. We will skip some meetings and the next one will be on 22 Jan 2020. Hope you all will have a merry Christmas and happy New Year. -- Cheers & Best regards, Feilong Wang (王飞龙) Head of R&D Catalyst Cloud - Cloud Native New Zealand -------------------------------------------------------------------------- Tel: +64-48032246 Email: flwang(a)catalyst.net.nz Level 6, Catalyst House, 150 Willis Street, Wellington --------------------------------------------------------------------------

1 0

[qa][nova][cinder] ceph job has been busted on stable/pike for awhile, fix or delete?
by Matt Riedemann 19 Dec '19

19 Dec '19

The ceph job on stable/pike has been broken for awhile [1]. The fix to make devstack-plugin-ceph (which is branchless) work on stable/pike depends on this devstack change on stable/pike to introduce the TARGET_BRANCH variable [2]. Question is, can we move [2] forward? If not, I make a motion that we drop ceph jobs from stable/pike (and likely stable/ocata if we are still running them there) because they won't work. The ceph job is non-voting anyway so that's why it goes unnoticed for so long when it's broken. If we aren't going to fix this stuff we shouldn't be wasting CI resources running broken jobs. Did I mention that you should all get off my lawn? :) [1] https://bugs.launchpad.net/devstack-plugin-ceph/+bug/1835627 [2] https://review.opendev.org/#/c/684756/ -- Thanks, Matt

5 7

[API SIG] holiday office hours
by Michael McCune 19 Dec '19

19 Dec '19

the API SIG will be closing it's office hours until the new year. have a peaceful and joyous holiday season and new years =) peace o/

1 0

[blazar] IRC meetings cancelled during the holidays
by Pierre Riteau 19 Dec '19

19 Dec '19

Hello, The Blazar IRC meetings of December 24, December 31, and January 2 are cancelled. The next meeting will be on Tuesday, January 7. Have a great holiday, Pierre

1 0

[manila] no weekly meeting 26 December 2019
by Tom Barron 19 Dec '19

19 Dec '19

Just noting that there will be no weekly Manila meeting 26 December. We'll next meet at the scheduled time, 1500 UTC, on freenode #openstack-meeting-alt, on 2 January 2020. [1] See you in the New Year, or in #openstack-manila in the mean time! -- Tom Barron [1] https://wiki.openstack.org/wiki/Manila/Meetings

1 0

CfP VHPC20: HPC Containers-Kubernetes
by VHPC 20 19 Dec '19

19 Dec '19

==================================================================== CALL FOR PAPERSa 15th Workshop on Virtualization in High-Performance Cloud Computing (VHPC 20) held in conjunction with the International Supercomputing Conference - High Performance, June 21-25, 2020, Frankfurt, Germany. (Springer LNCS Proceedings) ==================================================================== Date: June 25, 2020 Workshop URL: vhpc[dot]org Abstract registration Deadline: Jan 31st, 2020 Paper Submission Deadline: Apr 05th, 2020 Springer LNCS Call for Papers Containers and virtualization technologies constitute key enabling factors for flexible resource management in modern data centers, and particularly in cloud environments. Cloud providers need to manage complex infrastructures in a seamless fashion to support the highly dynamic and heterogeneous workloads and hosted applications customers deploy. Similarly, HPC environments have been increasingly adopting techniques that enable flexible management of vast computing and networking resources, close to marginal provisioning cost, which is unprecedented in the history of scientific and commercial computing. Most recently, Function as a Service (Faas) and Serverless computing, utilizing lightweight VMs-containers widens the spectrum of applications that can be deployed in a cloud environment, especially in an HPC context. Here, HPC-provided services can be become accessible to distributed workloads outside of large cluster environments. Various virtualization-containerization technologies contribute to the overall picture in different ways: machine virtualization, with its capability to enable consolidation of multiple underutilized servers with heterogeneous software and operating systems (OSes), and its capability to live-migrate a fully operating virtual machine (VM) with a very short downtime, enables novel and dynamic ways to manage physical servers; OS-level virtualization (i.e., containerization), with its capability to isolate multiple user-space environments and to allow for their coexistence within the same OS kernel, promises to provide many of the advantages of machine virtualization with high levels of responsiveness and performance; lastly, unikernels provide for many virtualization benefits with a minimized OS/library surface. I/O Virtualization in turn allows physical network interfaces to take traffic from multiple VMs or containers; network virtualization, with its capability to create logical network overlays that are independent of the underlying physical topology is furthermore enabling virtualization of HPC infrastructures. Publication Accepted papers will be published in a Springer LNCS proceedings volume. Topics of Interest The VHPC program committee solicits original, high-quality submissions related to virtualization across the entire software stack with a special focus on the intersection of HPC, containers-virtualization and the cloud. Major Topics: - HPC workload orchestration (Kubernetes) - Kubernetes HPC batch - HPC Container Environments Landscape - HW Heterogeneity - Container ecosystem (Docker alternatives) - Networking - Lightweight Virtualization - Unikernels / LibOS - State-of-the-art processor virtualization (RISC-V, EPI) - Containerizing HPC Stacks/Apps/Codes: Climate model containers each major topic encompassing design/architecture, management, performance management, modeling and configuration/tooling. Specifically, we invite papers that deal with the following topics: - HPC orchestration (Kubernetes) - Virtualizing Kubernetes for HPC - Deployment paradigms - Multitenancy - Serverless - Declerative data center integration - Network provisioning - Storage - OCI i.a. images - Isolation/security - HW Accelerators, including GPUs, FPGAs, AI, and others - State-of-practice/art, including transition to cloud - Frameworks, system software - Programming models, runtime systems, and APIs to facilitate cloud adoption - Edge use-cases - Application adaptation, success stories - Kubernetes Batch - Scheduling, job management - Execution paradigm - workflow - Data management - Deployment paradigm - Multi-cluster/scalability - Performance improvement - Workflow / execution paradigm - Podman: end-to-end Docker alternative container environment & use-cases - Creating, Running containers as non-root (rootless) - Running rootless containers with MPI - Container live migration - Running containers in restricted environments without setuid - Networking - Software defined networks and network virtualization - New virtualization NICs/Nitro alike ASICs for the data center? - Kubernetes SDN policy (Calico i.a.) - Kubernetes network provisioning (Flannel i.a.) - Lightweight Virtualization - Micro VMMs (Rust-VMM, Firecracker, solo5) - Xen - Nitro hypervisor (KVM) - RVirt - Cloud Hypervisor - Unikernels / LibOS - HPC Storage in Virtualization - HPC container storage - Cloud-native storage - Hypervisors in storage virtualization - Processor Virtualization - RISC-V hypervisor extensions - RISC-V Hypervisor ports - EPI - Composable HPC microservices - Containerizing Scientific Codes - Building - Deploying - Securing - Storage - Monitoring - Use case for containerizing HPC codes: Climate model containers for portability, reproducibility, traceability, immutability, provenance, data & software preservation The Workshop on Virtualization in High-Performance Cloud Computing (VHPC) aims to bring together researchers and industrial practitioners facing the challenges posed by virtualization in order to foster discussion, collaboration, mutual exchange of knowledge and experience, enabling research to ultimately provide novel solutions for virtualized computing systems of tomorrow. The workshop will be one day in length, composed of 20 min paper presentations, each followed by 10 min discussion sections, plus lightning talks that are limited to 5 minutes. Presentations may be accompanied by interactive demonstrations. Important Dates Jan 31st, 2020 - Abstract Apr 5th, 2020 - Paper submission deadline (Springer LNCS) Apr 26th, 2020 - Acceptance notification June 25th, 2020 - Workshop Day July 10th, 2020 - Camera-ready version due Chair Michael Alexander (chair), BOKU, Vienna, Austria Anastassios Nanos (co-chair), Sunlight.io, UK Program committee Stergios Anastasiadis, University of Ioannina, Greece Paolo Bonzini, Redhat, Italy Jakob Blomer, CERN, Europe Eduardo César, Universidad Autonoma de Barcelona, Spain Taylor Childers, Argonne National Laboratory, USA Stephen Crago, USC ISI, USA Tommaso Cucinotta, St. Anna School of Advanced Studies, Italy François Diakhaté CEA DAM Ile de France, France Kyle Hale, Northwestern University, USA Brian Kocoloski, Washington University, USA John Lange, University of Pittsburgh, USA Giuseppe Lettieri, University of Pisa, Italy Klaus Ma, Huawei, China Alberto Madonna, Swiss National Supercomputing Center, Switzerland Nikos Parlavantzas, IRISA, France Anup Patel, Western Digital, USA Kevin Pedretti, Sandia National Laboratories, USA Amer Qouneh, Western New England University, USA Carlos Reaño, Queen’s University Belfast, UK Adrian Reber, Redhat, Germany Riccardo Rocha, CERN, Europe Borja Sotomayor, University of Chicago, USA Jonathan Sparks, Cray, USA Kurt Tutschku, Blekinge Institute of Technology, Sweden John Walters, USC ISI, USA Yasuhiro Watashiba, Osaka University, Japan Chao-Tung Yang, Tunghai University, Taiwan Paper Submission-Publication Papers submitted to the workshop will be reviewed by at least two members of the program committee and external reviewers. Submissions should include abstract, keywords, the e-mail address of the corresponding author, and must not exceed 10 pages, including tables and figures at a main font size no smaller than 11 point. Submission of a paper should be regarded as a commitment that, should the paper be accepted, at least one of the authors will register and attend the conference to present the work. Accepted papers will be published in a Springer LNCS volume. The format must be according to the Springer LNCS Style. Initial submissions are in PDF; authors of accepted papers will be requested to provide source files. Abstract, Paper Submission Link: edas[dot]info/newPaper.php?c=26973 Lightning Talks Lightning Talks are non-paper track, synoptical in nature and are strictly limited to 5 minutes. They can be used to gain early feedback on ongoing research, for demonstrations, to present research results, early research ideas, perspectives and positions of interest to the community. Submit abstract via the main submission link. General Information The workshop is one day in length and will be held in conjunction with the International Supercomputing Conference - High Performance (ISC) 2019, June 21-25, Frankfurt, Germany.

1 0

[neutron] PTL on PTO
by Slawek Kaplonski 19 Dec '19

19 Dec '19

Hi, I will be on PTO from Friday 20.12.2019 up to 6.01.2020. I will probably not be available on IRC for most of the time but I will be checking emails from time to time. So if You have anything important, please email me. — Slawek Kaplonski Senior software engineer Red Hat

1 0

[neutron]CI meeting cancelled
by Slawek Kaplonski 19 Dec '19

19 Dec '19

Hi, Our Neutron CI meetings which should be on 24.12.2019 and 31.12.2019 will be cancelled. See You all in new year :) Have a great holiday time. — Slawek Kaplonski Senior software engineer Red Hat

1 0

[neutron] Team meeting cancelled
by Slawek Kaplonski 19 Dec '19

19 Dec '19

Hi, Our Neutron team meetings which should be on 23.12.2019 and 31.12.2019 will be cancelled. See You all in new year :) Have a great holiday time. — Slawek Kaplonski Senior software engineer Red Hat

1 0

[keystone] No meetings over the holidays
by Colleen Murphy 19 Dec '19

19 Dec '19

As discussed at yesterday's meeting, we'll cancel keystone team meetings for the next two weeks for the winter holidays. The next keystone meeting will be Tuesday, January 7 (17:00 UTC, #openstack-meeting-alt). Colleen

1 0

[resource-management-sig] Status of the "Resource Management" SIG
by Thierry Carrez 19 Dec '19

19 Dec '19

Hi, I was wondering about the status of the Resource Management SIG... It's been "forming" according to https://wiki.openstack.org/wiki/Res_Mgmt_SIG since January 2018... And I could'nt find a reference or log to any meeting after that. Does anyone have updated status on this one? Should it be removed from the list of active SIGs at https://governance.openstack.org/sigs/ ? -- Thierry Carrez (ttx)

5 6

[bifrost][ironic][kayobe][kolla][requirements] Kayobe CI breakage following ironic-lib release
by Pierre Riteau 19 Dec '19

19 Dec '19

Hello, I have been looking into CI failures that started impacting Kayobe today on the master branch, just as we're planning to branch stable/train this week (Kayobe is cycle trailing). Our seed jobs are failing because ironic doesn't start correctly [1]. The traceback shows that it is using code from the latest ironic-lib (3.0.0) which was released just last week [2] and dropped Python 2 compatibility. We're using Kolla Train images [3], but the latest kolla/centos-source-bifrost-deploy:train includes Bifrost 7.0.0 which fetches all its dependencies using Git master branches [4]. This only got changed later on stable/train [5], but there is no newer 7.x release. One of these dependencies is the requirements repo, which has just bumped the upper constraint for ironic-lib to 3.0.0 [6]. I believe this is what caused our jobs to start failing today. So I think we need: - a 7.0.1 release of Bifrost - an update of Kolla to use this release instead of 7.0.0 Would the ironic and kolla project teams be willing to help with this to fix our gate? Thanks a lot. [1] https://dafcf7323a7c828b67e0-814491f7a8e968b50eeaf14b0c7f115f.ssl.cf1.rackc… [2] https://review.opendev.org/#/c/698500/ [3] https://dafcf7323a7c828b67e0-814491f7a8e968b50eeaf14b0c7f115f.ssl.cf1.rackc… [4] https://opendev.org/openstack/bifrost/src/tag/7.0.0/playbooks/roles/bifrost… [5] https://review.opendev.org/#/q/I3005fc59d6c5e1f5000874342f956977d9929907 [6] https://review.opendev.org/#/c/698981/

2 4

[ironic] ibmc driver
by Julia Kreger 18 Dec '19

18 Dec '19

Greetings fellow ironicans and stackers! I'd like some thoughts on the `ibmc` driver[1] that was added early this year. Specifically it merged into ironic with an operating Third-Party CI, however soon after a series of unfortunate events occurred where the Third-Party CI stopped reporting sometime in early May, and shortly their after restrictions were put into place[2]. With that being said, I feel like we should go ahead and remove this driver since it does not seem to be maintained nor tested. -Julia [1]: https://review.opendev.org/#/c/639288/ [2]: https://www.federalregister.gov/documents/2019/05/21/2019-10616/addition-of…

3 4

[fuel] fuel-plugins, x/network-checker, x/fuel-noop-fixtures retirement
by Andreas Jaeger 18 Dec '19

18 Dec '19

Since we have now the fuel repositories retired, I propose to retire the fuel repos in the x/ namespace as well: all the plugins, network-checker and fuel-noop-fixuters There was no single merge to them since October 2017 (with exception of Ian's force-merge of URL replacements), see https://review.opendev.org/#/q/(projects:x/fuel-plugin+OR+project:x/network… I will push changes to repositories and would appreciate if teams merge them and abandon all open reviews. If anybody wants to keep the repos, please speak up here and/or -1 my changes. I'll use topic retire-x-fuel, https://review.opendev.org/#/q/topic:retire-x-fuel I'll just propose changes for now, we'll force-merge them in January 2020, Andreas -- Andreas Jaeger aj(a)suse.com Twitter: jaegerandi SUSE Software Solutions Germany GmbH, Maxfeldstr. 5, D 90409 Nürnberg (HRB 36809, AG Nürnberg) GF: Felix Imendörffer GPG fingerprint = EF18 1673 38C4 A372 86B1 E699 5294 24A3 FF91 2ACB

1 0

[cinder] next meeting 8 January 2020
by Brian Rosmaita 18 Dec '19

18 Dec '19

As discussed during today's meeting, we will *not* hold the Cinder weekly meeting over the next 2 weeks. The next meeting will be on 8 January 2020. https://etherpad.openstack.org/p/cinder-ussuri-meetings cheers, brian

1 0

[tripleo] Gate is unstable, do not recheck/approve anything now
by Emilien Macchi 18 Dec '19

18 Dec '19

We're encountering a bug in TripleO, see https://bugs.launchpad.net/tripleo/+bug/1856864 In the meantime please do not recheck or approve a patch, the gate is already fully loaded; we'll purge it, fix the bug and recheck what needs to be done. You can follow the progress of that work on our IRC channel #tripleo. Thanks for your patience. -- Emilien Macchi

1 0

[neutron] Cancle neutron L3 meeting
by LIU Yulong 18 Dec '19

18 Dec '19

Hi all, Due to some local reasons, I'm not be able to host the L3 meeting today. So let's cancel it. And also because contributors from most countries will have the Christmas and new year's holidays in the next two weeks, let's also cancel the following two L3 meetings. So the next L3 meeting will be raised on 8th Jan, 2020. OK, see you guys then.  And happy new year! Regards, LIU Yulong

1 0

[kolla][horizon] Get 503 Service unavailable after set RETRIEVE_PASSWORD.
by Eddie Yen 18 Dec '19

18 Dec '19

Hi, Below is the information about this environment. Openstack release: Rocky Kolla container source type: binary OS distro: Ubuntu 18.04 We tried to set OPENSTACK_ENABLE_PASSWORD_RETRIEVE to True in local_settings, but the dashboard got "503 Service Unavailable" after restart the Horizon container. And there's no error log or something in horizon.log Is there anyway to see what's going on? - Eddie

2 2

[openstack-dev][kuryr] Unable to connect to kube-apiserver
by Veera.reddy B 18 Dec '19

18 Dec '19

Hi , I install Kubernetes using "kubeadm init". Followed below link to install "kuryr-kubernetes". https://docs.openstack.org/kuryr-kubernetes/latest/installation/manual.html… Kube api configuration : /etc/kubernetes/manifests/kube-apiserver.yaml http://paste.openstack.org/show/787704/ kuryr config file : /etc/kuryr/kuryr.conf http://paste.openstack.org/show/787705/ Error while starting kuryr : #> kuryr-k8s-controller --config-file /etc/kuryr/kuryr.conf http://paste.openstack.org/show/787706/ Let me what I am missing in "/etc/kuryr/kuryr.conf" Thanks, Veera.

2 1

[openstack-dev][kuryr] Unable to connect to kube-apiserver
by VeeraReddy 18 Dec '19

18 Dec '19

Hi , I install Kubernetes using “kubeadm init”. Followed below link to install “kuryr-kubernetes”. https://docs.openstack.org/kuryr-kubernetes/latest/installation/manual.html… Kube api configuration : /etc/kubernetes/manifests/kube-apiserver.yaml http://paste.openstack.org/show/787704/ kuryr config file : /etc/kuryr/kuryr.conf http://paste.openstack.org/show/787705/ Error while starting kuryr : #> kuryr-k8s-controller--config-file /etc/kuryr/kuryr.conf http://paste.openstack.org/show/787706/ Let me what I am missing in “/etc/kuryr/kuryr.conf” Thanks, Veera.

1 0

[scientific-sig] No IRC meeting today
by Stig Telfer 18 Dec '19

18 Dec '19

Hi All - Apologies, in the rush to end of year we have no agenda items for today. Given the season, I suggest we reconvene with a fresh start on Tuesday 7th January 2020. Cheers, Stig

1 0

[Watcher]IRC meeting at 8:00 UTC today
by licanwei 18 Dec '19

18 Dec '19

1 0

[nova][ironic] need help understanding 'cpu_arch' in nova ironic driver
by melanie witt 18 Dec '19

18 Dec '19

Hey all, Recently I'm trying to figure out how to fulfill a use case in the nova ironic driver around treating an ironic node's 'cpu_arch' as optional. This is coming up as a result of a downstream issue [1] and recent change on the ironic side [2] to make cpu_arch optional for iscsi deployments. The change makes it so that ironic will _not_ include a 'cpu_arch' attribute as part of a node's properties if iscsi. On the nova side, we have a filter scheduler ImagePropertiesFilter which will only match a node if the architecture, hypervisor_type, and vm_mode in the glance image properties match the cpu_arch of the node. We have always pulled the cpu_arch of the from the ironic node properties since the original ironic driver code was added to nova. Now, the use case I'm trying to solve today [3] is where an iscsi ironic deployment has no cpu_arch specified on the ironic side and the deployer wants to use glance images with architecture specified in their image properties. Today (and historically always) the request to create an instance in this situation will fail with NoValidHost because the nova ironic driver could not determine a cpu_arch from the ironic node. My questions are: * Is this a valid thing to want to do? * If if is valid, what is the correct way that we should handle missing cpu_arch in the nova ironic driver? Should we guess at a default cpu_arch? If so, how? Or should we add a new config option where a default cpu_arch can be specified? Or, other? Thanks in advance for any input you can offer. Cheers, -melanie [1] https://bugzilla.redhat.com/show_bug.cgi?id=1653788 [2] https://review.opendev.org/620634 [3] https://bugzilla.redhat.com/show_bug.cgi?id=1688838

3 3

[TC] 'V' Technical Elections
by Kendall Nelson 18 Dec '19

18 Dec '19

Hello! /me takes TC hat off and puts election official hat on Having run our handy dandy tool to project dates[1] for the elections, we have some decisions to make again. At this point we have threeish options: 1. Run the elections with a week in between with the TC election happening BEFORE the PTL election like the script generated. The TC election would run March 10 to March 31 and the PTL Election would run April 7 to April 21. The primary concern here is that it might lead to some election burnout. 2. Run the elections back to back with the PTL election first (closer to the historic norm). This would be tweaking the generated dates by pulling the PTL election three weeks up and pushing back the TC dates by two weeks. The PTL election would run March 3 to March 17 and the PTL Election would run March 17 to April 7. Both elections would be concluded by milestone 3. Similar concerns with this option to the first with election burnout. 3. Run the elections in parallel as a combined election, similar to how we did for the Train elections. This is much easier for election officials because we only need to generate one electorate. The two elections would start March 10 and be done by March 31 following the TC election model with a nominations period, a campaigning period (optional for PTL elections), and then a polling period (assuming we need a runoff). Other info to keep in mind when formulating your opinions: - Extra ATC deadline currently is March 23-27 which will likely need to get bumped earlier for any of these options - RC1 is the week of April 20-24 - Milestone 3 is April 9 - Release schedule for reference[2] - For TC member terms, those closing in on their ~1 year terms would be closer to 13 months since the train elections concluded March 5th of last year -Kendall (diablo_rojo) & the Election Officials [1]http://paste.openstack.org/show/787114/ [2]https://releases.openstack.org/ussuri/schedule.html

9 24

[searchlight] Elasticsearch 5 and latest support
by Mathieu Gagné 18 Dec '19

18 Dec '19

Hi, I'm reading the documentation for Searchlight and it's recommending ElasticSearch 5.x: https://docs.openstack.org/searchlight/latest/install/elasticsearch.html I installed and tried to use Elasticsearch 5 and it doesn't work. The queries sent by Searchlight aren't accepted by Elasticsearch. For examples: When listing facets: TransportError(400, u'parsing_exception', u'[terms] failed to parse field [size]'): RequestError: TransportError(400, u'parsing_exception', u'[terms] failed to parse field [size]') When searching for images: No registered plugin for type owner: Exception: No registered plugin for type owner Is there any work in progress to add support for Elasticsearch 5? In fact, Elasticsearch 5 is EOL. Are there plans to support later versions? Thanks -- Mathieu

2 4

[OSH][Infra] Open UDP port 111 on test nodes
by Clark Boylan 18 Dec '19

18 Dec '19

Hello, One of our contributing test node clouds has discovered that occasionally one of our test nodes will have udp port 111 open. The concern with this is that the RPC portmap service can be used in reflection DDoS attacks. Upon further investigation we've discovered that this seems to happen in OSH jobs (like openstack-helm-multinode-temp-ubuntu) [0] that run OSH's setup-firewall role [1]. These jobs do indeed disable the host firewall which would leave any running port mapper service exposed. It looks like these jobs run with multiple nodes in their nodeset, but do not use the multinode base job. I point this out because the multinode base job aims to set up networking and firewalls such that the nodes can talk freely among themselves while still blocking out the outside world. If we need to enable network communicate between hosts in these jobs this seems like a good place to start. That said there is a good chance that kubernetes may need additional open traffic. Additionally, I expect those specific depend on the CNI plugin that has been chosen? >From an infrastructure perspective we'd like to be good stewards of the resources donated to us and in this case that means preventing unwanted network traffic. We are more than happy to help set up more appropriate firewall rules if we can get details on what is needed. I expect the Zuul project is also interested and we can bake some of these common network needs for kubernetes into Zuul's zuul-job standard library. Can the OSH project work with us to fix this problem? Perhaps other kubernetes users/devs/operators can chime in on how they have reconciled host firewalls with kubernetes network needs? Any help that can be provided here would be much appreciated. [0] http://zuul.opendev.org/t/openstack/build/6fc5285fdb76484b894f0d288facdbb2/… [1] https://opendev.org/openstack/openstack-helm-infra/src/branch/master/roles/… Thank you, Clark

2 1

[all] Volunteer mailing list administrators
by Jeremy Stanley 17 Dec '19

17 Dec '19

This is a long-overdue request. It's been more than a year since we combined openstack, openstack-dev, openstack-ops, openstack-sigs, openstack-tc and a number of other lower-traffic mailing lists into this new openstack-discuss mailing list. In that time, I've been serving as the sole administrator and moderator for the combined list. As I'm about to take an extended vacation away from regular Internet access for the first time since the list migration, I will be unable to check the moderation queue on a daily basis, and so would appreciate a bit of help from some of you. If there's anyone interested in helping out as additional administrators for the openstack-discuss mailing list, please reply to this message on-list (so other subscribers know who is volunteering) and I'll help bring you up to speed. In the immediate term I need at least one person willing to check the moderation queue a few times in the second half of December while I'm unavailable (daily would be awesome but a couple times a week is probably fine really). If you're expecting to be around and able to help with that, please respond on Monday or Tuesday of this week and I'll sync up to get you a copy of the Mailman administrator password for it and a quick walk-through of the moderator interface (if you already moderate other Mailman lists, all the better!). Moderation queue volume is typically on the order of twenty to fifty messages a day, most of which are spam of course, but one or two a day on average are legitimate messages either from non-subscribers with a question or sometimes slightly over the size limit because of attached logs. The spam and non-spam are pretty easy to tell apart if you've been around our community for a while: if the subject of the message has a recognizable topic tag in it or mentions the name of some OpenStack project then it's quite likely legitimate and can be approved. Spam on the other had usually either has a subject which is not in English (the required language for messages to this list) or is clearly someone selling something or running a scam. When in doubt though, you can quickly check the message body to be sure. I tend to spend at most 5 minutes a day looking through the moderation queue (and usually far less). Longer term, I'd like to see anywhere between 3-5 admins for the openstack-discuss list. No need to coordinate workload or vacations that way, we can just each check the queue when we think about it and that should be plenty often. Also while keeping on top of the moderation queue is the primary need, it would be great for these folks to know/learn a bit about how Mailman mailing lists are configured and how to troubleshoot them from the WebUI and message headers. Better still, if anyone wants to get even more involved, the OpenDev sysadmins would always welcome new recruits willing to help manage and run our mailing list servers and our infrastructure overall, I'm happy to make introductions! -- Jeremy Stanley

8 14

[nova][metadata] EC2 compatible metadata deprecation
by Mikhail Fedosin 17 Dec '19

17 Dec '19

Hello! In the documentation I noticed that EC2 metadata may soon be removed from Nova [1]. Currently, we use EC2 metadata in our product to obtain public and private IP addresses, as well as the instance-type (flavor). Therefore, I would like to ask you a couple of questions. 1. Do you plan to ensure compatibility before removing EC2 metadata from the system, i.e. to add these fields to the OpenStack metadata, which is not yet available? 2. When is it expected that EC2 metadata will be removed from the system? Best regards, Mikhail Fedosin [1] https://docs.openstack.org/nova/latest/user/metadata.html#general-guidelines

5 6

[ops] openstack ops meetup team meeting 2019-12-17
by Chris Morgan 17 Dec '19

17 Dec '19

Meeting minutes from today's meeting of the openstack ops meetups team on #openstack-operators : Meeting ended Tue Dec 17 15:35:22 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 10:35 AM Minutes: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2019/ops_meetup_tea… 10:35 AM Minutes (text): http://eavesdrop.openstack.org/meetings/ops_meetup_team/2019/ops_meetup_tea… 10:35 AM Log: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2019/ops_meetup_tea… the next meetup is in London on Jan 7,8 and registration is still open ( https://go.bloomberg.com/attend/invite/openstack-operators-meetup-london202… ) Regular updates on meetups are posted to the notification twitter account (see https://twitter.com/osopsmeetup) There will be an openstack ops meetup at the next summit (rumored to be in vancouver) and then later in 2020 in south korea. See the above-linked minutes for more details. Chris Morgan (on behalf of the openstack ops meetups team) -- Chris Morgan <mihalis68(a)gmail.com>

1 0

[Neutron][QoS] Next IRC QoS meeting 14/1/2020
by Rodolfo Alonso 17 Dec '19

17 Dec '19

Hello Neutrinos: We'll cancel next QoS meeting and meet again on the 14th of January. Happy holidays to all! Regards.

1 0

[kolla] Kolla and Kolla Ansible 9.0.0 released for Train
by Mark Goddard 17 Dec '19

17 Dec '19

Hi, I'm pleased to announce the availability of the Kolla and Kolla Ansible 9.0.0 releases for the Train cycle! Train brings a number of interesting new features, including Masakari and Qinling support, the ability to deploy multiple Nova cells and TLS encryption of the internal API network. Full details are in the release notes which are available here: https://docs.openstack.org/releasenotes/kolla/train.html https://docs.openstack.org/releasenotes/kolla-ansible/train.html We anticipate significant changes during the Train release series to support a migration to CentOS 8. We will communicate which releases are affected. The first official release of kolla-cli should be available in the next few days. Release notes will be available here: https://docs.openstack.org/releasenotes/kolla-cli/train.html The first official release of Kayobe is making some finishing touches, and should be released by the end of the year, or early next year. Thanks to everyone who contributed to this release, it adds a lot of useful features. A great way to end the year. Cheers, Mark

1 0

[goals][Drop Python 2.7 Support] Week R-22 Update
by Ghanshyam Mann 17 Dec '19

17 Dec '19

Hello Everyone, Below is the progress on "Drop Python 2.7 Support" for R-22 week. Schedule: https://governance.openstack.org/tc/goals/selected/ussuri/drop-py27.html#sc… * I am adding this in Ussuri schedule page[1] Highlights: ======== * We crossed the Milestone-1 and with that, we are in phase-2 of py2 drop which targets all the common libraries and testing tools can start dropping the py2 support. * All the services should drop the py2 but this time. Patches are already up, review and merge them before gate starts failing due to cross projects py2 drop. * I pushed the patches on specs repo to cleanup py2 specific requirement or tox or zuul changes. many projects were running 'openstack-tox-py27' which I have changed to 'openstack-tox-pep8' instead of moving them to py3. pep8 job is enough for Specs repo. * I saw many spec repo failing their docs job due to oslosphinx and incompatible version of yasfb[2]. We need to fix this along with py2 drop patches if existing spec repo running py2 job. NOTE: Phase-2 is for Library (including client library), QA tooling. Phase-3 is mainly for openstack/requirement and audit to all repo. (we can always adjust the schedule to make it smooth migration. For example, dropping a few testing jobs from phase-2/3 candidates if any cross-testing jobs are failing due to phase-1 candidates dropping the support[3].) Summary: ======= The OpenStack services have not merged the py2 drop patches: * Adjutant * Barbican * Designate * ec2-api * Glance * Neutron (stadium projects) * Freezer * Kolla * Karbor * Congress * Storlets * Sahara * Blazar * Masakari * Tacker * Trove (trove-dashbaord patch is not mergd) * Zaqar * Qinling * Tricircle * openstack-helm * python-openstackclient How you can help: ============== - Review the patches. Push the patches if I missed any repo targetted for phase-1. [1] https://review.opendev.org/#/c/699008/ [2] https://review.opendev.org/#/c/698998/ [3] http://lists.openstack.org/pipermail/openstack-discuss/2019-December/011392… [4] https://review.opendev.org/#/q/topic:drop-py27-support

3 3

[neutron][devstack] Future of lib/neutron and lib/neutron-legacy
by Slawek Kaplonski 17 Dec '19

17 Dec '19

Hi, Few years ago (I don’t know exactly when it started as I wasn’t very active upstream than for sure) Neutron team started work on new neutron module for Devstack. See [1] for details. But since then this new module is still not ready to use. For example in gate jobs we are still using lib/neutron-legacy module as this new one is always causing some problems. Things in its current shape may be confusing for new Devstack users as in fact to deploy Neutron properly they should use lib/neutron-legacy instead of lib/neutron now. Personally I never really checked exactly what issues are there in fact but I do remember some issues with using lib/neutron e.g. on subnodes in multinode jobs - see [2]. So I would like to ask a question what do You think we should do with it. Is there maybe any volunteer who would like to continue this work on adopting lib/neutron and to finally use it in gate jobs? Or if there is no anyone and we are all fine with using old module, maybe we should remove this lib/neutron and “undeprecate” and rename lib/neutron-legacy? [1] https://github.com/openstack/devstack/commit/2a242519f71e86416e78541826cac2… [2] https://review.opendev.org/#/c/662480/ — Slawek Kaplonski Senior software engineer Red Hat

3 2

Re: [OpenStack Foundation] [tc][board][all] - Adding OpenStack community support to the savedotorg campaign
by Graham Hayes 16 Dec '19

16 Dec '19

On 26/11/2019 16:44, Alan Clark wrote: > Who owns savedotorg.org? I see EFF references on the page but when I look it up the domain it appears to all be "REDACTED". >From https://savedotorg.org/index.php/about/ - it is ran by NTEN (https://www.nten.org/) It is supported by the EFF (among others) > >> -----Original Message----- >> From: Graham Hayes [mailto:gr@ham.ie] >> Sent: Tuesday, November 26, 2019 9:35 AM >> To: Jimmy McArthur <jimmy(a)openstack.org> >> Cc: openstack-discuss(a)lists.openstack.org; foundation- >> board(a)lists.openstack.org; foundation(a)lists.openstack.org >> Subject: Re: [OpenStack Foundation] [tc][board][all] - Adding OpenStack >> community support to the savedotorg campaign >> >> On 26/11/2019 16:16, Jimmy McArthur wrote: >>> From my reading of the situation, it’s a done deal. It seems like ICAAN just >> crammed it through. Is there new info out that could reverse it? >>> >>> Thanks, >>> Jimmy >> >> My understanding is it looks bleak, but there is a chance to shame the owners >> into halting the sale. >> >> I think ICAAN can still block the same (until December 13th, 30 days after they >> were notified), and through pure poor marketing, and raising our voices, this >> could help convince the current owners of PIR (who is ISOC) to re-consider the >> idea. >> >> >>>> On Nov 26, 2019, at 8:50 AM, Amy <amy(a)demarco.com> wrote: >>>> >>>> I agree with the OSF submitting on behalf of OpenStack and the other projects. >> I also like the idea of individuals signing as contributors. >>>> >>>> Amy Marrich (spotz) >>>> >>>>>> On Nov 26, 2019, at 8:17 AM, Sean McGinnis <sean.mcginnis(a)gmail.com> >> wrote: >>>>>> >>>>>> On Tue, Nov 26, 2019 at 7:00 AM Graham Hayes <gr(a)ham.ie> wrote: >>>>>> >>>>>> Hey All, >>>>>> >>>>>> I am not sure if this has been seen by everyone or not - but there >>>>>> is a change in how the .org top level domain is being ran in the >>>>>> works, in a way that may not be in the best interests of the non >>>>>> profits that it was created to facilitate. [1] >>>>>> >>>>>> A lot of well known non profits have already joined, and as a >>>>>> community that has an interest in the internet as a whole, and uses >>>>>> a .org domain, I think we should add our voice in support. >>>>>> >>>>>> What do people think? Are we happy to have the TC use its voice on >>>>>> behalf of the OpenStack project, or do we think the board should >>>>>> use its voice on behalf of the entire foundation? >>>>>> >>>>>> - Graham >>>>>> >>>>>> >>>>>> 1 - https://savedotorg.org/ >>>>>> >>>>> >>>>> I agree this is a Foundation level thing (though individuals can add >>>>> their names to the petition as well). I would support adding OSF to >>>>> the list of organizations. >>>>> >>>>> Sean >>>>> >>>> >>>> _______________________________________________ >>>> Foundation mailing list >>>> Foundation(a)lists.openstack.org >>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation >>> >> >> >> _______________________________________________ >> Foundation mailing list >> Foundation(a)lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/foundation

5 6

[tc] Follow up on action tems
by Jean-Philippe Evrard 16 Dec '19

16 Dec '19

Hello TC members, - There are still business opportunities merging for 2019. The process for 2020 need to start soon. Any takers? - We have pending action items from the last meeting: - ricolin: contact to Infra team to see if we got more ARM server in our Nodepool - ricolin/ttx: track the merger of the SIGs self-healing and auto- scaling - mnaser: static hosting story: Is it restarting? Where are we now? - ttx: Work on technical vision reflection update - ricolin/evrardjp: Expect/Request an update from Telemetry team. As mentioned in our channel [7], Rong Zh (PTL for Telemetry) will provide a Telemetry status report (high chance to send it out next week). - jungleboyj: analysis of the user survey. The patch is out for TCs to review [6] - ttx: make sure to start the discussion about uc/tc merge in January after the ops meetup - mnaser: write documentation in governance to clarify what was discussed about stable policy - We have new action items: - We need to update our charter for the election terms, to be more flexible. Who is okay with starting this? - We have plenty of things which are not reviewed, or WIP. Could you update (y)our patches please with either changes or votes? - aprice has asked me (JP) to write a report for the TC and SIG activities of 2019. If you want to know what I am cooking, or want to help on the text, please join here [5] - In the next elections, we'll be reducing our (=TC) size temporarily due to the current elections timing proposal. In order to not have this happen again, we should propose a charter change as soon as possible. Can someone tackle this? Please see the conversations here [1] and here [2] - We still have long action items from PTG: - For community goal `Drop Python 2.7 Support`, you can find the status update on the ML [9]. React there if you need. - The community goal `project specific PTL and contributor guides` proposal patch is under review [8] and will be merged soon. - gmann is sending an official goal schedule plan [3] . We need TC members to review this as well, as soon as possible. We also need to discuss when should we start the first step for next cycle in schedule during next meeting (if/when patch landed). - Please also review other patches, like [4] . And finally, some things to keep in mind: - We need to promote the first contact sig to organisations that might need help on getting things achieved in OpenStack. Regards, JP & Rico [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-December/011396… [2] http://lists.openstack.org/pipermail/openstack-discuss/2019-November/011155… [3] https://review.opendev.org/#/c/698299 [4] https://review.opendev.org/#/c/691737 [5] https://etherpad.openstack.org/p/2019-openstack-foundation-annual-report-dr… [6] https://review.opendev.org/#/c/698582/ [7] http://eavesdrop.openstack.org/irclogs/%23openstack-tc/%23openstack-tc.2019… [8] https://review.opendev.org/#/c/691737 [9] http://lists.openstack.org/pipermail/openstack-discuss/2019-December/011432…

2 2

[kolla] No more meetings in 2019
by Mark Goddard 16 Dec '19

16 Dec '19

Hi, We'll cancel the next 3 weeks meetings, and meet again on the 8th January. I'll be away from tomorrow until 2nd January. Cheers, Mark

1 0

[keystone] Meeting time change
by Colleen Murphy 16 Dec '19

16 Dec '19

As discussed in today's meeting[1], I would like to propose we move the team meeting to one hour later, 17:00 UTC, same day same channel. Everyone in attendance today was okay with the change but I wanted to give anyone who couldn't attend today the chance to object. Let me know if this change would prevent you from attending the meeting. If there are no objections this week, I'll propose a change to the eavesdrop calendar. For the moment, assume the meeting next week (December 17) will be at 17:00. Colleen [1] http://eavesdrop.openstack.org/meetings/keystone/2019/keystone.2019-12-10-1…

1 1

[all] Which will be the first OpenStack release to require Python 3 ?
by Neil Jerram 16 Dec '19

16 Dec '19

I think the answer is Ussuri (and hence that Train can still be run with Python 2), but have not been able to find a clear statement of this, hence asking here. (Suggest also updating https://wiki.openstack.org/wiki/Python3 with the answer.) Thanks, Neil

2 2

[neutron] bug deputy report for the week of Dec 9th
by Takashi Yamamoto 16 Dec '19

16 Dec '19

hi, here's the list of the bugs reported in the week. RFE: https://bugs.launchpad.net/neutron/+bug/1855123 Neutron ovs agent still fails vlan transparency check https://bugs.launchpad.net/neutron/+bug/1855854 [RFE] Dynamic DHCP allocation pool Critical: https://bugs.launchpad.net/neutron/+bug/1856156 Constraints file is not considered during doc build * backports probably need some investigations. https://review.opendev.org/#/q/Iea61238f37fdf24c0264f96d104ee0b3b6aec8e2 High: https://bugs.launchpad.net/neutron/+bug/1855759 neutron.plugins.ml2.drivers.agent._common_agent KeyError: 'gateway' . ERROR * a proposed patch: https://review.opendev.org/#/c/698287/ https://bugs.launchpad.net/neutron/+bug/1855888 ovs-offload with vxlan is broken due to adding skb mark * a proposed patch, blocked by gate: https://review.opendev.org/#/c/698336/ https://bugs.launchpad.net/neutron/+bug/1855912 MariaDB 10.1 fails during alembic migration https://bugs.launchpad.net/neutron/+bug/1856319 [SRIOV] Agent is reporting "resources_synced=True" when restarted and placement is down Low: https://bugs.launchpad.net/neutron/+bug/1855919 broken pipe errors cause neutron metadata agent to fail https://bugs.launchpad.net/neutron/+bug/1856152 Vm`s tap bound to br-int，When cfg.CONF.OVS.integration_bridge is configured as another bridge

1 0

[nova][ptg] Continue QoS port support
by Balázs Gibizer 14 Dec '19

14 Dec '19

Hi Novas! Here is my summarized plans for Ussuri about continuing the work on supporting qos neutron ports (those that has bandwidth resource request) in nova. What is missing: * Tempest coverage is missing for migrate and resize support that is merged in Train. This work is already underway and bugs has been caught [1][2] * Support evacuate, live migrate, unshelve. The work is described in [3][4] and the first set of patches for the evacuation support is up for review [5] * Support for cross cell resize with qos port needs some work. Matt prepared the cross cell resize code already in a way that no new RPC change will be needed [6] and I have a plan what to do [7]. * InstancePCIRequest persists parent_ifname during migration but the such change is not rolled back if the migration fails. This is ugly but I think it does not cause any issues [8]. I will look into this to remove the ugliness. The bandwidth support for the nova-manage heal_allocation tool was merged in Train. Originally I planned to backport that to Stein but that patch grown so big and incorporated may refactors along the way that I'm not sure any more that it is reasonable to backport it. I'm now thinking about keeping it as-is and suggesting operators to install Train nova in a virtualenv to run heal allocations for bandwidth aware servers if needed in Stein. I do have to run some manual tests to see if it actually works. Any feedback is welcome! cheers, gibi [1] https://bugs.launchpad.net/nova/+bug/1849695 [2] https://bugs.launchpad.net/nova/+bug/1849657 [3] https://blueprints.launchpad.net/nova/+spec/support-move-ops-with-qos-ports… [4] https://specs.openstack.org/openstack/nova-specs/specs/ussuri/approved/supp… [5] https://review.opendev.org/#/q/status:open+project:openstack/nova+branch:ma… [6] https://review.opendev.org/#/c/635080/43/nova/compute/manager.py@5375 [7] https://review.opendev.org/#/c/633293/49/nova/compute/manager.py@4742 [8] https://review.opendev.org/#/c/688387/6/nova/compute/manager.py@3404

2 3

[tc] Concluding the "2019 TC vision" exercise
by Thierry Carrez 13 Dec '19

13 Dec '19

Hi everyone, Back in 2016-2017, TC members participated in stewardship training at Zingerman's. Part of their framework relies on the concept of "visioning": how describing in details a desirable future helps you get there. As a result of that training, TC members in 2017 created such a "vision"[1], set in 2019. As the sole TC survivor of these ancient times and as we close the 2019 year, it sounds appropriate to reflect back on this exercise and discuss if anything more should be done in that area. [1] https://governance.openstack.org/tc/resolutions/20170404-vision-2019.html The first part of the vision, "Navigating with Constellations", was describing efforts to make OpenStack components combinations more easy to understand for specific use cases, and individual components more easily reusable in other types of deployments. The "constellation" concept never really took off, and product management is still very much done downstream of OpenStack. The "vision for OpenStack Clouds" living document[2] helped us refine our scope and better answer the "What is OpenStack" question. The OpenStack Map[3] helps navigate the ecosystem, and content on the software pages on openstack.org is now more directly driven[4] from the project teams, but overall making OpenStack easier to navigate is still very much a work in progress. That said, individual components are now generally easier to reuse in other contexts, as seen with Ironic reuse in Metal³. The second part of the vision, "Working with Adjacent Communities", was describing how we should interact and combine our work with components produced by adjacent communities, rather than beginning and ending with OpenStack. While the specific outcomes mentioned in the vision never happened, several efforts resulted in OpenStack having a more definite scope and place in the general technology landscape. Success of Kubernetes as an interoperable application deployment API helped position OpenStack more as an infrastructure provider. Our technical and non-technical experience was shared with adjacent communities like the cloud-native communities, but also with new open infrastructure projects under the OSF. The third part, "Embracing Community Diversity", is probably where we've seen the less progress in the last 3 years. It describes efforts to get a more diverse contributor base and TC representation. I feel like we still have a long way to go in that area, although things are gradually improving: we have seen more and more users of OpenStack step up and lead project teams, we are also seeing people with more of an operator background be elected to the TC, and this year the TC saw its first APAC-based member. The last part of the vision, "Growing New Leaders" describes facilitating inter-project work. Several initiatives have been put in place in that area since 2017. Community goals[5], SIGs[6], and more recently pop-up teams[7] (a concept which was described in the vision) all try to facilitate forming cross-disciplinary groups to advance complex inter-project issues in OpenStack. In summary, little of the specific plans described in the vision have actually been put in place, and the topics mentioned in there are all still work in progress. That said, the vision was a useful exercise in that it defined areas of focus for the TC stewardship of the community, and it did definitely inspire several of the plans we put in place those last 3 years. It was a time-consuming exercise though, so I'm not sure we should go through that exercise again and painting a vision for 2023. Comments, thoughts? [2] https://governance.openstack.org/tc/reference/technical-vision.html [3] http://www.openstack.org/openstack-map [4] https://opendev.org/osf/openstack-map/ [5] https://governance.openstack.org/tc/goals/index.html [6] https://governance.openstack.org/sigs/ [7] https://governance.openstack.org/tc/reference/popup-teams.html -- Thierry Carrez (ttx)

2 1

[Security SIG] Security SIG Newsletter - December 2019
by Gage Hugo 13 Dec '19

13 Dec '19

Hope everyone is having a good December so far, here's the update for this month from the Security SIG. Starting this month, this newsletter will be released on a monthly basis rather than a semi-weekly due to the sporadic activity and my availability. Also just a heads up, the next two weeks of meetings will be canceled for the Security SIG, we will resume on Jan 02nd. Have a Happy Holidays everyone! #Month Dec 2019 - Security SIG Meeting Info: http://eavesdrop.openstack.org/#Security_SIG_meeting - Weekly on Thursday at 1500 UTC in #openstack-meeting - Agenda: https://etherpad.openstack.org/p/security-agenda - https://security.openstack.org/ - https://wiki.openstack.org/wiki/Security-SIG #Updates - https://bugs.launchpad.net/keystone/+bug/1855080 was reported and a corresponding OSSA was released - This newsletter to be moved to a monthly release, rather than semi-weekly. #VMT Reports - A full list of publicly marked security issues can be found here: https://bugs.launchpad.net/ossa/ - OSSA-2019-005 was released: https://security.openstack.org/ossa/OSSA-2019-006.html

1 0