June 2019 - openstack-discuss - lists.openstack.org

[scientific-sig] IRC meeting today - ISC roundup, HPC containers, Shanghai CFP
by Stig Telfer 19 Jun '19

19 Jun '19

Hi all - We have a Scientific SIG IRC meeting at 1100 UTC (just under an hour’s time). Everyone is welcome. Today’s agenda is here: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_June_19th_2019 <https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_June_19th_2019> Today we’ll do a roundup of the HPC/cloud activity from the International Supercomputer Conference currently underway in Frankfurt. We’ll also have trip reports from the HPC containers workshop (also in Frankfurt) and the Sanger OpenStack day. Finally, we’d like to kick-off the planning for coordinated activities at the Shanghai Open Infrastructure Summit. Cheers, Stig

1 0

[telemetry] Cancel team meeting tomorrow
by Trinh Nguyen 19 Jun '19

19 Jun '19

Hi team, Unfortunately, I am on a business trip tomorrow so we cannot hold the team meeting. Please continue any conversation on the IRC channel if you want. For anything else, please let me know. Thank you, -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

1 0

[nova][dev][ops] server status when compute host is down
by melanie witt 18 Jun '19

18 Jun '19

Hey all, I'm looking for feedback around whether we can improve how we show server status in server list and server show when the compute host it resides on is down. When a compute host goes down while a server on it was previously running, the server status continues to show as ACTIVE in a server list. This is because the power state and status is adjusted by a periodic task run by nova-compute, so if nova-compute is down, it cannot update those states. So, for an end user, when they do a server list, they see their server as ACTIVE when it's actually powered off. We have another field called 'host_status' available since API microversion 2.16 [1] which is controlled by policy and defaults to admin, which is capable of showing the server status as UNKNOWN if the field is specified, for example: nova list --fields id,name,status,task_state,power_state,networks,host_status This is cool, but it is only available to admin by default, and it requires that the end user adds the field to their CLI command in the --fields option. Question: do people think we should make the server status field reflect UNKNOWN as well, if the 'host_status' is UNKNOWN? And if so, should it be controlled by policy or no? Normally, we do not expose compute host details to non-admin in the API by default, but I noticed recently that our "down cells" support will show server status as UNKNOWN if a server is in a down cell [2]. So I wondered if it would be considered OK to show UNKNOWN if a host is down we well, without defaulting it to admin-only. I would really appreciate if people could share their opinion here and if consensus is in support, I will move forward with proposing a change accordingly. Cheers, -melanie [1] https://docs.openstack.org/nova/latest/reference/api-microversion-history.h… [2] https://github.com/openstack/nova/blob/66a77f2fb75bbb9daebdca1cad0255ecafe4…

8 14

[nova] [placement] [ops] visualizing placement data as a graph
by Balázs Gibizer 18 Jun '19

18 Jun '19

Hi, Have you ever wondered how the placement resource provider tree looks like in your deployment or in your functional test? I did, so I put together a tool that can dump these trees as a dot file so it can be visualized as a graph. The osc-placement-tree [1][2] works as an openstack CLI plugin and also gives adapters to dump the trees from nova and placement functional test envs. Cheers, gibi [1] https://pypi.org/project/osc-placement-tree [2] https://github.com/gibizer/osc-placement-tree

2 1

[oslo] Courtesy ping changes
by Ben Nemec 18 Jun '19

18 Jun '19

