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

[neutron] Zuul checks fail
by Bernard Cafarelli 17 Jun '19

17 Jun '19

Hi neutrinos, a quick heads-up that currently Zuul will 100% give -1 on your reviews, failing 404 Not Found when trying to download Ubuntu Xenial image. Thanks to Yulong for filling launchpad bug [0] and submitting fix [1]. Once it is merged, we should be back in business [0] https://bugs.launchpad.net/neutron/+bug/1832968 [1] https://review.opendev.org/#/c/665530/ -- Bernard Cafarelli

1 1

[all][qinling] Please check your README files
by Marcin Juszkiewicz 17 Jun '19

17 Jun '19

Train cycle is supposed to be "we really go for Python 3" cycle. Contrary to previous "we do not have to care about Python 3" ones. I am working on switching Kolla images into Python 3 by default [1]. It is a job I would not recommend even to my potential enemies. Misc projects fail into random ways (sent a bunch of patches). 1. https://review.opendev.org/#/c/642375 Quite common issue is related to README files. I know that we have XXI century and UTF-8 is encoding for most of people here. But Python tools are not so advanced so far and loves to explode when see characters outside of US-ASCII encoding. Please check your README files. And move them to US-ASCII if needed. I already fixed few projects [2][3][4][5] but would love to see developers fixing their code too. 2. https://review.opendev.org/644531 3. https://review.opendev.org/644533 4. https://review.opendev.org/644535 5. https://review.opendev.org/644536

5 8

[telemetry] volume_type_id stored instead of volume_type name
by Florian Engelmann 17 Jun '19

17 Jun '19

Hi, some volumes are stored with the volume_type Id instead of the volume_type name: openstack metric resource history --details b5496a42-c766-4267-9248-6149aa9dd483 -c id -c revision_start -c revision_end -c instance_id -c volume_type +--------------------------------------+----------------------------------+----------------------------------+--------------------------------------+--------------------------------------+ | id | revision_start | revision_end | instance_id | volume_type | +--------------------------------------+----------------------------------+----------------------------------+--------------------------------------+--------------------------------------+ | b5496a42-c766-4267-9248-6149aa9dd483 | 2019-05-08T07:21:35.354474+00:00 | 2019-05-21T09:18:32.767426+00:00 | 662998da-c3d1-45c5-9120-2cff6240e3b6 | v-ssd-std | | b5496a42-c766-4267-9248-6149aa9dd483 | 2019-05-21T09:18:32.767426+00:00 | 2019-05-21T09:18:32.845700+00:00 | 662998da-c3d1-45c5-9120-2cff6240e3b6 | v-ssd-std | | b5496a42-c766-4267-9248-6149aa9dd483 | 2019-05-21T09:18:32.845700+00:00 | None | 662998da-c3d1-45c5-9120-2cff6240e3b6 | 8bd7e1b1-3396-49bf-802c-8c31a9444895 | +--------------------------------------+----------------------------------+----------------------------------+--------------------------------------+--------------------------------------+ I was not able to find anything fishy in ceilometer. So I guess it could be some event/notification with a wrong payload? Could anyone please verify this error is not uniq to our (rocky) environment by running: openstack metric resource list --type volume -c id -c volume_type All the best, Florian

2 1

[tripleo][molecule] feedback on testing ansible roles with molecule
by Sorin Sbarnea 17 Jun '19

17 Jun '19

Hi! While we do now have a POC job running molecule with tox for testing one tripleo-common role, I would like to ask for some feedback from running the same test locally, on your dev box. The report generated but openstack-tox-mol job looks like http://logs.openstack.org/36/663336/14/check/openstack-tox-mol/aa7345d/tox/… <http://logs.openstack.org/36/663336/14/check/openstack-tox-mol/aa7345d/tox/…> https://review.opendev.org/#/c/663336/ <https://review.opendev.org/#/c/663336/> Just download it and run: tox -e mol You will either need docker or at least to define DOCKER_HOST=ssh://somehost <ssh://somehost> as an alternative. Please send the feedback back to me or directly on the the review. Over the last days I fixed few minor issues related to differences between user environments and I want to make I improve it as much as possible. Thanks Sorin Sbarnea Tripleo CI

3 3

[nova] Strict isolation of group of hosts for image and flavor, modifying command 'nova-manage placement sync_aggregates'
by Kamde, Vrushali 17 Jun '19

17 Jun '19

Hi, Working on implementation of 'Support filtering of allocation_candidates by forbidden aggregates' spec. Need discussion particularly for point [1] where traits needs to be sync along with aggregates at placement. Master implementation for 'nova-manage placement sync_aggregates' command is to sync the nova host aggregates. Modifying this command to sync trait metadata of aggregate at placement. Below are the aggregate restful APIs which currently supports: 1. 'POST'-- /os-aggregates/{aggregate_id}/action(Add host) getting synced on the placement service 2. 'POST'-- /os-aggregates/{aggregate_id}/action(Remove host) getting synced on the placement service 3. 'POST'-- /os-aggregates/{aggregate_id}/action(set metadata) Doesn't get sync on the placement service. 4. 'POST'-- /os-aggregates/{aggregate_id}/action(unset metadata) Doesn't get sync on the placement service. I have added code to sync traits for below APIs and I don't see any issues there: 1. 'POST'-- /os-aggregates/{aggregate_id}/action(Add host) 2. 'POST'-- /os-aggregates/{aggregate_id}/action(set metadata) But there is an issue while removing traits for below APIs: 1. 'POST'-- /os-aggregates/{aggregate_id}/action(Remove host) 2. 'POST'-- /os-aggregates/{aggregate_id}/action(unset metadata) Ideally, we should remove traits set in the aggregate metadata from the resource providers associated with the aggregate for above two APIs but it could cause a problem for below scenario:- For example: 1. Create two aggregates 'agg1' and 'agg2' by using: 'POST'-- /os-aggregates(Create aggregate) 2. Associate above aggregates to host 'RP1' by using: 'POST'-- /os-aggregates/{aggregate_id}/action(Add host) 3. Setting metadata (trait:STORAGE_DISK_SSD='required') on the aggregate agg1 by using: 'POST'-- /os-aggregates/{aggregate_id}/action(set metadata) 4. Setting metadata (trait:STORAGE_DISK_SSD='required', trait:HW_CPU_X86_SGX='required') on the aggregate agg2 by using: 'POST'-- /os-aggregates/{aggregate_id}/action(set metadata) Traits set to 'RP1' are: STORAGE_DISK_SSD HW_CPU_X86_SGX Note: Here trait 'STORAGE_DISK_SSD' is set on both agg1 and agg2. Now, If we remove host 'RP1' from 'agg1' then the trait 'STORAGE_DISK_SSD' set to `RP1` also needs to be removed but since 'RP1' is also assigned to 'agg2', removing 'STORAGE_DISK_SSD' trait from 'RP1' is not correct. I have discussed about syncing traits issues with Eric on IRC [2], he has suggested few approaches as below: - Leave all traits alone. If they need to be removed, it would have to be manually via a separate step. - Support a new option so the caller can dictate whether the operation should remove the traits. (This is all-or-none.) - Define a "namespace" - a trait substring - and remove only traits in that namespace. If I'm not wrong, for last two approaches, we would need to change RestFul APIs. Need your feedback whether traits should be deleted from resource provider or not for below two cases? 1. 'POST'-- /os-aggregates/{aggregate_id}/action(Remove host) 2. 'POST'-- /os-aggregates/{aggregate_id}/action(unset metadata) [1]: https://review.opendev.org/#/c/609960/8/specs/train/approved/placement-req-… [2]: http://eavesdrop.openstack.org/irclogs/%23openstack-nova/%23openstack-nova.… Thanks & Regards, Vrushali Kamde Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding.

5 11

Comparative analysis of openstack and Cloudstack
by Dhairyasheel Ghadge 17 Jun '19

17 Jun '19

Hello all!!! I have been exploring the cloudstack cloud platform while comparing it with the openstack cloud platform. I am a little skeptical about which solution to use as our cloud platform between cloudstack and OpenStack. Following are the difficulties I am facing which comparing these two solutions. 1.) OpenStack has HEAT as the component for orchestration of application VM's deployed and the cloud setup services as well. Is there any orchestration feature in cloudstack which provides an autscaling feature for the application deployed in it? 2.) OpenStack has TROVE for DBaaS which takes care of the entire lifecycle of the database service which includes deployment, configuration, replication, failover, backup, patching, restores. Is there any similar service in cloudstack for providing DBaaS? 3.) Cloudstack documentation says that it has orchestration feature for its applications, but couldn't find any details regarding the same. Also, for big data Hadoop clusters provisioning, SAHARA component is used in OpenStack. What does this sahara feature provides and is it useful for big data applications? This is feature is not there in cloudstack. What is the importance of serverless functionality feature "Qinling" in openstack which is not there in cloudstack Are there any points of Openstack which completely outshines itself from cloudstack? Thankyou Dhairyasheel Ghadge

2 1

getting issues while configuring the Trove
by Saikrishna Ura 17 Jun '19

17 Jun '19

Hi, I installed Openstack in Ubuntu 18.04 by cloning the devstack repository with this url "git clone https://git.openstack.org/openstack-dev/devstack", but i can't able create or access with the trove, I'm getting issues with the installation. Can anyone help on this issue please. If any reference document or any guidance much appreciated. Thanks, Saikrishna U.

3 4

[Keystone] Performance degradation
by Gary Kotton 17 Jun '19

17 Jun '19

Hi, Over the last few weeks we have being doing performance tests on the Stein version and have seen a notable performance degradation. Further investigation showed that Keystone seems to be the bottleneck. An example of this is running a Rally test that creates a keystone tenant with users. We see that in Queens this takes 20 seconds to complete the whole iteration whilst Stein takes 30 seconds. We have done the following tests: 1. Vanilla devstack Queens vs Steins 2. In our Stein version e have swapped out the Keystone Stein container with the Keystone Queens container and the numbers are considerably better too (please note the same keystone configuration is used with regards to processes/threads etc.) Are any folks familiar with what may cause this? Are there any performance improvement suggestions or hints? Thanks Gary

2 4

[nova] Admin user cannot create vm with user's port?
by Lingxian Kong 17 Jun '19

17 Jun '19

Hi Nova team, In Nova, even the admin user cannot specify user's port to create a vm, is that designed intentionally or sounds like a bug? Best regards, Lingxian Kong Catalyst Cloud

3 6

Nova scheduler -- which compute node?
by Ken D'Ambrosio 16 Jun '19

16 Jun '19

Hey, all. First things first: we're running Juno. Yeah, it's ancient, and we've got Queens on-deck, but it's Juno. Anyway, to my question: how can you tell which compute node is *actually getting* the VM request, shy of logging into them and looking? For example, on the Nova node, you can see the nova-scheduler.log file talk about which hosts are weighted how, but it doesn't seem as if it actually comes out and says which host it's trying to give the VM to. Am I missing something? (I'd happily supply log snippets, but I figure this is a fairly general question, and didn't want to paste 1.7 TB of random, possibly-relevant logs.) Thanks! -Ken

2 1

[nova] 'pre-commit' integration
by Stephen Finucane 15 Jun '19

15 Jun '19

This is a heads up that I've proposed a patch to integrate [1] to add support for the 'pre-commit' tool [2] in nova. As noted in that change, this provides a faster, most automated alternative to the 'fast8' tox target we currently use for validating recently changed code. While this is opt-in, I'm also proposing deprecating the 'fast8' behavior since I don't think it's necessary with pre-commit support. As a result, it would be good if anyone that has an opinion on the matter took a look at the change. Have a good weekend, Stephen [1] https://review.opendev.org/665518 [2] https://pre-commit.com/

1 0

Are most grenade plugin projects doing upgrades wrong?
by Matt Riedemann 14 Jun '19

14 Jun '19

While fixing how the watcher grenade plugin is cloning the watcher repo for the base (old) side [1] to hard-code from stable/rocky to stable/stien, I noticed that several other projects with grenade plugins aren't actually setting a stable branch when cloning the plugin for the old side [2]. So I tried removing the stable/stein branch from the base plugin clone in watcher [3] and grenade cloned from master for the base (old) side [4]. Taking designate as an example, I see the same thing happening for it's grenade run [5]. Is there something I'm missing here or are most of the openstack projects running grenade via plugin actually just upgrading from master to master rather than n-1 to master? [1] https://review.opendev.org/#/c/664610/1/devstack/upgrade/settings [2] http://codesearch.openstack.org/?q=base%20enable_plugin&i=nope&files=&repos= [3] https://review.opendev.org/#/c/664610/2/devstack/upgrade/settings [4] http://logs.openstack.org/10/664610/2/check/watcher-grenade/ad2e068/logs/gr… [5] http://logs.openstack.org/47/662647/6/check/designate-grenade-pdns4/0b8968f… -- Thanks, Matt

3 2

[placement] update 19-23
by Chris Dent 14 Jun '19

14 Jun '19

