May 2020 - openstack-discuss - lists.openstack.org

[manila][ptg] Victoria Virtual PTG Items
by Goutham Pacha Ravi 28 May '20

28 May '20

Hello Zorillas and other interested Stackers, If you haven't already registered to be part of the virtual PTG, please do so as soon as possible [1]. There's now an etherpad posted to gather topics for the Ussuri Team Retrospective [2]. Please take a look and add your thoughts before the event. Also take a look at our Virtual PTG planning etherpad [3], and let me know if you have a problem with the draft schedule posted. As a reminder, these are the time slots for our meeting: == Monday, 1st June 2020 == 1400 UTC - 1700 UTC == Tuesday, 2nd June 2020 == 1500 UTC - 1700 UTC 2100 UTC - 2300 UTC == Friday, 5th June 2020 == 1400 UTC - 1700 UTC Our meetings are on Zoom and will be recorded. The Zoom Room is called "Cactus" and is linked out of the PTG Schedule page [4]. So make sure to bookmark it :) Looking forward to a happy week of designing with you all! -- Goutham Ravi [1] https://virtualptgjune2020.eventbrite.com/ [2] https://etherpad.opendev.org/p/manila-ussuri-retrospective [3] https://etherpad.opendev.org/p/vancouver-ptg-manila-planning [4] http://ptg.openstack.org/ptg.html

1 0

[nova][ptg] Healthchecks API
by Ghanshyam Mann 28 May '20

28 May '20

Hello Everyone, This is one of the PTG topic[1] but it will be good if we can get some discussion to happen before PTG and utilize the PTG time. I am sorry for starting this thread late. To provide the healthchecks API for nova, I have done 1 PoC which is basically extending the oslo healthchecks middleware plugins to add the real checks. - https://review.opendev.org/#/c/731396/ I am writing the details on this etherpad[2] where you can see the response and the flow of new plugins. Also describing briefly here: oslo provides healthchecks middleware with plugin framework. oslo provides two basic plugins which does file/port based health checks - disable_by_file - disable_by_files_ports New Idea is to extend those checks with new plugins on nova side: Nova can provide three plugins which are configurable[3]: 1. Nova_DB_healthcheck: Checks if API, cell0 and at least one cell DB is up. If so then return Healthy otherwise Unhealthy 2. Nova_MQ_healthcheck: Checks if at least one cells MQ is up. If so then return Healthy otherwise Unhealthy 3. Nova_services_healthcheck: Checks if at least one cell has at least one conductor and one compute service running. If so then return Healthy otherwise Unhealthy All plugins will return the dict of results for example DB dict of API, all cells DB with status, Please refer the example response in later part. TODO: Auth part for various plugins Flow diagrame of new plugins: - Nova_DB_healthcheck: -->API DB is up | --> cell0 DB and at least one cell DB is up I --> Return OK - Nova_MQ_healthcheck: -->API MQ is up | --> At leask: one cell MQ is up I --> Return OK - Nova_services_healthcheck: --> At least one cell has at least one conductor and one compute running --> TODO: need to check other services for example scheduler at least I --> Return OK Result: 200 OK if all enabled plugins return OK otherwise 503 Service Unavailable. Opinion/thoughts? [1] https://etherpad.opendev.org/p/nova-victoria-ptg [2]https://etherpad.opendev.org/p/nova-healthchecks [3] https://review.opendev.org/#/c/731396/1/etc/nova/api-paste.ini@107

1 0

[sdk][api-sig][ptg] Victoria PTG planning
by Artem Goncharov 27 May '20

27 May '20

Hi everyone interested :) The PTG planning for the API-SIG is there: https://etherpad.opendev.org/p/API-SIG-VictoriaPTG-Planning <https://etherpad.opendev.org/p/SDK-VictoriaPTG-Planning> Please enter yourself there if interested and add topics you want to discuss. We have currently 1 slot, so hurry up not to loose the chance: 02 June: 16:00 - 17:00 UTC Liberty And we plan to be using meetpad (fingers crossed). Hear from you soon, Artem

2 1

