February 2020 - openstack-discuss

[openstack-helm][neutron] neutron-dhcp-agent stuck in Init state
by Sanjay K 21 Feb '20

21 Feb '20

Hi All, I am trying to deploy openstack services using helm charts in my k8s cluster. My cluster is having 4 nodes - 1 k8s master, 1 controller and 2 compute nodes. I am using helm v3.0.3 for openstack stein. I have already deployed the below charts in my cluster successfully in the respective order - ingress, mariadb, rabbitmq, memcached, keystone, glance and then neutron. For mariadb, rabbitmq and glance, I am using PV and PVC in my local storage while deploying. All are ok until I deploy neutron. After deployment, all neutron pods works well except *neutron-dhcp-agent-default pod *which remains in Init:0/2 state. The pod description shows it has dependencies shown as - DEPENDENCY_SERVICE: openstack:rabbitmq,openstack:neutron-server,openstack:nova-api DEPENDENCY_JOBS: neutron-rabbit-init pods state- NAME READY STATUS RESTARTS AGE glance-api-b575ff7c-qp7wt 1/1 Running 0 132m glance-bootstrap-zjtw9 0/1 Completed 0 132m glance-db-init-86xgk 0/1 Completed 0 132m glance-db-sync-z9p9l 0/1 Completed 0 132m glance-ks-endpoints-wwm59 0/3 Completed 0 132m glance-ks-service-vs92t 0/1 Completed 0 132m glance-ks-user-znn88 0/1 Completed 0 132m glance-metadefs-load-g685b 0/1 Completed 0 132m glance-rabbit-init-648w8 0/1 Completed 0 132m glance-storage-init-jdlx2 0/1 Completed 0 132m ingress-8f98f7d96-llkwl 1/1 Running 0 3h42m ingress-error-pages-84647d8fcb-6j6bz 1/1 Running 0 3h42m keystone-api-5785f4787-lz296 1/1 Running 0 154m keystone-bootstrap-6tcdx 0/1 Completed 0 154m keystone-credential-setup-d9js5 0/1 Completed 0 154m keystone-db-init-zsgbj 0/1 Completed 0 154m keystone-db-sync-z8hfk 0/1 Completed 0 154m keystone-domain-manage-nk48h 0/1 Completed 0 154m keystone-fernet-setup-4pzlj 0/1 Completed 0 154m keystone-rabbit-init-mlpsn 0/1 Completed 0 154m mariadb-ingress-669c67b6b5-w8jxb 1/1 Running 0 3h32m mariadb-ingress-error-pages-d77467d69-9njgt 1/1 Running 0 3h32m mariadb-server-0 1/1 Running 0 3h32m memcached-memcached-7b49f48865-tf6xc 1/1 Running 0 3h11m neutron-db-init-zpl87 0/1 Completed 0 109m neutron-db-sync-plsnc 0/1 Completed 0 109m neutron-dhcp-agent-default-sf76z 0/1 Init:0/2 0 109m neutron-ks-endpoints-jgmdv 0/3 Completed 0 109m neutron-ks-service-nr5w2 0/1 Completed 0 109m neutron-ks-user-lw4p4 0/1 Completed 0 109m neutron-l3-agent-default-lnzk8 1/1 Running 0 109m neutron-lb-agent-default-44v9x 1/1 Running 0 109m neutron-lb-agent-default-94xw4 1/1 Running 0 109m neutron-lb-agent-default-whms2 1/1 Running 0 109m neutron-metadata-agent-default-7rbrh 1/1 Running 0 109m neutron-rabbit-init-qkhqm 0/1 Completed 0 109m neutron-server-964fcffcb-gvv4k 1/1 Running 0 109m rabbitmq-cluster-wait-vjbzq 0/1 Completed 0 3h18m rabbitmq-rabbitmq-0 1/1 Running 0 3h18m Please guide me how to resolve this neutron-dhcp-agent pod so that I can deploy other services after that. I have plan to deploy libvirt, nova, cinder, horizon and ceilometer charts into my cluster. thank you for your help and support. best regards, Sanjay

3 2

[all][dev] reno linting anyone?
by Radosław Piliszek 21 Feb '20

21 Feb '20

Hello fellow OpenStackers! I wonder whether any project applies any linting to release notes? How do you maintain quality of release notes? -yoctozepto

2 1

Re: [infra][neutron] Removing networking-calico from OpenStack governance
by David Comay 21 Feb '20

21 Feb '20

Neil, > networking-calico is the code that integrates Project Calico [1] with > Neutron. It has been an OpenStack project for several years, but we, i.e. > its developers [2], would like now to remove it from OpenStack governance > and instead manage it like the other Project Calico projects under > https://github.com/projectcalico/. My primary concern which isn't really governance would be around making sure the components in `networking-calico` are kept in-sync with the parent classes it inherits from Neutron itself. Is there a plan to keep these in-sync together going forward?