HTML: https://anticdent.org/placement-update-19-23.html 19-23. I'll be travelling the end of next week so there will be no 19-24. # Most Important We keep having interesting and helpful, but not yet fully conclusive, discussions related to the [spec for nested magic](https://review.opendev.org/662191). The discussion on the spec links back to a few different IRC discussions. Part of the reason this drags on so much is that we're trying to find a model that is internally consistent in placement and generally applicable while satisfying the NUMA requirements from Nova, while not requiring either Placement or Nova to bend over backwards to get things right, and while not imposing additional complexity on simple requests. (And probably a few other whiles...) If you have thoughts on these sorts of things, join that review. In the meantime there are plenty of other things to review (below). # What's Changed * A blocker migration for incomplete consumers has been added, and the inline migrations that would guard against the incompleteness have been removed. * CORS configuration and use in Placement has been modernized and corrected. You can now, if you want, talk to Placement from JavaScript in your browser. (This was a bug I found while working on a [visualisation toy](https://github.com/cdent/placeview) with a friend.) * Result sets for certain nested provider requests could return different results in Python versions 2 and 3. This has [been fixed](https://review.opendev.org/663137). * That ^ work was the result of working on implementing [mappings in allocations](https://docs.openstack.org/placement/latest/specs/train/approv… which has [merged today as microversion 1.34](https://docs.openstack.org/placement/latest/placement-api-microversio… # Specs/Features * <https://review.opendev.org/654799> Support Consumer Types. This has some open questions that need to be addressed, but we're still go on the general idea. * <https://review.opendev.org/662191> Spec for nested magic 1. The easier parts of nested magic: same_subtree, resourceless request groups, verbose suffixes (already merged as 1.33). See "Most Important" above. Some non-placement specs are listed in the Other section below. # Stories/Bugs (Numbers in () are the change since the last pupdate.) There are 20 (0) stories in [the placement group](https://storyboard.openstack.org/#!/project_group/placement). 0 (0) are [untagged](https://storyboard.openstack.org/#!/worklist/580). 3 (0) are [bugs](https://storyboard.openstack.org/#!/worklist/574). 6 (2) are [cleanups](https://storyboard.openstack.org/#!/worklist/575). 11 (0) are [rfes](https://storyboard.openstack.org/#!/worklist/594). 2 (0) are [docs](https://storyboard.openstack.org/#!/worklist/637). If you're interested in helping out with placement, those stories are good places to look. * Placement related nova [bugs not yet in progress](https://goo.gl/TgiPXb) on launchpad: 16 (1). * Placement related nova [in progress bugs](https://goo.gl/vzGGDQ) on launchpad: 6 (-1). [1832814: Placement API appears to have issues when compute host replaced](https://bugs.launchpad.net/nova/+bug/1832814) is an interesting bug. In a switch from RDO to OSA, resource providers are being duplicated because of a change in node name. # osc-placement osc-placement is currently behind by 11 microversions. There are no changes that have had attention in less than 4 weeks. There are 4 other changes. # Main Themes ## Nested Magic The overview of the features encapsulated by the term "nested magic" are in a [story](https://storyboard.openstack.org/#!/story/2005575) and [spec](https://review.opendev.org/662191). There is some in progress code, mostly WIPs to expose issues and think about how things ought to work: * <https://review.opendev.org/663009> PoC: resourceless request, including some code from <https://review.opendev.org/657510> WIP: Allow RequestGroups without resources ## Consumer Types Adding a type to consumers will allow them to be grouped for various purposes, including quota accounting. A [spec](https://review.opendev.org/654799) has started. There are some questions about request and response details that need to be resolved, but the overall concept is sound. ## Cleanup We continue to do cleanup work to lay in reasonable foundations for the nested work above. As a nice bonus, we keep eking out additional performance gains too. There are two new stories about some minor performance degradations: * <https://storyboard.openstack.org/#!/story/2005888> GET /allocations/{non existent consumer} slower than expected * <https://storyboard.openstack.org/#!/story/2005889> Allocation mappings have introduced a slight performance reduction Gibi discovered that osprofiler wasn't working with placement and then fixed it: * <https://review.opendev.org/663945> Add support for osprofiler in wsgi Thanks to Ed Leafe for his report on the [state of graph database work](http://lists.openstack.org/pipermail/openstack-discuss/2019-June/0070…. # Other Placement Miscellaneous changes can be found in [the usual place](https://review.opendev.org/#/q/project:openstack/placement+status:op…. There are three [os-traits changes](https://review.opendev.org/#/q/project:openstack/os-traits+status:… being discussed. And one [os-resource-classes change](https://review.opendev.org/#/q/project:openstack/os-resource-classe…. # Other Service Users New discoveries are added to the end. Merged stuff is removed. Anything that has had no activity in 4 weeks has been removed. * <https://review.openstack.org/601596> Nova: spec: support virtual persistent memory * <https://review.openstack.org/#/q/topic:bug/1819923> Nova: nova-manage: heal port allocations * <https://review.openstack.org/650188> nova-spec: Allow compute nodes to use DISK_GB from shared storage RP * <https://review.opendev.org/659233> Cyborg: Placement report * <https://review.opendev.org/657801> rpm-packaging: placement service * <https://review.opendev.org/657016> Delete resource providers for all nodes when deleting compute service * <https://review.opendev.org/654066> nova test and fix for: Drop source node allocations if finish_resize fails * <https://review.opendev.org/656885> nova: WIP: Hey let's support routed networks y'all! * <https://review.opendev.org/662371> starlingx: Add placement chart patch to openstack-helm * <https://review.opendev.org/662229> helm: WIP: add placement chart * <https://review.opendev.org/662164> kolla-ansible: Add a explanatory note for "placement_api_port" * <https://review.opendev.org/656023> Nova: Use OpenStack SDK for placement * <https://review.opendev.org/612497> Nova: Spec: Provider config YAML file * <https://review.opendev.org/623558> Nova: single pass instance info fetch in host manager * <https://review.opendev.org/663478> docs: Add Placement service to Minimal deployment for Stein * <https://review.opendev.org/663270> devstack: Add setting of placement microversion on tempest conf * <https://review.opendev.org/634551> libvirt: report pmem namespaces resources by provider tree * <https://review.opendev.org/660852> Nova: Remove PlacementAPIConnectFailure handling from AggregateAPI * <https://review.opendev.org/661237> Nova: Validate requested host/node during servers create * <https://review.opendev.org/#/q/topic:bp/support-move-ops-with-qos-ports> Nova: support move ops with qos ports * <https://review.opendev.org/664631> Kolla-ansible: Fix placement log perms in config.json * <https://review.opendev.org/665168> TripleO: Enable Request Filter for Image Types * <https://review.opendev.org/663979> Neutron: Force segments to use placement 1.1 * <https://review.opendev.org/664689> Nova: get_ksa_adapter: nix by-service-type confgrp hack * <https://review.opendev.org/664862> OSA: Add nova placement to placement migration # End If you, like me, use this collection of information to drive what to do early in the next week, you might like [placement-reviewme](https://github.com/cdent/placement-reviewme) which brute force loads all the links from the HTML version of this in tabs in your browser. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent

1 0

[requirements][kuryr][flame] openshift dificulties
by Matthew Thode 14 Jun '19

14 Jun '19

Openshift upstream is giving us difficulty as they are capping the version of urllib3 and kubernetes we are using. -urllib3===1.25.3 +urllib3===1.24.3 -kubernetes===9.0.0 +kubernetes===8.0.1 I've opened an issue with them but not had much luck there (and their prefered solution just pushes the can down the road). https://github.com/openshift/openshift-restclient-python/issues/289 What I'd us to do is move off of openshift as our usage doesn't seem too much. openstack/kuryr-tempest-plugin uses it for one import (and just one function with that import). I'm not sure exactly what you are doing with it but would it be too much to ask to move to something else? x/flame has it in it's constraints but I don't see any actual usage, so perhaps it's a false flag. Please let me know what you think -- Matthew Thode

3 7

[charms] Proposing Sahid Orentino Ferdjaoui to the Charms core team
by Chris MacNaughton 14 Jun '19

14 Jun '19

Hello all, I would like to propose Sahid Orentino Ferdjaoui as a member of the Charms core team. Chris MacNaughton

5 4

Retiring TripleO-UI - no longer supported
by Jason Rist 13 Jun '19

13 Jun '19

Hi everyone - I’m writing the list to announce that we are retiring TripleO-UI and it will no longer be supported. It’s already deprecated in Zuul and removed from requirements, so I’ve submitted a patch to remove all code. https://review.opendev.org/661113 Thanks, Jason Jason Rist Red Hat <https://www.redhat.com/> jrist / knowncitizen <https://www.redhat.com/>`

3 7

[nova] Help wanted with bug triage!
by Eric Fried 13 Jun '19

13 Jun '19

Folks- Nova's queue of untriaged bugs [1] has been creeping slowly upward lately. We could really use some focused effort to get this back under control. We're not even (necessarily) talking about *fixing* bugs - though that's great too. We're talking about triaging [2]. If every nova contributor (you don't need to be a core) triaged just one bug a day, it wouldn't take long for things to be back in manageable territory. Thanks in advance. efried [1] https://bugs.launchpad.net/nova/+bugs?search=Search&field.status=New [2] https://wiki.openstack.org/wiki/Nova/BugTriage

1 0

Re: [tc] Recap for Technical Committee Meeting 6 June 2019 @ 1400 UTC
by Alexandra Settle 13 Jun '19

13 Jun '19

Hi Alan, Thanks for your response :) I hope you don't mind, I'm replying back to you and the openstack-discuss list so the other TC members also working on the Help Most Wanted text can review your thoughts. In the etherpad, you can just start writing and it will give you an individual colour assigned to your user. If you feel like we won't see/know who you are, just put your initials next to your comments :) Thanks so much for offering to help. I've transferred over your thoughts below into the etherpad for now. Thanks, Alex On 13/06/2019 00:14, Alan Clark wrote: > Hey Alexandra, > > As I mentioned during the TC meeting I would love to help with the "Help Most Wanted" text. > > I took a look at the etherpad for the documentation role [1] > > I would like to offer a couple suggested changes. I wasn't sure where to post them, so am pinging you directly. > > My first comment is around the audience. Who is most likely to fit and fill this role. I think the audience we are after for this posting are those that take the OpenStack documentation to develop for re-use and distribution. Those are the most likely persons to convince to take a higher contribution and leadership role. Which is what this posting targets. > > The opening description section conveys the documentation teams pain and struggles. I think a more effective opening would be to convey the business and personal benefits the audience gains from contributing. They have to sell this to their boss. Boss wants to solve their pain not the documentation teams. If we agree that the most likely audience to contribute in this posted role, then their benefits are more complete documentation with less effort. Being able to leverage and re-use the community contributed text means much less text that the audience person has to write. Helping the community effort helps steer the contributed text to fill the needs and gaps that you find of most need. The first paragraph starts in the right direction but I suggest replacing the second paragraph with these ideas. I’m sure you can elaborate these ideas better than me. > > My second thought is that this posting should convey that it’s easy to do and get started. In fact you could turn it into an FAQ style. The First timers page is full of great material and a good page to point to: https://docs.openstack.org/doc-contrib-guide/quickstart/first-timers.html > Address the question of how easy it is to get started, that they use the tools they commonly use and here’s where to get their questions and concerns answered. > > Thanks, > AlanClark > > [1] https://etherpad.openstack.org/p/2019-upstream-investment-opportunities-ref… > > > > > >> -----Original Message----- >> From: Alexandra Settle [mailto:a.settle@outlook.com] >> Sent: Thursday, June 06, 2019 9:51 AM >> To: openstack-discuss(a)lists.openstack.org >> Subject: [tc] Recap for Technical Committee Meeting 6 June 2019 @ 1400 UTC >> >> Hello all, >> >> Thanks to those who joined the TC meeting today and running through it with me >> at the speed of light. Gif game was impeccably strong and that's primarily what I >> like about this community. >> >> For a recap of the meeting, please see the eavesdrop [0] for full detailed logs and >> action items. All items in the agenda [1] were covered and no major concerns >> raised. >> >> Next meeting will be on the 8th of July 2019. >> >> Cheers, >> >> Alex >> >> [0] http://eavesdrop.openstack.org/meetings/tc/2019/tc.2019-06-06-14.00.txt >> >> [1] >> http://lists.openstack.org/pipermail/openstack-discuss/2019-June/006877.html >> >> >

1 0

[openstack-helm] custom container images for helm
by Robson Ramos Barreto 13 Jun '19

13 Jun '19

Hi all I saw in the docker hub that there is just until rocky ubuntu xenial version. I'd like to know how can I create my own images centos-based from new versions like Stein to be used with the helm charts, if is there any specific customization to works with helm or, for example, if can I use the kolla images. Thank you Regards

2 3

[edge] China Mobile Edge platform evaluation presentation next Tuesday on the Edge WG call
by Ildiko Vancsa 13 Jun '19

13 Jun '19

Hi, I attended a presentation today from Qihui Zhao about China Mobile’s experience on evaluation different edge deployment models with various software components. As many of the evaluated components are part of OpenStack and/or StarlingX I invited her for next week’s Edge Computing Group call (Tuesday, June 18) to share their findings with the working group and everyone who is interested. For agenda and call details please visit this wiki: https://wiki.openstack.org/wiki/Edge_Computing_Group#Meetings Please let me know if you have any questions. Thanks and Best Regards, Ildikó

1 0

[sigs][publiccloud][publiccloud-wg][publiccloud-sig][billing] Meeting today at 1400 UTC regarding billing initiative
by Tobias Rydberg 13 Jun '19

13 Jun '19

Hi all, This is a reminder for todays meeting for the Public Cloud SIG - 1400 UTC in #openstack-publiccloud. The topic of the day will be continued discussions regarding the billing initiative. More information about that at https://etherpad.openstack.org/p/publiccloud-sig-billing-implementation-pro… See you all later today! Cheers, Tobias -- Tobias Rydberg Senior Developer Twitter & IRC: tobberydberg www.citynetwork.eu | www.citycloud.com INNOVATION THROUGH OPEN IT INFRASTRUCTURE ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED

1 0

[goal][python3] Train unit tests weekly update (goal-13)
by Corey Bryant 13 Jun '19

13 Jun '19

This is the goal-13 weekly update for the "Update Python 3 test runtimes for Train" goal [1]. There are 13 weeks remaining for completion of Train community goals [2]. == What's the Goal? == To ensure (in the Train cycle) that all official OpenStack repositories with Python 3 unit tests are exclusively using the 'openstack-python3-train-jobs' Zuul template or one of its variants (e.g. 'openstack-python3-train-jobs-neutron') to run unit tests, and that tests are passing. This will ensure that all official projects are running py36 and py37 unit tests in Train. For complete details please see [1]. == Ongoing Work == I have initial scripts working to automate patch generation for all supported projects. I plan to get them cleaned up and submitted for review next week, and I plan to start submitting patches next week. For reference my goal-tools scripts are located at: https://github.com/coreycb/goal-tools/commit/6eaf2535af02d5c48ebd9762e280c7…. I'll be off Thurs/Fri this week. Open patches needing reviews: https://review.openstack.org/#/q/topic:python3-train+is:open Failing patches: https://review.openstack.org/#/q/topic:python3-train+status:open+(+label:Ve… == Completed Work == Merged patches: https://review.openstack.org/#/q/topic:python3-train+is:merged == How can you help? == Please take a look at the failing patches and help fix any failing unit tests for your project(s). Python 3.7 unit tests will be self-testing in zuul. If you're interested in helping submit patches, please let me know. == Reference Material == [1] Goal description: https://governance.openstack.org/tc/goals/train/python3-updates.html [2] Train release schedule: https://releases.openstack.org/train/schedule.html (see R-5 for "Train Community Goals Completed") Storyboard: https://storyboard.openstack.org/#!/board/<TBD> Porting to Python 3.7: https://docs.python.org/3/whatsnew/3.7.html#porting-to-python-3-7 Python Update Process: https://opendev.org/openstack/governance/src/branch/master/resolutions/2018… Train runtimes: https://opendev.org/openstack/governance/src/branch/master/reference/runtim… Thanks, Corey

1 0

[doc][release][requirements] new warning and impending incompatible change in sphinxcontrib-datatemplates
by Doug Hellmann 12 Jun '19

12 Jun '19

The new 0.4.0 release of sphinxcontrib-datatemplates will emit a deprecation warning message when the "datatemplate" directive is used. This may break jobs that run sphinx-build with the -W option enabled. That package includes support for the new form of the directive, which includes a different variation depending on the type of the data source, allowing different options to be used for each directive. See https://doughellmann.com/blog/2019/06/12/sphinxcontrib-datatemplates-0-4-0/ for details about the release and https://sphinxcontribdatatemplates.readthedocs.io/en/latest/index.html for details about the new syntax. The 1.0.0 release (not yet scheduled) will drop the legacy form of the directive entirely. -- Doug

1 0

[ironic][neutron] Security groups on bare metal instances
by Jason Anderson 12 Jun '19

12 Jun '19

