- openstack-discuss - lists.openstack.org

[nova] Stein automated upgrade checks
by Matt Riedemann 14 Mar '19

14 Mar '19

As a reminder we should look through the upgrade release notes each release to see if anything should be automated with the "nova-status upgrade check" command. I looked over the release notes we do have [1] and I couldn't really come up with anything that should obviously be added. Mel already wrote one for nova-consoleauth. The only other one I could think of maybe was the one about flavors with disk=0, but that involves checking policy which is customizable and even then is OK as long as disk=0 flavors are used only for volume-backed servers. I don't know if it's worth just having a simple upgrade check that looks for disk=0 flavors and dumps a warning? Mohammed should probably weigh in here. Having a warning that can't be easily ignored in an upgrade check might not be great since the return code is 1 for any warnings and if tooling is failing on rc!=0 then some deployments could break. [1] https://docs.openstack.org/releasenotes/nova/unreleased.html#upgrade-notes -- Thanks, Matt

1 0

[packaging][placement][docs] placement install docs
by Chris Dent 14 Mar '19

14 Mar '19

There are some rudimentary placement install docs [1]. I say rudimentary because as far as I know they haven't been validated against reality in any way. They started out as copies of the docs that had lived in nova for rocky [2] with adaptations to address what seemed the likely names for the placement-related packages that will exist at some point. In January I posted a message [3] asking for feedback on the docs from people familiar with the RDO, Ubuntu and SUSE packages for feedback and verification. Unless I missed it, that didn't happen. We'll be cutting an RC1 of placement some time next week (the week of 18 March) and I'd like these docs to either be accurate or marked up in a way that expresses when they will become accurate. I'm sure there are plenty of people who think that placement packages are important and hope to have useful documentation for using them. Can some of those people please step forward and help out here, or let me know what needs to happen to get things in reasonable form? I haven't used packages to manage placement, ever, and I suspect that's the case of most of the regular palcement contributors as well, so I am (and they are) not well-positioned to figure this stuff out on our lonesomes. Thanks for your help. [1] https://docs.openstack.org/placement/latest/install/ [2] for example, ubuntu: https://docs.openstack.org/nova/rocky/install/controller-install-ubuntu.html [3] http://lists.openstack.org/pipermail/openstack-discuss/2019-January/001379.… -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

1 0

[tc][ptl][goals][python3][adjutant][barbican][heat][ironic][magnum][charms][qa][rally][swift][tacker][Telemetry][tripleo][trove] last push for python3-first goal for stein
by Doug Hellmann 14 Mar '19

14 Mar '19

2 1

[searchlight] RC1 target week
by Trinh Nguyen 13 Mar '19

13 Mar '19

Hi team, Just a kind reminder that next week will be our RC1 target. We will not release any new feature, only critical/security fixes are acceptable. All the big feature like tacker plugin, multi-openstack-clouds, etc. will have to wait until Train. Feel free to reach out. Bests, -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

1 0

[zaqar] wanghao's Candidacy for Zaqar PTL
by hao wang 13 Mar '19

13 Mar '19

Hi Zaqar, First I'm very sorry that I make a mistake about the date to candidacy for Zaqar PTL. But I still want to serve this project in the new cycle, so there is my self-nomination: I want to continue running as Zaqar PTL for the Train cycle. We did good jobs in Stein: 1. We are removing the useless pool group totally in Stein and make the model of pool and flavor more clear. 2. Introduce topic resource for notification in Zaqar 3. Send Email subscription by Zaqar 4. Delete message with claim ID In Train release, we will continue our works in: 1) Introduce a new resource for queue's metadata 2) Continue to support more backends for topic resource 3) Consider removing some backends that seem useless more and more. 4) Support sms subscription in Zaqar Thanks for your consideration!

2 1

[requirements][FFE][openstackdocstheme] Feature freeze exception for openstackdocstheme
by Eric Fried 13 Mar '19

13 Mar '19

Hello. I would like to request a freeze exception to release openstackdocstheme per [1]. This is more on the basis of "extremely low risk" than "gotta have it": it picks up a couple of commits with aesthetic improvements I would like to take advantage of (see commit message). Thanks, efried [1] https://review.openstack.org/642908

2 1

[neutron] [designate] [kolla] dnsmasq internal resolver and instance hostnames
by Krzysztof Klimonda 13 Mar '19

13 Mar '19

