February 2020 - openstack-discuss

[nova] Ussuri spec push (and scrub)
by Eric Fried 06 Feb '20

06 Feb '20

Hi all. Ahead of spec freeze next Thursday (Feb 13) we've agreed to do a review day next Tuesday, Feb 11th. If you own a blueprint [1] that isn't already Design:Approved (there are 20 as of this writing) and are still interested in landing it in Ussuri, please make sure your spec is review-ready, and plan to be present in #openstack-nova on Tuesday so we can work through any issues quickly. If you are a nova maintainer, please plan as much time as possible on Tuesday to review open specs [2] and discuss them in IRC. As a reminder, soon after spec freeze I would like to scrub the list of Design:Approved blueprints ("if we're going to do this, here's how") to decide which should be Direction:Approved ("we're going to do this in Ussuri") and which should be deferred. I will send a separate email about this after the milestone. Thanks, efried [1] https://blueprints.launchpad.net/nova/ussuri [2] https://review.opendev.org/#/q/project:openstack/nova-specs+path:%255Especs…

1 0

[tc] February meeting agenda
by Rico Lin 06 Feb '20

06 Feb '20

Hello everyone, Our next meeting is happening this Thursday (the 6th), and the agenda is, as usual, on the wiki! Here is a primer of the agenda for this month: - Report on large scale sig - Report on tc/uc merge - report on the post for the analysis of the survey - Report on the convo Telemetry - Report on multi-arch SIG - report on infra liaison and static hosting - report on stable branch policy work - report on the oslo metrics project - report on the community goals for U and V, py2 drop - report on release naming - report on the ideas repo - report on charter change - Report on whether SIG guidelines worked - volunteers to represent OpenStack at the OpenDev advisory board - Report on the OSF board initiatives - Dropping side projects: using golden signals See you all in meeting:) -- May The Force of OpenStack Be With You, *Rico Lin*irc: ricolin

1 1

[openstack-dev][kuryr] Not working in ARM64 (as Node)
by VeeraReddy 06 Feb '20

06 Feb '20

Hi,I am trying to run kubelet in arm64 platform1. Generated kuryr-cni successfullly. using kur-cni Dockerfile2. Generated kuryr-cni-arm64 container.3. my kube-kuryr-arm64.yml (http://paste.openstack.org/show/789208/) My master node in x86 installed successfully using devstack While running kubelet in arm platform , not able to create kubelet interface (kubelet logs: http://paste.openstack.org/show/789206/) COntroller logs: http://paste.openstack.org/show/789209/ Please help me to fix the issue Veera. Regards, Veera.

2 3

[ops][cinder] Moving volume to new type
by Jonathan Proulx 06 Feb '20

06 Feb '20

Hi All, I'm currently languishing on Mitaka so perhaps further back than help can reach but...if anyone can tell me if this is something dumb I'm doing or a know bug in mitaka that's preventing me for movign volumes from one type to anyother it'd be a big help. In the further past I did a cinder backend migration by creating a new volume type then changing all the existign volume sto the new type. This is how we got from iSCSI to RBD (probably in Grizzly or Havana). Currently I'm starting to move from one RBD pool to an other and seems like this should work in the same way. Both pools and types exist and I can create volumes in either but when I run: openstack volume set --type ssd test-vol it rather silently fails to do anything (CLI returns 0), looking into schedulerlogs I see: # yup 2 "hosts" to check DEBUG cinder.scheduler.base_filter Starting with 2 host(s) get_filtered_objects DEBUG cinder.scheduler.base_filter Filter AvailabilityZoneFilter returned 2 host(s) get_filtered_objects DEBUG cinder.scheduler.filters.capacity_filter Space information for volume creation on host nimbus-1@ssdrbd#ssdrbd (requested / avail): 8/47527.78 host_passes DEBUG cinder.scheduler.base_filter Filter CapacityFilter returned 2 host(s) get_filtered_objects /usr/lib/python2.7/dist-packages/cinder/scheduler/base DEBUG cinder.scheduler.filters.capabilities_filter extra_spec requirement 'ssdrbd' does not match 'rbd' _satisfies_extra_specs /usr/lib/python2.7/dist- DEBUG cinder.scheduler.filters.capabilities_filter host 'nimbus-1@rbd#rbd': free_capacity_gb: 71127.03, pools: None fails resource_type extra_specs req DEBUG cinder.scheduler.base_filter Filter CapabilitiesFilter returned 1 host(s) get_filtered_objects /usr/lib/python2.7/dist-packages/cinder/scheduler/ # after filtering we have one DEBUG cinder.scheduler.filter_scheduler Filtered [host 'nimbus-1@ssdrbd#ssdrbd': free_capacity_gb: 47527.78, pools: None] _get_weighted_candidates # but it fails? ERROR cinder.scheduler.manager Could not find a host for volume 49299c0b-8bcf-4cdb-a0e1-dec055b0e78c with type bc2bc9ad-b0ad-43d2-93db-456d750f194d. successfully creating a volume in ssdrbd is identical to that point, except rather than ERROR on the last line it goes to: # Actually chooses 'nimbus-1@ssdrbd#ssdrbd' as top host DEBUG cinder.scheduler.filter_scheduler Filtered [host 'nimbus-1@ssdrbd#ssdrbd': free_capacity_gb: 47527.8, pools: None] _get_weighted_candidates DEBUG cinder.scheduler.filter_scheduler Choosing nimbus-1@ssdrbd#ssdrbd _choose_top_host # then goes and makes volume DEBUG oslo_messaging._drivers.amqpdriver CAST unique_id: 1b7a9d88402a41f8b889b88a2e2a198d exchange 'openstack' topic 'cinder-volume' _send DEBUG cinder.scheduler.manager Task 'cinder.scheduler.flows.create_volume.ScheduleCreateVolumeTask;volume:create' (e70dcc3f-7d88-4542-abff-f1a1293e90fb) transitioned into state 'SUCCESS' from state 'RUNNING' with result 'None' _task_receiver Anyone recognize this situation? Since I'm retiring the old spinning disks I can also "solve" this on the Ceph side by changing the crush map such that the old rbd pool just picks all ssds. So this isn't critical, but in the transitional period until I have enough SSD capacity to really throw *everything* over, there are some hot spot volumes it would be really nice to move this way. Thanks, -Jon

2 1

[charms] modular deployment
by Florian Rommel 06 Feb '20

06 Feb '20

Hi, we are starting to look into deploying Openstack with Charms ,however there seems to be NO documentation on how to separate ceph osd and mon out of the Openstack-base bundle. We already have a ceph cluster so we would like to reuse that instead of hyperconverging. Is there any way do do this with charms or do we need to look into openstack ansible? Thank you and best regards, //F

2 2

Active-Active Cinder + RBD driver + Co-ordination
by Paul Browne 06 Feb '20

06 Feb '20

Hi list, I had a quick question about Active-Active in cinder-volume and cinder-backup stable/stein and RBD driver, if anyone can help. Using only the Ceph RBD driver for volume backends, is it required to run A-A cinder services with clustering configuration so that they form a cluster? And, if so, is an external coordinator (redis/etcd/Consul) necessary, again only using RBD driver? Best docs I could find on this so far were; https://docs.openstack.org/cinder/latest/contributor/high_availability.html , I support more aimed at devs/contributoers than operators, but it's not 100% clear to me on these questions Thanks, Paul -- ******************* Paul Browne Research Computing Platforms University Information Services Roger Needham Building JJ Thompson Avenue University of Cambridge Cambridge United Kingdom E-Mail: pfb29(a)cam.ac.uk Tel: 0044-1223-746548 *******************

2 1

Re: [queens]cinder][iscsi] issue
by Ignazio Cassano 06 Feb '20