Hi all, We've been scratching our heads for a while, trying to figure out how security groups for bare metal instances are supposed to work. The configuration guide for Networking<https://docs.openstack.org/ironic/latest/install/configure-networking.html>[1] implies that using the 'iptables_hybrid' firewall driver should work. We are using Neutron tenant networks<https://docs.openstack.org/ironic/latest/install/configure-tenant-networks.…>[2] with Ironic. My understanding is that the iptables_hybrid driver creates a new OVS port (with prefix qvo), logically connects that to the integration bridge, and then creates a veth pair inside a new network namespace, and that veth device then gets some iptables rules to handle the security group rules. It is not clear to me how or when that qvo "hybrid" port is even created; I've combed through the Neutron code base for a while looking for clues. We had tried using the "pure" OVS firewall solution, where security group rules are expessed using OpenFlow flows. However, this doesn't work, as there is not OVS port for a bare metal instance (at least, not in our setup.) We are using networking-generic-switch<https://docs.openstack.org/networking-generic-switch/latest/>[3], which provisions ports on a physical switch with a VLAN tag on the provider network. From OVS' perspective, the traffic exits OVS with that VLAN tag and that's that; OVS in this situation is only responsible for handling routing between provider networks and performing NAT for egress and ingress via Floating IP assignments. So, I'm wondering if others have had success getting security groups to work in a bare metal environment, and have any clues we could follow to get this working nicely. I'm beginning to suspect our problems have to do with the fact that we're doing VLAN isolation predominately via configuring physical switches, and as such there isn't a clear point where security groups can be inserted. The problem we are trying to solve is limiting ingress traffic on a Floating IP, so we only allow SSH from a given host, or only allow ports X and Y to be open externally, etc. Thanks in advance, as usual, for any insights! /Jason [1]: https://docs.openstack.org/ironic/latest/install/configure-networking.html [2]: https://docs.openstack.org/ironic/latest/install/configure-tenant-networks.… [3]: https://docs.openstack.org/networking-generic-switch/latest/

3 3

[SIG][WG] Shanghai PTG Changes
by Kendall Nelson 12 Jun '19

12 Jun '19

Hello All, After Denver we were able to take time to reflect on the improvements we can make now that the PTG will occur immediately following the summit for the near future. While Shanghai will have its own set of variables, it's still good to reevaluate how we allocate time for groups and how we structure the week overall. tldr; - No BoFs, try to focus more specific discussions into topics for the Forum and follow up with PTG slot for more general conversations - PTG slots can be as short as 1/4 of a day - More shared space at the Shanghai venue, less dedicated space - New breakdown: 1.5 days of Forum and 3.5 days of PTG - Survey will be out in a few weeks for requesting PTG space For many of you (and myself as FC SIG Chair) there were a lot of different ways to get time to talk about topics. There was the forum, there were BoF sessions you could request, and there was also the option of having PTG sessions. Using the FC SIG as an example, we had two forum sessions (I think?), a BoF, and a half day at the PTG. This was WAY too much time for us. We didn't realize it when we were asking for space all the different ways, but we ended up with a lot of redundant discussions and time in which we didn't do much but just chat (which was great, but not the best use of the time/space since we could have done that in a hallway and not a dedicated room). To account for this duplication, we are going to get rid of the BoF mechanism for asking for space since largely the topics discussed there could be more cleanly divided into feedback focused Forum sessions and PTG team discussion time. The tentative plan is to try to condense as many of the SIG/WGs PTG slots towards the start of the PTG as we can so that they will more or less immediately follow the forum so that you can focus on making action items out of the conversations had and the feedback received at the Forum. We will also offer a smaller granularity of time that you can request at the PTG. Previously, a half day slot was as small as you could request; this time we will be offering 1/4 day slots (we found with more than one SIG/WG that even at a half day they were done in an hour and a half with all that they needed to talk about). The venue itself (similar to Denver) will have a few large rooms for bigger teams to meet, however, most teams will meet in shared space. That being said, we will add to the PTGbot more clearly defined locations in the shared space so its easier to find groups in shared spaces. I regret to inform you that, again, projection will be a very limited commodity. Yeah.. please don't shoot the messenger. Due to using mainly shared space, projection is just something we are not able to offer. The other change I haven't already mentioned is that we are going to have the PTG start a half day early. Instead of only being 3 days like in Denver, we are going to add more time to the PTG and subtract a half day from the Forum. Basically the breakdown will be 1.5 Forum and 3.5 PTG with the Summit overlapping the first two days. I will be sending the PTG survey out to SIG Chairs/ WG Leads in a couple weeks with a few changes. -Kendall Nelson (diablo_rojo)

2 2

Openstack Octavia Configuration
by Ashwinkumar Kandasami 12 Jun '19

12 Jun '19

Hi, I am a graduate student trying to deploy openstack in my own environment. I waana configure openstack octavia with my existing openstack cloud. I done the openstack deployment using RDO project. I tried configure openstack with ovn neutron l2 agent with octavia but i getting alert like we can’t able to use octavia for ovn type neutron agent, then how can i use it?? Sent from Mail for Windows 10

2 1

[Glance] Can Glance be installed on a server other than the controller?
by Jordan Michaels 12 Jun '19

12 Jun '19

For anyone who's interested, this issue turned out to be caused by the system times being different on the separate server. I had set up Chrony according to the docs but never verified it was actually working. While reviewing the logs I noticed the time stamps were different on each server and that is what pointed me in the right direction. Just wanted to post the solution for posterity. Hopefully this helps someone in the future. -Jordan

1 0

Re: [Release-job-failures] Pre-release of openstack/horizon failed
by Sean McGinnis 12 Jun '19

12 Jun '19

This appears to have been a network issue that prevented the installation of one of the requirements. Fungi was able to reenqueue the job and it passed the second time through. Everything looks good now, but if anything unusual is noticed later, please let us know in the #openstack-release channel. Sean On Wed, Jun 12, 2019 at 9:48 AM <zuul(a)openstack.org> wrote: > Build failed. > > - release-openstack-python > http://logs.openstack.org/e3/e30d8258f5993736dc8982e280ae43fe1ed22395/pre-r… > : FAILURE in 3m 06s > - announce-release announce-release : SKIPPED > - propose-update-constraints propose-update-constraints : SKIPPED > > _______________________________________________ > Release-job-failures mailing list > Release-job-failures(a)lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/release-job-failures >

2 1

[kolla] meeting tomorrow
by Mark Goddard 12 Jun '19

12 Jun '19

Hi, I'm unable to chair the IRC meeting tomorrow. If someone else can stand in that would be great, otherwise we'll cancel. Thanks, Mark

1 1

[tc][ptls][all] Change to the health check process
by Alexandra Settle 12 Jun '19

12 Jun '19

Hi all, The TC have made the decision to stop health tracking team projects. During discussions at the Train cycle PTG, the OpenStack TC concluded that its experiments in formally tracking problems within individual project teams was not providing enough value for the investment of effort it required. The wiki has subsequently been closed down [0]. The component of it which is still deemed valuable is having specific TC members officially assigned as liaisons to each project team, so in future that will continue but will be documented in the openstack/governance Git repository's project metadata and on the project pages linked from the OpenStack Project Teams page [1]. This was discussed at the most recent TC meeting [2] and it was agreed upon that SIGs are to be included in the liaison roster for team health checks. Please keep your eyes out for changes coming up in the governance repo and PTLS - also please keep your inboxes open for TC members to reach out and introduce themselves as your liaison. In the mean time - if you have any concerns, please do not hesitate to reach out to any one of the TC members. Cheers, Alex [0] https://wiki.openstack.org/wiki/OpenStack_health_tracker [1] https://governance.openstack.org/tc/reference/projects/ [2] http://eavesdrop.openstack.org/meetings/tc/2019/tc.2019-06-06-14.00.log.htm…

1 0

Openstack - Octavia
by Ashwinkumar Kandasamy 12 Jun '19

12 Jun '19

Hi, I am a private cloud engineer in india. I deployed openstack in my own environment. I done that through openstack RDO project with openstack network type 1 (provider network). I want to configure openstack LBaaS (Octavia) in an existing openstack. How can i do that? please help me for that. -- Thank You, *Ashwinkumar K* *Software Associate,* *ZippyOPS Consulting Services LLP,* *Chennai.*

1 0

[requirements] paramiko 2.5.0 causing ImportError: cannot import name py31compat
by Pierre Riteau 12 Jun '19

12 Jun '19

Hello, paramiko 2.5.0 was released yesterday [1]. It appears to trigger failures in the Kayobe molecule job with the following error [2]: ImportError: cannot import name py31compat It's not clear yet why this is happening, since py31compat lives in setuptools. paramiko 2.5.0 includes changes to paramiko/py3compat.py which could be related. For now, we're capping paramiko [3] as it is blocking our gate. I thought I would share with the list, in case other projects experience similar errors. Cheers, Pierre [1] https://pypi.org/project/paramiko/#history [2] http://logs.openstack.org/17/664417/1/check/kayobe-tox-molecule/0370fdd/job… [3] https://review.opendev.org/#/c/664533/

2 1

[ptl] Shanghai PTG Changes
by Kendall Nelson 11 Jun '19

11 Jun '19

Hello All, After Denver we were able to take time to reflect on the improvements we can make now that the PTG will occur immediately following the summit for the near future. While Shanghai will have its own set of variables, it's still good to reevaluate how we allocate time for groups and how we structure the week overall. tldr; - Onboarding is moving into the PTG for this round (updates stay a part of the Summit) - You can still do regular PTG stuff (or both onboarding and regular PTG stuff) - PTG slots can be as short as 1/4 of a day - More shared space at the Shanghai venue, less dedicated space - New breakdown: 1.5 days of Forum and 3.5 days of PTG - Survey will be out in a few weeks for requesting PTG space We'll have our traditional project team meetings at the PTG in Shanghai as the default format, that won't change. However, we know many of you don't expect to have all your regulars attend the PTG in Shanghai. To combat this and still help project teams make use of the PTG in the most effective way possible we are encouraging teams that want to meet but might not have all the people they need to have technical discussions to meet anyway and instead focus on a more thorough onboarding of our Chinese contributors. Project teams could also do a combination of the two, spend an hour and a half on onboarding (or however much time you see fit) and then have your regular technical discussions after. Project Updates will still be a part of the Summit like normal, its just the onboardings that will be compacted into the PTG for Shanghai. We are making PTG days more granular as well and will have the option to request 1/4 day slots in an effort to leave less empty space in the schedule. So if you are only doing onboarding, you probably only need 1/4 to 1/2 of a day. If you are doing just your regular technical discussions and still need three days, thats fine too. The venue itself (similar to Denver) will have a few large rooms for bigger teams to meet, however, most teams will meet in shared space. For those teams meeting to have only technical discussions and for teams that have larger groups, we will try to prioritize giving them their own dedicated space. For the shared spaces, we will add to the PTGbot more clearly defined locations within the shared space so its easier to find teams meeting there. I regret to inform you that, again, projection will be a very limited commodity. Yeah.. please don't shoot the messenger. Due to using mainly shared space, projection is just something we are not able to offer. The other change I haven't already mentioned is that we are going to have the PTG start a half day early. Instead of only being 3 days like in Denver, we are going to add more time to the PTG and subtract a half day from the Forum. Basically the breakdown will be 1.5 Forum and 3.5 PTG with the Summit overlapping the first two days. I will be sending the PTG survey out to PTLs/Project Leads in a couple weeks with a few changes. -Kendall Nelson (diablo_rojo)

1 0

[dev][keystone] M-1 check-in and retrospective meeting
by Colleen Murphy 11 Jun '19

11 Jun '19

Hi team, During the PTG, we agreed to have milestone-ly check-ins in order to try to keep momentum going throughout the cycle. Milestone 1 is already nearly upon us, so it's time to schedule this meeting. I'd like to schedule a two-hour video call during which we'll conduct a brief retrospective of the cycle so far, review our past action items, and refine and reevaluate our plans for the rest of the cycle. I've created a doodle poll[1] to schedule the session for either the week of M-1[2] or the following week. If you have questions, concerns, or thoughts about this meeting, let's discuss it in this thread (or you can message me privately). Colleen [1] https://doodle.com/poll/hyibxqp9h8sgz56p [2] https://releases.openstack.org/train/schedule.html

1 3

[Nova][Ironic] Reset Configurations in Baremetals Post Provisioning
by Kumari, Madhuri 11 Jun '19

11 Jun '19

Hi Ironic, Nova Developers, I am currently working on implementing Intel Speed Select(ISS) feature[1] in Ironic and I have a use case where I want to change ISS configuration in BIOS after a node is provisioned. Such use case of changing the configuration post deployment is common and not specific to ISS. A real-life example for such a required post-deploy configuration change is the change of BIOS settings to disable hyper-threading in order to address a security vulnerability. Currently there is no way of changing any BIOS configuration after a node is provisioned in Ironic. One solution for it is to allow manual deploy steps in Ironic[2](not implemented yet) which can be trigged by changing traits in Nova. For this purpose, we would need to change a trait of the server's flavor in Nova. This trait is mapped to a deploy step in Ironic which does some operation(change BIOS config and reboot in this use case). In Nova, the only API to change trait in flavor is resize whereas resize does migration and a reboot as well. In short, I am looking for a Nova API that only changes the traits, and trigger the ironic deploy steps but no reboot and migration. Please suggest. Thanks in advance. Regards, Madhuri [1] https://specs.openstack.org/openstack/ironic-specs/specs/not-implemented/su… [2] https://storyboard.openstack.org/#!/story/2005129

7 17

[tripleo] Proposing Kamil Sambor core on TripleO
by Emilien Macchi 11 Jun '19

11 Jun '19

Kamil has been working on TripleO for a while now and is providing really insightful reviews, specially on Python best practices but not only; he is one of the major contributors of the OVN integration, which was a ton of work. I believe he has the right knowledge to review any TripleO patch and provide excellent reviews in our project. We're lucky to have him with us in the team! I would like to propose him core on TripleO, please raise any objection if needed. -- Emilien Macchi

10 10

[edge][ironic][neutron][starlingx] Open Infrastructure Summit and PTG Edge overview and next steps
by Ildiko Vancsa 11 Jun '19

11 Jun '19

Hi, There were a lot of interesting discussions about edge computing at the Open Infrastructure Summit[1] and PTG in Denver. Hereby I would like to use the opportunity to share overviews and some progress and next steps the community has taken since. You can find a summary of the Forum discussions here: https://superuser.openstack.org/articles/edge-and-5g-not-just-the-future-bu… Check the following blog post for a recap on the PTG sessions: https://superuser.openstack.org/articles/edge-computing-takeaways-from-the-… The Edge Computing Group is working towards testing the minimal reference architectures for which we are putting together hardware requirements. You can catch up and chime in on the discussion on this mail thread: http://lists.openstack.org/pipermail/edge-computing/2019-June/000597.html For Ironic related conversations since the event check these threads: * http://lists.openstack.org/pipermail/edge-computing/2019-May/000582.html * http://lists.openstack.org/pipermail/edge-computing/2019-May/000588.html We are also in progress to write up an RFE for Neutron to improve segment range management for edge use cases: http://lists.openstack.org/pipermail/edge-computing/2019-May/000589.html If you have any questions or comments to any of the above topics you can respond to this thread, chime in on the mail above threads, reach out on the edge-computing mailing[2] list or join the weekly edge group calls[3]. If you would like to get involved with StarlingX you can find pointers on the website[4]. Thanks, Ildikó (IRC: ildikov on Freenode) [1] https://www.openstack.org/videos/summits/denver-2019 [2] http://lists.openstack.org/cgi-bin/mailman/listinfo/edge-computing [3] https://wiki.openstack.org/wiki/Edge_Computing_Group#Meetings [4] https://www.starlingx.io/community/