Important: Action is required if you want to continue receiving courtesy pings. Read on for details. This is an oslo-specific followup to [0]. There's a lot of good discussion there if you're interested in the background for this email. The TLDR version is that we're going to keep the Oslo courtesy ping list because a number of Oslo contributors have expressed their preference for it. However, we are making some changes. First, the ping list will be cleared at the start of each cycle. This should prevent us from pinging people who no longer work on Oslo (which is almost certainly happening right now). Everyone who wants a courtesy ping will need to re-opt-in each cycle. We'll work out a transition process so people don't just stop receiving pings. Second, the ping list is going to move from the script in oslo.tools to the meeting agenda[1] on the wiki. There's no need for Oslo core signoff on ping list changes and that makes it a waste of time for both the cores and the people looking to make changes to the list. This does mean we'll lose the automatic wrapping of the list, but once we clean up the stale entries I suspect we won't need to wrap it as much anyway. I will continue to use the existing ping list for the next two weeks to give everyone a chance to add their name to the new list. I've seeded the new list with a couple of people who had expressed interest in continuing to receive pings, but if anyone else wants to continue getting them please add yourself to the list in [1] (see the Agenda Template section). I'm intentionally _not_ adding all of the active Oslo cores on the assumption that you may prefer to set up your own notification method. I might automatically carry over cores from cycle to cycle since they are presumably still interested in Oslo and chose that notification method, but we'll worry about that at the start of next cycle. I think that covers the current plan for courtesy pings in Oslo. If you have any comments or concerns please let me know. Otherwise expect this new system to take effect in 3 weeks. Thanks. -Ben 0: http://lists.openstack.org/pipermail/openstack-discuss/2019-May/006235.html 1: https://wiki.openstack.org/wiki/Meetings/Oslo

1 1

[openstack-helm] Voting for OpenStack-Helm IRC Meeting Times
by MCEUEN, MATT 18 Jun '19

18 Jun '19

Hi team, As discussed in the Denver PTG, OpenStack-Helm has a number of contributors across Europe, Asia, and the US, and there's no single weekly meeting time that works well for everyone. There are also different approaches that could be used to better accommodate team members in different time zones. Let's vote as a team to get the Times/Approaches that work for the majority of contributors Tuesday meeting times: - Time A: [1pm UTC] https://everytimezone.com/s/d147ddd2 - Time B: [3pm UTC] https://everytimezone.com/s/d5289c0a - Time C: [9pm UTC] https://everytimezone.com/s/c5ee2f54 - Time D: [10pm UTC] https://everytimezone.com/s/c428653b Time B is our current meeting time. We also have three different ways we can approach those meeting times: - Uniform: same meeting time every week - Alternating: switch between two different times, every other week - Doubled: have two meetings every Tuesday on opposite ends of the day If we did "Doubled", portdirect would generally facilitate both meetings, along with anyone who wanted to attend both; in general team members wouldn't be expected to be at both. INSTRUCTIONS: Please use the following etherpad: https://etherpad.openstack.org/p/airship-meeting-vote-2019 Please vote for your top five preferred meeting schedules, one per line, including a Time and an Approach. Please include your name/nick. Example: example_person: 1. Time A Uniform 2. Time D Uniform 3. Time A and D Alternating 4. Time A and C Doubled 5. Time C Uniform Portdirect will abstain from voting, do a by-hand Condorcet tally, and share the results. I'm helping him facilitate. Voting is open to all OpenStack-Helm Contributors, will conclude EOD Tuesday the 25th, so we get two shots at reminding folks in the team meetings. Thanks! Matt

1 0

[placement] candidate logo
by Chris Dent 18 Jun '19

18 Jun '19

https://burningchrome.com/magpie2.png Is the latest iteration of the candidate placement logo. Please shout out if it's not okay. It's been through a few iterations of feedback to get it to a form closer to what we discussed a couple of weeks ago. For those not aware: The image is of an Australian Magpie. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent

6 9

[nova][tempest] Should we make image certificate validation a configurable feature?
by Lee Yarwood 18 Jun '19

18 Jun '19

Hello all, $subject, this came up downstream after we noticed failures due to a race within the ServerShowV263Test test that I've documented in the following upstream bug: tempest.api.compute.servers.test_servers.ServerShowV263Test only passing when image has already been cached https://bugs.launchpad.net/tempest/+bug/1831866 As the test itself is pretty useless without valid certs, signed images etc I'd like to make the overall feature optional within Tempest and wire up some additional configurables for anyone looking to actually test this correctly. I've received some feedback in the review but this has stalled so I wanted to see if I could get things moving again by posting to the ML. Thanks in advance, -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76

2 2