[all][interop WG] Call for Participationin for Virtual PTG interop WG and seek ambassadors
by prakash RAMCHANDRAN 27 May '20

27 May '20

Hi all, We are looking for participation & presenters, contributors form different OpenStack and adjacent projects in Open Infrastructure , k8s, CNCF, OPNFV, ONAP, OCN etc. Please register in etherpad and review for anything you like to share wrt user level API for Multi Cloud, Hybrid Cloud and Edge cloud Interop capability or compatibility. The bridge will be tested this Friday May 29th before we finalize the location or bridge, Add you name topic and your inputs for rapid delivery slots of say 5-10 mts each on June 1st. https://etherpad.opendev.org/p/interop_virtual_ptg_planning_june_2020 Schedule June 1 (UTC 13-15 hrs = 6AM-8 AM PDT = 9AM-11 AM EST = 9PM-11PM BJT) First hr will focus on Project team like Nova, Neutron, Ciner, Keystone, Glance & Swift.Second Hour - Open for new ideas Additionally we would like ambassadors who can register and attend other Virtual PTG projects and provide us feedback after attending them as what they can provide to us for Interop WG from all other projects. ThanksFor Interop WGChair PrakashVice Chair Mark

1 0

[tripleo] Ussuri containers
by Wesley Hayutin 27 May '20

27 May '20

Greetings, FYI we had a squatter in docker.io steal away the tripleoussuri namespace. We are investigating using quay but we need to do quite a bit of testing for it. For now please remind folks that the default container registry namespace is not tripleo$release for ussuri. We're using "tripleou" [1]. If you want to pull from the rdo registry, you will find those containers in tripleoussuri for now [2], but will be moved to use tripleou as well for consistency. Note the following update to tripleo-common as well [3] Full story is that we attempted to contact docker.io support several times as they have a policy around removing squatting namespaces. The support team never responded. Our goal is drop docker.io and use quay.io but taking a step by step phased approach to that. Thanks all [1] https://hub.docker.com/u/tripleou [2] https://registry.rdoproject.org:8443/oapi/v1/namespaces/tripleoussuri/image… [3] https://review.opendev.org/#/c/731244/

1 0

[Nova][CentOS] extrem slow first boot Centos 8.1 with failures
by Nicolas Ghirlanda 27 May '20

27 May '20

