April 2019 - openstack-discuss - lists.openstack.org

NVMe PCI-passthrough
by Manuel Sopena Ballesteros 03 Apr '19

03 Apr '19

Dear Openstack community, I am trying to attach NVMe drives to my vms and would like to check the configuration I have because for some reason it is not working. This is my physical host details: [root@zeus-59 ~]# lspci -nn -D | grep -i ssd 0000:03:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01) 0000:04:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01) 0000:06:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01) 0000:07:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01) 0000:08:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01) 0000:09:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01) 0000:84:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01) 0000:85:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01) 0000:86:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01) 0000:87:00.0 Non-Volatile memory controller [0108]: Intel Corporation PCIe Data Center SSD [8086:0953] (rev 01) My idea is to attach either 0000:03:00.0 or 0000:04:00.0 to a vm This is how I identify the block devices for each pci device: [root@zeus-59 ~]# ls -l /sys/bus/pci/devices/0000\:03\:00.0/nvme total 0 drwxr-xr-x. 4 root root 0 Apr 3 14:02 nvme0 [root@zeus-59 ~]# ls -l /sys/bus/pci/devices/0000\:04\:00.0/nvme total 0 drwxr-xr-x. 4 root root 0 Apr 3 14:02 nvme1 I installed the OS on the physical machine leaving those 2 drives intact: [root@zeus-59 ~]# lsblk NAME MAJ:MIN RM SIZE RO TYPE MOUNTPOINT sda 8:0 0 59.6G 0 disk ├─sda1 8:1 0 1G 0 part /boot └─sda2 8:2 0 4G 0 part [SWAP] sr0 11:0 1 906M 0 rom nvme0n1 259:15 0 1.8T 0 disk nvme1n1 259:0 0 1.8T 0 disk nvme2n1 259:11 0 1.8T 0 disk └─nvme2n1p1 259:12 0 1.8T 0 part /var/lib/docker/btrfs nvme3n1 259:6 0 1.8T 0 disk └─nvme3n1p1 259:7 0 1.8T 0 part nvme4n1 259:13 0 1.8T 0 disk └─nvme4n1p1 259:14 0 1.8T 0 part nvme5n1 259:5 0 1.8T 0 disk └─nvme5n1p1 259:8 0 1.8T 0 part nvme6n1 259:17 0 1.8T 0 disk └─nvme6n1p1 259:18 0 1.8T 0 part nvme7n1 259:9 0 1.8T 0 disk └─nvme7n1p1 259:10 0 1.8T 0 part nvme8n1 259:3 0 1.8T 0 disk └─nvme8n1p1 259:4 0 1.8T 0 part nvme9n1 259:1 0 1.8T 0 disk └─nvme9n1p1 259:2 0 1.8T 0 part The next thing is to configure Openstack nova api config [pci] alias = { "vendor_id":"8086", "product_id":"0953", "device_type":"type-PCI", "name":"nvme"} nova scheduler config [filter_scheduler] enabled_filters = RetryFilter, AvailabilityZoneFilter, ComputeFilter, ComputeCapabilitiesFilter, ImagePropertiesFilter, ServerGroupAntiAffinityFilter, ServerGroupAffinityFilter, PciPassthroughFilter available_filters = nova.scheduler.filters.all_filters nova compute config [filter_scheduler] enabled_filters = RetryFilter, AvailabilityZoneFilter, ComputeFilter, ComputeCapabilitiesFilter, ImagePropertiesFilter, ServerGroupAntiAffinityFilter, ServerGroupAffinityFilter, PciPassthroughFilter available_filters = nova.scheduler.filters.all_filters [pci] passthrough_whitelist = [ {"address":"0000:03:00.0"}, {"address":"0000:04:00.0"} ] alias = { "vendor_id":"8086", "product_id":"0953", "device_type":"type-PCI", "name":"nvme"} Then I create my flavor openstack flavor create nvme.small --ram 64000 --disk 10 --vcpus 7 --property "pci_passthrough:alias"="nvme:1" I created the vm towards the host with the free nvme drives [root@openstack-deployment ~]# openstack server create --flavor nvme.small --image centos7.5-image --nic net-id=hpc --security-group admin --key-name mykey --availability-zone nova:zeus-59.localdomain test_nvme_small Vm creation fails and I can see this error in the nova compute logs 2019-04-03 16:50:35.512 7 ERROR nova.virt.libvirt.guest [req-8478a99f-bad0-43d5-b405-55c45e8d8cae 91e83343e9834c8ba0172ff369c8acac b91520cff5bd45c59a8de07c38641582 - default default] Error launching a defined domain with XML: <domain type='kvm'> <name>instance-00000090</name> ... <devices> <emulator>/usr/libexec/qemu-kvm</emulator> <disk type='file' device='disk'> <driver name='qemu' type='qcow2' cache='none'/> <source file='/var/lib/nova/instances/a261fcd4-eca3-4982-8b2a-1df33087ab40/disk'/> <target dev='vda' bus='virtio'/> <address type='pci' domain='0x0000' bus='0x00' slot='0x04' function='0x0'/> </disk> ... 2019-04-03 16:50:35.513 7 ERROR nova.virt.libvirt.driver [req-8478a99f-bad0-43d5-b405-55c45e8d8cae 91e83343e9834c8ba0172ff369c8acac b91520cff5bd45c59a8de07c38641582 - default default] [instance: a261fcd4-eca3-4982-8b2a-1df33087ab40] Failed to start libvirt guest: libvirtError: unsupported configuration: host doesn't support passthrough of host PCI devices Any idea or advice would be very helpful Thank you very much NOTICE Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.

3 3

cinder 14.0.0.0rc2 (stein)
by no-reply＠openstack.org 03 Apr '19

03 Apr '19

Hello everyone, A new release candidate for cinder for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/cinder/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://git.openstack.org/cgit/openstack/cinder/log/?h=stable/stein Release notes for cinder can be found at: https://docs.openstack.org/releasenotes/cinder/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/cinder/+bugs and tag it *stein-rc-potential* to bring it to the cinder release crew's attention.

1 0

[trove] CI job migration to Bionic for stable/stein
by Lingxian Kong 03 Apr '19

03 Apr '19

Hi team, I've fixed the problems that blocked the job migration for the master, now according to the community requirement, we also need to finish the migration for stable/stein. I've already backported the needed patches, please review or reply directly to this email if you have any concerns. https://review.openstack.org/#/c/649744/ https://review.openstack.org/#/c/649745/ --- Cheers, Lingxian Kong Catalyst Cloud

1 0

keystone 15.0.0.0rc2 (stein)
by no-reply＠openstack.org 03 Apr '19

03 Apr '19