1 0

[tripleo] Outstanding specs & blueprints for the Train cycle
by Alex Schultz 11 Jun '19

11 Jun '19

Hey folks, I wanted to send a note about a last call for specs for the train cycle. In a previous mail back in May[0], I had mentioned that the plan was to try and have all the blueprints and specs finalized by Train milestone 1. Since milestone 1 was last week, this is your final call for specs & blueprints. Please let me know if there are any outstanding items by next week's IRC meeting on June 18, 2019. I will be applying a -2 to any outstanding specs that have not merged or been spoken for. Thanks, -Alex [0] http://lists.openstack.org/pipermail/openstack-discuss/2019-May/006223.html

1 0

[openstack-ansible] suse support for stable/queens
by Mohammed Naser 11 Jun '19

11 Jun '19

Hi everyone, The most recent set of automatic proposal patches are all failing for opensuse-42 due to the fact that it seems the operating system is now shipping with LXC 3 instead of LXC 2. The patch that added support to LXC 3 for our newer branches was mainly done there to add support for Bionic, which means that we can't really backport it all the way to Queens. We have two options right now: 1. Someone can volunteer to implement LXC 3 support in stable/queens in order to get opensuse-42 working again 2. We move the opensuse-42 jobs to non-voting for 1/2 weeks and if no one fixes them, we drop them (because they're a waste of CI resources). I'd like to hear what the community has to say about this to be able to move forward. Thanks, Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

3 3

[OCTAVIA][ROCKY] - MASTER & BACKUP instances unexpectedly deleted by octavia
by Gaël THEROND 11 Jun '19

11 Jun '19

Hi guys, I’ve a weird situation here. I smoothly operate a large scale multi-region Octavia service using the default amphora driver which imply the use of nova instances as loadbalancers. Everything is running really well and our customers (K8s and traditional users) are really happy with the solution so far. However, yesterday one of those customers using the loadbalancer in front of their ElasticSearch cluster poked me because this loadbalancer suddenly passed from ONLINE/OK to ONLINE/ERROR, meaning the amphoras were no longer available but yet the anchor/member/pool and listeners settings were still existing. So I investigated and found out that the loadbalancer amphoras have been destroyed by the octavia user. The weird part is, both the master and the backup instance have been destroyed at the same moment by the octavia service user. Is there specific circumstances where the octavia service could decide to delete the instances but not the anchor/members/pool ? It’s worrying me a bit as there is no clear way to trace why does Octavia did take this action. I digged within the nova and Octavia DB in order to correlate the action but except than validating my investigation it doesn’t really help as there are no clue of why the octavia service did trigger the deletion. If someone have any clue or tips to give me I’ll be more than happy to discuss this situation. Cheers guys!

4 11

[Kolla] Stuck at bootstrap_gnocchi during deployment using Ubuntu binary on Rocky release.
by Eddie Yen 11 Jun '19

11 Jun '19

Hi Our env needs Gnocchi because Ceilometer, and we using Kolla to deploy Ceph as the env storage backend. But I found that it always stuck at bootstrap_gnocchi. The error log shows below when check with docker logs: 2019-06-11 10:59:17,707 [19] ERROR gnocchi.utils: Unable to initialize storage driver Traceback (most recent call last): File "/usr/lib/python3/dist-packages/tenacity/__init__.py", line 333, in call result = fn(*args, **kwargs) File "/usr/lib/python3/dist-packages/gnocchi/storage/__init__.py", line 102, in get_driver conf.storage) File "/usr/lib/python3/dist-packages/gnocchi/storage/ceph.py", line 52, in __init__ self.rados, self.ioctx = ceph.create_rados_connection(conf) File "/usr/lib/python3/dist-packages/gnocchi/common/ceph.py", line 51, in create_rados_connection raise ImportError("No module named 'rados' nor 'cradox'") ImportError: No module named 'rados' nor 'cradox' This error occurred not only the image from Docker Hub, but also build by Kolla-build in Ubuntu binary based. Strange is, no error occur if turn into use Ubuntu source based images. And I guess it only happen when enabled Ceph. Does anyone have idea about this? Many thanks, Eddie.

2 2

[tripleo] TripleO CI Summary: Sprint 31
by Rafael Folco 10 Jun '19

10 Jun '19

Greetings, The TripleO CI team has just completed Sprint 31 / Unified Sprint 10 (May 16 thru Jun 05). The following is a summary of completed work during this sprint cycle: - Created image and container build jobs for RDO on RHEL 7 in the internal instance of Software Factory. - Completed the bootstrapping of OSP 15 standalone job on RHEL8 running in the internal Software Factory. - Promotion status: green on all branches at most of the sprint. The planned work for the next sprint [1] are: - Complete RDO on RHEL7 work by having an independent pipeline running container and image build, standalone and ovb featureset001 jobs. This includes fixing ovb job and start consuming rhel containers from the standalone jobs. - Replicate RHEL7 jobs created in the last sprint for RHEL8 running in the internal Software Factory. Expected outcome is to have a preliminary job producing logs with successes or failures at the end of the sprint. - Create a design document for a staging environment to test changes in the promoter server. This will benefit CI team with less breakages in the promoter server and also prepare the grounds for the multi-arch builds. The Ruck and Rover for this sprint are Sorin Sbarnea (zbr) and Ronelle Landy (rlandy). Please direct questions or queries to them regarding CI status or issues in #tripleo, ideally to whomever has the ‘|ruck’ suffix on their nick. Ruck/rover notes are being tracked in etherpad [2]. Thanks, rfolco [1] https://tree.taiga.io/project/tripleo-ci-board/taskboard/unified-sprint-11 [2] https://etherpad.openstack.org/p/ruckroversprint11

1 0

[ops][neutron]After an upgrade to openstack queens, Neutron is unable to communicate properly with rabbitmq
by Jean-Philippe Méthot 10 Jun '19

10 Jun '19

Hi, We had a Pike openstack setup that we updated to Queens earlier this week. It’s a 30 compute nodes infrastructure with 2 controller nodes and 2 network nodes, using openvswitch for networking. Since we upgraded to queens, neutron-server on the controller nodes has been unable to contact the openvswitch-agents through rabbitmq. The rabbitmq is clustered on both controller nodes and has been giving us the following error when neutron-server connections fail : =ERROR REPORT==== 5-Jun-2019::18:50:08 === closing AMQP connection <0.23859.0> (10.30.0.11:53198 -> 10.30.0.11:5672 - neutron-server:1170:ccf11f31-2b3b-414e-ab19-5ee2cf5dd15d): missed heartbeats from client, timeout: 60s The neutron-server logs show this error: 2019-06-05 18:50:33.132 1169 ERROR oslo.messaging._drivers.impl_rabbit [req-17167988-c6f2-475e-8b6a-90b92777e03a - - - - -] [b7684919-c98b-402e-90c3-59a0b5eccd1f] AMQP server on controller1:5672 is unreachable: [Errno 104] Connection reset by peer. Trying again in 1 seconds.: error: [Errno 104] Connection reset by peer 2019-06-05 18:50:33.217 1169 ERROR oslo.messaging._drivers.impl_rabbit [-] [bd6900e0-ab7b-4139-920c-a456d7df023b] AMQP server on controller1:5672 is unreachable: <RecoverableConnectionError: unknown error>. Trying again in 1 seconds.: RecoverableConnectionError: <RecoverableConnectionError: unknown error> The relevant service version numbers are as follow: rabbitmq-server-3.6.5-1.el7.noarch openstack-neutron-12.0.6-1.el7.noarch python2-oslo-messaging-5.35.4-1.el7.noarch Rabbitmq does not show any alert. It also has plenty of memory and a high enough file limit. The login user and credentials are fine as they are used in other openstack services which can contact rabbitmq without issues. I’ve tried optimizing rabbitmq, upgrading, downgrading, increasing timeouts in neutron services, etc, to no avail. I find myself at a loss and would appreciate if anyone has any idea as to where to go from there. Best regards, Jean-Philippe Méthot Openstack system administrator Administrateur système Openstack PlanetHoster inc.

4 6

[all] [TC] Call for Election Officials
by Kendall Nelson 10 Jun '19

10 Jun '19

Hello, The upcoming round for OpenStack's technical elections (both PTL and TC) is set to happen in September this year[1]. We would like to encourage anyone interested to volunteer to help administer the elections, especially as some of our long-service volunteers periodically become ineligible by way of being nominated for election themselves. While elections have historically been handled by a small number of volunteers, the intention was for this to NOT be a closed process. The election process is detailed in this document [2], with tooling managed in gerrit [3], and uses StoryBoard [4] to keep track of various election activities. We are happy to mentor individuals and share knowledge about the elections process in an effort to get more of the community involved. Involvement can be on an ongoing basis or simply volunteering to help with some small part of one election just to learn how the process works. The election officials team is explicitly delegated by the Technical Committee, who have historically consistently expressed interest in more volunteers to assist. Please let us know if you would like to volunteer! -Kendall Nelson & The Election Officials [1] https://review.opendev.org/#/c/661673/2 [2] https://governance.openstack.org/election/process.html [3] https://opendev.org/openstack/election [4] https://storyboard.openstack.org/#!/project/openstack/election

1 0

[tc][all] Train Community Goals
by Lance Bragstad 10 Jun '19

10 Jun '19

Hi all, The goals for the Train development cycle have merged. Both are available on governance.openstack.org [0][1]. Please have a look if you haven't already. Goal champions are asettle and gmann. As always, if you have any comments, questions, or concerns, please don't hesitate to reach out on the mailing list or in #openstack-tc. Thanks, Lance [0] https://governance.openstack.org/tc/goals/train/pdf-doc-generation.html [1] https://governance.openstack.org/tc/goals/train/ipv6-support-and-testing.ht…

1 1

[neutron] Bug deputy report for week of June 3rd
by Brian Haley 10 Jun '19

10 Jun '19

Hi, I was Neutron bug deputy last week. Below is a short summary about reported bugs. -Brian Critical bugs ------------- * https://bugs.launchpad.net/neutron/+bug/1832225 - Neutron-vpnaas unit tests broken - Broken by https://review.opendev.org/#/c/653903/ - https://review.opendev.org/#/c/664257/ High bugs --------- * https://bugs.launchpad.net/neutron/+bug/1831534 - [l3][dvr] with openflow security group east-west traffic between different vlan networks is broken - https://review.opendev.org/#/c/662925/ - https://review.opendev.org/#/c/663008/ * https://bugs.launchpad.net/neutron/+bug/1831575 - br-tun gets a wrong arp drop rule when dvr is connected to a network but not used as gateway - https://review.opendev.org/#/c/662999/ - https://review.opendev.org/#/c/663000/ * https://bugs.launchpad.net/neutron/+bug/1831647 - Creation of existing resource takes too much time or fails - https://review.opendev.org/#/c/663749/ * https://bugs.launchpad.net/neutron/+bug/1831919 - Impossible to change a list of static routes defined for subnet because of InvalidRequestError with Cisco ACI integration - https://review.opendev.org/#/c/663714/ - https://review.opendev.org/#/c/663713/ - https://review.opendev.org/#/c/663712/ Medium bugs ----------- * https://bugs.launchpad.net/neutron/+bug/1831404 - rarp packet will be dropped in flows cause vm connectivity broken after live-migration - Yang Li took ownership * https://bugs.launchpad.net/neutron/+bug/1831613 - SRIOV: agent may not register VFs - https://review.opendev.org/#/c/663031/ * https://bugs.launchpad.net/neutron/+bug/1831706 - [DVR] Modify `in_port` field of packets which from remote qr-* port - Possibly related to https://review.opendev.org/#/c/639009 and https://bugs.launchpad.net/neutron/+bug/1732067 * https://bugs.launchpad.net/neutron/+bug/1831811 - Unable to filter using same cidr value as used for subnet create - https://review.opendev.org/#/c/663464/ * https://bugs.launchpad.net/ubuntu/+source/neutron-fwaas/+bug/1832210 - incorrect decode of log prefix under python 3 - https://review.opendev.org/#/c/664234/ Low bugs -------- * https://bugs.launchpad.net/neutron/+bug/1831916 - BGP dynamic routing in neutron - https://review.opendev.org/#/c/663711/ Wishlist bugs ------------- None Invalid bugs ------------ * https://bugs.launchpad.net/bugs/1831613 - moved to lbaas storyboard Further triage required ----------------------- * https://bugs.launchpad.net/neutron/+bug/1831726 - neutron-cli port-update ipv6 fixed_ips Covering previous - Fixed IP getting replaced when using neutronclient, as API ref says will happen. - Looks like the openstackclient is doing things properly by appending the new fixed IP to the existing. - Might just be a documentation issue. * https://bugs.launchpad.net/neutron/+bug/1832021 - Checksum drop of metadata traffic on isolated provider networks - Related to recent revert of TCP checksum-fill iptables rule, https://review.opendev.org/#/c/654645/ - but since that was an invalid rule there is probably another issue here.

1 0

[placement] update 19-22
by Chris Dent 10 Jun '19

10 Jun '19