[neutron] Bug deputy report for the week of June 10th
by Miguel Lavalle 17 Jun '19

17 Jun '19

Critical: https://bugs.launchpad.net/neutron/+bug/1832307 Functional test neutron.tests.functional.agent.linux.test_ip_lib.IpMonitorTestCase. test_add_remove_ip_address_and_interface is failing. Proposed fix: https://review.opendev.org/#/c/664889/ https://bugs.launchpad.net/neutron/+bug/1832968 neutron tempest test fails 100% due to abandoned ubuntu image release. Fix proposed and merged: https://review.opendev.org/665530 https://bugs.launchpad.net/bgpvpn/+bug/1833051 Unit tests in networking-bgpvpn are broken. Fix proposed: https://review.opendev.org/#/c/665637/ High: https://bugs.launchpad.net/neutron/+bug/1832985 Update of segmentation id for network don't works. Fix proposed: https://review.opendev.org/#/c/665548/, https://review.opendev.org/#/c/665623/ Medium: https://bugs.launchpad.net/neutron/+bug/1832636 Error creating IPv6 subnet on routed network segment https://bugs.launchpad.net/neutron/+bug/1832021 Checksum drop of metadata traffic on isolated networks with DPDK (needs further triaging) https://bugs.launchpad.net/neutron/+bug/1832210 incorrect decode of log prefix under python 3 https://bugs.launchpad.net/neutron/+bug/1832278 Reference policies related to 'update_port' don't work properly with shared network. Proposed fix: https://review.opendev.org/664470 https://bugs.launchpad.net/neutron/+bug/1832745 _update_network_segmentation_id KeyError: 'provider:network_type' https://bugs.launchpad.net/neutron/+bug/1815762 you can end up in a state where qvo* interfaces aren't owned by ovs which results in a dangling connection https://bugs.launchpad.net/neutron/+bug/1832925 Class neutron.common.utils.Timer is not thread safe Low: https://bugs.launchpad.net/neutron/+bug/1832603 BGP dynamic routing config doc should use openstack client in examples. Assigned to tidwellr https://bugs.launchpad.net/neutron/+bug/1832743 delete_dvr_dst_mac_for_arp uses wrong table id. Proposed fix: https://review.opendev.org/#/c/665175/ (approved) https://bugs.launchpad.net/neutron/+bug/1833122 FWaaS admin documentation is outdated. Fix proposed: https://review.opendev.org/#/c/665749/ https://bugs.launchpad.net/neutron/+bug/1833125 Remaining neutron-lbaas relevant code and documentation RFEs: https://bugs.launchpad.net/neutron/+bug/1832526 [RFE] Network segmentation support for edge deployments https://bugs.launchpad.net/neutron/+bug/1832758 [RFE] Allow/deny custom ethertypes in security groups Incomplete: https://bugs.launchpad.net/neutron/+bug/1832769 designate client requires region name to fetch PTR records Invalid / Won't fix: https://bugs.launchpad.net/neutron/+bug/1832574 Able to update the http-method-type for ICMP type healthmonoitor

1 0

ocatvia on rocky openstack environment does not work as expected
by Sergio Traldi 17 Jun '19

17 Jun '19