Hello everyone, A new release candidate for keystone for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/keystone/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://git.openstack.org/cgit/openstack/keystone/log/?h=stable/stein Release notes for keystone can be found at: https://docs.openstack.org/releasenotes/keystone/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/keystone/+bugs and tag it *stein-rc-potential* to bring it to the keystone release crew's attention.

1 0

networking-powervm 8.0.0.0rc2 (stein)
by no-reply＠openstack.org 03 Apr '19

03 Apr '19

Hello everyone, A new release candidate for networking-powervm for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/networking-powervm/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://git.openstack.org/cgit/openstack/networking-powervm/log/?h=stable/s… Release notes for networking-powervm can be found at: https://docs.openstack.org/releasenotes/networking-powervm/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/networking-powervm/+bugs and tag it *stein-rc-potential* to bring it to the networking-powervm release crew's attention.

1 0

ceilometer-powervm 8.0.0.0rc2 (stein)
by no-reply＠openstack.org 03 Apr '19

03 Apr '19

Hello everyone, A new release candidate for ceilometer-powervm for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/ceilometer-powervm/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://git.openstack.org/cgit/openstack/ceilometer-powervm/log/?h=stable/s… Release notes for ceilometer-powervm can be found at: https://docs.openstack.org/releasenotes/ceilometer-powervm/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/ceilometer-powervm/+bugs and tag it *stein-rc-potential* to bring it to the ceilometer-powervm release crew's attention.

1 0

nova_powervm 8.0.0.0rc2 (stein)
by no-reply＠openstack.org 03 Apr '19

03 Apr '19

Hello everyone, A new release candidate for nova_powervm for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/nova-powervm/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://git.openstack.org/cgit/openstack/nova-powervm/log/?h=stable/stein Release notes for nova_powervm can be found at: https://docs.openstack.org/releasenotes/nova-powervm/ If you find an issue that could be considered release-critical, please file it at: https://bugs.launchpad.net/nova-powervm/+bugs and tag it *stein-rc-potential* to bring it to the nova_powervm release crew's attention.

1 0

openstack-placement 1.0.0.0rc3 (stein)
by no-reply＠openstack.org 03 Apr '19

03 Apr '19

Hello everyone, A new release candidate for openstack-placement for the end of the Stein cycle is available! You can find the source code tarball at: https://tarballs.openstack.org/placement/ Unless release-critical issues are found that warrant a release candidate respin, this candidate will be formally released as the final Stein release. You are therefore strongly encouraged to test and validate this tarball! Alternatively, you can directly test the stable/stein release branch at: https://git.openstack.org/cgit/openstack/placement/log/?h=stable/stein Release notes for openstack-placement can be found at: https://docs.openstack.org/releasenotes/placement/ If you find an issue that could be considered release-critical, please file it at: https://storyboard.openstack.org/#!/project/openstack/placement and tag it *stein-rc-potential* to bring it to the openstack-placement release crew's attention.

1 0

[release][ptl] Delays on releasing RC requests
by Sean McGinnis 03 Apr '19

03 Apr '19

Just a heads up to anyone that is proposing a new RC release by this Thursday's final RC deadline. Sphinx 2.0 was released last Thursday, removing some deprecations that were not noticed in various libs and extensions that end up being used in our docs jobs. Our immediate issue is sphinxcontib.datatemplates that has been updated to handle not using the deprecated calls. But we have been blocked on a requirements update to allow that newer release to be used. We think (fingers crossed) that we have all the stars aligned where that should be merging in about an hour or so. Once it does, we should be able to recheck any existing release requests that have failing doc jobs and get those processed. If you were planning on requesting a new RC today, please go ahead and submit the request. If you have any questions, please stop by the #openstack-release channel. Thanks! Sean

1 1

[nova] super long online_data_migrations
by Mohammed Naser 03 Apr '19

03 Apr '19

Hi there, During upgrades, I've noticed that when running online_data_migrations with "infinite-until-done" mode, it loops over all of the migrations one by one. However, one of the online data migrations (instance_obj.populate_missing_availability_zones) makes a query that takes a really long time as it seems inefficient (which eventually results in 0, cause it already ran), which means as it loops in "blocks" of 50, there's almost a 2-3 to 8 minute wait in really large environments. The question ends up in specific: SELECT count(*) AS count_1 FROM (SELECT instance_extra.created_at AS instance_extra_created_at, instance_extra.updated_at AS instance_extra_updated_at, instance_extra.deleted_at AS instance_extra_deleted_at, instance_extra.deleted AS instance_extra_deleted, instance_extra.id AS instance_extra_id, instance_extra.instance_uuid AS instance_extra_instance_uuid FROM instance_extra WHERE instance_extra.keypairs IS NULL AND instance_extra.deleted = 0) AS anon_1 The explain for the DB query in this example: +------+-------------+----------------+------+---------------+------+---------+------+--------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +------+-------------+----------------+------+---------------+------+---------+------+--------+-------------+ | 1 | SIMPLE | instance_extra | ALL | NULL | NULL | NULL | NULL | 382473 | Using where | +------+-------------+----------------+------+---------------+------+---------+------+--------+-------------+ It's possible that it can be ever worse, as this number is from another very-long running environments. +------+-------------+----------------+------+---------------+------+---------+------+---------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +------+-------------+----------------+------+---------------+------+---------+------+---------+-------------+ | 1 | SIMPLE | instance_extra | ALL | NULL | NULL | NULL | NULL | 3008741 | Using where | +------+-------------+----------------+------+---------------+------+---------+------+---------+-------------+ I'm not the SQL expert, could we not optimize this? Alternatively, could we update the online data migrations code to "pop out" any of the migrations that return 0 for the next iteration, that way it only works on those online_data_migrations that *have* to be done, and ignore those it knows are done? Thanks, Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

5 7

[kolla] IRC meeting time
by Mark Goddard 03 Apr '19

03 Apr '19