HTML: https://anticdent.org/placement-update-19-22.html Welcome to placement update 19-22. # Most Important We are continuing to work through issues associated with the [spec for nested magic](https://review.opendev.org/662191). Unsurprisingly, there are edge cases where we need to be sure we're doing the right thing, both in terms of satisfying the use cases as well as making sure we don't violate the general model of how things are supposed to work. # What's Changed * We've had a few responses on [the thread to determine the fate of can_split](http://lists.openstack.org/pipermail/openstack-discuss/2019-May/…. The consensus at this point is to not worry about workloads that mix NUMA-aware guests with non-NUMA-aware on the same host. * Support forbidden traits (microversion 1.22) has been added to osc-placement. * Office hours will be 1500 UTC on Wednesdays. * os-traits 0.13.0 and 0.14.0 were released. * Code to optionaly run a [wsgi profiler](https://docs.openstack.org/placement/latest/contributor/testing.h… in placement has merged. * The request group mapping in allocation candidates spec has merged, more on that in themes, below. # Specs/Features * <https://review.opendev.org/654799> Support Consumer Types. This has some open questions that need to be addressed, but we're still go on the general idea. * <https://review.opendev.org/662191> Spec for nested magic 1. The easier parts of nested magic: same_subtree, resource request groups, verbose suffixes (already merged as 1.33). Recently some new discussion here. These and other features being considered can be found on the [feature worklist](https://storyboard.openstack.org/#!/worklist/594). Some non-placement specs are listed in the Other section below. # Stories/Bugs (Numbers in () are the change since the last pupdate.) There are 20 (1) stories in [the placement group](https://storyboard.openstack.org/#!/project_group/placement). 0 (0) are [untagged](https://storyboard.openstack.org/#!/worklist/580). 3 (1) are [bugs](https://storyboard.openstack.org/#!/worklist/574). 4 (0) are [cleanups](https://storyboard.openstack.org/#!/worklist/575). 11 (0) are [rfes](https://storyboard.openstack.org/#!/worklist/594). 2 (0) are [docs](https://storyboard.openstack.org/#!/worklist/637). If you're interested in helping out with placement, those stories are good places to look. * Placement related nova [bugs not yet in progress](https://goo.gl/TgiPXb) on launchpad: 15 (-1). * Placement related nova [in progress bugs](https://goo.gl/vzGGDQ) on launchpad: 7 (0). # osc-placement osc-placement is currently behind by 11 microversions. Pending Changes: * <https://review.openstack.org/#/c/640898/> Add 'resource provider inventory update' command (that helps with aggregate allocation ratios). * <https://review.openstack.org/586056> Provide a useful message in the case of 500-error # Main Themes ## Nested Magic The overview of the features encapsulated by the term "nested magic" are in a [story](https://storyboard.openstack.org/#!/story/2005575). There is some in progress code, some of it WIPs to expose issues: * <https://review.opendev.org/663009> PoC: resourceless request, including some code from <https://review.opendev.org/657510> WIP: Allow RequestGroups without resources * <https://review.opendev.org/657463> Add NUMANetworkFixture for gabbits * <https://review.opendev.org/662785> Prepare objects for allocation request mappings. This work exposed a [bug in hash handling](https://storyboard.openstack.org/#!/story/2005822) that is [being fixed](https://review.opendev.org/663137). ## Consumer Types Adding a type to consumers will allow them to be grouped for various purposes, including quota accounting. A [spec](https://review.opendev.org/654799) has started. There are some questions about request and response details that need to be resolved, but the overall concept is sound. ## Cleanup We continue to do cleanup work to lay in reasonable foundations for the nested work above. As a nice bonus, we keep eking out additional performance gains too. * <https://review.opendev.org/661769> Add olso.middleware.cors to conf generator * <https://review.opendev.org/661922> Modernize CORS config and setup. Ed Leafe's ongoing work with using a graph database probably needs some kind of report or update. # Other Placement Miscellaneous changes can be found in [the usual place](https://review.opendev.org/#/q/project:openstack/placement+status:op…. There are several [os-traits changes](https://review.opendev.org/#/q/project:openstack/os-traits+status:… being discussed. # Other Service Users New discoveries are added to the end. Merged stuff is removed. Anything that has had no activity in 4 weeks has been removed. * <https://review.openstack.org/601596> Nova: spec: support virtual persistent memory * <https://review.openstack.org/#/q/topic:bug/1819923> Nova: nova-manage: heal port allocations * <https://review.openstack.org/650188> nova-spec: Allow compute nodes to use DISK_GB from shared storage RP * <https://review.opendev.org/659233> Cyborg: Placement report * <https://review.opendev.org/657884> Nova: Spec to pre-filter disabled computes with placement * <https://review.opendev.org/657801> rpm-packaging: placement service * <https://review.opendev.org/657016> Delete resource providers for all nodes when deleting compute service * <https://review.opendev.org/654066> nova fix for: Drop source node allocations if finish_resize fails * <https://review.opendev.org/656885> nova: WIP: Hey let's support routed networks y'all! * <https://review.opendev.org/662371> starlingx: Add placement chart patch to openstack-helm * <https://review.opendev.org/662229> helm: WIP: add placement chart * <https://review.opendev.org/662164> kolla-ansible: Add a explanatory note for "placement_api_port" * <https://review.opendev.org/658451> neutron-spec: L3 agent capacity and scheduling * <https://review.opendev.org/656023> Nova: Use OpenStack SDK for placement * <https://review.opendev.org/659302> puppet: Implement generic placement::config::placement_config * <https://review.opendev.org/663272> puppet: Add parameter for `scheduler/query_placement_for_image_type_support` * <https://review.opendev.org/612497> Nova: Spec: Provider config YAML file * <https://review.opendev.org/623558> Nova: single pass instance info fetch in host manager * <https://review.opendev.org/661245> Watcher: Add Placement helper * <https://review.opendev.org/663478> docs: Add Placement service to Minimal deployment for Stein * <https://review.opendev.org/663270> devstack: Add setting of placement microversion on tempest conf * <https://review.opendev.org/634551> libvirt: report pmem namespaces resources by provider tree * <https://review.opendev.org/657796> Nova: Defaults missing group_policy to 'none' * <https://review.opendev.org/660852> Nova: Remove PlacementAPIConnectFailure handling from AggregateAPI # End Making good headway. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent

2 1

Cinder Ceph backup concurrency
by Cory Hawkless 10 Jun '19

10 Jun '19

I'm using Rocky and Cinders built in Ceph backup driver which is working ok but I'd like to limit each instance of the backup agent to X number of concurrent backups. For example, if I(Or a tenant) trigger a backup to run on 20 volumes, the cinder-0backuip agent promptly starts the process of backup up all 20 volumes simultaneously and while this works ok it has the downside of over saturating links, causing high IO on the disks etc. Ideally I'd like to have each cinder-backup agent limited to running X(Perhaps 5) backups jobs at any one time and the remaining jobs will be 'queued' until an agent has less than X jobs remaining. Is this possible at all? Based on my understanding the Cinder scheduler services handles the allocation and distribution of the backup tasks, is that correct? Thanks in advance Cory

3 2

[kolla] Feedback request: removing kolla-cli
by Mark Goddard 10 Jun '19

10 Jun '19