Hello all, I created a centos image with a pretty similar kickstart config like from that link https://github.com/CentOS/sig-cloud-instance-build/pull/159/commits/2c542bb… Packer is building the image fine, also the post installation tasks after a reboot in qemu (which is running fine and fast), so everything looks good so far. Then upload to openstack and on first boot, the instance is booting fine until that point of boot: [[0;32m OK [0m] Started D-Bus System Message Bus. [[0;32m OK [0m] Started Hardware RNG Entropy Gatherer Daemon. Starting OpenSSH rsa Server Key Generation... Starting System Security Services Daemon... [ 9.913211] piix4_smbus 0000:00:01.3: SMBus Host Controller at 0x700, revision 0 [ 9.988763] input: PC Speaker as /devices/platform/pcspkr/input/input6 [ 10.137969] sd 0:0:0:0: Attached scsi generic sg0 type 0 [ 10.332234] cirrus 0000:00:02.0: vgaarb: deactivate vga console [ 10.419654] Console: switching to colour dummy device 80x25 [ 10.421488] [TTM] Zone kernel: Available graphics memory: 2017692 kiB [ 10.422946] [TTM] Initializing pool allocator [ 10.424036] [TTM] Initializing DMA pool allocator [ 10.425630] [drm] fb mappable at 0xFC000000 [ 10.426612] [drm] vram aper at 0xFC000000 [ 10.427436] [drm] size 33554432 [ 10.428108] [drm] fb depth is 16 [ 10.428884] [drm] pitch is 2048 [ 10.449202] fbcon: cirrusdrmfb (fb0) is primary device [ 10.465230] Console: switching to colour frame buffer device 128x48 [ 10.499394] cirrus 0000:00:02.0: fb0: cirrusdrmfb frame buffer device [ 10.524033] [drm] Initialized cirrus 1.0.0 20110418 for 0000:00:02.0 on minor 0 On the console there is no further update from here. In the boot log it slowly progresses, but with Failures of starting services e.g. Starting RPC Bind... Starting Security Auditing Service... [ 9.500362] audit: type=1400 audit(1590589814.846:4): avc: denied { read } for pid=784 comm="auditd" name="group" dev="sda1" ino=259654 scontext=system_u:system_r:auditd_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0 [ 9.517988] audit: type=1400 audit(1590589814.863:5): avc: denied { read } for pid=783 comm="rpcbind" name="passwd" dev="sda1" ino=259634 scontext=system_u:system_r:rpcbind_t:s0 tcontext=system_u:object_r:unlabeled_t:s0 tclass=file permissive=0 [[0;1;31mFAILED[0m] Failed to start RPC Bind. See 'systemctl status rpcbind.service' for details. or [[0;32m OK [0m] Started OpenSSH ecdsa Server Key Generation. [[0;32m OK [0m] Started GSSAPI Proxy Daemon. [[0;32m OK [0m] Started OpenSSH ed25519 Server Key Generation. [[0;32m OK [0m] Started OpenSSH rsa Server Key Generation. [[0;1;31mFAILED[0m] Failed to start Authorization Manager. See 'systemctl status polkit.service' for details. [[0;1;33mDEPEND[0m] Dependency failed for Dynamic System Tuning Daemon. [[0;1;31mFAILED[0m] Failed to start NTP client/server. See 'systemctl status chronyd.service' for details. Also cloud-init is not able to assign an ip. [[0;32m OK [0m] Started D-Bus System Message Bus. Starting Network Manager... [ 550.962041] cloud-init[1070]: Cloud-init v. 18.5 running 'init' at Wed, 27 May 2020 14:37:46 +0000. Up 460.76 seconds. [ 550.964516] cloud-init[1070]: ci-info: +++++++++++++++++++++++++++Net device info++++++++++++++++++++++++++++ [ 550.967275] cloud-init[1070]: ci-info: +--------+-------+-----------+-----------+-------+-------------------+ [ 550.970075] cloud-init[1070]: ci-info: | Device | Up | Address | Mask | Scope | Hw-Address | [ 550.972524] cloud-init[1070]: ci-info: +--------+-------+-----------+-----------+-------+-------------------+ [ 550.975221] cloud-init[1070]: ci-info: | ens3 | False | . | . | . | fa:16:3e:a3:7d:d5 | [ 550.977970] cloud-init[1070]: ci-info: | lo | True | 127.0.0.1 | 255.0.0.0 | host | . | [ 550.980623] cloud-init[1070]: ci-info: | lo | True | ::1/128 | . | host | . | [ 550.983300] cloud-init[1070]: ci-info: +--------+-------+-----------+-----------+-------+-------------------+ [ 550.986164] cloud-init[1070]: ci-info: +++++++++++++++++++Route IPv6 info+++++++++++++++++++ [ 550.988469] cloud-init[1070]: ci-info: +-------+-------------+---------+-----------+-------+ [ 550.991092] cloud-init[1070]: ci-info: | Route | Destination | Gateway | Interface | Flags | [ 550.993576] cloud-init[1070]: ci-info: +-------+-------------+---------+-----------+-------+ [ 550.996326] cloud-init[1070]: ci-info: +-------+-------------+---------+-----------+-------+ After that time, the system is up, but no hostname is set (due to cloud-init issues). If I now reboot, everything is working fine, cloud-init is working etc. If I set selinux from enforcing to permissive in the kickstart config, the issues are not showing up, but I need selinux to stay enforcing. Anyone with the same issues or any hints appreciated. regards Nicolas

1 1

[ironic] [ptg] PTG week schedule
by Dmitry Tantsur 27 May '20

27 May '20

