- openstack-discuss - lists.openstack.org

[wallaby][nova] Change Time Zone
by Malik Obaid 03 Jun '21

03 Jun '21

2 1

[kolla] [kolla-ansible] fluentd doesn't forward OpenStack logs to Elasticsearch
by Bernd Bausch 03 Jun '21

03 Jun '21

I might have found a bug in Kolla-Ansible (Victoria version) but don't know where to file it. This is about central logging. In my installation, none of the interesting logs (Nova, Cinder, Neutron...) are sent to Elasticsearch. I confirmed that using tcpdump. I found that fluentd's config file /etc/kolla/fluentd/td-agent.conf tags these logs with "kolla.*". But later in the file, one finds filters like this: # Included from conf/filter/01-rewrite-0.14.conf.j2: <match kolla.var.log.kolla.*.*.log> @type rewrite_tag_filter capitalize_regex_backreference yes ... <rule> key programname pattern ^(nova-api|nova-compute|nova-compute-ironic|nova-conductor|nova-manage|nova-novncproxy|nova-scheduler|nova-placement-api|placement-api|privsep-helper)$ tag openstack_python </rule> If I understand this right, this basically re-tags all nova logs with "openstack_python". The same config file has an output rule at the very end. I think the intention is to make this a catch-all rule (or "match anything else"): # Included from conf/output/01-es.conf.j2: <match *.**> @type copy <store> @type elasticsearch host 192.168.122.209 port 9200 scheme http etc. Unfortunately, the /openstack_python/ tag doesn't match /*.**/, since it contains no dot. I fixed this with <match **>. Now I receive all logs, but I am not sure if this is the right way to fix it. The error, if it is one, is in https://opendev.org/openstack/kolla-ansible/src/branch/master/ansible/roles…. If you want me to file a bug, please let me know how. Bernd.

2 3

[largescale-sig] Next meeting: June 2, 15utc
by Thierry Carrez 03 Jun '21

03 Jun '21

Hi everyone, Our next Large Scale SIG meeting will be this Wednesday in #openstack-meeting-3 on OFTC IRC, at 15UTC. You can doublecheck how it translates locally at: https://www.timeanddate.com/worldclock/fixedtime.html?iso=20210602T15 Note that we changed IRC networks, you should now connect to OFTC[1] rather than Freenode servers. [1] https://www.oftc.net/ A number of topics have already been added to the agenda, including discussing our next OpenInfra.Live show. Feel free to add other topics to our agenda at: https://etherpad.openstack.org/p/large-scale-sig-meeting Regards, -- Thierry Carrez

1 1

[neutron] Drivers meetning 04.06.2021 - agenda
by Slawek Kaplonski 03 Jun '21

03 Jun '21

Hi, We have one new RFE to discuss on the tomorrows drivers meeting: https://bugs.launchpad.net/neutron/+bug/1930200 - [RFE] Add support for Node-Local virtual IP[1] Please check it, ask any questions You will have regarding this proposal and see You on the meeting tomorrow. -- Slawek Kaplonski Principal Software Engineer Red Hat -------- [1] https://bugs.launchpad.net/neutron/+bug/1930200 - [RFE] Add support for Node-Local virtual IP

1 0

[all][tc] Technical Committee next weekly meeting on June 3rd at 1500 UTC
by Ghanshyam Mann 02 Jun '21

02 Jun '21

Hello Everyone, NOTE: FROM THIS WEEK ONWARDS, TC MEETINGS WILL BE HELD IN #openstack-tc CHANNEL ON OFTC NETWORK (NOT FREENODE) Technical Committee's next weekly meeting is scheduled for June 3rd at 1500 UTC. If you would like to add topics for discussion, please add them to the below wiki page by Wednesday, June 2nd, at 2100 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting -gmann

1 1

[ops] rabbitmq queues for nova versioned notifications queues keep filling up
by Ajay Tikoo (BLOOMBERG/ 120 PARK) 02 Jun '21

02 Jun '21

I am not sure if this is the right channel/format to post this question, so my apologies in advance if this is not the right place. We are using Openstack Rocky. Watcher needs versioned notifications to be enabled. However after enabling versioned notifications, the queues for versioned_notifications (info and error) keep filling up Based on the updates the the Watchers cluster data model, it appears that Watcher is consuming messages, but they still linger in these queues. So with nova versioned notifications disabled, Watcher is unable to update the cluster data model (between rebuild intervals), and with them enabled, it keeps filling up the MQ queues. What is the best way to resolve this? Thank you, Ajay Tikoo

1 0

Is the server Action Log immutable?
by Linebarger, John 02 Jun '21

02 Jun '21

Hello! Is the server Action Log absolutely immutable? Meaning, if you make a mistake in handling a server (VM) and it shows up in the Action Log, is there any way to remove that entry? I understand that the Action Log is kept in a database but am searching in vain for an API call that will allow such entries to be modified or deleted as opposed to merely displayed. What workarounds might exist? Thanks! Enjoy! John M. Linebarger, PhD, MBA Principal Member of Technical Staff Sandia National Laboratories (Office) 505-845-8282

2 1

[nova] Proper way to regenerate request_specs of existing instances?
by Patryk Jakuszew 02 Jun '21

02 Jun '21

Hi! I have a Rocky deployment and I want to enable AggregateInstanceExtraSpecsFilter on it. There is one slight problem I'm trying to solve in a proper way: fixing the request_specs of instances that are already running. After enabling the filter, I want to add necessary metadata keys to flavors, but this won't be propagated into request_specs of running instances, and this will cause issues later on (like scheduler selecting wrong destination hosts for migration, for example) Few years ago I encountered a similar problem on Mitaka: that deployment already had the filter enabled, but some flavors were misconfigured and lacked the metadata keys. I ended up writing a crude Python script which connected directly into the Nova database, searched for bad request_specs and manually appended the necessary extra_specs keys into request_specs JSON blob. Now, my question is: has anyone encountered a similar scenario before? Is there a more clean method for regeneration of instance request_specs, or do I have to modify the JSON blobs manually by writing directly into the database? -- Regards, Patryk Jakuszew

3 4

[interop] something strange
by Kanevsky, Arkady 02 Jun '21

02 Jun '21

Team, Once we merged https://review.opendev.org/c/osf/interop/+/786116 I expect that all old guidelines will move into directory "previous". I just sync my master to latest and still see old guidelines on top level directory. Any idea why? Thanks, Arkady Kanevsky, Ph.D. SP Chief Technologist & DE Dell Technologies office of CTO Dell Inc. One Dell Way, MS PS2-91 Round Rock, TX 78682, USA Phone: 512 7204955

2 2

PNDriver on openstack VM is not able to communicate to ET200SP device connected to my physical router
by Kumar Prasad, Vikash 02 Jun '21

02 Jun '21

Dear Community, I have installed openstack on Centos 7 on Virutalbox VM. Now I am running an application PNDriver on openstack VM(VNF), which is supposed to communicate with a hardware ET200SP, which is connected to my physical home router. Now my PNDriver is not able to communicate to ET200SP hardware device. PNDriver minimum requirements to run on an interface is using ethtool it should list the speed, duplex, and port properties, but by default speed , duplex, and port values it is Showing "unknown" on openstack VM(VNF). I tried setting these values using ethtool and somehow I was able to set duplex, speed values but port value when I am trying to set it is throwing error. My question is how we can set the port value of openstack VM(Vnf) using ethtool? Second question is that suppose if we create a VM on virtualbox, then virtualbox provides a provision for bridged type on network setting, can I not configure openstack vm (vnf) like a virtualbox VM so that my vnf can also get broadcast messages broadcasted by the connected hardware devices in my home router? Thanks Vikash kumar prasad