Hi, As discussed in the last weekly meeting [1], I'd like to see if there is a meeting time that better suits our contributor base. Our current meeting slot is on Wednesday at 1500 UTC, which isn't good for contributors in APAC. If you are interested in joining the kolla IRC meetings on an at least semi-regular basis (let's say once per month minimum), please respond here with a broad range of UTC times that generally suit you. Feel free to add ideal/if need be annotations. Non-cores are of course welcome. I'll get the ball rolling. Ideal: 0900 - 1800 UTC If need be: 0800 - 2100 UTC Cheers, Mark

4 4

[trove] Trove for Train
by Lingxian Kong 03 Apr '19

03 Apr '19

Hi, I'm Lingxian Kong, I'm going to serve as Trove PTL for the Train dev cycle. Since the master branch is open for contribution and review, for those who care about Trove, here are several things I'd like to bring to your attention and most importantly, need your feedback. - Deprecate nova-network. As I mentioned in the candidacy, The nova-network related code is spread in the repo, which makes it very difficult for new feature implementation and bugfix. Considering nova-network was deprecated in the OpenStack Newton release, I propose we also deprecate nova-network support in Trove and remove after several cycles according to the deprecation policy of the community. I'm not sure if there is still anyone using nova-network for Trove, especially in production. If yes, please reply to this email. - Create service VM in admin project by default Currently, Trove has configuration support to create the db instance in the admin project, which I think should be the default deployment model to reduce the security risk given all the db instances are communicating with RabbitMQ in the control plane. - Remove SecurityGroup API extension TBH, I don't know when and why that extension was added in Trove but since it's not included in Trove API document( https://developer.openstack.org/api-ref/database/) I assume there is on one relies on that in production, so should be safe to remove. - Remove SecurityGroup related database model I don't have the history development background in my mind, but IMHO, i don't think it's reasonable for Trove to maintain such information in db. - Security group management enhancement Removing the API extension and database model doesn't mean Trove shouldn't support security group for the db instance, on the contrary, security should always be the first thing we consider for new features. The two tasks above are actually prerequisites for this one. In order to make it easy to maintain and as more secure as possible, Trove is not going to allow the end user to manipulate the security group associated with db instance. Trove will try to provide as more information as possible to make the debugging and performance tuning easy. - Monitoring capability Currently, there is no monitoring capability support in Trove, and I think that's the only main part missing for Trove to be running in production. I don't have a full picture in mind now but will try to figure out how to achieve that. - Priorities of the previous dev cycles Of course, I shouldn't put the previous dev cycle priorities away from the track, e.g. the Stein dev cycle priorities are well documented here https://etherpad.openstack.org/p/trove-stein-priorities-and-specs-tracking As Trove project has been experiencing some up and downs in the past, but it's still very useful in some deployment use cases and has some advantages over the container deployment model. As you could guess, the reason I raised my hand to lead Trove is that we(Catalyst Cloud) have been deploying Trove in production, so all those things are aiming at making Trove production ready, not only for private cloud but also for the public. If you have any concerns related to what's mentioned above, please don't hesitate to reply. Alternately, I'm always in the #openstack-trove IRC channel and could answer any questions during the working hours of UTC+12. I really appreciate any feedback from the community. --- Cheers, Lingxian Kong Catalyst Cloud

5 6

[horizon] Unused xstatic-* projects retirement
by Ivan Kolodyazhny 03 Apr '19

03 Apr '19

Hi team, There are some xstatic packages which I didn't start to use in Horizon or plugins. We didn't do any release of them. During the last meeting [1] we agreed to mark them as retired. I'll start retired procedure [2] today. If you're going to use them, please let me know. The list of the projects to be retired: - xstatic-angular-ui-router - xstatic-bootstrap-datepicker - xstatic-hogan - xstatic-jquery-migrate - xstatic-jquery.quicksearch - xstatic-jquery.tablesorter - xstatic-rickshaw - xstatic-spin - xstatic-vis [1] http://eavesdrop.openstack.org/meetings/horizon/2019/horizon.2019-01-09-15.… Regards, Ivan Kolodyazhny, http://blog.e0ne.info/

3 4

[stable][kolla] EOL kolla ocata branch
by Eduardo Gonzalez 03 Apr '19

03 Apr '19

Hi stable team, Kolla project is ready to tag EOL the stable/ocata branch. We would like to tag the following repositories as EOL: - openstack/kolla - openstack/kolla-ansible Let me know if need anything else. Regards

4 5

[taas] tap-as-a-service tempest plugin going to move
by Takashi Yamamoto 03 Apr '19

03 Apr '19

hi, tap-as-a-service tempest plugin is going to be moved into a separate branch-less repository. [1][2] i'm not sure what projects are using the plugin for their jobs. (thus this heads-up) i will update networking-midonet jobs. [3] [1] https://github.com/openstack/tap-as-a-service-tempest-plugin [2] https://review.openstack.org/#/c/649304/ [3] https://review.openstack.org/#/c/649309/

1 0

[release][heat] missing releases on tarballs.openstack.org
by Matthew Thode 03 Apr '19

03 Apr '19

Hi, there are a few tags missing for heat at https://tarballs.openstack.org/heat/ The missing releases are 11.0.1 and 12.0.0rc1 at the least. The cause may be the package name was changed in setup.cfg because it needed to be openstack-heat to be an available name on pypi. (via smcginnis). -- Matthew Thode

3 2

[tripleo][openstack-ansible] collaboration on os_tempest role update XVII - Apr 03, 2019
by Chandan kumar 03 Apr '19

03 Apr '19

Hello, Here is the 17th update (Mar 27 to Apr 02, 2019) on collaboration on os_tempest[1] role between TripleO and OpenStack-Ansible projects. Highlights of the week: * os_tempest got support of new source build process using python_venv_build role and it removes tempest_developer_mode from the os_tempest var * keystone_service_internaluri_insecure var got removed from os_tempest playbook and tempest_tempest_conf_overrides is passed to handle tempestconf overrides using zuul jobs. Thanks to odyssey4me, jrosser and mnaser for helping on new source build process patch. Things got merged: os_tempest: * Reuse tempest_tempest_conf_overrides in tempestconf extra args - https://review.openstack.org/648137 * Update role for new source build process - https://review.openstack.org/648026 * Test using integrated build - https://review.openstack.org/648580 tripleo * Update os_tempest playbook var for source install - https://review.openstack.org/648617 * Add tempest_tempest_conf_overrides to fs overrides - https://review.openstack.org/648373 * Remove keystone_service_internaluri_insecure var from os_tempest - https://review.openstack.org/647782 Things in progress: os_tempest: * user guide - https://review.openstack.org/#/c/644570/ tripleo * Introduce tempest_services var for installing tempest_plugins - https://review.openstack.org/#/c/648678/ * Add tempest_test_whitelist to allowed_override - https://review.openstack.org/648110 * Remove the tempest_test_whitelist from playbook - https://review.openstack.org/648111 What is coming for next week? * Arx is working on moving vars from os_tempest tripleo playbook to zuul var overrides so that it will be consumable while porting tripleo standalone scenario jobs to os_tempest. Here is the 16th update [2]. Have queries, Feel free to ping us on #tripleo or #openstack-ansible channel. Links: [1.] http://git.openstack.org/cgit/openstack/openstack-ansible-os_tempest [2.] http://lists.openstack.org/pipermail/openstack-discuss/2019-March/004270.ht… Thanks, Chandan Kumar

1 0

[octavia-api][queens] broken pipe
by Ignazio Cassano 03 Apr '19

03 Apr '19

Hello All, I installed octavia queens with centos and it works but in /var/log/messages I got a lot of errors like the following: Apr 2 09:53:15 tst2-osctrl01 octavia-api: self.RequestHandlerClass(request, client_address, self) Apr 2 09:53:15 tst2-osctrl01 octavia-api: File "/usr/lib64/python2.7/SocketServer.py", line 651, in __init__ Apr 2 09:53:15 tst2-osctrl01 octavia-api: self.finish() Apr 2 09:53:15 tst2-osctrl01 octavia-api: File "/usr/lib64/python2.7/SocketServer.py", line 710, in finish Apr 2 09:53:15 tst2-osctrl01 octavia-api: self.wfile.close() Apr 2 09:53:15 tst2-osctrl01 octavia-api: File "/usr/lib64/python2.7/socket.py", line 279, in close Apr 2 09:53:15 tst2-osctrl01 octavia-api: self.flush() Apr 2 09:53:15 tst2-osctrl01 octavia-api: File "/usr/lib64/python2.7/socket.py", line 303, in flush Apr 2 09:53:15 tst2-osctrl01 octavia-api: self._sock.sendall(view[write_offset:write_offset+buffer_size]) Apr 2 09:53:15 tst2-osctrl01 octavia-api: error: [Errno 32] Broken pipe octavia-api is under haproxy: listen octavia_cluster bind 10.102.184.190:9876 balance source option tcpka option httpchk option tcplog server tst2-osctrl01 10.102.184.191:9876 check fall 5 inter 2000 rise 2 server tst2-osctrl02 10.102.184.192:9876 check fall 5 inter 2000 rise 2 server tst2-osctrl03 10.102.184.193:9876 check fall 5 inter 2000 rise 2 Any help, please ? Another question is related to openstack command: Must I use neutron lbbas command or openstack loadbalancer command for octavia ? Loadbalancers created with neutron command cannot be shown with openstack loadbalancer command . Many thanks Ignazio

3 5

[ops] ops meetups twitter
by Chris Morgan 02 Apr '19

02 Apr '19

Hey all, Those of you who use twitter, please follow https://twitter.com/osopsmeetup to receive low-volume technical-only notifications of news relevant to openstack operators, mainly meetups. The account is run by the OpenStack Ops Meetups team. Chris -- Chris Morgan <mihalis68(a)gmail.com>

1 0

[scientific-sig] IRC Meeting today 2100 UTC
by Stig Telfer 02 Apr '19

02 Apr '19

Hi All - We have a Scientific SIG IRC meeting today at 2100 UTC in channel #openstack-meeting. Everyone is welcome. Today’s agenda is here: https://wiki.openstack.org/wiki/Scientific_SIG#IRC_Meeting_April_2nd_2019 We have a CFP for high-performance containerised workloads, follow-up on the discussion around help most needed for SIGs, and planning for SIG activities at the Denver summit. Cheers, Stig

1 0

[dev][keystone] Meeting time
by Colleen Murphy 02 Apr '19

02 Apr '19

As discussed in today's meeting, the end of the cycle is a good time to revisit the team meeting time. Please fill out the poll: https://doodle.com/poll/zxv6d2mxngmhb3vc We'll plan on having next week's meeting at the normal time in the normal meeting channel and discuss/announce any changes then. Colleen

1 2

[tripleo] disbanding security squad
by Juan Antonio Osorio Robles 02 Apr '19

02 Apr '19

Hello, So, the security squad hasn't had any activity for some time now. So I'm disbanding it for the time being. Folks can revive it if the need arises. The review to remove it from our docs is the following: https://review.openstack.org/#/c/649346/ Best regards

1 0

[Gerrit][Infra] Marking bot comments in email headers?
by Michael Still 02 Apr '19

02 Apr '19

Hi, wouldn't it be cool if we could somehow mark email from gerrit that came from a bot? Or inversely, call out email sent by a human somehow. That way I could null route all the bot spam and suddenly gerrit email would be useful again. Is this a thing upstream gerrit supports at all? Thanks, Michael

2 1

[sphinx][pecan][wsme][mistral] Sphinx 2.0.0 is not compatible with
by Renat Akhmerov 02 Apr '19

02 Apr '19

Hi, We have a problem with "openstack-tox-docs” CI job, see [1]. It seems like the new version of Sphinx (2.0.0) is not compatible with sphinxcontrib-pecanwsme 0.9.0. Does anyone know how to better address this? I guess there needs to be a new version of sphinxcontrib-pecanwsme that fixes this bug but I’m not even sure that this project is maintained. [1] http://logs.openstack.org/16/648316/6/check/openstack-tox-docs/3a2d588/job-… Thanks Renat Akhmerov @Nokia

3 4

qemu emulation or virtualiztion, which one is it using?
by Manuel Sopena Ballesteros 02 Apr '19

02 Apr '19

Hi, "openstack hypervisor list" command shows qemu as type of hypervisor. How do I know it is using virtualization and not qemu emulation? Thank you NOTICE Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.

4 6

[summit][ptg][mistral] Mistral PTL is at the Summit and the PTG
by Renat Akhmerov 02 Apr '19

02 Apr '19

Hi, Just want to make sure that people interested in any Mistral discussions know that I’m going to Denver and will be there almost till the end of the PTG. So if you’d like to catch me there, just ping me over email or in IRC (rakhmerov). Unfortunately, the approval to go was given quite late and we (again) failed to arrange a full event for Mistral. For that reason I don’t expect many Mistral team members to be in Denver. We’ll fix that in future. But for now we’ll have to be satisfied with informal talks. Some possible reasons why you may want to meet me there: • You already use Mistral but you need additional features in it and you are not sure wether it’s doable or not • You are just looking at Mistral as a technology that might be potentially useful for you and you have questions about architecture, use cases, real experience with it etc. • You’ve already tried Mistral in the past but had issues with it and you’re not sure wether it's worth trying again • You want to help with the development of the project but you don’t know what to begin with and how to better communicate with us Also, if anyone thinks I may be useful at some sessions that are somehow related to Mistral then please let me know and I’ll come. Thanks! Renat Akhmerov @Nokia

1 0

[keystone] how to write a plugin?
by Sergey Vilgelm 01 Apr '19

01 Apr '19

Hello community, Please help me to figure out how to write a plugin for keystone to modify the current functionality. I planned to create a middleware, but found that the paste was removed in Rocky and now Keystone uses the hard-coded list of middleware/apps. I need to call an additional script/api when creating a domain or a project. Is it possible to implement this without patching Keystone? -- Sergey Vilgelm https://www.vilgelm.info

2 3

[searchlight] Searchlight for Train
by Trinh Nguyen 01 Apr '19

01 Apr '19

Hi team, As we are reaching the final weeks of the Stein cycle, I would like to discuss a little bit about what we've done in Stein and planning for the Train cycle. Stein cycle highlights as putting in [1]: - Searchlight now works with Elasticsearch 5.x - We have released a new vision to make Searchlight a multi-cloud application [2]. Moreover, we did a comparison of our vision and the OpenStack clouds vision - Functional test setup has been improved - Searchlight now can work and be tested with Python 3.7 And for the Train cycle, we would like to accomplish these main goals to fulfill the vision: - Make searchlight work with multiple cloud platforms including multiple OpenStack clouds [6], Azure [9], Google Cloud [10], AWS [11]. - Add support for other OpenStack resources: Tacker [7], Octavia [8] - Deprecate support for Elasticsearch 2.x [5] There is a lot of work to be done so I would continue putting effort to encourage new contributors to Searchlight and explore the values it could bring the world. Let's rock it!!! Yours, [1] https://releases.openstack.org/stein/highlights.html#searchlight-search-ser… [2] https://docs.openstack.org/searchlight/latest/contributor/searchlight-visio… [3] https://docs.openstack.org/searchlight/latest/contributor/vision-reflection… [4] https://governance.openstack.org/tc/reference/technical-vision.html [5] https://storyboard.openstack.org/#!/story/2004904 [6] https://storyboard.openstack.org/#!/story/2004840 [7] https://storyboard.openstack.org/#!/story/2004968 [8] https://storyboard.openstack.org/#!/story/2004383 [9] https://storyboard.openstack.org/#!/story/2004718 [10] https://storyboard.openstack.org/#!/story/2004996 [11] https://storyboard.openstack.org/#!/story/2004719 -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

1 0

[placement][nova][infra] best way to add to required-projects on several zuul jobs
by Chris Dent 01 Apr '19

01 Apr '19

The extraction of placement led to the development of os-traits and os-resource-classes [1,2] which are python modules which contain symbols that represent "blessed" strings used as traits and resource classes in at least nova, placement and neutron, but plenty of others soon. These symbols are actively used when developing new features, so being able to access the python modules via tox-siblings [3] in both unit and functional tests, from multiple projects, would be grand: developers could depends-on changes in modules as they are being developed, or rely on symbols in master of the modules before there is a release to pypi. What is the best way to do this? Many projects are using templates like "openstack-python-jobs" but as far as I can tell there's no easy way to override just a part of a template in a local .zuul.yaml and the usual thing is to create another template such as "openstack-python-jobs-neutron" which re-lists all the jobs within, and adds a custom required-projects to each job. Is this (creating another template) the right/best way to add to required-projects for this kind of thing? If not, what's the best way? Presumably it is better to create a centralized job or template when >1 projects will need the additional libraries? Ideas? Thanks. [1] https://docs.openstack.org/os-traits/latest/ [2] https://docs.openstack.org/os-resource-classes/latest/ [3] https://docs.openstack.org/infra/manual/zuulv3.html#installation-of-sibling… -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

2 1

[all] Train goal: removing and simplifying the endpoint tripplets?
by Thomas Goirand 01 Apr '19

01 Apr '19

Hi, During the summit in Tokyo (if I remember well), Sean Dague lead a discussion about removing the need for having 3 endpoints per service. I was very excited about the proposal, and it's IMO a shame it hasn't been implemented. Everyone in the room agreed. Here the content of the discussion as I remember it: <discussion in Tokyo> 1/ The only service that needed the admin endpoint was Keystone. This requirement is now gone. So we could get rid of the admin endpoint all together. 2/ The need for an interal vs public endpoint was only needed for accounting (of for example bandwidth when uploading to Glance), but this could be work-around by operators by using intelligent routing. So we wouldn't need the internal endpoint. This makes us only need the public endpoint, and that's it. Then, there are these %(tenant_id)s bits in the endpoints which are also very much annoying, and could be removed if the clients were smarter. These are still needed, apparently, for: - cinder - swift - heat </discussion in Tokyo> Is anyone planning to implement (at least some parts of) the above? Cheers, Thomas Goirand (zigo)

8 7

[trove] Use storyboard
by Lingxian Kong 01 Apr '19

01 Apr '19

Hi trove team, We are going to use storyboard[1] for task tracking from Train dev cycle, please make sure there is related story/task for every new patch from now on. I didn't migrate things from launchpad so the links in the existing patches are still valid. [1]: https://storyboard.openstack.org/#!/project_group/trove --- Cheers, Lingxian Kong Catalyst Cloud

1 0

[neutron] CI meeting cancel
by Slawomir Kaplonski 01 Apr '19

01 Apr '19

Hi, I can’t chair neutron CI meeting this Tuesday (2.04) so I cancel it. See You on next meeting on 9.04. — Slawek Kaplonski Senior software engineer Red Hat

1 0

[training-labs] DHCP IP conflict with Ubuntu 18.04.2
by Julian Meier 01 Apr '19

01 Apr '19

Hi, we are currently working on a new environment for our school to teach some basic knowledge about OpenStack. Our goal is to run OpenStack training-labs for each student on VMs running on ESXi. Therefor we've enabled nested virtualization (vhv.enable=TRUE) for the VMs in vSphere. Then we basically do following on Ubuntu 18.04.2: ``` echo 1 > /sys/module/kvm/parameters/ignore_msr # to avoid following error while building the base image: "This usually means the libguestfs appliance failed to start or crashed." sudo apt-get install -y qemu-kvm libvirt-bin libguestfs-tools bridge-utils virt-manager virsh pool-create-as --name default --type dir --target /var/lib/libvirt/images wget http://tarballs.openstack.org/training-labs/dist/labs-stable-rocky.tgz tar xzf labs-stable-rocky.tgz cd labs/ ``` We build the base image ubuntu-18.04-server-amd64 with `./st.py --build basedisk --provider kvm` and then the cluster `./st.py --build cluster --provider kvm`. Everything works fine till...: stacktrain.log: ``` 12256 13:08:19.992 stacktrain.core.autostart INFO Start autostart/04_setup_nova_compute.sh 12256 13:08:19.994 stacktrain.core.ssh DEBUG vm_ssh: ssh -q -i /opt/oslab/labs/lib/osbash-ssh-keys/osbash_key -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o ConnectTimeout=20 -o ControlPath=none -p 22 osbash(a)192.168.122.208 bash autostart/04_setup_nova_compute.sh && rm -vf autostart/04_setup_nova_compute.sh 12256 13:08:19.994 stacktrain.core.ssh DEBUG Writing live log for ssh call at /opt/oslab/labs/log/021_04_setup_nova_compute.auto. 12256 13:08:56.551 stacktrain.core.ssh ERROR ssh returned status 255. 12256 13:08:56.552 stacktrain.core.autostart ERROR Script failure: 04_setup_nova_compute 11272 13:08:57.110 stacktrain.core.autostart ERROR Script failed. Exiting. ``` ssh.log: ``` ssh -q -i /opt/oslab/labs/lib/osbash-ssh-keys/osbash_key -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o ConnectTimeout=20 -o ControlPath=none -p 22 osbash(a)192.168.122.208 mkdir -p autostart ssh -q -i /opt/oslab/labs/lib/osbash-ssh-keys/osbash_key -o UserKnownHostsFile=/dev/null -o StrictHostKeyChecking=no -o ConnectTimeout=20 -o ControlPath=none -p 22 osbash(a)192.168.122.208 bash autostart/04_setup_nova_compute.sh && rm -vf autostart/04_setup_nova_compute.sh ``` For me it looks like both VMs (controller + compute1) get the same IP address (with `./st.py --build nodes_only --provider kvm`): ... Your cluster nodes: INFO VM name: compute1 INFO SSH login: ssh osbash(a)192.168.122.47 INFO (password: osbash) INFO VM name: controller INFO SSH login: ssh osbash(a)192.168.122.47 INFO (password: osbash) INFO Dashboard: Assuming horizon is on controller VM. INFO http://192.168.122.47/horizon/ INFO User : myuser (password: myuser_user_pass) INFO User : admin (password: admin_user_secret) INFO Network: mgmt INFO Network address: 10.0.0.0 INFO Network: provider INFO Network address: 203.0.113.0 ``` >From within the VMs: ``` # controller: osbash@osbash:~$ ifconfig ens3 ens3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.122.47 netmask 255.255.255.0 broadcast 192.168.122.255 inet6 fe80::5054:ff:fed9:b165 prefixlen 64 scopeid 0x20<link> ether 52:54:00:d9:b1:65 txqueuelen 1000 (Ethernet) ... osbash@osbash:~$ netplan ip leases ens3 # This is private data. Do not parse. ADDRESS=192.168.122.47 NETMASK=255.255.255.0 ROUTER=192.168.122.1 SERVER_ADDRESS=192.168.122.1 NEXT_SERVER=192.168.122.1 BROADCAST=192.168.122.255 T1=1800 T2=3150 LIFETIME=3600 DNS=192.168.122.1 HOSTNAME=osbash CLIENTID=ffb55e67ff00020000ab11bba91ddef33599c5 osbash@osbash:~$ cat /etc/machine-id b8c7057a4c084e69aa3743960d41d5ce # compute1: osbash@compute1:~$ ifconfig ens3 ens3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500 inet 192.168.122.47 netmask 255.255.255.0 broadcast 192.168.122.255 inet6 fe80::5054:ff:fe17:b640 prefixlen 64 scopeid 0x20<link> ether 52:54:00:17:b6:40 txqueuelen 1000 (Ethernet) ... osbash@compute1:~$ netplan ip leases ens3 # This is private data. Do not parse. ADDRESS=192.168.122.47 NETMASK=255.255.255.0 ROUTER=192.168.122.1 SERVER_ADDRESS=192.168.122.1 NEXT_SERVER=192.168.122.1 BROADCAST=192.168.122.255 T1=1800 T2=3150 LIFETIME=3600 DNS=192.168.122.1 HOSTNAME=compute1 CLIENTID=ffb55e67ff00020000ab11bba91ddef33599c5 osbash@compute1:~$ cat /etc/machine-id b8c7057a4c084e69aa3743960d41d5ce ``` I believe the VMs share the same IP address because of the same machine-id (which is used as DUID: http://manpages.ubuntu.com/manpages/bionic/man5/networkd.conf.5.html) Am I wrong? Thanks for your help, Julian

1 0

[placement] update 19-12
by Chris Dent 01 Apr '19

01 Apr '19

HTML: https://anticdent.org/placement-update-19-12.html Placement update 19-12. Nearing 1/4 of the way through the year. I won't be around on Monday, if someone else can chair the [meeting](http://eavesdrop.openstack.org/#Placement_Team_Meeting) that would be great. Or feel free to cancel it. # Most Important An RC2 was cut earlier this week, expecting it to be the last, but there are a [couple of patches](https://review.openstack.org/#/q/project:openstack/placement+branc… which could be put in an RC3 if we were inclined that way. Discuss. We merged a first suite of [contribution guidelines](https://docs.openstack.org/placement/latest/contributor/contrib…. These are worth reading as they explain how to manage bugs, start new features, and be a good reviewer. Because of the introduction of StoryBoard, processes are different from what you may have been used to in Nova. Because of limited time and space and conflicting responsibilities the Placement team will be doing a [Virtual Pre-PTG](http://lists.openstack.org/pipermail/openstack-discuss/2019-March/…. # What's Changed * The contribution guidelines linked above describe how to manage specs, which will now be in-tree. If you have a spec to propose or re-propose (from stein in nova), it now goes in ``doc/source/specs/train/approved/``. * Some [image type traits](https://review.openstack.org/648147) have merged (to be used in a nova-side request pre-filter), but the change has exposed an issue we'll need to resolve: os-traits and os-resource-classes are under the cycle-with-intermediary style release which means that at this time in the cycle it is difficult to make a release which can delay work. We could switch to independent. This would make sense for libraries that are basically lists of strings. It's hard to break that. We could also investigate making os-traits and os-resource-classes required-projects in job templates in zuul. This would allow them to be "tox siblings". Or we could wait. Please express an opinion if you have one. * In discussion in `#openstack-nova` about the patch to [delete placement from nova](https://review.openstack.org/#/c/618215/), it was decided that rather than merge that after the final RC, we would wait until the PTG. There is discussion on the patch which attempts to explain the reasons why. # Specs/Blueprint/Features * The spec for [forbidden aggregate membership](https://docs.openstack.org/placement/latest/specs/train/approve… has merged. * The two traits-related specs from stein will need to be re-proposed to placement for train: * [any traits](http://specs.openstack.org/openstack/nova-specs/specs/stein/approve… * [mixing required traits](http://specs.openstack.org/openstack/nova-specs/specs/stein/approve… * The spec for [request group mapping](https://review.openstack.org/597601) will need to be revisited. # Bugs * StoryBoard stories in [the placement group](https://storyboard.openstack.org/#!/project_group/placement): 4 * Placement related [bugs not yet in progress](https://goo.gl/TgiPXb): 14. * [In progress placement bugs](https://goo.gl/vzGGDQ) 7. +1. We should do a bug squash day at some point. Should we wait until after the PTG or no? Note that the [contribution guidelines](https://docs.openstack.org/placement/latest/contributor/contrib… has some information on how to evaluate new stories and what tags to add. # osc-placement osc-placement is currently behind by 13 microversions. Pending changes: * [support for 1.19](https://review.openstack.org/#/c/641094/) * [support for 1.21](https://review.openstack.org/#/c/641123/) * [aggregate allocation ratio tool](https://review.openstack.org/#/c/640898/) # Main Themes Be thinking about what you'd like the main themes to be. Put them on the [PTG etherpad](https://etherpad.openstack.org/p/placement-ptg-train). # Other Placement * <https://review.openstack.org/#/q/topic:2005297-negative-aggregate-membership> Negative member of aggregate filtering resource providers and allocation candidates. This is nearly ready. * <https://review.openstack.org/#/c/645255/> This is a start at unit tests for the PlacementFixture. It is proving a bit "fun" to get right, as there are many layers involved. Making sure seemingly unrelated changes in placement don't break the nova gate is important. Besides these unit tests, there's discussion on the PTG etherpad of running the nova functional tests, or a subset thereof, in placement's check run. On the one hand this is a pain and messy, but on the other consider what we're enabling: Functional tests that use the real functionality of an external service (real data, real web requests), not stubs or fakes. * <https://review.openstack.org/641404> Use ``code`` role in api-ref titles # Other Service Users There's a lot here, but it is certain this is not all of it. If I missed something you care about, followup mentioning it. * <https://review.openstack.org/552924> Nova: Spec: Proposes NUMA topology with RPs * <https://review.openstack.org/622893> Nova: Spec: Virtual persistent memory libvirt driver implementation * <https://review.openstack.org/641899> Nova: Check compute_node existence in when nova-compute reports info to placement * <https://review.openstack.org/601596> Nova: spec: support virtual persistent memory * <https://review.openstack.org/#/q/topic:bug/1790204> Workaround doubling allocations on resize * <https://review.openstack.org/555081> Nova: Spec: Standardize CPU resource tracking * <https://review.openstack.org/646029> Nova: Spec: Use in_tree getting allocation candidates * <https://review.openstack.org/645316> Nova: Pre-filter hosts based on multiattach volume support * <https://review.openstack.org/606199> Ironic: A fresh way of looking at step retrieval * <https://review.openstack.org/647396> Nova: Add flavor to requested_resources in RequestSpec * <https://review.openstack.org/633204> Blazar: Retry on inventory update conflict * <https://review.openstack.org/640080> Nova: Use aggregate_add_host in nova-manage * <https://review.openstack.org/#/q/topic:bp/count-quota-usage-from-placement> Nova: count quota usage from placement * <https://review.openstack.org/#/q/topic:bug/1819923> Nova: nova-manage: heal port allocations * <https://review.openstack.org/648500> Tempest: Init placement client in tempest Manager object * <https://review.openstack.org/624335> puppet-tripleo: Initial extraction of the Placement service from Nova * <https://review.openstack.org/#/q/topic:bug/1821824> Nova: bug fix prevent forbidden traits from working as expected * <https://review.openstack.org/648665> Nova: Spec for a new nova virt driver to manage an RSD * <https://review.openstack.org/#/q/topic:bug/1819460> Nova: Handle placement error during re-schedule * <https://review.openstack.org/#/c/642067/> Helm: Allow more generic overrides for nova placement-api * <https://review.openstack.org/647578> Nova: add spec for image metadata prefiltering -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

3 3

[Magnum] Cluster Create failure
by Navdeep Uniyal 01 Apr '19

01 Apr '19

Hi All, I am trying to create a cluster using Magnum using : magnum cluster-create kubernetes-cluster --cluster-template kubernetes-cluster-template --master-count 1 --node-count 1 --keypair magnum_key My Template looks like this: +-----------------------+--------------------------------------+ | Property | Value | +-----------------------+--------------------------------------+ | insecure_registry | - | | labels | {} | | updated_at | - | | floating_ip_enabled | True | | fixed_subnet | - | | master_flavor_id | small | | user_id | b4727cb329c14c388d777d0ce38c8a6b | | uuid | 24d01aea-c968-42e3-bcaa-a2e756aac5c7 | | no_proxy | - | | https_proxy | - | | tls_disabled | False | | keypair_id | - | | hidden | False | | project_id | 4c6bc4445c764249921a0a6e40b192dd | | public | False | | http_proxy | - | | docker_volume_size | 4 | | server_type | vm | | external_network_id | 5guknet | | cluster_distro | fedora-atomic | | image_id | fedora-atomic-latest | | volume_driver | - | | registry_enabled | False | | docker_storage_driver | devicemapper | | apiserver_port | - | | name | kubernetes-cluster-template | | created_at | 2019-03-27T12:21:27+00:00 | | network_driver | flannel | | fixed_network | - | | coe | kubernetes | | flavor_id | small | | master_lb_enabled | False | | dns_nameserver | 8.8.8.8 | +-----------------------+--------------------------------------+ I am getting the following error: {"explanation": "The server could not comply with the request since it is either malformed or otherwise incorrect.", "code": 400, "error": {"message": "ResourceTypeUnavailable: : resources.kube_masters<nested_st ack>.resources.0<file:///var/lib/magnum/env/lib/python2.7/site-packages/magnum/drivers/k8s_fedora_atomic_v1/templates/kubemaster.yaml>: : HEAT-E99001 Service cinder is not available for resource type Magnum::Opt ional::Cinder::Volume, reason: cinder volumev3 endpoint is not in service catalog.", "traceback": null, "type": "StackValidationFailed"}, "title": "Bad Request"} log_http_response /var/lib/magnum/env/local/lib/python2.7/site-packages/heatclient/common/http.py:157 2019-03-27 17:28:11.174 145885 ERROR oslo_messaging.rpc.server [req-b4037dc5-2fe1-4533-a6e3-433609c6b22d - - - - -] Exception during message handling: InvalidParameterValue: ERROR: ResourceTypeUnavailable: : res ources.kube_masters<nested_stack>.resources.0<file:///var/lib/magnum/env/lib/python2.7/site-packages/magnum/drivers/k8s_fedora_atomic_v1/templates/kubemaster.yaml>: : HEAT-E99001 Service cinder is not available for resource type Magnum::Optional::Cinder::Volume, reason: cinder volumev3 endpoint is not in service catalog. 2019-03-27 17:28:11.174 145885 ERROR oslo_messaging.rpc.server Traceback (most recent call last): 2019-03-27 17:28:11.174 145885 ERROR oslo_messaging.rpc.server File "/var/lib/magnum/env/local/lib/python2.7/site-packages/oslo_messaging/rpc/server.py", line 166, in _process_incoming 2019-03-27 17:28:11.174 145885 ERROR oslo_messaging.rpc.server res = self.dispatcher.dispatch(message) 2019-03-27 17:28:11.174 145885 ERROR oslo_messaging.rpc.server File "/var/lib/magnum/env/local/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 265, in dispatch 2019-03-27 17:28:11.174 145885 ERROR oslo_messaging.rpc.server return self._do_dispatch(endpoint, method, ctxt, args) 2019-03-27 17:28:11.174 145885 ERROR oslo_messaging.rpc.server File "/var/lib/magnum/env/local/lib/python2.7/site-packages/oslo_messaging/rpc/dispatcher.py", line 194, in _do_dispatch 2019-03-27 17:28:11.174 145885 ERROR oslo_messaging.rpc.server result = func(ctxt, **new_args) 2019-03-27 17:28:11.174 145885 ERROR oslo_messaging.rpc.server File "/var/lib/magnum/env/local/lib/python2.7/site-packages/magnum/conductor/handlers/cluster_conductor.py", line 80, in cluster_create 2019-03-27 17:28:11.174 145885 ERROR oslo_messaging.rpc.server raise e 2019-03-27 17:28:11.174 145885 ERROR oslo_messaging.rpc.server InvalidParameterValue: ERROR: ResourceTypeUnavailable: : resources.kube_masters<nested_stack>.resources.0<file:///var/lib/magnum/env/lib/python2.7/s ite-packages/magnum/drivers/k8s_fedora_atomic_v1/templates/kubemaster.yaml>: : HEAT-E99001 Service cinder is not available for resource type Magnum::Optional::Cinder::Volume, reason: cinder volumev3 endpoint is not in service catalog. 2019-03-27 17:28:11.174 145885 ERROR oslo_messaging.rpc.server The magnum.conf file is as suggested in https://docs.openstack.org/magnum/pike/install/install-guide-from-source.ht… I DO NOT have cinder in my openstack. I believe, it is optional. Please suggest how can I resolve this issue. Kind Regards, Navdeep

4 13

[nova][CI] nova-live-migration failing
by Eric Fried 01 Apr '19

01 Apr '19

I've noticed the nova-live-migration job failing consistently over the weekend on clearly unrelated patches. Haven't had a chance to look into it at all. Please consider holding off blind rechecks for a bit. Thanks, Eric Fried Concept Brazilian Jiu Jitsu http://taylorbjj.com

2 1

[neutron] CI broken
by Slawomir Kaplonski 01 Apr '19

01 Apr '19

Hi, Just FYI, since few days we have broken neutron-tempest-plugin-designate-scenario job and it is failing 100% times. Bug is reported in [1]. If this job failed on Your patch, please don’t recheck as it will not solve the problem. [1] https://bugs.launchpad.net/neutron/+bug/1822453 — Slawek Kaplonski Senior software engineer Red Hat

2 2

Re: [nova][CI] nova-live-migration failing
by Eric Fried 01 Apr '19

01 Apr '19

> I've noticed the nova-live-migration job failing consistently over the > weekend on clearly unrelated patches. Haven't had a chance to look > into it at all. Please consider holding off blind rechecks for a bit. Matt identified bug [1], cause [2], and fix [3]. Please wait until the latter has merged (or rebase on top of it) before rechecking in nova. Thanks, efried [1] https://bugs.launchpad.net/nova/+bug/1822605 [2] https://review.openstack.org/#/c/601433/ [3] https://review.openstack.org/#/c/649036/

1 0

[neutron] bug deputy report for week of 2019-03-25
by Bence Romsics 01 Apr '19

01 Apr '19

Hi Neutrinos, I was the bug deputy this week. I'm going to be on a training on Monday, so I'm sending this report a bit early. If I have the chance on Monday I'll send an updated version still before the team meeting in reply to this. We have no critical bugs and no new RFEs this week. If I may, please let me call your attention to the two High bugs below. High: * https://bugs.launchpad.net/neutron/+bug/1821912 intermittent ssh failures in various scenario tests gate failure, no fix proposed yet * https://bugs.launchpad.net/neutron/+bug/1822256 Ip segments lost when restart ovs-agent with openvswitch firewall packet loss at agent restart, no fix proposed yet Medium: * https://bugs.launchpad.net/neutron/+bug/1822100 Network Update if current provider net attribure key/value pair in request fix proposed: https://review.openstack.org/648522 * https://bugs.launchpad.net/neutron/+bug/1822105 Policy rules related to "sub parameters" doesn't work properly fix proposed: https://review.openstack.org/648532 * https://bugs.launchpad.net/neutron/+bug/1821948 Unstable unit test uses subnet broadcast address low frequency gate failure, fix merged: https://review.openstack.org/648172 Low: * https://bugs.launchpad.net/neutron/+bug/1822155 neutron-keepalived-state-change can not start on some python3 distro problem specific to (unsupported) python3.4, fix proposed: https://review.openstack.org/648459 * https://bugs.launchpad.net/neutron/+bug/1822199 neutron-vpn-netns-wrapper not invoked with --rootwrap_config parameter low hanging fruit, no fix proposed yet Incomplete: * https://bugs.launchpad.net/neutron/+bug/1821567 network_segment_ranges could not load in tricirlce test likely not a neutron bug but a tricircle one * https://bugs.launchpad.net/neutron/+bug/1821925 Limit test coverage for Extended Maintenance stable branches please look at it if you're interested in stable / extended maintenance process * https://bugs.launchpad.net/neutron/+bug/1821963 Rally test delete-subnets fails at higher concurrency could not reproduce yet, waiting to hear back from reporter Duplicate: * https://bugs.launchpad.net/neutron/+bug/1821357 VRRP vip on VM not reachable from other network on DVR setup duplicate of https://bugs.launchpad.net/bugs/1774459 Cheers, Bence irc: rubasov

1 1

[kuryr] Changing upstream meeting time
by Daniel Mellado 01 Apr '19

01 Apr '19

Hi all! Since most of our regular meeting attendees are in CEST time zone, I'm shifting the time slot for our regular meetings to match DST, so the new meeting time would be Mondays at 14:00 UTC. I've already proposed a patch at [1]. Searching at http://eavesdrop.openstack.org/ shows no conflict, so we'll be meeting at that time at #openstack-meeting-4 (falling back to #openstack-kuryr should any issues arise). If you have any doubt or comment, feel free to ping me at the irc. Best! Daniel [1] https://review.openstack.org/#/c/648927/

1 0

[monasca][ptg] PTG Planning
by Witek Bedyk 01 Apr '19

01 Apr '19

Hello everyone, the schedule for the next PTG in Denver has been published [1]. We have a room reserved from Thursday afternoon until Saturday. I have started an etherpad to collect topics for the discussion: https://etherpad.openstack.org/p/monasca-ptg-stein Please add your name and the times when you can attend (both F2F and remotely). Please also put the topics you would like to discuss or features you think we should add in the next release cycle. Thanks for your input and I'm looking forward to see/hear you there. Witek [1] https://www.openstack.org/ptg#tab_schedule

1 1