Hi ironicers! The PTG is next week, and I'd like to share our plans for it. We don't have anything planned on Monday, and the weekly meeting is cancelled as well. 2-hour slots are reserved Tuesday to Friday 14:00 UTC - 16:00 UTC in the Liberty room. The up-to-date schedule and notes are available on https://etherpad.opendev.org/p/Ironic-VictoriaPTG-Planning, the current version is as follows: Tue, Jun 2nd: 14:00-15:00: Releases, perceptions and our place in the world: governance and perceptions 15:00-16:00: Releases, perceptions and our place in the world: standalone future Wed, Jun 3rd: 14:00-15:00: Deployment Efficency 15:00-16:00: Aborting non-waiting transient states Thu, Jun 4th: 14:00-15:00: Fishy future 15:00-16:00: IPAM integrations outside of Neutron Fri, Jun 5th: 14:00-15:00: Operator suggestions/feedback/painpoints 15:00-16:00: Ideas and brainstorming I would like to highlight the operators feedback slot on Friday at 14:00 UTC. We would like to hear more opinions from people running ironic! Please join us. Hear from you soon, Dmitry

1 0

[kolla-ansible] External Ceph and cinder-volumes
by Alfredo De Luca 27 May '20

27 May '20

Hi all. I am sing kolla-ansible 4.0 with and external ceph already deployed. I have in globals.yml the following setting: enable_ceph: "no" glance_backend_ceph: "yes" nova_backend_ceph: "yes" cinder_backend_ceph: "yes" enable_cinder_backend_lvm: "no" When I run kolla-ansible I got an error about not having cinder-volumes group Cannot process volume group cinder-volumes Do you know why it keeps looking for the cinder volumes? I ve done it before with no problem but maybe something in the global not correctly configured? Cheers -- */Alfredo*

2 7

[cyborg] Edge sync up at the PTG
by Ildiko Vancsa 27 May '20

27 May '20

Hi Cyborg Team, I’m reaching out to check if you are available during next week to continue discussions on edge related topics that we started in Shanghai. The OSF Edge Computing Group is meeting next week and we have a slot reserved to sync up with OpenStack projects such as Cyborg on Wednesday (June 3) at 1300 UTC - 1400 UTC. Would the team be available to join at that time? Thanks, Ildikó

1 0

[tripleo][operators] Removal of mistral from the TripleO Undercloud
by Kevin Carter 27 May '20

27 May '20

Hello stackers, In the pursuit to remove Mistral from the TripleO undercloud, we've discovered an old capability that we need to figure out how best to handle. Currently, we provide the ability for an end-user (operator / deployer) to pass in "N" Mistral workflows as part of a given deployment plan which is processed by python-tripleoclient at runtime [0][1]. From what we have documented, and what we can find within the code-base, we're not using this feature by default. That said, we do not remove something if it is valuable in the field without an adequate replacement. The ability to run arbitrary Mistral workflows at deployment time was first created in 2017 [2] and while present all this time, its documented [3] and intra-code-base uses are still limited to samples [4]. As it stands now, we're on track to making Mistral inert this cycle and if our progress holds over the next couple of weeks the capability to run arbitrary Mistral workflows will be the only thing left within our codebase that relies on Mistral running on the Undercloud. So the question is what do we do with functionality. Do we remove this ability out right, do we convert the example workflow [5] into a stand-alone Ansible playbook and change the workflow runner to an arbitrary playbook runner, or do we simply leave everything as-is and deprecate it to be removed within the next two releases? Although it would be perfectly acceptable to keep Mistral around a little while longer, it would also be a bummer if this one capability was the only reason we were not able to remove Mistral from the Undercloud. Any and all feedback from operators, deployers, developers, former developers, etc would be greatly appreciated. Thank you in advance. [0] https://opendev.org/openstack/python-tripleoclient/src/commit/af719b795bc9b… [1] https://opendev.org/openstack/python-tripleoclient/src/commit/af719b795bc9b… [2] https://review.opendev.org/#/c/457874 [3] https://specs.openstack.org/openstack/tripleo-specs/specs/pike/tripleo-deri… [4] https://opendev.org/openstack/tripleo-heat-templates/src/commit/48da6a13936… [5] https://opendev.org/openstack/tripleo-common/src/commit/cc4f9c57b708259e9e9… Kevin Carter IRC: kecarter

5 9