06 Feb '20

Hello , On centos kvm nodes, setting skip_kpartx no in multipath.conf solved the problem and now os_brick can flush maps Ignazio Il giorno lun 3 feb 2020 alle ore 15:13 Ignazio Cassano < ignaziocassano(a)gmail.com> ha scritto: > Hello all we are testing openstack queens cinder driver for Unity iscsi > (driver cinder.volume.drivers.dell_emc.unity.Driver). > > The unity storage is a Unity600 Version 4.5.10.5.001 > > We are facing an issue when we try to detach volume from a virtual machine > with two or more volumes attached (this happens often but not always). > > We also facing the same issue live migrating a virtual machine. > > > Multimaph -f does not work because it returns "map in use" and the volume > is not detached. > > Attached here there hare nova-compute e volume logs in debug mode. > > Could anyone help me ? > > Ignazio > > >

1 0

[kolla] All services stats DOWN after re-launch whole cluster.
by Eddie Yen 06 Feb '20

06 Feb '20

Hi everyone, We have the Kolla Openstack site, which is 3 HCI (Controller+Compute) + 3 Storage (Ceph OSD) site without internet. We did the shutdown few days ago since CNY holidays. Today we re-launch whole cluster back. First we met the issue that MariaDB containers keep restarting, and we fixed by using mariadb_recovery command. After that we check the status of each services, and found that all services shown at Admin > System > System Information are DOWN. Strange is no MariaDB, AMQP connection, or other error found when check the downed service log. We tried reboot each servers but the situation still a same. Then we found the RabbitMQ log not updating, the last log still stayed at the date we shutdown. Logged in to RabbitMQ container and type "rabbitmqctl status" shows connection refused, and tried access its web manager from <VIP>:15672 on browser just gave us "503 Service unavailable" message. Also no port 5672 listening. I searched this issue on the internet but only few information about this. One of solution is delete some files in mnesia folder, another is remove rabbitmq container and its volume then re-deploy. But both are not sure. Does anyone know how to solve it? Many thanks, Eddie.

4 8

[Ironic] [Sushy] [CI] 3rd Party CI
by Rajini.Karthik＠Dell.com 05 Feb '20

05 Feb '20

Announcing Dell 3rd Party Ironic CI is now functional for Openstack/Sushy library. Please take a look at https://review.opendev.org/#/c/705289/ Regards Rajini

1 0

[sahara] Cancelling Sahara meeting February 6
by Jeremy Freudberg 05 Feb '20

05 Feb '20

Hi all, There will be no Sahara meeting 2020-02-06, the principal reason being that I am on PTO. Holler if you need anything. Thanks, Jeremy

1 0