March 2019 - openstack-discuss - lists.openstack.org

[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

[tripleo][openstack-ansible] collaboration on os_tempest role update XIV - Mar 13, 2019
by Chandan kumar 13 Mar '19

13 Mar '19

Hello, Here is the 13th update (Mar 06 to Mar 12, 2019) on collaboration on os_tempest[1] role between TripleO and OpenStack-Ansible projects. Highlights of the week: * docs for os_tempest role configuration added https://docs.openstack.org/openstack-ansible-os_tempest/latest/user/configu… * Now os_tempest role is less dependent on root user * How os_tempest job is defined in tripleo side docs added https://docs.openstack.org/tripleo-docs/latest/install/basic_deployment/os_… * python-tempestconf is gatted with os_temepst tripleo job * Tripleo can now collect os_tempest realted files at one place in user's home directory under tempest folder. http://logs.openstack.org/76/640976/5/check/tripleo-ci-centos-7-standalone-… Thanks to Arx, Martin Kopec, Marios, Sagi on docs help, tempest log collection, odyssey4me, jrosser on tempest vars cleanup & cloudnull, mnaser on other reviews. Things got merged: [os_tempest] * Create tempest related directories from ansible user - https://review.openstack.org/640005 * Remove tempest_image_dir_owner var - https://review.openstack.org/629419 * Document os_tempest configuration options - https://review.openstack.org/639147 [openstack-ansible] * Set tempest_image_dir to /opt/cache/files in openstack CI - https://review.openstack.org/641308 [python-tempestconf] * Add tripleo-ci-centos-7-standalone-os-tempest job - https://review.openstack.org/640992 [tripleo] * Add os_tempest documentation - https://review.openstack.org/#/c/640859/ * Collect os_tempest files from tempest directory - https://review.openstack.org/#/c/640976/ Things in Progress: [os_tempest] * Fix tempest_image_dir default var to user's home tempest-image dir - https://review.openstack.org/640742 * os_tempest dependencies: https://review.openstack.org/#/q/topic:ostempest_packaging+(status:open+OR+… [tripleo] * Adding tempest .txt files in collect-logs role - https://review.openstack.org/#/c/640358/ What next this week: * make tripleo os_tempest job voting * complete os_tempest dependencies * Some more docs addition on how to run os_tempest role locally with minimal vars. Here is the 13th update [2]. Have queries, Feel free to ping us on #tripleo or #openstack-ansible channel. Links: [1.] http://git.openstack.org/cgit/openstack/openstack-ansible-os_tempest [2.] http://lists.openstack.org/pipermail/openstack-discuss/2019-March/003482.ht… Thanks, Chandan Kumar

1 0

[nova] [openstack-charms] [elections] 'Train' Release PTL Election Kickoff
by Kendall Nelson 12 Mar '19

12 Mar '19

Hello Everyone! Polls for PTL elections are now open and will remain open for you to cast your vote until Mar 19, 2019 23:45 UTC. We are having elections for Nova and OpenStack_Charms. If you are a Foundation individual member and had a commit in one of the program's projects[0] over the Feb 09, 2018 00:00 UTC - Feb 19, 2019 00:00 UTC timeframe (Rocky to Stein) then you are eligible to vote. You should find your email with a link to the Condorcet page to cast your vote in the inbox of your gerrit preferred email[1]. What to do if you don't see the email and have a commit in at least one of the programs having an election: * check the trash or spam folders of your gerrit Preferred Email address, in case it went into trash or spam * wait a bit and check again, in case your email server is a bit slow * find the sha of at least one commit from the program project repos[0] and email the election officials. If we can confirm that you are entitled to vote, we will add you to the voters list for the appropriate election. Our democratic process is important to the health of OpenStack, please exercise your right to vote! Candidate statements/platforms can be found linked to Candidate names on this page: https://governance.openstack.org/election/#train-ptl-candidates Happy voting, -Kendall Nelson (diablo_rojo) [0] The list of the program projects eligible for electoral status: https://git.openstack.org/cgit/openstack/governance/plain/reference/project… [1] Sign into review.openstack.org: Go to Settings > Contact Information. Look at the email listed as your Preferred Email. That is where the ballot has been sent.

1 0

[ptl][I18n][election] PTL Candidacy for Train
by Ian Y. Choi 12 Mar '19

12 Mar '19

Hello, I am writing to announce my PTL candidacy of I18n for Train release. I served the PTL role on Ocata and Pike cycle, and have been great memory with last three release cycles with Frank who did so wonderful PTL activities. During Train cycle, I would like to do and collaborate with team members: * Helping to continue previous nice work (e.g., translation checksite, user-survey translation) * Investigating with Zanata's health and possible alternatives [1] * Communicating with translators and language coordinators * Sharing the voice from OpenStack teams with I18n team * Clean handover to the next PTL or discussing with team's direction (e.g., to a working group) I want to add the fourth part - as Frank wrote non-candicacy [2], it would be so great if the project gets fresh air. I don't think I am the part of fresh air since I also stayed in I18n team a lot like Frank. But it seems that I18n team needs more transition and hand-over period for a new PTL, or more discussion with team members might be needed to think about our team's direction such as changing the team status from an official team to a working group. With many thanks, /Ian [1] https://www.redhat.com/archives/zanata-devel/2019-February/msg00000.html [2] http://lists.openstack.org/pipermail/openstack-i18n/2019-March/003367.html

1 0

[ironic][ceilometer] Does anyone use the sensor data collection?
by Julia Kreger 12 Mar '19

12 Mar '19

Greetings everyone, I've been pondering retooling the metrics collection design in ironic, and I'm extremely curious if anyone actually uses what is presently in ironic in terms of metrics collection integration with ceilometer. The events, if enabled, should be getting funneled under the event_type "hardware.ipmi.metrics.update". If your using it, please contact me off-list. Thanks, -Julia

1 0

[ptl][sdk][election] PTL Candidacy
by Monty Taylor 12 Mar '19

12 Mar '19

Hi everybody! I'd like to run for PTL of OpenStackSDK again. We've been angling for a 1.0 release for the last few cycles and still haven't gotten there. We haven't gotten there because as we continue to merge in the shade logic, we've been finding places where we need to make some fundamental changes to the model. For instance, we made all Resource objects also behave like dicts, so that shade methods could return Resource objects directly. In order to do that, we had to rename the 'update' method on Resource objects to 'commit', since dicts have an update method already. We're currently in the midst of moving a good amount of the shade logic into the Proxy layer, so that uploading an image via the shade api or the proxy api is using the same code. That will be ongoing but should mostly be non-disruptive. I believe we're close enough, and have enough of a co-gating relationship with openstackclient, that this next cycle we need to start the work of shifting openstackclient implemention to openstacksdk from the python clients. Doing this should help us shake out any last remaining model deficiencies. We managed to get several long-standing todo list items done this past cycle. Cinder v3 support landed. Finally. We're also microversioning the Ironic calls, and have a good framework in place to do so with the other services as needed. We got the FairSemaphore feature added to keystoneauth which lets us remove the TaskManager and instead rely on an applications existing concurrency mechanism to handle parallelism while retaining our ability to perform client-side rate limiting. This change was actually inspired by some issues we saw in the field with Nodepool and the extra overhead from the TaskManager thread pool, but should end up facilitating more efficient use of openstacksdk constructs in OpenStack services using eventlet or other non-thread based concurrency systems. We still need to overhaul the caching layer. But once TaskManager is out we should be in a better place to deal with that. I'm sure there will be more things to do too. There always are. In any case, I'd love to keep helping to pushing these rocks uphill. Thanks! Monty

1 0

[stable][EM] Extended Maintenace - Pike
by Elõd Illés 12 Mar '19

12 Mar '19

Hi, As we are nearing to Pike Extended Maintenance (release page [1] shows 2019-03-03 but most probably will happen after Stein release) I have generated the list of open changes and unreleased changes on *stable/pike* for the follows-policy tagged repositories [2] (that seems to have relevant changes). Maybe it is useful for teams, who are planning to do a final release on Pike before moving stable/pike branches to Extended Maintenance. [1] https://releases.openstack.org/ [2] https://etherpad.openstack.org/p/pike-final-release-before-em Thanks, Előd

1 0