Hi, I’m trying to wrap my head around how neutron, dnsmasq and resolving internal hostnames is supposed to be working. I have a lab deployment with pike where I want to enable designate service, and also have instances resolve their “siblings” using hostnames (the deployment is done using kolla if it matters). I’ve noticed that dnsmasq is not authorative for the domain set in `dns_domain` and sends all DNS requests up the chain - that seems to make instances unable to resolve their own name, and names of other instances in the same network. Is getting it to work as simple as adding `auth-zone=$dns_domain` to `/etc/neutron/dnsmasq.conf` or is there something more going on with my deployment, and that should just work? -Chris

1 0

[oslo] [rabbitmq] RabbitMQ and EPMD bound to ipv6 issue
by Gabriele Santomaggio 13 Mar '19

13 Mar '19

Hi all, Recently we had an issue with RabbitMQ and EPMD bound to ipv6. Here [1] you can find the discussion. Note that this issue happens **only** when: 1- epmd is bound only to ipv6 interface 2- there are no other ways to look up the hostname The problem [2] is more in Erlang than in RabbitMQ 1 - https://groups.google.com/d/msg/rabbitmq-users/mbsT8PSJTHQ/JKEwev3uBQAJ 2 - https://github.com/erlang/otp/pull/602 Regards -- Gabriele Santomaggio Cloud Developer @SUSE

1 0

[kolla] Let's switch to Python 3
by Marcin Juszkiewicz 13 Mar '19

13 Mar '19

Python 2 is going bye bye. Everyone knows that, lot of us ignores that. But we need to move on. Kolla has few patches to make use of Python3 based binary packages. One for Fedora [1], other for Ubuntu and Debian [2]. 1. https://review.openstack.org/624838 2. https://review.openstack.org/625298 But those patches are just tip of iceberg... # Types of images There are two types of images in Kolla: - binary - source ## Binaries state in distributions Binary ones are built from distribution packages. For RHEL/CentOS/OracleLinux is means RDO packages, for Ubuntu it is UCA and for Debian it is whatever is in distribution repositories. RDO ones are Python 2 based because there is no other version of Python in RHEL7 (I do not count EPEL or SCL). For Ubuntu we have a mix of Python 2 and Python 3 (from what I heard). Debian needs update to Buster (current 'testing', currently in soft freeze) and then we will get Python 3 packages (currently for Rocky). ### Pip issue On binary distributions we tend to use 'pip' from distribution packages. Which means 8.1.2 for CentOS:7, 9.0.1 for Ubuntu:bionic and 18.1 for Debian:buster. ## Source images In my opinion this type of images is most common during development cycle. Here we install Python and binaries from distribution repositories and then bootstrap latest 'pip' and use it to install all Python modules we need. For now those images are Python 2 based. # WIP plans for T cycle For T cycle we should move whatever possible to Python 3. Which means Debian:buster, Ubuntu:bionic and source images. No idea yet does it involves CentOS:7 source images as well as this would require us to use EPEL repository for Python 3. ## Always bootstrap pip Due to 'pip' issue we may need to bootstrap latest version in each type of images. This will give us simple 'pip' command in each image nevermind which version of Python is used. That saves us from dealing with "is it 'pip' or 'pip3' we need to use" thing. ## Create new variables There will be few different versions of Python in use: 2.7 (RHEL7 family), 3.6 (Ubuntu:bionic and RHEL7/EPEL), 3.7 (Debian:buster). As we tend to modify some files or need to know where Python modules are present. We may use values from 'sys.path' list for it or create 'python_path' (or similar) variable and set it per distribution/image_type. # Some kind of work items list 1. Move Debian to 'buster' release. https://review.openstack.org/612681 2. Bootstrap 'pip' in all image types. 3. Move source images to Python 3 (Debian, Ubuntu for sure, no idea yet about CentOS). 4. Move binary images to Python 3 (Debian, Ubuntu, Fedora/RHEL8) Each step will require several build/test/fix cycles. We also need to identify which images still require Python 2. # Summary I know that this mail looks a bit chaotic but I think that we need to discuss and plan what we need to do and how. And cooperate with external teams which provide binary packages (that's why Thomas and Haïkel are in Cc:). What do you think?

5 10

[scientific-sig] IRC Meeting today CANCELLED
by Stig Telfer 13 Mar '19

13 Mar '19

Hi All - Owing to a shortage of time and content we are cancelling today’s meeting. Apologies, Stig

1 0