1 0

[kolla] IRC channel -> OFTC
by Mark Goddard 02 Jun '21

02 Jun '21

Hi Koalas, As you may already know, Openstack IRC has moved IRC channels from Freenode [1] to OFTC. So from today onwards, our weekly team meetings and general project discussion will be on OFTC on the same channel (#openstack-kolla). Kindly register yourself on OFTC n/w[ 2] if you have not done so yet. Thanks, Mark [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022718.html [2] https://www.oftc.net/Services/#register-your-account

1 0

[Octavia] Weekly meeting moving to OFTC
by Gregory Thiemonge 02 Jun '21

02 Jun '21

Hi team, The next Octavia team meeting (today at 16:00 UTC) will be on the OFTC network on #openstack-lbaas. Thanks,

1 0

Tacker Auto Scale Support
by Fadi Badine 01 Jun '21

01 Jun '21

Hello, I would like to know if VNF auto scaling is supported by Tacker and if so in which release. I tried looking at release notes but couldn't find anything. Thanks! Best regards, Fadi Badine Product Manager Office: +961 (1) 900 818 Mobile: +961 (3) 822 966 W: www.enghousenetworks.com<http://www.enghousenetworks.com> E: fadi.badine(a)enghouse.com<mailto:fadi.badine@enghouse.com>

2 1

[telemetry] Wallaby ceilometer.compute.discovery fails to get domain metadata
by Zakhar Kirpichenko 01 Jun '21

01 Jun '21

Hi! I'm facing a weird situation where Ceilometer compute agent fails to get libvirt domain metadata on an Ubuntu 20.04 LTS with the latest updates, kernel 5.4.0-65-generic and Openstack Wallaby Nova compute services installed using the official Wallaby repo for Ubuntu 20.04. All components have been deployed manually. Ceilometer agent is configured with instance_discovery_method = libvirt_metadata. The agent is unable to fetch the domain metadata, and the following error messages appear in /var/log/ceilometer/ceilometer-agent-compute.log on agent start and periodic polling attempts: 2021-06-01 16:01:18.297 1835684 ERROR ceilometer.compute.discovery [-] Fail to get domain uuid baf06f57-ac5b-4661-928c-7adaeaea0311 metadata, libvirtError: metadata not found: Requested metadata element is not present: libvirt.libvirtError: metadata not found: Requested metadata element is not present 2021-06-01 16:01:18.298 1835684 ERROR ceilometer.compute.discovery [-] Fail to get domain uuid 208c0d7a-41a3-4fa6-bf72-2f9594ac6b8d metadata, libvirtError: metadata not found: Requested metadata element is not present: libvirt.libvirtError: metadata not found: Requested metadata element is not present 2021-06-01 16:01:18.300 1835684 ERROR ceilometer.compute.discovery [-] Fail to get domain uuid d979a527-c1ba-4b29-8e30-322d4d2efcf7 metadata, libvirtError: metadata not found: Requested metadata element is not present: libvirt.libvirtError: metadata not found: Requested metadata element is not present 2021-06-01 16:01:18.301 1835684 ERROR ceilometer.compute.discovery [-] Fail to get domain uuid a41f21b6-766d-4979-bbe1-84f421b0c3f2 metadata, libvirtError: metadata not found: Requested metadata element is not present: libvirt.libvirtError: metadata not found: Requested metadata element is not present 2021-06-01 16:01:18.302 1835684 ERROR ceilometer.compute.discovery [-] Fail to get domain uuid fd5ffe32-c6d6-4898-9ba2-2af1ffebd502 metadata, libvirtError: metadata not found: Requested metadata element is not present: libvirt.libvirtError: metadata not found: Requested metadata element is not present 2021-06-01 16:01:18.302 1835684 ERROR ceilometer.compute.discovery [-] Fail to get domain uuid aff042c9-c311-4944-bc42-09ccd5a90eb7 metadata, libvirtError: metadata not found: Requested metadata element is not present: libvirt.libvirtError: metadata not found: Requested metadata element is not present 2021-06-01 16:01:18.303 1835684 ERROR ceilometer.compute.discovery [-] Fail to get domain uuid 9510bc46-e4e2-490c-9cbe-c9eb5e349b8d metadata, libvirtError: metadata not found: Requested metadata element is not present: libvirt.libvirtError: metadata not found: Requested metadata element is not present 2021-06-01 16:01:18.304 1835684 ERROR ceilometer.compute.discovery [-] Fail to get domain uuid 4d2c2c9b-4eff-460a-a00b-19fdbe33f5d4 metadata, libvirtError: metadata not found: Requested metadata element is not present: libvirt.libvirtError: metadata not found: Requested metadata element is not present 2021-06-01 16:01:18.305 1835684 DEBUG ceilometer.polling.manager [-] Skip pollster cpu_l3_cache, no resources found this cycle poll_and_notify /usr/lib/python3/dist-packages/ceilometer/polling/manager.py:177 2021-06-01 16:01:18.305 1835684 DEBUG ceilometer.polling.manager [-] Skip pollster disk.device.write.bytes, no resources found this cycle poll_and_notify /usr/lib/python3/dist-packages/ceilometer/polling/manager.py:177 2021-06-01 16:01:18.305 1835684 DEBUG ceilometer.polling.manager [-] Skip pollster network.incoming.packets, no resources found this cycle poll_and_notify /usr/lib/python3/dist-packages/ceilometer/polling/manager.py:177 2021-06-01 16:01:18.305 1835684 DEBUG ceilometer.polling.manager [-] Skip pollster disk.device.read.requests, no resources found this cycle poll_and_notify /usr/lib/python3/dist-packages/ceilometer/polling/manager.py:177 2021-06-01 16:01:18.306 1835684 DEBUG ceilometer.polling.manager [-] Skip pollster network.outgoing.packets, no resources found this cycle poll_and_notify /usr/lib/python3/dist-packages/ceilometer/polling/manager.py:177 2021-06-01 16:01:18.306 1835684 DEBUG ceilometer.polling.manager [-] Skip pollster network.outgoing.bytes, no resources found this cycle poll_and_notify /usr/lib/python3/dist-packages/ceilometer/polling/manager.py:177 2021-06-01 16:01:18.306 1835684 DEBUG ceilometer.polling.manager [-] Skip pollster network.incoming.bytes, no resources found this cycle poll_and_notify /usr/lib/python3/dist-packages/ceilometer/polling/manager.py:177 2021-06-01 16:01:18.306 1835684 DEBUG ceilometer.polling.manager [-] Skip pollster cpu, no resources found this cycle poll_and_notify /usr/lib/python3/dist-packages/ceilometer/polling/manager.py:177 2021-06-01 16:01:18.306 1835684 DEBUG ceilometer.polling.manager [-] Skip pollster disk.device.write.requests, no resources found this cycle poll_and_notify /usr/lib/python3/dist-packages/ceilometer/polling/manager.py:177 2021-06-01 16:01:18.307 1835684 DEBUG ceilometer.polling.manager [-] Skip pollster disk.device.read.bytes, no resources found this cycle poll_and_notify /usr/lib/python3/dist-packages/ceilometer/polling/manager.py:177 2021-06-01 16:01:18.307 1835684 DEBUG ceilometer.polling.manager [-] Skip pollster memory.usage, no resources found this cycle poll_and_notify /usr/lib/python3/dist-packages/ceilometer/polling/manager.py:177 All domains exist and their metadata is readily available using virsh or a simple Python script. Nova compute service is fully functional, Ceilometer agent is partially functional as it is able to export compute.node.cpu.* metrics but nothing related to libvirt domains. I already filed a bug report https://bugs.launchpad.net/ceilometer/+bug/1930446, but would appreciate feedback and/or advice. Best regards, Zakhar --- More deployment information: Installed Ceilometer-related packages: ceilometer-agent-compute 2:16.0.0-0ubuntu1~cloud0 ceilometer-common 2:16.0.0-0ubuntu1~cloud0 python3-ceilometer 2:16.0.0-0ubuntu1~cloud0 Installed Nova-related packages: nova-common 3:23.0.0-0ubuntu1~cloud0 nova-compute 3:23.0.0-0ubuntu1~cloud0 nova-compute-kvm 3:23.0.0-0ubuntu1~cloud0 nova-compute-libvirt 3:23.0.0-0ubuntu1~cloud0 python3-nova 3:23.0.0-0ubuntu1~cloud0 python3-novaclient 2:17.4.0-0ubuntu1~cloud0 Installed Libvirt-related packages: libvirt-clients 6.0.0-0ubuntu8.9 libvirt-daemon 6.0.0-0ubuntu8.9 libvirt-daemon-driver-qemu 6.0.0-0ubuntu8.9 libvirt-daemon-driver-storage-rbd 6.0.0-0ubuntu8.9 libvirt-daemon-system 6.0.0-0ubuntu8.9 libvirt-daemon-system-systemd 6.0.0-0ubuntu8.9 libvirt0:amd64 6.0.0-0ubuntu8.9 python3-libvirt 6.1.0-1 Installed Qemu-related packages: libvirt-daemon-driver-qemu 6.0.0-0ubuntu8.9 qemu-block-extra:amd64 1:4.2-3ubuntu6.16 qemu-kvm 1:4.2-3ubuntu6.16 qemu-system-common 1:4.2-3ubuntu6.16 qemu-system-data 1:4.2-3ubuntu6.16 qemu-system-gui:amd64 1:4.2-3ubuntu6.16 qemu-system-x86 1:4.2-3ubuntu6.16 qemu-utils 1:4.2-3ubuntu6.16 Apparmor is enabled and running the default configuration, no messages related to apparmor and libvirt, qemu, nova-compute, ceilometer-agent, etc are visible in the logs. I am also attaching the relevant Ceilometer agent and Nova configuration files: ceilometer.conf: [DEFAULT] transport_url = rabbit://WORKING-TRANSPORT-URL verbose = true debug = true auth_strategy = keystone log_dir = /var/log/ceilometer [compute] instance_discovery_method = libvirt_metadata [keystone_authtoken] www_authenticate_uri = http://CONTROLLER.VIP:5000 auth_url = http://CONTROLLER.VIP:5000 memcached_servers = LIST-OF-WORKING-MEMCACHED-SERVERS auth_type = password project_domain_name = default user_domain_name = default project_name = service username = ceilometer password = WORKING_PASSWORD [service_credentials] auth_type = password auth_url = http://CONTROLLER.VIP:5000/v3 memcached_servers = LIST-OF-WORKING-MEMCACHED-SERVERS project_domain_id = default user_domain_id = default project_name = service username = ceilometer password = WORKING_PASSWORD interface = internalURL region_name = RegionOne [oslo_messaging_notifications] driver = messagingv2 transport_url = rabbit://WORKING-TRANSPORT-URL polling.yaml: --- sources: - name: some_pollsters interval: 300 meters: - cpu - cpu_l3_cache - memory.usage - network.incoming.bytes - network.incoming.packets - network.outgoing.bytes - network.outgoing.packets - disk.device.read.bytes - disk.device.read.requests - disk.device.write.bytes - disk.device.write.requests - hardware.cpu.util - hardware.cpu.user - hardware.cpu.nice - hardware.cpu.system - hardware.cpu.idle - hardware.cpu.wait - hardware.cpu.kernel - hardware.cpu.interrupt - hardware.memory.used - hardware.memory.total - hardware.memory.buffer - hardware.memory.cached - hardware.memory.swap.avail - hardware.memory.swap.total - hardware.system_stats.io.outgoing.blocks - hardware.system_stats.io.incoming.blocks - hardware.network.ip.incoming.datagrams - hardware.network.ip.outgoing.datagrams nova.conf: [DEFAULT] log_dir = /var/log/nova lock_path = /var/lock/nova state_path = /var/lib/nova instance_usage_audit_period = hour compute_monitors = cpu.virt_driver,numa_mem_bw.virt_driver reserved_host_memory_mb = 2048 instance_usage_audit = True resume_guests_state_on_host_boot = true my_ip = COMPUTE.HOST.IP.ADDR report_interval = 30 transport_url = rabbit://WORKING-TRANSPORT-URL [api] [api_database] [barbican] [cache] expiration_time = 600 backend = oslo_cache.memcache_pool backend_argument = memcached_expire_time:660 enabled = true memcache_servers = LIST-OF-WORKING-MEMCACHED-SERVERS [cinder] catalog_info = volumev3::internalURL [compute] [conductor] [console] [consoleauth] [cors] [cyborg] [database] connection = mysql+pymysql://WORKING-CONNECTION-STRING connection_recycle_time = 280 max_pool_size = 5 max_retries = -1 [devices] [ephemeral_storage_encryption] [filter_scheduler] [glance] api_servers = http://CONTROLLER.VIP:9292 [guestfs] [healthcheck] [hyperv] [image_cache] [ironic] [key_manager] [keystone] [keystone_authtoken] www_authenticate_uri = http://CONTROLLER.VIP:5000 auth_url = http://CONTROLLER.VIP:5000 region_name = RegionOne memcached_servers = LIST-OF-WORKING-MEMCACHED-SERVERS auth_type = password project_domain_name = Default user_domain_name = Default project_name = service username = nova password = WORKING-PASSWORD [libvirt] live_migration_scheme = ssh live_migration_permit_post_copy = true disk_cachemodes="network=writeback,block=writeback" images_type = rbd images_rbd_pool = vms images_rbd_ceph_conf = /etc/ceph/ceph.conf rbd_user = cinder rbd_secret_uuid = SECRET-UUID [metrics] [mks] [neutron] auth_url = http://CONTROLLER.VIP:5000 region_name = RegionOne memcached_servers = LIST-OF-WORKING-MEMCACHED-SERVERS auth_type = password project_domain_name = Default user_domain_name = Default project_name = service username = neutron password = WORKING-PASSWORD [notifications] notify_on_state_change = vm_and_task_state [oslo_concurrency] lock_path = /var/lib/nova/tmp [oslo_messaging_amqp] [oslo_messaging_kafka] [oslo_messaging_notifications] driver = messagingv2 [oslo_messaging_rabbit] amqp_auto_delete = false rabbit_ha_queues = true [oslo_middleware] [oslo_policy] [pci] [placement] region_name = RegionOne project_domain_name = Default project_name = service auth_type = password user_domain_name = Default auth_url = http://CONTROLLER.VIP:5000/v3 username = placement password = WORKING-PASSWORD [powervm] [privsep] [profiler] [quota] [rdp] [remote_debug] [scheduler] [serial_console] [service_user] [spice] [upgrade_levels] [vault] [vendordata_dynamic_auth] [vmware] [vnc] enabled = true server_listen = 0.0.0.0 server_proxyclient_address = $my_ip novncproxy_base_url = https://WORKING-URL:6080/vnc_auto.html [workarounds] [wsgi] [zvm] [cells] enable = False [os_region_name] openstack =

1 0

Re: [Nova] Meeting time poll
by Sam Su (苏正伟) 01 Jun '21

01 Jun '21

0 *H÷ 010 +0 *H÷ $>Content-Type: text/plain; charset="gb2312" Content-Transfer-Encoding: 8bit Hi, Nova team£º There are many asian developers for Openstack community. I found the current IRC time of Nova is not friendly to them, especially to East Asian. If they can take part in the IRC meeting, the Nova may have more developers. Of cource, Central Europe and NA West Coast is firstly considerable. If the team could schedule the meeting once per month, time suitable for asians, more people would participate in the meeting discussion. -----ÓÊŒþÔŒþ----- ·¢ŒþÈË: Artom Lifshitz [mailto:alifshit@redhat.com] ·¢ËÍÊ±Œä: 2021Äê5ÔÂ14ÈÕ 1:07 ÊÕŒþÈË: OpenStack Discuss <openstack-discuss(a)lists.openstack.org> Ö÷Ìâ: [Nova] Meeting time poll hem Hey all, As discussed during the IRC meeting today, the Red Hat Nova team would like to know if it's possible to shift the IRC meeting to a different day and/or time. This would facilitate our own internal calls, but I want to be very clear that we'll structure our internal calls around upstream, not the other way around. So please do not perceive any pressure to change, this is just a question :) To help us figure this out, I've created a Doodle poll [1]. I believe the regular attendees of the IRC meeting are spread between Central Europe and NA West Coast, so I've tried to list times that kinda make sense in both of those places, with a couple of hours on each side as a safety margin. Please vote on when you'd like the Nova IRC meeting to take place. Ignore the actual dates (like May 10), the important bits are the days of the week (Monday, Tuesday, etc). This is obviously a recurring meeting, something that Doodle doesn't seem to understand. I've not included Mondays and Wednesdays in the list of possibilities, as they would not work for Red Hat Nova. You can also vote to keep the status quo :) The times are listed in UTC, like the current meeting time, so unfortunately you have to be mindful of the effects of daylight savings time :( Thanks in advance! [1] https://doodle.com/poll/45ptnyn85iuw7pxz E0¢0 cÊR,S8vMÂä:ÐVê0 *H÷ 0Y10 &ò,dcom10 &ò,dlangchao10 &ò,dhome10U INSPUR-CA0 170109092830Z 270109093829Z0Y10 &ò,dcom10 &ò,dlangchao10 &ò,dhome10U INSPUR-CA0"0 *H÷ 0 «ä5ïc$Œ©æ'µ¯Þ6>úUKÛdÔ²Áe9Î~{BîÒLgD÷*wvVÊŠ/DýUj_xá\m/ óž=kÐ·éGÙœQ€ýx~Wùgk ÛÜøãÔ7É6NçÏ*?n°Ê²mhùè{Ã¯ôÌÆ 7üF-Î<@ÃÓÍ¬WçÅyåLZrF 6~føÈ×T~$0d¡ýL|zšøW=ötÚ%ýq,¥Ã~Ÿ"ÀýŸÑö2T,QÕÔ,dºÂÅ^§ÈôïåJ)ëVvp Ó£f0d0 +7CA0U0Uÿ0ÿ0U^YŠŽLX`Nöµ¥9Š2Á5j0 +70 *H÷ JÄß»íu+¶Wù«áMÈL¯i8y1ü'áRæL€uK·u`K=9@žnA0×ŠqÓÂéÑVxÓf Ý»Åü<ÔUrpŠz¶Ï7vèÑ¥`oñ÷7Ä°ù¬?Þ`PMKŠžp»9 ìcwg UhÁþuu|6~ŒÁècŸŸkl!êkMÔS3B±Æù¯:«ççA^5"ÆX¯ èË&á)PNäŒØkäA-7fGR,¿äŸœÞ}ÖfeKéK¥[ H¢WžÓ{oÊù ,F_5°ÎZË>u00 ~a"Ã'pMÊsa"0 *H÷ 0Y10 &ò,dcom10 &ò,dlangchao10 &ò,dhome10U INSPUR-CA0 190606032704Z 240604032704Z010 &ò,dcom10 &ò,dlangchao10 &ò,dhome10Uæµªæœ®ä¿¡æ¯10U èæ£äŒ1$0" *H÷ suzhengwei@inspur.com0"0 *H÷ 0 ÏþOªdbñ3S©ÁPf~°Š(ÒóÙéáœö»sÉÐ»¹w»#žŽý;Fqt$â MÓBß€]¡MhžR=IIPXHŠîÃ<F¶ÚI¥Ñ3Oåå£1 éêi²LÕŸ8 ·Ëì7NOH|µ<M³õÚá ±®åÙ@üì€® ·²)ŒYŸ'1~ðäHŠç«\Æ§è~\¬º}¥os:õàÕ48IM"ÌÀ÷Z\|pÉ'Âpl;ççµeŠÈÜlªéYØw1¡~¡ðKäpåAøNšu!Ä}£00= +700.&+7ò©×z©=÷Ø\Jý&§Md\0)U%"0 ++ +7 0U 05 +7 (0&0 +0 +0 +7 0D *H÷ 7050*H÷ 0*H÷ 0+0 *H÷ 0UÉÈ¿ñY-ŸŒ°ÕŸf7Uv€0U#0^YŠŽLX`Nöµ¥9Š2Á5j0ÑUÉ0Æ0Ã À œºldap:///CN=INSPUR-CA,CN=JTCA2012,CN=CDP,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=home,DC=langchao,DC=com?certificateRevocationList?base?objectClass=cRLDistributionPoint0Ä+·0Ž0±+0€ldap:///CN=INSPUR-CA,CN=AIA,CN=Public%20Key%20Services,CN=Services,CN=Configuration,DC=home,DC=langchao,DC=com?cACertificate?base?objectClass=certificationAuthority0GU@0> % +7 suzhengwei@inspur.comsuzhengwei@inspur.com0 *H÷ ÊÃæÖñâ5ð+Éý,¬°Ü3zþdŸšÒMÚ¹Úxæ¥¹ÛHBœTfBUâ_lfÓ:.#§mK"§ÈL¹ç[Ç¿5FezK>6yÎP®)iÑ65k\&\v"³ÓÃäzKÇ S]*ÊO)§RÅþdãÖñN2üGç#v&4.$¯U»±[*3'NZfºÒ%åsÓå<"ù9¹{§ÌçÛîf7¶ùãÖ² ÞÌ-ÚÃñêfP!ï$JÑG£Cor°\S×AEzÙkÈšÖóB¯Lá!Öñ100p0Y10 &ò,dcom10 &ò,dlangchao10 &ò,dhome10U INSPUR-CA~a"Ã'pMÊsa"0 + ø0 *H÷ 1 *H÷ 0 *H÷ 1 210514012326Z0# *H÷ 1ŸÂÕ¶T0DóüÑµ¶80 +71r0p0Y10 &ò,dcom10 &ò,dlangchao10 &ò,dhome10U INSPUR-CA~a"Ã'pMÊsa"0*H÷ 1r p0Y10 &ò,dcom10 &ò,dlangchao10 &ò,dhome10U INSPUR-CA~a"Ã'pMÊsa"0 *H÷ 100 `He*0 `He0 *H÷ 0 `He0*H÷ 0 *H÷ @0+0 `He0 `He0 `He0 *H÷ «ä-7X×òÍ O05xÍh6÷ŽÔ?îk6è{îI®pq¯¯øQì¬°âmª¿%m<<Uv«d\ígt?)ÁJçá3S©å íL£&Îžð,°& h{stuCÃKÈ5=ÒvéqjórÝ^ç€ 1ºéT£Õn·rÈ£g&:2Ø)=C'SW>XËÄ âá{ a9[l}a=QÂ}7žR"È¹²8Üij Ÿ& l£·;Ÿ¹ö÷a4ó8Hv×{\#ª0&II¹¡ëžP%O2®jª?Â,HçôF

2 5

[Meeting] RDO Community Meeting
by Amy Marrich 01 Jun '21

01 Jun '21

Just a reminder that this week's meeting will be our video meeting[0][1] as it is the first meeting of the month. Our IRC meetings will be on OFTC in the #rdo channel beginning next week. Thanks, Amy (spotz) 0 - https://meet.google.com/uzo-tfkt-top. 1 - https://etherpad.opendev.org/p/RDO-Meeting

1 0

[requirements][docs] sphinx and docutils major version update
by Matthew Thode 01 Jun '21

01 Jun '21

Looks like a major version update came along and broke things. I'd appreciate if some docs people could take a look at https://review.opendev.org/793022 Thanks, -- Matthew Thode

2 1

[ops] ops meetups team meeting restarted succesfully on OFTC!
by Chris Morgan 01 Jun '21

01 Jun '21

We had a quick rehearsal meeting of the OpenStack Ops Meetups team on IRC on the new IRC host this morning. Minutes are linked below, however the key points : new team member amorin OFTC IRC worked fine openstack's meetbot instance is correctly connected and the expected commands worked (big shoutout to Jeremy Stanley and the opendev infra team for a seamless switch!) No strong preference to move away from IRC amongst those present We will try to re-animate the #openstack-operators as a channel for technical discussions between openstack operators Meeting ended Tue Jun 1 14:28:21 2021 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 10:28 AM Minutes: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2021/ops_meetup_tea… 10:28 AM Minutes (text): http://eavesdrop.openstack.org/meetings/ops_meetup_team/2021/ops_meetup_tea… 10:28 AM Log: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2021/ops_meetup_tea… Chris -- Chris Morgan <mihalis68(a)gmail.com>

1 0

[ops] trial ops meetups team meeting on oftc now
by Chris Morgan 01 Jun '21

01 Jun '21

let's try to kick the tires of the new IRC location (irc.oftc.net) for a ops meetups team reunion https://etherpad.opendev.org/p/ops-meetups-team -- Chris Morgan <mihalis68(a)gmail.com>

1 0

[docs] Request to clean up reviewers on openstack-doc-core and openstack-contributor-guide-core
by Julia Kreger 01 Jun '21

01 Jun '21

Greetings, I went to go hunt down a reviewer for the contributors guide this morning and found that at least one of the reviewers no longer works on OpenStack. In this case pkovar, but just glancing at the group lists, there appears to be others. If someone with appropriate privileges could update the group memberships to better reflect reality, it would be helpful to the rest of the community. Thanks! -Julia

5 5

[ops] Is there s way, i can boot nova instance using external DHCP
by Swamy C.N.N 01 Jun '21

01 Jun '21

Hi I know, this does not fit in the cloud operator model nor the openstack-neutron way of doing things. However, i have this use case: - vmware is booting guest vm with underlying DHCP server for IPAM integrated with DNS for host registration as the guest vms power on. So, vm gets ip with its hostname DNS registered as it boots. - I started a few vms on openstack, I can attach guest vms on these provider n/w and I can see they are reachable just like any other vm on an enterprise network similar to vmware guest vms and this is great. However, I cannot find any docs, option where these guest vms can cross over to external DHCP for ip address management because the provider network operates at Layer3. Found this blueprint, review discussion https://blueprints.launchpad.net/neutron/+spec/dhcp-relay Which is close to what i'm looking for and not updated for sometime. Wanted to know if anyone has come across this scenario and how to get over this. As one of the options, validated openstack-designate service which solves the hostname registration not the IPAM. Also it needs site DNS server domain management . Something, I can look at if the external DHCP server is not an option for nova boot. Thanks, Swamy

1 0

Is there s way, i can boot nova instance using external DHCP server ?
by Swamy C.N.N 01 Jun '21

01 Jun '21

Hi, I know, this does not fit in the cloud operator model nor the openstack-neutron way of doing things. However, i have this use case: - vmware is booting guest vm with underlying DHCP server for IPAM integrated with DNS for host registration as the guest vms power on. So, vm gets ip with its hostname DNS registered as it boots. - I started a few vms on openstack, I can attach guest vms on these provider n/w and I can see they are reachable just like any other vm on an enterprise network similar to vmware guest vms and this is great. However, I cannot find any docs, option where these guest vms can cross over to external DHCP for ip address management because the provider network operates at Layer3. Found this blueprint, review discussion https://blueprints.launchpad.net/neutron/+spec/dhcp-relay Which is close to what i'm looking for and not updated for sometime. Wanted to know if anyone has come across this scenario and how to get over this. As one of the options, validated openstack-designate service which solves the hostname registration not the IPAM. Also it needs site DNS server domain management . Something, I can look at if the external DHCP server is not an option for nova boot. Thanks, Swamy

1 0

[qa] Weekly meeting moving to OFTC starting June 1st
by Martin Kopec 01 Jun '21

01 Jun '21

Hello, as you are probably aware, OpenStack IRC has moved from FreeNode to OFTC network during the weekend [1]. Starting this week our weekly Office Hour which is held on #openstack-qa channel *will be at OFTC* network. [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022718.html Regards, -- Martin Kopec Senior Software Quality Engineer Red Hat EMEA

1 0

[horizon] Project channel and weekly meeting moving to OFTC n/w
by vishal manchanda 01 Jun '21

01 Jun '21

Hello Everyone, As you may already know Openstack IRC has moved from Freenode[1] n/w to OFTC n/w. So from tomorrow onwards, our weekly team meetings will be on OFTC n/w on the same channel (#openstack-meeting-alt) as previous one at Freenode n/w. Also, please try to discuss any topics on the same channel (openstack-horizon) on OFTC n/w. Kindly register yourself on OFTC n/w[ 2] if you have not done yet. Thanks & Regards, Vishal Manchanda [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022718.html [2] https://www.oftc.net/Services/#register-your-account

1 0

[blazar] Project channel and weekly meeting moving to OFTC
by Pierre Riteau 01 Jun '21

01 Jun '21

Hello, Like the rest of the OpenStack community, Blazar is moving to the OFTC network, still using the #openstack-blazar channel. Please join us over there. The bi-weekly meeting will also be on the OFTC network, still in #openstack-meeting-alt for now. For more information about the change of IRC network, read [1]. Best wishes, Pierre Riteau (priteau) [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022718.html

1 0

[magnum] docker_volume_size considered harmful?
by Krzysztof Klimonda 31 May '21

31 May '21

Hi, Reading through recent magnum reviews on gerrit, I've noticed Spyros' comment that he hopes not many people use this option. That lead me to look into issues related to this, but the only related piece of information I could find was that this option has been observed (or proven, depending on whether we read release notes or commit message) to become a bottleneck for scaling larger clusters. Firstly, if this option is considered problematic for scaling wouldn't it make sense to somehow deprecated it, and put a warning in the documentation describing the reasoning for that? Right now it seems to be a preferred way of deploying clusters based on the documentation - it is used in the cluster template creation example here: https://docs.openstack.org/magnum/latest/user/ Secondly, if docker volume is considered problematic, does this mean that volume-based instances have the same problem in general, and image-based instances should be used instead? When does this become a problem? For clusters with 20 nodes? 100? 200? 500? -- Krzysztof Klimonda kklimonda(a)syntaxhighlighted.com

1 0

[tacker] Next meeting moving on OFTC
by Yasufumi Ogawa 31 May '21

31 May '21

Hi team, The next tacker team meeting will be held on OFTC #openstack-meeting channel. Please refer [1] and [2] for joining to OFTC if you are not ready. [1] https://www.oftc.net/ [2] https://www.oftc.net/Services/#register-your-account Thanks, Yasufumi

1 0

Question regarding the production status of DB2 in Trove
by Bekir Fajkovic 31 May '21

31 May '21

Hello! One question regarding the development status of DB2 inside Trove. I see that DB2 is still in experimental phase, when could it be expected for that datastore type to get production ready status? Best Regards. Bekir Fajkovic Senior DBA Mobile: +46 70 019 48 47 www.citynetwork.eu | www.citycloud.com INNOVATION THROUGH OPEN IT INFRASTRUCTURE ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED

3 8

[sdk]: Block storage resource get volume created at time
by dmeng 31 May '21

31 May '21

Hello there, Hope this email finds you well. I have a question for getting the volume created at time using the openstacksdk block storage volume class. I found that the attribute volume.create_at is in a format like "2021-05-28T17:16:45.000000", and we don't know the timezone for it. Wondering if the openstack always uses the GMT? or anywhere we could set it to our pacific time? Thanks and have a great day! Catherine

1 0

[puppet] Moved #puppet-openstack from Freenode to OFTC
by Tobias Urdin 31 May '21

31 May '21

Hello Puppeters! Just a friendly reminder that we have moved #puppet-openstack from Freenode to OFTC. Best regards

1 0

[oslo] Weekly meeting moving to OFTC next week
by Herve Beraud 31 May '21

31 May '21

Hello, Just a friendly reminder to inform all the Osloers that OpenStack IRC has moved from freenode to OFTC during the past weekend. So henceforward our weekly team meeting will be at OFTC network, on the same channel (#openstack-oslo) as it was previously at Freenode. If anyone has yet to register on OFTC then kindly do so as soon as possible. Don't forget that meetings are now scheduled the first and the third Monday of each month [1]. So, see you there during our next meeting on Monday 03 June. [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-April/022124.ht… -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

1 0

[glance] Weekly meeting moving to OFTC from this week
by Abhishek Kekane 31 May '21

31 May '21

Hello Everyone, Everyone is aware that OpenStack IRC has moved from freenode to OFTC during the past weekend. So henceforward our weekly team meeting will be at OFTC network, on the same channel (#openstack-meeting) as it was previously at Freenode. If anyone has yet to register on OFTC then kindly do so as soon as possible. Thanks & Best Regards, Abhishek Kekane

1 0

[neutron] Meetings are moving to OFTC this week
by Slawek Kaplonski 31 May '21

31 May '21

Hi, OpenStack moved to the OFTC IRC channels already so starting this week our team meeting, CI meeting and drivers meeting will be at OFTC server, on same channels as it was previously at Freenode. -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[requirements][neutron][os-vif][octavia] pyroute2 and eventlet update breaking gate
by Matthew Thode 31 May '21

31 May '21

looks like more updates to bother you about. pyroute2 review is at https://review.opendev.org/793020 eventlet review is at https://review.opendev.org/793021 It looks like this is mainly impacting neutron related projects -- Matthew Thode

4 5

[nova] Next nova meeting will be already on OFTC
by Balazs Gibizer 31 May '21

31 May '21

Hi, The next weekly meeting on 1st of June will be held already on the OFTC IRC servers, in the #openstack-meeting-3 channel. Cheers, gibi

1 0

[neutron] Bug deputy report - week of May 24th
by Slawek Kaplonski 31 May '21

31 May '21

Hi, I was bug deputy last week. Here is my report regarding bugs from it: **critical** https://bugs.launchpad.net/neutron/+bug/1929518 - Functional db migration tests broken - assigned, patch proposed https://bugs.launchpad.net/neutron/+bug/1929633 - Mechanism driver 'ovn' failed in create_port_precommit: AttributeError: 'NoneType' object has no attribute 'chassis_exists' - Issue related to switch ovn to be default neutron's backend in devstack, in progress **high** https://bugs.launchpad.net/neutron/+bug/1929523 - Test tempest.scenario.test_network_basic_ops.TestNetworkBasicOps.test_subnet_details is failing from time to time - Unassigned https://bugs.launchpad.net/neutron/+bug/1929832 - stable/ussuri py38 support for keepalived-state-change monitor - In progress https://bugs.launchpad.net/neutron/+bug/1930222 - "test_add_and_remove_metering_label_rule_src_and_dest_ip_only" failing in py39 , in progress **medium** https://bugs.launchpad.net/neutron/+bug/1929438 - Cannot provision flat network after reconfiguring physical bridges - assigned, patch already proposed https://bugs.launchpad.net/neutron/+bug/1929578 - Make OVN metadata agent OVNDB read-only - assigned, patch proposed https://bugs.launchpad.net/neutron/+bug/1929676 - API extensions not supported by e.g. OVN driver may still be on the list returned from neutron - assigned, patch proposed https://bugs.launchpad.net/neutron/+bug/1930195 - Bump os-ken to 2.0.0 - in progress **Low** https://bugs.launchpad.net/neutron/+bug/1929658 - [OVN] Enable OVN L3 router plugin support for filter-validation - assigned, fix proposed https://bugs.launchpad.net/neutron/+bug/1929821 - [dvr] misleading fip rule priority not found error message - unassigned https://bugs.launchpad.net/neutron/+bug/1929998 - VXLAN interface cannot source from lo with multiple IPs - assigned... **undecided** https://bugs.launchpad.net/neutron/+bug/1930096 - Missing static routes after neutron-l3-agent restart - waiting for some info... **RFE** https://bugs.launchpad.net/neutron/+bug/1930200 - [RFE] Add support for Node- Local virtual IP, -- Slawek Kaplonski Principal Software Engineer Red Hat

1 0

[masakari] Tomorrow meeting will be on OFTC
by Radosław Piliszek 31 May '21

31 May '21

Dears, Please be informed that we, as OpenStack community, have migrated our IRC presence to OFTC. Hence, the Masakari meetings, starting with the tomorrow one, will be held on #openstack-masakari on OFTC. Please find OFTC connection info on http://www.oftc.net/ Kind regards, -yoctozepto

1 0

[release] Release countdown for week R-18, May 31 - Jun 04
by Herve Beraud 30 May '21

30 May '21

Development Focus ----------------- We are now past the Xena-1 milestone. Teams should now be focused on feature development! General Information ------------------- Our next milestone in this development cycle will be Xena-2, on 15 July, 2021. This milestone is when we freeze the list of deliverables that will be included in the Xena final release, so if you plan to introduce new deliverables in this release, please propose a change to add an empty deliverable file in the deliverables/xena directory of the openstack/releases repository. Now is also generally a good time to look at bugfixes that were introduced in the master branch that might make sense to be backported and released in a stable release. If you have any questions around the OpenStack release process, feel free to ask on this mailing-list or on the #openstack-release channel on IRC (at OFTC). Upcoming Deadlines & Dates -------------------------- Xena-2 Milestone: 15 July, 2021 -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

1 0

Pack Stack Install Issue on CentOS 7.
by Ken.Germann＠L3Harris.com 30 May '21

30 May '21

I removed mariadb-server, mariadb-client, mariadb-compat and mariadb-common. I run packstack -answer-file=answer.conf I get this error message: ERROR : Error appeared during Puppet run: 192.245.72.101_controller.pp Error: Execution of '/usr/bin/yum -d 0 -e 0 -y install mariadb-server-galera' returned 1: Package 3:mariadb-server-10.3.20-3.el7.0.0.rdo1.x86_64 is obsoleted by MariaDB-server-10.5.10-1.el7.centos.x86_64 which is already installed You will find full trace in log /var/tmp/packstack/20210527-170042-RiVtzU/manifests/192.245.72.101_controller.pp.log Any ideas how I work around this issue? Thank You, Ken Germann UNAP IRAD System Administrator Lead Aviation Systems / l3HARRIS Technologies Office: +1-954-732-0391 / Mobile: +1-954-732-0391 l3harris.com<mailto:l3harris.com> / kgermann(a)l3harris.com<mailto:kgermann@l3harris.com> MS F-11A / 1025 W. Nasa Dr. / Melbourne, FL 32919 / USA [rsz_1harriswebpage_rotator] CONFIDENTIALITY NOTICE: This email and any attachments are for the sole use of the intended recipient and may contain material that is proprietary, confidential, privileged or otherwise legally protected or restricted under applicable government laws. Any review, disclosure, distributing or other use without expressed permission of the sender is strictly prohibited. If you are not the intended recipient, please contact the sender and delete all copies without reading, printing, or saving.

3 2

[all][tc] What's happening in Technical Committee: summary 28th May, 21: Reading: 5 min
by Ghanshyam Mann 28 May '21

28 May '21

Hello Everyone, Here is last week's summary of the Technical Committee activities. 1. What we completed this week: ========================= * Community Infra ELK services help has been added in 2021 Upstream Investment Opportunity[1]. * It is decided to move the IRC network from Freenode to OFTC[2]. 2. TC Meetings: ============ * TC held this week meeting on Thursday; you can find the full meeting logs in the below link: - http://eavesdrop.openstack.org/meetings/tc/2021/tc.2021-05-27-15.00.log.html * We will have next week's meeting on June 3rd, Thursday 15:00 UTC[3]. 3. Activities In progress: ================== TC Tracker for Xena cycle ------------------------------ TC is using the etherpad[4] for Xena cycle working item. We will be checking and updating the status biweekly in the same etherpad. Open Reviews ----------------- * Three open reviews for ongoing activities[5]. Nomination is open for the 'Y' release naming ------------------------------------------------------ * Y release naming process is started[6]. Nomination is open until June 10th feel free to propose names in below wiki ** https://wiki.openstack.org/wiki/Release_Naming/Y_Proposals Replacing ATC terminology with AC (Active Contributors) ------------------------------------------------------------------- * As UC is merged into TC, this is to include the AUC into ATC so that they can be eligible for TC election voting. We are having a good amount of discussion on Gerrit[7], feel free to review the patch if you have any points regarding this. * In the last TC meeting, we will write a TC resolution to map the ATC with the new term AC from Bylaws' perspective. Retiring sushy-cli -------------------- * Ironic project is retiring the sushy-cli[8] MIgration from Freenode to OFTC ----------------------------------------- * TC held an emergency meeting on Wednesday, May 26th, 2021 and decided to move the IRC network from Freenode to OFTC[9]. You can find the detailed discussion in etherpad[10]. * We are also adding it as TC resolution[11]. * Next step will be communicated on ML thread, please join the channel on OFTC network. * We updated the minimum guide for how to join in OFTC in the contributor guide[12] 4. How to contact the TC: ==================== If you would like to discuss or give feedback to TC, you can reach out to us in multiple ways: 1. Email: you can send the email with tag [tc] on openstack-discuss ML[13]. 2. Weekly meeting: The Technical Committee conduct a weekly meeting every Thursday 15 UTC [14] 3. Office hours: The Technical Committee offers a weekly office hour every Tuesday at 0100 UTC [15] 4. Ping us using 'tc-members' nickname on #openstack-tc IRC channel. [1] https://governance.openstack.org/tc/reference/upstream-investment-opportuni… [2] http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022718.html [3] https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting [4] https://etherpad.opendev.org/p/tc-xena-tracker [5] https://review.opendev.org/q/project:openstack/governance+status:open [6] http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022383.html [7] https://review.opendev.org/c/openstack/governance/+/790092 [8] https://review.opendev.org/c/openstack/governance/+/792348 [9] http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022718.html [10] https://etherpad.opendev.org/p/openstack-irc [11] https://review.opendev.org/c/openstack/governance/+/793260 [12] https://docs.openstack.org/contributors/common/irc.html [13] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-discuss [14] http://eavesdrop.openstack.org/#Technical_Committee_Meeting [15] http://eavesdrop.openstack.org/#Technical_Committee_Office_hours -gmann

1 0

[interop] Interop Testing Guidelines
by Jimmy McArthur 28 May '21

28 May '21

Hi all - I noticed that the most recent testing guidelines [1] are from 2016. Is there a plan to update those to the 2020 guidelines? They still mention Chris Hoge, who is no longer in the community, and I'm assuming the guidelines there are outdated as well. Cheers, Jimmy https://opendev.org/osf/interop/src/branch/master/2016.08/procedure.rst

4 8

[ops] ops meetups team resuming meetings **NEW LOCATION**
by Chris Morgan 28 May '21

28 May '21

We'll meet briefly next Tuesday 2021-6-6 on irc.oftc.net at 10am EST in #openstack-operators Agenda https://etherpad.opendev.org/p/ops-meetups-team Chris -- Chris Morgan <mihalis68(a)gmail.com>

2 2

[requirements][keystone] sqlalchemy-1.4 update seems to impact keystone gate
by Matthew Thode 28 May '21

28 May '21

If someone from the keystone team can take a look that'd be helpful, thanks :D review is at https://review.opendev.org/788339 -- Matthew Thode

2 1

[ussuri][tripleo]
by Ruslanas Gžibovskis 28 May '21

28 May '21

Hi all, I am running deployment with TripleO. receiving error: Stack rsw/88b97419-3db1-4dac-b104-44544a044a59 UPDATE_FAILED rsw.Compute.0.Compute: resource_type: OS::TripleO::ComputeServer physical_resource_id: 613f907a-450a-48b5-995f-aa33f46d2092 status: CREATE_FAILED status_reason: | ResourceInError: resources.Compute: Went to status ERROR due to "Message: No valid host was found. , Code: 500" real 26m6.790s user 4m9.877s sys 0m32.829s meanwhile, while it is running, I see that it is booting up, loading pxe image successfully, later undercloud initiates communication on 9999 port to ironic agent listening on compute. after that it just fails deployment. I have checked containers/nova/nova-conductor.log and found interesting line, which I have preformated to see error: http://paste.openstack.org/show/idc7RcrUuMuNMkvoopxF/ which refers me to image building... Now I am building images with: http://paste.openstack.org/show/805786/ previously, I was facing this error with misconfigured elements of image, but now it should be set according to default files. does anyone have an idea, where I could try looking at to fix this issue? thank you -- Ruslanas Gžibovskis +370 6030 7030

1 1

[requirements][keystone] Werkzeug major update has gate implications
by Matthew Thode 27 May '21

27 May '21

Werkzeug had a major update that seems to break keystone gating. I'd appreciate it if someone from the keystone team could take a look at https://review.opendev.org/793022 Thanks, -- Matthew Thode

1 1

server/instance and ssh keys
by Mauricio Tavares 27 May '21

27 May '21

Is there a way to query openstack about which ssh pubkey was used with a given server?

2 3

[simplification] Making ask.openstack.org read-only
by Thierry Carrez 27 May '21

27 May '21

Hi everyone, This has been discussed several times on this mailing list in the past, but we never got to actually pull the plug. Ask.openstack.org was launched in 2013. The reason for hosting our own setup was to be able to support multiple languages, while StackOverflow rejected our proposal to have our own openstack-branded StackExchange site. The Chinese ask.o.o side never really took off. The English side also never really worked perfectly (like email alerts are hopelessly broken), but we figured it would get better with time if a big community formed around it. Fast-forward to 2020 and the instance is lacking volunteers to help run it, while the code (and our customization of it) has become more complicated to maintain. It regularly fails one way or another, and questions there often go unanswered, making us look bad. Of the top 30 users, most have abandoned the platform since 2017, leaving only Bernd Bausch actively engaging and helping moderate questions lately. We have called for volunteers several times, but the offers for help never really materialized. At the same time, people are asking OpenStack questions on StackOverflow, and sometimes getting answers there[1]. The fragmentation of the "questions" space is not helping users getting good answers. I think it's time to pull the plug, make ask.openstack.org read-only (so that links to old answers are not lost) and redirect users to the mailing-list and the "OpenStack" tag on StackOverflow. I picked StackOverflow since it seems to have the most openstack questions (2,574 on SO, 76 on SuperUser and 430 on ServerFault). We discussed that option several times, but I now proposed a change to actually make it happen: https://review.opendev.org/#/c/746497/ It's always a difficult decision to make to kill a resource, but I feel like in this case, consolidation and simplification would help. Thoughts, comments? [1] https://stackoverflow.com/questions/tagged/openstack -- Thierry

10 18

[release] IRC meeting updates
by Herve Beraud 27 May '21

27 May '21

Hello team, As you know we face issues with freenode and we need to address them ASAP. This email aims to socialize the plan that we will follow as the release team. The TC provided good guidelines to follow for the next few days/weeks, so we will apply them from A to Z [1]: 1. Do NOT change any channel topics to represent this change. This is likely to result in the channel being taken over by Freenode and will disrupt communications within our community. 2. Register your nicknames on OFTC [2][3] 3. Be *prepared* to join your channels on OFTC. The OpenStack community channels have already been registered on OFTC and await you. [3] 4. Continue to use Freenode for OpenStack discussions until the bots have been moved and the official cut-over takes place this coming weekend. We anticipate using OFTC starting Monday, May 31st. 5. Projects should work to get a few volunteers to staff their project channels on Freenode, for the near future to help redirect people to OFTC. This should occur via private messages to avoid a ban. 6. Continue to hold project meetings on Freenode until the bots are enabled on OFTC. 7. Update project wikis/documentation with the new IRC network information. We ask that you consider referring to the central contributor guide. 8. The TC is asking that projects take advantage of this time of change to consider moving project meetings from the #openstack-meeting* channels to their project channel. 9. Please avoid discussing the move to OFTC in Freenode channels as this may also trigger a takeover of the channel. So, to be clear, our next meeting will be on freenode (as usual) and it will remain there as long as our bots won't be transferred to OFTC. We should note that the TC explicitly asked us to avoid discussing the freenode/OFTC topic on our freenode channel, so don't be surprised if I don't speak about that during our next meeting. If you want to bring related feedback, then, please do it by replying to this ML thread. I'll transfer it to the TC through their etherpad [4]. If not yet done, please, start registering your nicknames on OFTC and be ready to join it ASAP. To finish, please carefully read the TC's original thread [1]. Thanks for your attention. [1] http://lists.openstack.org/pipermail/openstack-discuss/2021-May/022718.html [2] https://etherpad.opendev.org/p/feedback-on-freenode [3] https://www.oftc.net/Services/#register-your-account [4] https://etherpad.opendev.org/p/openstack-irc -- Hervé Beraud Senior Software Engineer at Red Hat irc: hberaud https://github.com/4383/ https://twitter.com/4383hberaud -----BEGIN PGP SIGNATURE----- wsFcBAABCAAQBQJb4AwCCRAHwXRBNkGNegAALSkQAHrotwCiL3VMwDR0vcja10Q+ Kf31yCutl5bAlS7tOKpPQ9XN4oC0ZSThyNNFVrg8ail0SczHXsC4rOrsPblgGRN+ RQLoCm2eO1AkB0ubCYLaq0XqSaO+Uk81QxAPkyPCEGT6SRxXr2lhADK0T86kBnMP F8RvGolu3EFjlqCVgeOZaR51PqwUlEhZXZuuNKrWZXg/oRiY4811GmnvzmUhgK5G 5+f8mUg74hfjDbR2VhjTeaLKp0PhskjOIKY3vqHXofLuaqFDD+WrAy/NgDGvN22g glGfj472T3xyHnUzM8ILgAGSghfzZF5Skj2qEeci9cB6K3Hm3osj+PbvfsXE/7Kw m/xtm+FjnaywZEv54uCmVIzQsRIm1qJscu20Qw6Q0UiPpDFqD7O6tWSRKdX11UTZ hwVQTMh9AKQDBEh2W9nnFi9kzSSNu4OQ1dRMcYHWfd9BEkccezxHwUM4Xyov5Fe0 qnbfzTB1tYkjU78loMWFaLa00ftSxP/DtQ//iYVyfVNfcCwfDszXLOqlkvGmY1/Y F1ON0ONekDZkGJsDoS6QdiUSn8RZ2mHArGEWMV00EV5DCIbCXRvywXV43ckx8Z+3 B8qUJhBqJ8RS2F+vTs3DTaXqcktgJ4UkhYC2c1gImcPRyGrK9VY0sCT+1iA+wp/O v6rDpkeNksZ9fFSyoY2o =ECSj -----END PGP SIGNATURE-----

1 0

[puppet][tripleo] Inviting tripleo CI cores to maintain tripleo jobs ?
by Takashi Kajinami 26 May '21

26 May '21

Hi team, As you know, we currently have TripleO jobs in some of the puppet repos to ensure a change in puppet side doesn't break TripleO which consumes some of the modules. Because these jobs hugely depend on the job definitions in TripleO repos, I'm wondering whether we can invite a few cores from the TripleO CI team to the puppet-openstack core group to maintain these jobs. I expect the scope here is very limited to tripleo job definitions and doesn't expect any +2 for other parts. I'd be nice if I can hear any thoughts on this topic. Thank you, Takashi

4 7

[all][tc] Technical Committee next weekly meeting on May 27th at 1500 UTC
by Ghanshyam Mann 26 May '21

26 May '21

Hello Everyone, Technical Committee's next weekly meeting is scheduled for May 27th at 1500 UTC. If you would like to add topics for discussion, please add them to the below wiki page by Wednesday, May 26th, at 2100 UTC. https://wiki.openstack.org/wiki/Meetings/TechnicalCommittee#Next_Meeting -gmann

1 2