5 8

[all] Proposed release schedule for Victoria
by Sean McGinnis 21 Feb '20

21 Feb '20

Hello everyone, Looking for feedback and increasing awareness for a proposed release schedule for Victoria: https://review.opendev.org/#/c/708471/ Mainly, looking for any feedback on any conflicts with major holidays, external factors, and other things that could potentially be an issue for this schedule. Until the logs are culled, here is a convenient link to see what the schedule looks like: https://storage.gra.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/… Here are the key dates for the schedule: May 13: Ussuri release June 8-12: OpenDev+PTG June 18: Victoria milestone 1 July 30: Victoria milestone 2 Sept 3: Final non-client lib releases Sept 10: Victoria milestone 3, feature freeze, final lib releases Sept 24: RC1 deadline Oct 8: Final RCs Oct 14: Victoria release Oct 19-23: Open Infrastructure Summit Part of the reason for the slightly shorter schedule was to wrap up prior to the Summit. Another version was looked at to extend past the Summit, but given the various deadlines and crunch that happens around that time, that ended up needed to be extended too far out to avoid conflicts. Please comment on the patch, or reply here, if it looks like there would be any major issues with this release schedule. Thanks! Sean

1 0

[nova][sfe] Support re-configure deleted_on_termination in server
by Brin Zhang(张百林) 21 Feb '20

21 Feb '20

Hi, nova: We would like to have a spec freeze exception for the spec: Support re-configure deleted_on_termination in server [1], and it’s PoC code in [2] I will attend the nova meeting on February 20 2020 1400 UTC as much as possible. [1] https://review.opendev.org/#/c/580336/ [2] https://review.opendev.org/#/c/693828/ brinzhang

2 2

[neutron] networking-bagpipe gate failure
by Akihiro Motoki 21 Feb '20

21 Feb '20

Hi, networking-bagpipe gate is broken now due to its dependencies. The situation is complicated so I am summarizing it and exploring the right solution. # what happens now Examples of the gate failure are [1] and [2], and the exact failure is found at [3]. It fails due to horizon dependency from networking-bgpvpn train release (horizon>=14.0.0<17.0.0) and the upper-constraints.txt master (horizon==18.0.0). The neutron team has not released a beta for ussuri, so requirements.txt tries to install networking-bgpvpn train which has capping of horizon version. The capping of horizon in networking-bgpvpn was introduced in [6] and we cut a release so it started to cause the failure like this. We've explored several workarounds to avoid it including specifying horizon in networking-bagpipe, specify horizon in required-projects in networking-bagpipe and dropping networking-bgpvpn in requirements.txt in networking-bagpipe, but all of them do not work. # possible solutions I am thinking two options. The one is to cut a beta release in neutron stadium for ussuri. The other is to uncap horizon in networking-bgpvpn train and release it. I believe both work but the first one would be better as it is time to release beta for Ussuri. Discussing it in the IRC, we are planning to release beta soon. (ovn-octavia-provider is also waiting for a beta release of neutron.) # Side notes Capping dependencies in stable branches is not what we usually do. Why we don't do this was discussed in the mailing list thread [4] and it is highlighted in [5]. Thanks, Akihiro Motoki (irc: amotoki) [1] https://review.opendev.org/#/c/708829/ [2] https://review.opendev.org/#/c/703949/ [3] https://zuul.opendev.org/t/openstack/build/3bc82305168b4d8cad7e4964c7207e00… [4] http://lists.openstack.org/pipermail/openstack-discuss/2019-November/thread… [5] http://lists.openstack.org/pipermail/openstack-discuss/2019-November/011283… [6] https://review.opendev.org/#/c/699456/

4 3

[cinder] ussuri virtual mid-cycle part 2 poll
by Brian Rosmaita 20 Feb '20

20 Feb '20

The second session of the Cinder virtual mid-cycle will be held the week of 16 March. As with part 1, the length will be 2 hours. There's a poll up to determine a suitable day and time that week: https://doodle.com/poll/eme483iv2faupn6z Please fill out the poll as soon as you can. If all the times are horrible for you, please suggest an alternative in a comment on the poll. The poll closes at 21:00 UTC on Wednesday 26 February 2020. cheers, brian

1 0

[security] Vulnerability Management Policy Changes
by Gage Hugo 20 Feb '20

20 Feb '20