Hi, We discussed during the kolla virtual PTG [1] the option of removing support for the kolla-cli deliverable [2], as a way to improve the long term sustainability of the project. kolla-cli was a project started by Oracle, and accepted as a kolla deliverable. While it looks interesting and potentially useful, it never gained much traction (as far as I'm aware) and the maintainers left the community. We have never released it and CI has been failing for some time. We propose dropping support for kolla-cli in the Train cycle. If this will affect you and you would like to help maintain it, please get in touch. Thanks, Mark [1] https://etherpad.openstack.org/p/kolla-train-ptg [2] https://github.com/openstack/kolla-cli

1 1

[kolla] Feedback request: removing OracleLinux support
by Mark Goddard 10 Jun '19

10 Jun '19

Hi, We discussed during the kolla virtual PTG [1] the option of removing support for Oracle Linux, as a way to improve the long term sustainability of the project. Since (from afar) OracleLinux is very similar to CentOS, it does not require too much maintenance, however it is non-zero and does consume CI resources. Contributors from Oracle left the community some time ago, and we do not generally see Oracle Linux in bug reports, so must assume it is not well used. We propose dropping support for OracleLinux in the Train cycle. If this will affect you and you would like to help maintain it, please get in touch. Thanks, Mark [1] https://etherpad.openstack.org/p/kolla-train-ptg

2 2

[ironic] Should we add ironic-prometheus-exporter under Ironic umbrella?
by Iury Gregory 10 Jun '19

10 Jun '19

Greetings Ironicers! I would like to have your input on the matter of moving the ironic-prometheus-exporter to Ironic umbrella. *What is the ironic-prometheus-exporter? * The ironic-prometheus-exporter[1] provides a way to export hardware sensor data from Ironic project in OpenStack to Prometheus [2]. It's implemented as an oslo-messaging notification driver to get the sensor data and a Flask Application to export the metrics to Prometheus. It can not only be used in metal3-io but also in any OpenStack deployment which includes Ironic service. *How to ensure the sensor data will follow the Prometheus format?* We are using the prometheus client_python [3] to generate the file with the metrics that come trough the oslo notifier plugin. *How it will be tested on the gate?* Virtualbmc can't provide sensor data that the actual plugin supports. We would collect sample metrics from the hardware and use it in the unit tests. Maybe we should discuss this in the next ironic weekly meeting (10th June)? [1] https://github.com/metal3-io/ironic-prometheus-exporter [2] https://prometheus.io/ [3] https://github.com/prometheus/client_python -- *Att[]'sIury Gregory Melo Ferreira * *MSc in Computer Science at UFCG* *Part of the puppet-manager-core team in OpenStack* *Software Engineer at Red Hat Czech* *Social*: https://www.linkedin.com/in/iurygregory *E-mail: iurygregory(a)gmail.com <iurygregory(a)gmail.com>*

2 2

[requirements] SQLAlchemy 1.3.4 backward compatible?
by Lingxian Kong 10 Jun '19

10 Jun '19

Trove Jenkins jobs failed because of the SQLAlchemy upgrade from 1.2.19 to 1.3.4 in https://github.com/openstack/requirements/commit/4f3252cbd7c63fd1c60e9bd097… yesterday. A lot of error messages like the following: sqlalchemy.exc.ArgumentError: Textual SQL expression 'visible=0 or auto_apply=1...' should be explicitly declared as text('visible=0 or auto_apply=1...') sqlalchemy.exc.OperationalError: (sqlite3.OperationalError) duplicate column name: priority_apply I'm wondering who else is also affected? Any hints for the workaround? Best regards, Lingxian Kong Catalyst Cloud

1 1

[Glance] Can Glance be installed on a server other than the controller?
by Jordan Michaels 09 Jun '19

09 Jun '19

Hi Folks, First time posting here so apologies if this question is inappropriate for this list. Just a quick question to see if Glance can be installed on a server other than the controller? By following the installation docs for Rocky I can get Glance installed just fine on the controller (works great!), but following that same documentation on a separate server I cannot get it to authenticate. It's probably just something I'm doing, but I've run out of ideas on what to check next (both the controller and the separate server use the same auth and config), and I just want to make sure it's possible. It's also possible I'm losing my mind, so, there's that. =P Posted about it in detail here: https://ask.openstack.org/en/question/122501/glance-unauthorized-http-401-o… Appreciate any advice! Kind regards, Jordan

3 2

[neutron] Mellanox Connectx5 ASAP2+LAG over VF+vxlan
by Zoltan Langi 08 Jun '19

08 Jun '19

Hello everyone, I hope someone more experienced can help me with this problem I've been struggling for a while now. I'm trying to set up ASAP2 ovs vxlan offload on a dual port Mellanox ConnectX5 card between 2 hosts using LACP link aggregation and Rocky release. When the LAG is not there, only one pf is being used, the offload works just fine, getting the line speed out of the vf-s. (I initially followed this ASAP2 guide, works well: https://community.mellanox.com/s/article/getting-started-with-mellanox-asap…) Decided, to provide HA for the vf-s, may as well use LACP as it's supported for ASAP2 according to Mellanox: https://www.mellanox.com/related-docs/prod_software/ASAP2_Hardware_Offloadi… (page15) So what I've done I've created a systemd script that puts the eswitch into switchdev mode on both ports before the networking starts at boot time, the bond0 comes up after the mode was changed just like in the docs. The bond0 interface wasn't added to the ovs as the doc recommends as it keeps the vxlan tunnel, only the vf is there after openstack creates the vm. The problem is only one direction of the traffic is offloaded when LAG is being used. I opened a mellanox case and they recommended to install the latest ovs version which I did: https://community.mellanox.com/s/question/0D51T00006kXkRzSAK/connectx5-asap… After using the latest OVS from master, the problem still exist, the offload simply doesn't work properly. The speed I am getting is way far away from the values that I get when only a single port is used. Does anyone has any experience or any idea what should I look our for or check? Thank you very much, anything is appreciated! Zoltan

3 4

Neutron with LBA and BGP-EVPN over IP fabric
by Jan Marquardt 08 Jun '19

08 Jun '19

Hi, we are currently trying to build an Openstack Cloud with an IP fabric and FRR directly running on each host. Therefore each host is supposed to advertise its VNIs to the fabric. For this purpose I’d need VXLAN interfaces with the following config: 18: vx-50: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-test state UNKNOWN mode DEFAULT group default qlen 1000 link/ether 7e:d2:e6:3c:5a:65 brd ff:ff:ff:ff:ff:ff promiscuity 1 vxlan id 50 local 10.0.0.101 srcport 0 0 dstport 8472 nolearning ttl inherit ageing 300 udpcsum noudp6zerocsumtx noudp6zerocsumrx bridge_slave state forwarding priority 32 cost 100 hairpin off guard off root_block off fastleave off learning off flood on port_id 0x8001 port_no 0x1 designated_port 32769 designated_cost 0 designated_bridge 8000.7e:d2:e6:3c:5a:65 designated_root 8000.7e:d2:e6:3c:5a:65 hold_timer 0.00 message_age_timer 0.00 forward_delay_timer 0.00 topology_change_ack 0 config_pending 0 proxy_arp off proxy_arp_wifi off mcast_router 1 mcast_fast_leave off mcast_flood on neigh_suppress off group_fwd_mask 0x0 group_fwd_mask_str 0x0 vlan_tunnel off addrgenmode eui64 numtxqueues 1 numrxqueues 1 gso_max_size 65536 gso_max_segs 65535 It seems that Neutron/lba is not capable of creating VXLAN interfaces with such a config. By default lba creates them with mode multicast, but I’d need unicast. The only way to activate unicast mode seems to be setting l2pop, but then lba does not set local address. Furthermore, I don't think we really need l2pop, because this part is supposed to be done by BGP-EVPN. Is there any way to achieve such config with Neutron/lba? Best Regards Jan -- Artfiles New Media GmbH | Zirkusweg 1 | 20359 Hamburg Tel: 040 - 32 02 72 90 | Fax: 040 - 32 02 72 95 E-Mail: support(a)artfiles.de | Web: http://www.artfiles.de Geschäftsführer: Harald Oltmanns | Tim Evers Eingetragen im Handelsregister Hamburg - HRB 81478

2 2

[keystone] Keystone Team Update - Week of 3 June 2019
by Colleen Murphy 07 Jun '19

07 Jun '19

# Keystone Team Update - Week of 3 June 2019 ## News ### Milestone 1 Check-in We scheduled our Milestone 1 meeting[1] and I proposed a draft agenda[2]. Looking forward to a productive meeting! [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-May/006783.html [2] http://lists.openstack.org/pipermail/openstack-discuss/2019-June/006976.html ### Sphinx update and the gate This week the release of Sphinx 2.1.0 broke our documentation builds. The issue[3] is that module constants are now automatically included as members in the document, and we were using constants as shorthand for external, imported modules that had broken docstrings. We've come up with a workaround[4], but as Elod pointed out, we're now documenting constants like CONF, LOG, and others which is an unexpected change in behavior. [3] https://github.com/sphinx-doc/sphinx/issues/6447 [4] https://review.opendev.org/663373 ### Expiring users We discussed[5] the work needed[6] to allow federated users to create and use application credentials, which formerly was making application credentials refreshable and is now being reworked to move the refresh layer upwards, but we had differring recollections on whether that layer was with the user or the grant. Kristi will update the spec to mention both options and the implementation and user experience implications for each option. [5] http://eavesdrop.openstack.org/meetings/keystone/2019/keystone.2019-06-04-1… [6] https://review.opendev.org/604201 ## Open Specs Train specs: https://bit.ly/2uZ2tRl Ongoing specs: https://bit.ly/2OyDLTh All specs for Train should now be proposed, new specs will not be accepted for Train after this point. Please provide and respond to feedback on open specs so that we can merge them in a timely manner. ## Recently Merged Changes Search query: https://bit.ly/2pquOwT We merged 3 changes this week. ## Changes that need Attention Search query: https://bit.ly/2tymTje There are 42 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. ## Bugs This week we opened 5 new bugs and closed 2. Bugs opened (5) Bug #1831918 (keystone:Medium) opened by Nathan Oyler https://bugs.launchpad.net/keystone/+bug/1831918 Bug #1831400 (keystone:Undecided) opened by Brin Zhang https://bugs.launchpad.net/keystone/+bug/1831400 Bug #1832005 (keystone:Undecided) opened by Maciej Kucia https://bugs.launchpad.net/keystone/+bug/1832005 Bug #1831791 (keystonemiddleware:Undecided) opened by Nathan Oyler https://bugs.launchpad.net/keystonemiddleware/+bug/1831791 Bug #1831406 (oslo.limit:Undecided) opened by jacky06 https://bugs.launchpad.net/oslo.limit/+bug/1831406 Bugs closed (2) Bug #1831400 (keystone:Undecided) https://bugs.launchpad.net/keystone/+bug/1831400 Bug #1831791 (keystonemiddleware:Undecided) https://bugs.launchpad.net/keystonemiddleware/+bug/1831791 ## Milestone Outlook https://releases.openstack.org/train/schedule.html Today is the last day to submit spec proposals for Train. The spec freeze is on the Train-2 milestone next month. Focus now should be on reviewing and updating specs. It's also not too early to get started on feature implementations. ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter

1 0

[nova] [cyborg] Impact of moving bind to compute
by Nadathur, Sundar 07 Jun '19

07 Jun '19

Hi, The feedback in the Nova - Cyborg interaction spec [1] is to move the call for creating/binding accelerator requests (ARQs) from the conductor (just before the call to build_and_run_instance, [2]) to the compute manager (just before spawn, without holding the build sempahore [3]). The point where the results of the bind are needed is in the virt driver [4] - that is not changing. The reason for the move is to enable Cyborg to notify Nova [5] instead of Nova virt driver polling Cyborg, thus making the interaction similar to other services like Neutron. The binding involves device preparation by Cyborg, which may take some time (ballpark: milliseconds to few seconds to perhaps 10s of seconds - of course devices vary a lot). We want to overlap as much of this as possible with other tasks, by starting the binding as early as possible and making it asynchronous, so that bulk VM creation rate etc. are not affected. These considerations are probably specific to Cyborg, so trying to make it uniform with other projects deserve a closer look before we commit to it. Moving the binding from [2] to [3] reduces this overlap. I did some measurements of the time window from [2] to [3]: it was consistently between 20 and 50 milliseconds, whether I launched 1 VM at a time, 2 at a time, etc. This seems acceptable. But this was just in a two-node deployment. Are there situations where this window could get much larger (thus reducing the overlap)? Such as in larger deployments, or issues with RabbitMQ messaging, etc. Are there larger considerations of performance or scaling for this approach? Thanks in advance. [1] https://review.opendev.org/#/c/603955/ [2] https://github.com/openstack/nova/blob/master/nova/conductor/manager.py#L15… [3] https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L1882 [4] https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L… [5] https://wiki.openstack.org/wiki/Nova/ExternalEventAPI Regards, Sundar

2 3

[Security SIG] Weekly Newsletter - June 06th 2019
by Gage Hugo 07 Jun '19

07 Jun '19

#Week of: 06 June 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 #Meeting Notes - Summary: http://eavesdrop.openstack.org/meetings/security/2019/security.2019-06-06-1… - This week we discussed the [openstack-security] mailing list usage. Currently it's only being used for launchpad to send automated notifications on security bugs. Due to this, we are considering designating the [openstack-security] mailing list to only be used for automated notifications and rewording the description for the mailing list to state this for clarity. If anyone is wanting to ask questions about security related questions, we will suggest using the -discussion mailing list. - We will discuss more on this next week and hammer out the final details. ## News - the scientific sig meeting this week featured a discussion on secure computing environments, if anyone here is interested in the transcript or wants to reach out to the participants about anything: - http://eavesdrop.openstack.org/meetings/scientific_sig/2019/scientific_sig.… - Image Encryption pop-up team's proposal: - https://review.opendev.org/#/c/661983/ - Storyboard work is nearly in place for a mechanism to auto-assign security teams to private stories marked "security" - https://review.opendev.org/#/q/topic:security-teams # VMT Reports - A full list of publicly marked security issues can be found here: https://bugs.launchpad.net/ossa/ - No new public security bugs this week

1 0

[openstack-ansible][powervm] dropping support
by Mohammed Naser 07 Jun '19

07 Jun '19

Hi everyone, I've pushed up a patch to propose dropping support for PowerVM support inside OpenStack Ansible. There has been no work done on this for a few years now, the configured compute driver is the incorrect one for ~2 years now which indicates that no one has been able to use it for that long. It would be nice to have this driver however given the infrastructure we have upstream, there would be no way for us to effectively test it and bring it back to functional state. I'm proposing that we remove the code here: https://review.opendev.org/662587 powervm: drop support If you're using this code and would like to contribute to fixing it and (somehow) adding coverage, please reach out, otherwise, we'll drop this code to clean things up. Thanks, Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

2 2

<Openstack-StarlingX> Unable to run ssh/iperf on StarlingX Vm
by Anirudh Gupta 07 Jun '19

07 Jun '19

Hi Team, I have created All in one simplex setup using release 2018.10. I have spawned 2 VM’s on it. The ping is successful between the VM’s, but I am unable to ssh or run iperf on it. Can you please help me in resolving the issue. Regards अनिरुद्ध गुप्ता (वरिष्ठ अभियंता) Hughes Systique Corporation D-23,24 Infocity II, Sector 33, Gurugram, Haryana 122001 DISCLAIMER: This electronic message and all of its contents, contains information which is privileged, confidential or otherwise protected from disclosure. The information contained in this electronic mail transmission is intended for use only by the individual or entity to which it is addressed. If you are not the intended recipient or may have received this electronic mail transmission in error, please notify the sender immediately and delete / destroy all copies of this electronic mail transmission without disclosing, copying, distributing, forwarding, printing or retaining any part of it. Hughes Systique accepts no responsibility for loss or damage arising from the use of the information transmitted by this email including damage from virus.

2 3

RE: '[Nova][Ironic] Reset Configurations in Baremetals Post Provisioning
by Kumari, Madhuri 07 Jun '19

07 Jun '19

Hi Eric, >-----Original Message----- >From: Eric Fried [mailto:openstack@fried.cc] >Waitwait. The VM needs to be rebooted for the BIOS change to take effect? >So (non-live) resize would actually satisfy your use case just fine. But the >problem is that the ironic driver doesn't support resize at all? > Yes you're right here. But the resize in Nova does migration which we don't want to do. Just apply the new traits and IronicDriver will run the matching deploy steps. >Without digging too hard, that seems like it would be a fairly straightforward >thing to add. It would be limited to only "same host" >and initially you could only change this one attribute (anything else would >have to fail). > >Nova people, thoughts? > >efried >. Regards, Madhuri

1 0

[nova] Validation for requested host/node on server create
by Matt Riedemann 06 Jun '19

06 Jun '19

It seems we've come to an impasse on this change [1] because of a concern about where to validate the requested host and/or hypervisor_hostname. The change is currently validating in the API to provide a fast fail 400 response to the user if the host and/or node don't exist. The concern is that the lookup for the compute node will be done again in the scheduler [2]. Also, if the host is not provided, then to validate the node we have to iterate the cells looking for the given compute node (we could use placement though, more on that below). I've added this to the nova meeting agenda for tomorrow but wanted to try and enumerate what I see are the options before the meeting so we don't have to re-cap all of this during the meeting. The options as I see them are: 1. Omit the validation in the API and let the scheduler do the validation. Pros: no performance impact in the API when creating server(s) Cons: if the host/node does not exist, the user will get a 202 response and eventually a NoValidHost error which is not a great user experience, although it is what happens today with the availability_zone forced host/node behavior we already have [3] so maybe it's acceptable. 2. Only validate host in the API since we can look up the HostMapping in the API DB. If the user also provided a node then we'd just throw that on the RequestSpec and let the scheduler code validate it. Pros: basic validation for the simple and probably most widely used case since for non-baremetal instances the host and node are going to be the same Cons: still could have a late failure in the scheduler with NoValidHost error; does not cover the case that only node (no host) is specified 3. Validate both the host and node in the API. This can be broken down: a) If only host is specified, do #2 above. b) If only node is specified, iterate the cells looking for the node (or query a resource provider with that name in placement which would avoid down cell issues) c) If both host and node is specified, get the HostMapping and from that lookup the ComputeNode in the given cell (per the HostMapping) Pros: fail fast behavior in the API if either the host and/or node do not exist Cons: performance hit in the API to validate the host/node and redundancy with the scheduler to find the ComputeNode to get its uuid for the in_tree filtering on GET /allocation_candidates. Note that if we do find the ComputeNode in the API, we could also (later?) make a change to the Destination object to add a node_uuid field so we can pass that through on the RequestSpec from API->conductor->scheduler and that should remove the need for the duplicate query in the scheduler code for the in_tree logic. I'm personally in favor of option 3 since we know that users hate NoValidHost errors and we have ways to mitigate the performance overhead of that validation. Note that this isn't necessarily something that has to happen in the same change that introduces the host/hypervisor_hostname parameters to the API. If we do the validation in the API I'd probably split the validation logic into it's own patch to make it easier to test and review on its own. [1] https://review.opendev.org/#/c/645520/ [2] https://github.com/openstack/nova/blob/2e85453879533af0b4d0e1178797d26f026a… [3] https://docs.openstack.org/nova/latest/admin/availability-zones.html -- Thanks, Matt

4 6

[goal][python3] Train unit tests weekly update (goal-14)
by Corey Bryant 06 Jun '19

06 Jun '19

This is the goal-14 weekly update for the "Update Python 3 test runtimes for Train" goal [1]. There are 14 weeks remaining for completion of Train community goals [2]. == What's the Goal? == To ensure (in the Train cycle) that all official OpenStack repositories with Python 3 unit tests are exclusively using the 'openstack-python3-train-jobs' Zuul template or one of its variants (e.g. 'openstack-python3-train-jobs-neutron') to run unit tests, and that tests are passing. This will ensure that all official projects are running py36 and py37 unit tests in Train. That is the main goal. Other work items will consist of: * Dropping py35 and old py3 zuul templates (e.g. drop 'openstack-python35-jobs', 'openstack-python36-jobs', 'openstack-python37-jobs', etc) * Updating setup.cfg classifiers (e.g. drop 'Programming Language :: Python :: 3.5' and add 'Programming Language :: Python :: 3.7') * Updating the list of default tox.ini environment (e.g. drop py35 and add py37) For complete details please see [1]. == Role of Goal Champion == Ensure patches are proposed to all affected repositories, encourage teams to help land patches, and report weekly status. == Role of Project Teams == Fix failing tests so that the proposed patches can merge. Project teams should merge the change to the Zuul config before the end of the Train cycle. == Ongoing Work == I will be the goal champion for this goal. I'm just getting organized at this point. Over the next week I plan to get scripts working to automate patch generation for all supported projects and start submitting patches. Open patches needing reviews: https://review.openstack.org/#/q/topic:python3-train+is:open == Completed Work == Merged patches: https://review.openstack.org/#/q/topic:python3-train+is:merged (Wow, look at that! Thanks Zhong Shengping.) == How can you help? == Please take a look at the failing patches and help fix any failing unit tests for your project(s). Python 3.7 unit tests will be self-testing in zuul. If you're interested in helping submit patches, please let me know. Failing patches: https://review.openstack.org/#/q/topic:python3-train+status:open+(+label:Ve… == Reference Material == [1] Goal description: https://review.opendev.org/#/c/657908 [2] Train release schedule: https://releases.openstack.org/train/schedule.html (see R-5 for "Train Community Goals Completed") Storyboard: https://storyboard.openstack.org/#!/board/<TBD> Porting to Python 3.7: https://docs.python.org/3/whatsnew/3.7.html#porting-to-python-3-7 Python Update Process: https://opendev.org/openstack/governance/src/branch/master/resolutions/2018… Train runtimes: https://opendev.org/openstack/governance/src/branch/master/reference/runtim… Thanks, Corey

1 0

Re: [Openstack-operators] [nova][glance] nova-compute choosing incorrect qemu binary when scheduling 'alternate' (ppc64, armv7l) architectures?
by Matt Riedemann 06 Jun '19

06 Jun '19

On 8/18/2018 10:09 PM, Matt Riedemann wrote: >> This sounds promising and there seems to be a feasible way to do this, >> but it also sounds like a decent amount of effort and would be a new >> feature in a future release rather than a bugfix - am I correct in >> that assessment? > > Yes I'd say it's a blueprint and not a bug fix - it's not something we'd > backport to stable branches upstream, for example. Just an update on this since it came up in IRC today (unrelated discussion which reminded me of this thread), Kashyap has created a nova blueprint: https://blueprints.launchpad.net/nova/+spec/pick-guest-arch-based-on-host-a… -- Thanks, Matt

1 0

[tc] Recap for Technical Committee Meeting 6 June 2019 @ 1400 UTC
by Alexandra Settle 06 Jun '19

06 Jun '19

Hello all, Thanks to those who joined the TC meeting today and running through it with me at the speed of light. Gif game was impeccably strong and that's primarily what I like about this community. For a recap of the meeting, please see the eavesdrop [0] for full detailed logs and action items. All items in the agenda [1] were covered and no major concerns raised. Next meeting will be on the 8th of July 2019. Cheers, Alex [0] http://eavesdrop.openstack.org/meetings/tc/2019/tc.2019-06-06-14.00.txt [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-June/006877.html

1 0

[blazar] IRC meeting today
by Pierre Riteau 06 Jun '19

06 Jun '19

Hello, We have our biweekly Blazar IRC meeting in less than one hour: https://wiki.openstack.org/wiki/Meetings/Blazar#Agenda_for_06_Jun_2019_.28A… We have the opportunity of discussing further how we can enforce policies for limiting reservation usage. I would also like to discuss downstream patches which could be contributed to the project. Everyone is welcome to join. Cheers, Pierre

1 0

[tc][kolla][kayobe] Feedback request: kayobe seeking official status
by Mark Goddard 06 Jun '19

06 Jun '19

Hi, The Kayobe project [1] seeks to become an official OpenStack project during the Train cycle. Kayobe is a deployment tool that uses Kolla Ansible and Bifrost to deploy a containerised OpenStack control plane to bare metal. The project was started 2 years ago to fill in some gaps in Kolla Ansible, and has since been used for a number of production deployments. It's frequently deployed in Scientific Computing environments, but is not limited to this. We ran a packed workshop on Kayobe at the Denver summit and got some great feedback, with many people agreeing that it makes Kolla Ansible easier to adopt in environments with no existing provisioning system. We use OpenStack development workflows, including IRC, the mailing list, opendev, zuul, etc. We see two options for becoming an official OpenStack project: 1. become a deliverable of the Kolla project 2. become an official top level OpenStack project Given the affinity with the Kolla project I feel that option 1 seems natural. However, I do not want to use influence as PTL to force this approach. There is currently only one person (me) who is a member of both core teams, although all kayobe cores are active in the Kolla community. I would not expect core memberships to change, although we would probably end up combining IRC channels, meetings and design sessions. I would hope that combining these communities would be to the benefit of both. Please provide feedback on this matter - whether positive or negative. Thanks, Mark [1] http://kayobe.readthedocs.io

4 4

[horizon] dropping 2012.2 tag on pypi
by Guilherme Steinmüller 06 Jun '19

06 Jun '19

Hello, As we've discussed with nova tag recently [1], I'd suggest the same for horizon. When we search on pypi the version it shows is 2012.2 and when we click release history we can see that the most recent version is 15.1.0 [2] [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-May/006780.html [2] https://pypi.org/project/horizon/#history Regards, Guilherme Steinmuller

3 2

[cloudkitty] Shift IRC meeting of June 7th
by Luka Peschke 06 Jun '19

06 Jun '19

Hi all, Tomorrow's IRC meeting for CloudKitty will be held at 14h UTC (16 CEST) instead of 15h UTC as huats and I won't be available at 15h. Cheers, -- Luka Peschke

1 0

[glance] zeroing image, preserving other parameters
by Volodymyr Litovka 06 Jun '19

06 Jun '19

Dear colleagues, for some reasons, I need to shrink image size to zero (freeing storage as well), while keeping this record in Glance database. First which come to my mind is to delete image and then create new one with same name/uuid/... and --file /dev/null, but this is impossible because Glance don't really delete records from database, marking them as 'deleted' instead. Next try was to use glance image-upload from /dev/null, but this is also prohibited with message "409 Conflict: Image status transition from [activated, deactivated] to saving is not allowed (HTTP 409)" I found https://docs.openstack.org/glance/rocky/contributor/database_architecture.h…'s "image_destroy" but have no clues on how to access this API. Is it kind of library or kind of REST API, how to access it and whether it's safe to use it in terms of longevity and compatibility between versions? Or, may be, you can advise any other methods to solve the problem of zeroing glance image data / freeing storage, while keeping in database just a record about this image? Thank you. -- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

2 3

[k8s-sig][cinder] Ember-CSI goes Beta!
by Gorka Eguileor 06 Jun '19

06 Jun '19

Hi, The Ember-CSI team is happy to announce the release of version v0.9, marking the graduation of the project into Beta. Ember-CSI is where Kubernetes storage and OpenStack storage intersect. By leveraging existing Cinder drivers via cinderlib [1], Ember-CSI is able to provide block and mount storage to containers in any Kubernetes cluster supporting the Container Storage Interface (CSI) in a lightweight solution, as it doesn't need to deploy a DBMS or Message Broker systems, and doesn't need to deploy the usual Cinder API, Volume, or Scheduler services either. Key features of the project are: - Multi-driver support on single container - Support for mount filesystems - Support for block - Topology support - Snapshot support - Liveness probe - No need to deploy a DBMS in K8s (uses CRD for metadata) - Multi-CSI version support on single container (v0.2, v0.3, and v1.0) - Storage driver list tool - Support live debugging of running driver - Duplicated requests queuing support (for k8s) - Support of mocked probe (when using faulty sidecars) - Configurable default mount filesystem The Beta is available in Docker Hub [2] -under "stable" and "ember_0.9.0-stein" tags- as well as in PyPi [3]. After this milestone, where we have achieved feature parity with CSI v1.0, we will mostly focus on the areas we consider necessary for the transition into GA: upgrading mechanism, performance improvements, and documentation. If time permits, we will also work on features from newer CSI spec versions, such as volume expansion. For those interested in the project, the team can be reached on FreeNode's #ember-csi channel and at the Google group [4]. We also have a small site [5] with articles on how to try it on K8s with 2 backends (LVM and Ceph) and the github org [6]. Cheers, Gorka. [1]: https://opendev.org/openstack/cinderlib [2]: https://hub.docker.com/r/embercsi/ember-csi [3]: https://pypi.org/project/ember-csi/ [4]: https://groups.google.com/forum/#!forum/embercsi [5]: https://ember-csi.io [6]: https://github.com/embercsi/

1 0

[nova] API updates week 19-23
by gmann＠ghanshyammann.com 06 Jun '19

06 Jun '19

Hi All, Please find the Nova API updates of this week. API Related BP : ============ Code Ready for Review: ------------------------------ 1. Support adding description while locking an instance: - Topic: https://review.opendev.org/#/q/topic:bp/add-locked-reason+(status:open+OR+s… - Weekly Progress: OSC patch has been updated by tssurya. 2. Add host and hypervisor_hostname flag to create server - Topic: https://review.opendev.org/#/q/topic:bp/add-host-and-hypervisor-hostname-fl… - Weekly Progress: patches have been updated with review comments. 3. Detach and attach boot volumes: - Topic: https://review.openstack.org/#/q/topic:bp/detach-boot-volume+(status:open+O… - Weekly Progress: No Progress Spec Ready for Review: ----------------------------- 1. Nova API policy improvement - Spec: https://review.openstack.org/#/c/547850/ - PoC: https://review.openstack.org/#/q/topic:bp/policy-default-refresh+(status:op… - Weekly Progress: Under review and updates. 2. Support for changing deleted_on_termination after boot -Spec: https://review.openstack.org/#/c/580336/ - Weekly Progress: No update this week. 3. Nova API cleanup - Spec: https://review.openstack.org/#/c/603969/ - Weekly Progress: Spec is merged. 4. Specifying az when restore shelved server - Spec: https://review.openstack.org/#/c/624689/ - Weekly Progress: Spec is updated for review comments. 5. Support delete_on_termination in volume attach api -Spec: https://review.openstack.org/#/c/612949/ - Weekly Progress: No updates this week. 7. Add API ref guideline for body text - ~8 api-ref are left to fix. Previously approved Spec needs to be re-proposed for Train: --------------------------------------------------------------------------- 1. Servers Ips non-unique network names : - https://blueprints.launchpad.net/nova/+spec/servers-ips-non-unique-network-… - https://review.openstack.org/#/q/topic:bp/servers-ips-non-unique-network-na… 2. Volume multiattach enhancements: - https://blueprints.launchpad.net/nova/+spec/volume-multiattach-enhancements - https://review.openstack.org/#/q/topic:bp/volume-multiattach-enhancements+(… Bugs: ==== No progress report in this week. NOTE- There might be some bug which is not tagged as 'api' or 'api-ref', those are not in the above list. Tag such bugs so that we can keep our eyes. -gmann

1 0

[sigs][publiccloud][publiccloud-wg][publiccloud-sig][billing] Bi-weekly meeting today at 1400 UTC
by Tobias Rydberg 06 Jun '19

06 Jun '19

Hi all, This is a reminder for todays meeting for the Public Cloud SIG - 1400 UTC in #openstack-publiccloud. The main focus for the meeting will be continues discussions regarding the billing initiative. More information about that at https://etherpad.openstack.org/p/publiccloud-sig-billing-implementation-pro… Agenda at: https://etherpad.openstack.org/p/publiccloud-wg See you all later today! Cheers, Tobias -- Tobias Rydberg Senior Developer Twitter & IRC: tobberydberg www.citynetwork.eu | www.citycloud.com INNOVATION THROUGH OPEN IT INFRASTRUCTURE ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED

1 0

Re: [Release-job-failures] Tag of openstack/ironic failed
by Thierry Carrez 06 Jun '19

06 Jun '19

zuul(a)openstack.org wrote: > Build failed. > > - publish-openstack-releasenotes-python3 http://logs.openstack.org/c9/c9009f704afed7579c9d8dfcf7b774623966ef5b/tag/p… : POST_FAILURE in 13m 56s This error occurred after tagging openstack/ironic 11.1.3, due to some transient network issue during release notes build rsync: http://zuul.openstack.org/build/d6f47db4f78b44599c4036a7039a1f5b It prevented release notes for 11.1.3 from being published. However the ironic release notes were regenerated after that, resulting in proper publication: http://zuul.openstack.org/build/e1b75f44857e44b1a94c2499e8b5f742 https://docs.openstack.org/releasenotes/ironic/rocky.html#relnotes-11-1-3-s… Note that the release pipeline jobs completed successfully, so the release itself is OK. Impact: Release notes for ironic 11.1.3 were unavailable for 30min. TODO: None -- Thierry Carrez (ttx)

1 0

[ops] database archiving tool
by Pierre-Samuel LE STANG 06 Jun '19

06 Jun '19

Hi all, At OVH we needed to write our own tool that archive data from OpenStack databases to prevent some side effect related to huge tables (slower response time, changing MariaDB query plan) and to answer to some legal aspects. So we started to write a python tool which is called OSArchiver that I briefly presented at Denver few days ago in the "Optimizing OpenStack at large scale" talk. We think that this tool could be helpful to other and are ready to open source it, first we would like to get the opinion of the ops community about that tool. To sum-up OSArchiver is written to work regardless of Openstack project. The tool relies on the fact that soft deleted data are recognizable because of their 'deleted' column which is set to 1 or uuid and 'deleted_at' column which is set to the date of deletion. The points to have in mind about OSArchiver: * There is no knowledge of business objects * One table might be archived if it contains 'deleted' column * Children rows are archived before parents rows * A row can not be deleted if it fails to be archived Here are features already implemented: * Archive data in an other database and/or file (actually SQL and CSV formats are supported) to be easily imported * Delete data from Openstack databases * Customizable (retention, exclude DBs, exclude tables, bulk insert/delete) * Multiple archiving configuration * Dry-run mode * Easily extensible, you can add your own destination module (other file format, remote storage etc...) * Archive and/or delete only mode It also means that by design you can run osarchiver not only on OpenStack databases but also on archived OpenStack databases. Thanks in advance for your feedbacks. -- Pierre-Samuel Le Stang

5 10

[oslo] Bandit Strategy
by Ben Nemec 06 Jun '19

06 Jun '19

Nefarious cap bandits are running amok in the OpenStack community! Won't someone take a stand against these villainous headwear thieves?! Oh, sorry, just pasted the elevator pitch for my new novel. ;-) Actually, this email is to summarize the plan we came up with in the Oslo meeting this morning. Since we have a bunch of projects affected by the Bandit breakage I wanted to make sure we had a common fix so we don't have a bunch of slightly different approaches in each project. The plan we agreed on in the meeting was to push a two patch series to each repo - one to cap bandit <1.6.0 and one to uncap it with a !=1.6.0 exclusion. The first should be merged immediately to unblock ci, and the latter can be rechecked once bandit 1.6.1 releases to verify that it fixes the problem for us. We chose this approach instead of just tweaking the exclusion in tox.ini because it's not clear that the current behavior will continue once Bandit fixes the bug. Assuming they restore the old behavior, this should require the least churn in our repos and means we're still compatible with older versions that people may already have installed. I started pushing patches under https://review.opendev.org/#/q/topic:cap-bandit (which prompted the digression to start this email ;-) to implement this plan. This is mostly intended to be informational, but if you have any concerns with the plan above please do let us know immediately. Thanks. -Ben

8 32

[kolla][tripleo] Podman/buildah
by Mark Goddard 06 Jun '19

06 Jun '19

Hi, At the Denver forum during the kolla feedback session [1], the topic of support for podman [2] and buildah [3] was raised. RHEL/CentOS 8 removes support for Docker [4], although presumably it will still be possible to pull down an RPM from https://download.docker.com/linux/. Currently both kolla and kolla-ansible interact with docker via the docker python module [5], which interacts with the docker daemon API. Given that podman and buildah are not daemons, I would expect the usage model to be a bit different. There is a python API for podman [6] which we might be able to use. I understand that Tripleo uses buildah to build images already (please correct me if I'm wrong). How is this achieved with kolla? Perhaps using 'kolla-build --template-only' to generate Dockerfiles then invoking buildah separately? Are you planning to work on adding buildah support to kolla itself? For running services, Tripleo uses Paunch [7] to abstract away the container engine, and it appears Podman support was added here - building CLI argument strings rather than via a python API [8]. For anyone using kolla/kolla-ansible, please provide feedback on how useful/necessary this would be to you. Thanks, Mark [1] https://etherpad.openstack.org/p/DEN-train-kolla-feedback [2] https://podman.io/ [3] https://buildah.io/ [4] https://access.redhat.com/solutions/3696691 [5] https://github.com/docker/docker-py [6] https://github.com/containers/python-podman [7] https://docs.openstack.org/developer/paunch/readme.html [8] https://github.com/openstack/paunch/blob/ecc2047b2ec5eaf39cce119abe1678ac19…

5 8

[airship] Is Ironic ready for Airship?
by 郭勇 06 Jun '19

06 Jun '19

I know Airship choose Maas as bare mental management tool. I want to know whether Maas is more suitable for Airship when it comes to under-infrastructure? If Maas is more suitable, then what feature should ironic develop? Thanks for your reply

2 1

[kolla][tripleo] Python 3, CentOS/RHEL 8
by Mark Goddard 06 Jun '19

06 Jun '19

Hi, At the recent kolla virtual PTG [1], we discussed the move to python 3 images in the Train cycle. hrw has started this effort for Ubuntu/Debian source images [2] and is making good progress. Next we will need to consider CentOS and RHEL. It seems that for Train RDO will provide only python 3 packages with support for CentOS 8 [3]. There may be some overlap in the trunk (master) packages where there is support for both CentOS 7 and 8. We will therefore need to combine the switch to python 3 with a switch to a CentOS/RHEL 8 base image. Some work was started during the Stein cycle to support RHEL 8 images with python 3 packages. There will no doubt be a few scripts that need updating to complete this work. We'll also need to test to ensure that both binary and source images work in this new world. Tripleo team - what are your plans for CentOS/RHEL 8 and python 3 this cycle? Are you planning to continue the work started in kolla during the Stein release? Thanks, Mark [1] https://etherpad.openstack.org/p/kolla-train-ptg [2] https://blueprints.launchpad.net/kolla/+spec/debian-ubuntu-python3 [3] https://review.rdoproject.org/etherpad/p/moving-rdo-to-centos8 [4] https://review.opendev.org/#/c/632156/

2 2

[upgrade][neutron] supported release window on rolling upgrade
by Akihiro Motoki 06 Jun '19

06 Jun '19

The neutron team is discussing how many releases we should support in RPC messages [1] (to drop downgrade codes in OVO). This affects rolling upgrade scenarios. Controller nodes are upgrade in FFU way, but we cannot upgrade compute nodes at once. This means controller nodes with N+X release need to talk compute nodes with N release. As of now, the neutron team is thinking to support LTS to LTS upgrade scenarios for major distributions and N->N+4 looks like the longest window. Rolling upgrade scenarios affect not only neutron but also other projects like nova, so I am sending this mail for broader input. [1] https://review.opendev.org/#/c/661995/ Thanks, Akihiro Motoki (irc: amotoki)

1 0

[qa][openstack-ansible] redefining devstack
by Mohammed Naser 05 Jun '19

05 Jun '19

Hi everyone, This is something that I've discussed with a few people over time and I think I'd probably want to bring it up by now. I'd like to propose and ask if it makes sense to perhaps replace devstack entirely with openstack-ansible. I think I have quite a few compelling reasons to do this that I'd like to outline, as well as why I *feel* (and I could be biased here, so call me out!) that OSA is the best option in terms of a 'replacement' # Why not another deployment project? I actually thought about this part too and considered this mainly for ease of use for a *developer*. At this point, Puppet-OpenStack pretty much only deploys packages (which means that it has no build infrastructure, a developer can't just get $commit checked out and deployed). TripleO uses Kolla containers AFAIK and those have to be pre-built beforehand, also, I feel they are much harder to use as a developer because if you want to make quick edits and restart services, you have to enter a container and make the edit there and somehow restart the service without the container going back to it's original state. Kolla-Ansible and the other combinations also suffer from the same "issue". OpenStack Ansible is unique in the way that it pretty much just builds a virtualenv and installs packages inside of it. The services are deployed as systemd units. This is very much similar to the current state of devstack at the moment (minus the virtualenv part, afaik). It makes it pretty straight forward to go and edit code if you need/have to. We also have support for Debian, CentOS, Ubuntu and SUSE. This allows "devstack 2.0" to have far more coverage and make it much more easy to deploy on a wider variety of operating systems. It also has the ability to use commits checked out from Zuul so all the fancy Depends-On stuff we use works. # Why do we care about this, I like my bash scripts! As someone who's been around for a *really* long time in OpenStack, I've seen a whole lot of really weird issues surface from the usage of DevStack to do CI gating. For example, one of the recent things is the fact it relies on installing package-shipped noVNC, where as the 'master' noVNC has actually changed behavior a few months back and it is completely incompatible at this point (it's just a ticking thing until we realize we're entirely broken). To this day, I still see people who want to POC something up with OpenStack or *ACTUALLY* try to run OpenStack with DevStack. No matter how many warnings we'll put up, they'll always try to do it. With this way, at least they'll have something that has the shape of an actual real deployment. In addition, it would be *good* in the overall scheme of things for a deployment system to test against, because this would make sure things don't break in both ways. Also: we run Zuul for our CI which supports Ansible natively, this can remove one layer of indirection (Zuul to run Bash) and have Zuul run the playbooks directly from the executor. # So how could we do this? The OpenStack Ansible project is made of many roles that are all composable, therefore, you can think of it as a combination of both Puppet-OpenStack and TripleO (back then). Puppet-OpenStack contained the base modules (i.e. puppet-nova, etc) and TripleO was the integration of all of it in a distribution. OSA is currently both, but it also includes both Ansible roles and playbooks. In order to make sure we maintain as much of backwards compatibility as possible, we can simply run a small script which does a mapping of devstack => OSA variables to make sure that the service is shipped with all the necessary features as per local.conf. So the new process could be: 1) parse local.conf and generate Ansible variables files 2) install Ansible (if not running in gate) 3) run playbooks using variable generated in #1 The neat thing is after all of this, devstack just becomes a thin wrapper around Ansible roles. I also think it brings a lot of hands together, involving both the QA team and OSA team together, which I believe that pooling our resources will greatly help in being able to get more done and avoiding duplicating our efforts. # Conclusion This is a start of a very open ended discussion, I'm sure there is a lot of details involved here in the implementation that will surface, but I think it could be a good step overall in simplifying our CI and adding more coverage for real potential deployers. It will help two teams unite together and have more resources for something (that essentially is somewhat of duplicated effort at the moment). I will try to pick up sometime to POC a simple service being deployed by an OSA role instead of Bash, placement which seems like a very simple one and share that eventually. Thoughts? :) -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

16 35

[ops][nova][placement] NUMA topology vs non-NUMA workloads
by Alexandre Arents 05 Jun '19

05 Jun '19

>From OVH point of view, We do not plan for now to mix NUMA aware and NUMA unaware workload on same compute. So you can go ahead without "can_split" feature if it helps. Alex >This message is primarily addressed at operators, and of those, >operators who are interested in effectively managing and mixing >workloads that care about NUMA with workloads that do not. There are >some questions within, after some background to explain the issue. > >At the PTG, Nova and Placement developers made a commitment to more >effectively manage NUMA topologies within Nova and Placement. On the >placement side this resulted in a spec which proposed several >features that would enable more expressive queries when requesting >allocation candidates (places for workloads to go), resulting in >fewer late scheduling failures. > >At first there was one spec that discussed all the features. This >morning it was split in two because one of the features is proving >hard to resolve. Those two specs can be found at: > >* https://review.opendev.org/658510 (has all the original discussion) >* https://review.opendev.org/662191 (the less contentious features split out) > >After much discussion, we would prefer to not do the feature >discussed in 658510. Called 'can_split', it would allow specified >classes of resource (notably VCPU and memory) to be split across >multiple numa nodes when each node can only contribute a portion of >the required resources and where those resources are modelled as >inventory on the NUMA nodes, not the host at large. > >While this is a good idea in principle it turns out (see the spec) >to cause many issues that require changes throughout the ecosystem, >for example enforcing pinned cpus for workloads that would normally >float. It's possible to make the changes, but it would require >additional contributors to join the effort, both in terms of writing >the code and understanding the many issues. > >So the questions: > >* How important, in your cloud, is it to co-locate guests needing a > NUMA topology with guests that do not? A review of documentation > (upstream and vendor) shows differing levels of recommendation on > this, but in many cases the recommendation is to not do it. > >* If your answer to the above is "we must be able to do that": How > important is it that your cloud be able to pack workloads as tight > as possible? That is: If there are two NUMA nodes and each has 2 > VCPU free, should a 4 VCPU demanding non-NUMA workload be able to > land there? Or would you prefer that not happen? > >* If the answer to the first question is "we can get by without > that" is it satisfactory to be able to configure some hosts as NUMA > aware and others as not, as described in the "NUMA topology with > RPs" spec [1]? In this set up some non-NUMA workloads could end up > on a NUMA host (unless otherwise excluded by traits or aggregates), > but only when there was contiguous resource available. > >This latter question articulates the current plan unless responses >to this message indicate it simply can't work or legions of >assistance shows up. Note that even if we don't do can_split, we'll >still be enabling significant progress with the other features >described in the second spec [2]. > >Thanks for your help in moving us in the right direction. > >[1] https://review.opendev.org/552924 >[2] https://review.opendev.org/662191 >-- >Chris Dent ٩◔̯◔۶ https://anticdent.org/ >freenode: cdent -- Alexandre Arents

1 0

[cloudkitty] Core team updates
by Luka Peschke 05 Jun '19

05 Jun '19

Hi all, I'd like to propose some updates to the CloudKitty core team: * First of all I'd like to welcome Justin Ferrieu (jferrieu on IRC) to the core team. He's been around contributing (mostly on the Prometheus collector and fetcher) and reviewing a lot for the last two releases (https://www.stackalytics.com/report/contribution/cloudkitty/90) It would be great if he had +2/+A power. * Some cores have been inactive for a long time. For now, Pierre-Alexandre Bardina can be removed from the core team, and I've reached out to the other inactive cores. We'll wait a bit for a reply before we proceed. Of course, if these people want to contribute again in the future, we'd be glad to welcome them back in the core team. Thanks to all contributors! Cheers, -- Luka Peschke

2 1

[kolla] Priorities for the Train cycle
by Mark Goddard 05 Jun '19

05 Jun '19

Hi, Thanks to those who attended the recent kolla virtual PTG [1]. We had some good technical discussions but did not get to a topic that I was keen to cover - priorities for the Train cycle. As a community of volunteers it can be difficult to guide the project in a particular direction, but agreeing on some priorities can help us to focus our efforts - both with reviews and development. I have seen this work well in the ironic team. Based on our recent discussions and knowledge of community goals, I compiled a list of candidate work items [2]. If you are involved with the kolla community (operator, developer, core, etc.), please vote on these priorities to indicate what you think we should focus on in the Train cycle. I will leave this open for a week, then order the items. At this point we can try to assign an owner to each. Thanks, Mark [1] https://etherpad.openstack.org/p/kolla-train-ptg [2] https://etherpad.openstack.org/p/kolla-train-priorities

1 0

[kolla] Feedback request: removing ceph deployment
by Mark Goddard 05 Jun '19

05 Jun '19

Hi, We discussed during the kolla virtual PTG [1] the option of removing support for deploying Ceph, as a way to improve the long term sustainability of the project. Ceph support in kolla does require maintenance, and is not the core focus of the project. There are other good tools for deploying Ceph (ceph-deploy, ceph-ansible), and Kolla Ansible supports integration with an external Ceph cluster deployed using these or other methods. To avoid leaving people in a difficult position, we would recommend a deployment tool (probably ceph-ansible), and provide an automated, tested and documented migration path to it. Here is a rough proposed schedule for removal: * Train: deprecate Ceph deployment, add CI tests for kolla-ansible with ceph-ansible * U: Obsolete Ceph deployment, provide migration path to ceph-ansible * V: Remove Ceph deployment Please provide feedback on this plan and how it will affect you. Thanks, Mark [1] https://etherpad.openstack.org/p/kolla-train-ptg

1 0

[kolla] Moving weekly IRC meetings to #openstack-kolla
by Mark Goddard 05 Jun '19

05 Jun '19

Hi, In the recent virtual PTG we agreed to move the weekly IRC meetings to the #openstack-kolla channel. This will take effect from today's meeting at 1500 UTC. Cheers, Mark

1 0

[airship] Is Ironic ready for Airship?
by Guoyong 05 Jun '19

05 Jun '19

I know Airship choose Maas as bare mental management tool. I want to know whether Maas is more suitable for Airship when it comes to under- infrastructure? If Maas is more suitable, then what feature should ironic develop? Thanks for your reply ------------------------------------------------------------------------------------------------------------------------------------- 本邮件及其附件含有新华三集团的保密信息，仅限于发送给上面地址中列出的个人或群组。禁止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！ This e-mail and its attachments contain confidential information from New H3C, which is intended only for the person or entity whose address is listed above. Any use of the information contained herein in any way (including, but not limited to, total or partial disclosure, reproduction, or dissemination) by persons other than the intended recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by phone or email immediately and delete it!

1 0

[scientific-sig] IRC Meeting today: CERN OpenStack Day, SDN, Secure computing and more
by Stig Telfer 05 Jun '19

05 Jun '19

Hi all - We have a Scientific SIG IRC meeting today at 1100 UTC in channel #openstack-meeting. Everyone is welcome. Today’s agenda is online here: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_June_5th_2019 <https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_June_5th_2019> If you’d like anything added, please let us know. Today we’ll do a roundup of last week’s excellent CERN OpenStack day, and follow up on the issues with south-bound coherency between Neutron and SDN. We’d also like to restart some discussions around secure computing environments - please come along with your experiences. Finally, we are looking for EMEA-region contributors to the research computing private/hybrid cloud advocacy study discussed at the PTG. Plenty to cover! Cheers, Stig

1 0

[telemetry] Meeting tomorrow cancelled
by Trinh Nguyen 05 Jun '19

05 Jun '19

Hi team, I'm leaving the office for vacation tomorrow so I will not able to hold the meeting. The next meeting will be on June 20th. Mean while, if you have any thing to discuss, please let me know or put it on the agenda [1]. Thanks, [1] https://etherpad.openstack.org/p/telemetry-meeting-agenda -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

1 0

[tc][form][ptg] Summary for "help-most-needed" list & its Future
by gmann＠ghanshyammann.com 05 Jun '19

05 Jun '19

Hello Everyone, We had many discussions on the help-most-needed list [1] & its future at Denver conference ( Joint leadership meeting, Forum and PTG). This time we are able to get volunteers from the board of directors, also new ideas to redefine the list and give another chance if we can get contributors to help from companies or universities. I am summarising all the discussions below, feel free to append/correct if I missed anything. * Joint Leadership Meeting: TC raised the topic of help-most-needed list to Board of Directors during the Joint leadership meeting and briefed the progress on adding the business value to each item in the list(thanks lance for working on those). TC raised the point of not getting help on those items which are there for many years. For example, many companies using designate and glance but there is no help from those companies in term of contributors. There are few ideas to market and publish this list on different platform and stakeholders. Alan gave a good idea to pick and publish one of the items in the foundation newsletter. For the first time, we had two volunteers from the Board of Directors, 1. Prakash Ramchandran 2. Allison Randal who will broadcast this list in companies and universities to get some contributors. Big thanks for helping on this. * Forum: 'Planning & Defining Structure for ‘Help most needed’ list' [2] We hosted forum sessions dedicated to further discussion on this 'help most needed’ list planning and future Structure. We discussed the ideas of defining the template for new entry and if there can be any exit criteria. There was mixed suggestion on exit criteria and how we make this list more effective. It is not easy to get help from companies at least now where many of the companies are reducing their upstream developers. Allison suggested that foundation staff and BoD are the good candidates to bridge between list and companies. She also suggested to reach out to professor instead of the student at OpenStack-interested universities and volunteers to reach out to OSU for that. Below are the action items we collected from that session. If you would like to volunteer for any of the unassigned AI, feel free to reach out to TC. Action Items: - (suggestion made by Alan Clark at joint leadership meeting) Pick a random item from the list and highlight it in the foundation newsletter (ttx) - (suggestion made by wendar) OSF Staff and BoD acting as matchmaker between list items and ecosystem companies who may be a good fit for pitching in (prakash, wendar) - make clear that we don't need full-time commitments, but we do need long-term commitments - gmann - pair up glance contribution needs with Edge WG participants who are interested in integrating/improving it to ensure it's also maintained - UC has a stronger connection to users/operators and could also help identify potential organizations who are interested in the long-term survival of these projects - (wendar)Identify professors at OpenStack-interested universities and give them project ideas. No point in advertising directly to students (post-doctorate programs in particular, not undergraduate programs) - adjust the business value sections to make it clear where these contributions impact the bottom line/profits arising from solving the problem statements (evrardjp asettle) - Reach user groups? - wendar will reach out to OSU * PTG: 'Evolution of help-most-needed list' [3] PTG discussion collected the good steps forward and working items to redefine/replan this list. The suggestion is to remove the cap on the number of items in the help needed list. It will be uncapped and will be renamed to something else. zaneb already proposed the renaming the entry template idea [4]. The list will be reiterated annually and new list obviously can have items from previous year list. Leveraging User Survey on grabbing information about project usage and what project companies contribute can provide good data to TC to decide the reach out companies for the help needed items. Below are the AI from PTG discussion- Action Items: - Update ML regarding forum session + discussion around uncapping list (gmann) - Suggest adding questions in user survey (ttx) - Rename "help most needed" to <??> (zaneb, asettle) - Uncap the list & add governance docs surrounding annual resubmission for items (ttx, evrardjp) - Include a "completition/exit/etc criteria" - Include (or not?) SIGs in all of this (to be discussed in reviews) [1] https://governance.openstack.org/tc/reference/help-most-needed.html [2] https://etherpad.openstack.org/p/Den-forum-help-most-needed [3] https://etherpad.openstack.org/p/tc-train-ptg [4] https://review.opendev.org/#/c/657447/ - gmann

1 0