Hi, I installed using packstack 2 node 1 controller and 1 compute with rocky release in CentOS 7 OS. I define an external network and configure openvswitch and I can assign floating IP. Everythings works fine. (VMs creation, images upload, security group, key pair, ...) I tested neutron, glance, nova, keystone, ... I followed the documentation to install ad configure octavia, so I create the user, the endpoint, the db, the network lb-mgmt-net, the subnet, the neutron security group for amphorae and the rules, the image amphorae, I tagged the image,... I set the main values in /etc/octavia/octavia.conf for keystone for the bind, and so on ... and I started the services. I followed these documentations: https://docs.openstack.org/octavia/queens/contributor/guides/dev-quick-star… http://sudomakeinstall.com/uncategorized/building-octavia-images-with-cento… https://blog.zufardhiyaulhaq.com/manual-instalation-octavia-openstack-queens At the end everything seems to work but I have two "problems" 1): I can not create a lb without a project from the openstack client if I do: [root@cld-ctrl-pa-02 ~(keystone_admin)]# openstack loadbalancer create --name lb --vip-subnet-id c5887a52-bddb-4e8b-8023-cd7c341194fa Validation failure: Missing project ID in request where one is required. (HTTP 400) (Request-ID: req-1b9307c5-8aee-472d-ac56-44b6f34b05ce) If I put the project the lb has been created: [root@cld-ctrl-pa-02 ~(keystone_admin)]# openstack loadbalancer create --name lb1 --vip-subnet-id c5887a52-bddb-4e8b-8023-cd7c341194fa --project c86066dd95e345c386ef5e095b83918a +---------------------+--------------------------------------+ | Field | Value | +---------------------+--------------------------------------+ | admin_state_up | True | | created_at | 2019-06-11T14:02:10 | | description | | | flavor | | | id | f740be24-edf1-459c-ac77-c93917cbca31 | | listeners | | | name | lb1 | | operating_status | OFFLINE | | pools | | | project_id | c86066dd95e345c386ef5e095b83918a | | provider | amphora | | provisioning_status | PENDING_CREATE | | updated_at | None | | vip_address | 198.51.100.1 | | vip_network_id | e4a02581-1d90-4ea2-9e73-681ff66a4328 | | vip_port_id | 1666d874-f1b5-437e-a989-ea49f65ba5a3 | | vip_qos_policy_id | None | | vip_subnet_id | c5887a52-bddb-4e8b-8023-cd7c341194fa | +---------------------+--------------------------------------+ But the project has been not a mandatory value to pass to the client. 2) Second problem: all the loadbalancers I created lay on the lb-mgmt-subent and not in the subnet I passed. In the example above. My subnet is like this: [root@cld-ctrl-pa-02 ~(keystone_admin)]# openstack subnet list | grep c5887a52-bddb-4e8b-8023-cd7c341194fa | c5887a52-bddb-4e8b-8023-cd7c341194fa | private_subnet | 8d37ca14-47b8-4ce8-aa27-fb4f8267d9ab | 10.0.0.0/24 | But the VIP created is 198.51.100.1 and each loadbalancer I create have that IP as VIP and I think this is not correct: [root@cld-ctrl-pa-02 ~(keystone_admin)]# openstack loadbalancer list +--------------------------------------+----------+----------------------------------+--------------+---------------------+----------+ | id | name | project_id | vip_address | provisioning_status | provider | +--------------------------------------+----------+----------------------------------+--------------+---------------------+----------+ | 21d121fd-799f-4244-bf33-622e2fcd0060 | lb-demo | 78932a05499d4916bfd1895f7017cac1 | 198.51.100.1 | ACTIVE | amphora | | 94653251-849e-41c4-9071-f75382a46569 | lb-test | 78932a05499d4916bfd1895f7017cac1 | 198.51.100.1 | ACTIVE | amphora | | a76ccc28-0242-46e4-8ac5-b1410a29cf4a | lb1 | 78932a05499d4916bfd1895f7017cac1 | 198.51.100.1 | ACTIVE | amphora | | f740be24-edf1-459c-ac77-c93917cbca31 | lb789 | c86066dd95e345c386ef5e095b83918a | 198.51.100.1 | ACTIVE | amphora | | aeb6e964-fc24-4b04-aa94-9b5ccfe4eb09 | lb-test2 | 78932a05499d4916bfd1895f7017cac1 | 198.51.100.1 | ACTIVE | amphora | +--------------------------------------+----------+----------------------------------+--------------+---------------------+----------+ I tried using different users and different projects and different networks but the result is the same in all loadbalancer created. In log file I dis not find anything useful for all of the problems. If someone has got some hints it could be great. For the first problem I found this ( http://www.codeha.us/openstack-discuss/msg00906.html ) but nobody answer to this problem. The second may be is correct but I expect different VIP for each loadbalancer crerated and may be in the network I passed not int eh lb management subenet. Thanks in advance Cheers Sergio

2 1