The Vulnerability Management Team (VMT) has recently updated the vulnerability:managed policy[0] here, the key points are: - Softened our #5 policy from a hard requirement to a recommendation - Clarified that the VMT does not track external software components - Defined that a project must tag releases to qualify for VMT oversight, and that the VMT only deals with vulnerabilities in real releases (not pre-releases, release candidates, milestones...) - Private embargo's shall not last more than 90 days, except under unusual circumstances With the VMT policy changes[0] merged, we have also updated the VMT process document[1] to match. The biggest change to note is the new 90 day embargo limit: "If a report is held in embargo for 90 days without a fix, or significant details of the report are disclosed in a public venue, the embargo is terminated by a VMT coordinator at that time and subsequent process switches to the public report workflow instead." We'll be updating all current private reports to let participants know that there is a 90-day deadline (from when we update the report) to make those reports public. [0] https://review.opendev.org/#/c/678426/ [1] https://security.openstack.org/vmt-process.html

1 0

[tripleo][rdo][rdo-dev] Status of RDO Trunk Ussuri on CentOS 7 and transition to CentOS 8
by Alfredo Moralejo Alonso 20 Feb '20

20 Feb '20

Hi, I'd like to open a discussion about the status of RDO Ussuri repositories on CentOS7. As you know RDO and upstream teams (kolla, puppet-openstack, TripleO, TripleO CI, etc...) have been working to switch to CentOS8 during last few weeks. In order to make the transition easier from CentOS 7 to CentOS 8, RDO is still maintaining Trunk repos consistent for both CentOS 7/Python 2 and CentOS 8/Python 3. As OpenStack projects have been dropping support for P ython 2, we've started pinning them to the last commit working with Python 2[1], we were expecting that transition will finish soon but it's still going on. Over time, the number of pinned packages has been growing including services and Oslo libraries where we can't follow upper-constraints anymore [2]. Recently, Kolla has removed support for CentOS 7 so i doubt it makes sense to keep pinning packages to keep RDO Trunk consistent artificially and continue running promotion pipelines on a repo with so many outdated packages. Also, pinning these projects makes that changes needed for CentOS 8 will not be in RDO and would need to be backported manually to each package. My proposal is: - Unpin all packages in Ussuri to follow master trunk, or versions in upper -constraints (for clients and libraries). - RDO Ussuri on CentOS 7 repo consistent link will not move anymore (so no more promotions based on it). - We will keep running centos7-master DLRN builder, so that packages still builing with Python 2 will be available in current repo [3] to be used by teams needing them until migration to CentOS 8 is finished everywhere. - Projects which already have CentOS 8 jobs gating in master branch can remove CentOS 7 ones. We understand this can add some pressure on moving to CentOS8 to the teams working on it, but I'd say it's already a priority and it's justified at this stage. What do you think about this plan?, is there any reason to keep CentOS 7 artificially consistent and promoting at this point of the transition to CentOS 8? Best regards, Alfredo [1] https://review.rdoproject.org/r/#/q/topic:pin-py2 [2] https://review.rdoproject.org/r/#/c/24796/ [3] http://trunk.rdoproject.org/centos7-master/current

1 0

[manila] Core Team additions
by Goutham Pacha Ravi 20 Feb '20

20 Feb '20

Hello Zorillas/Stackers, I'd like to make propose some core team additions. Earlier in the cycle [1], I sought contributors who are interested in helping us maintain and grow manila. I'm happy to report that we had an fairly enthusiastic response. I'd like to propose two individuals who have stepped up to join the core maintainers team. Bear with me as I seek to support my proposals with my personal notes of endorsement: Victoria Martinez de la Cruz - Victoria has been contributing to Manila since it's inception. She has played various roles during this time and has contributed in significant ways to build this community. She's been the go-to person to seek reviews and collaborate on for CephFS integration, python-manilaclient, manila-ui maintenance and support for the OpenStack client. She has also brought onboard and mentored multiple interns on the team (Fun fact: She was recognized as Mentor of Mentors [2] by this community). It gives me great joy that she agreed to help maintain the project as a core maintainer. Carlos Eduardo - Carlos has made significant contributions to Manila for the past two releases. He worked on several feature gaps with the DHSS=True driver mode, and is now working on graduating experimental features that the project has been building since the Newton release. He performs meaningful reviews that drive good design discussions. I am happy to note that he needed little mentoring to start reviewing the OpenStack Way [3] - this is a dead give away to me to spot a dedicated maintainer who cares about growing the community, along with the project. Please give me your +/- 1s for this proposal. Thank you, Goutham Pacha Ravi (gouthamr) [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-October/009910.… [2] https://superuser.openstack.org/articles/openstack-community-contributor-aw… [3] https://docs.openstack.org/project-team-guide/review-the-openstack-way.html

7 7