May 2019 - openstack-discuss - lists.openstack.org

[placement] Poll for what do with the meeting
by Chris Dent 20 May '19

20 May '19

In today's placement meeting it was agreed to have a poll to decide what to do about the meeting. I've created a public poll at https://civs.cs.cornell.edu/cgi-bin/vote.pl?id=E_9599a2647c319fd4&akey=12a2… It will run until the end of this week. If you are participating in the placement project, or want to, please register your preferences so we can decide how to proceed. Thanks. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent

1 0

[openstack-ansible] Retirement of unused OpenStack Ansible roles
by Guilherme Steinmüller 20 May '19

20 May '19

Hello all, We have been discussing about some of our roles that are not maintained for a while, some of them are not even integrated with our main repository. In order to the team to focus on performance and stability of the roles that has been actively used, we are discussing about retiring the unused ones. The roles are the following: openstack-ansible-os_monasca openstack-ansible-os_monasca-agent openstack-ansible-os_zaqar openstack-ansible-os_watcher openstack-ansible-os_almanach openstack-ansible-os_molteniron openstack-ansible-os_searchlight We would love to help if someone wants to pick one or some of them to keep our variety of roles. If we don't hear back, we'll retire those roles out of OpenStack Ansible. Thank you Guilherme Steinmüller

6 11

[nova][cinder][ptg] Summary: Swap volume woes
by Lee Yarwood 20 May '19

20 May '19

Hello, tl;dr - No objections to reworking the swap volume API in Train https://etherpad.openstack.org/p/ptg-train-xproj-nova-cinder - L3-18 Summary: - Deprecate the existing swap volume API in Train, remove in U. - Deprecate or straight up remove existing CLI support for the API. - Write up a spec introducing a new API specifically for use by Cinder when retyping or migrating volumes. Potentially using the external events API or policy to lock down access to the API. - Optionally rework the Libvirt virt driver implementation of the API to improve performance and better handle failure cases as suggested by mdbooth. This might include introducing and using a quiesce volume API. I'm personally out for the next two weeks but will start on the above items once back. Cheers, -- Lee Yarwood A5D1 9385 88CB 7E5F BE64 6618 BCA6 6E33 F672 2D76

2 2

[Kolla] Few questions about offline deploy & operation.
by Eddie Yen 20 May '19

20 May '19

Hi everyone, I'm a newbie of using Kolla-ansible to deploy OpenStack. Everything works well. But I have few questions about Kolla since I was using Fuel as deploy tool before. The questions may silly, but I really want to know since I didn't found much informations to solve my questions.. About offline deployment: I already known that we need have OS local repository (CentOS or Ubuntu), docker local package repository, and local docker registry. But one thing I'm not sure that it will use pip to install python packages or not. Because I found it will also install pip into target node during bootstrap-servers. If so, which python package should I prepare for? About operation: 1. Is it possible to operate a single service to whole OpenStack nodes? Like using crm to check status about MySQL or RabbitMQ services on all control nodes. 2. How can I maintenance the Ceph OSD if OSD down caused by disk issue? I know how to rebuild OSD by Ceph commands but I'm not sure how to do if ceph-osd running in container. Many thanks, Eddie.

2 2

[all][dev] python-etcd3 needs maintainers
by Chris Dent 20 May '19

20 May '19

Going through my todo list after returning from travels and I'm reminded of: When I was at OpenInfraDays UK, Louis Taylor (aka kragniz) asked me if I could check with the OpenStack community to see if there are people who are actively using python-etcd3 [1] that are interested in helping to maintain it. It needs more attention than he is able to give. python-etcd3 is a "Python client for the etcd API v3" over GRPC so more v3-native than etcd3-gateway [2]. I've used python-etcd3 in etcd-compute and it works well. I've been hoping to contribute in my Copious Free Time but don't seem to have any. [1] https://github.com/kragniz/python-etcd3 [2] https://github.com/dims/etcd3-gateway -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent tw: @anticdent

3 2

Re: On reporting CPU flags that provide mitiation (to CVE flaws) as Nova 'traits'
by Kashyap Chamarthy 20 May '19

20 May '19

On Wed, May 15, 2019 at 11:49:03AM +0100, Sean Mooney wrote: > On Wed, 2019-05-15 at 11:24 +0200, Kashyap Chamarthy wrote: [...] > > Contention / unsolved question > > ------------------------------ > > > > Whether we should expose CPU flags (e.g. "SSBD", or "STIBP") that > > provide mitigation from CPU flaws as traits or not? It is a "policy" > > decision, and the 'traits' are "forever" (well, you can soft-deprecate > > them with a comment) once they're added, hence all the belaboring. > > > > There's no consensus here. Some think that we should _not_ allow those > > CPU flags as traits which can 'allow' you to target vulnerable hosts. > > for what its worth im in this camp and have said so in other places > where we have been disucssing it. Yep, noted. > > Some think it is okay to add these as granular CPU traits. (Have > > a gander at the discussion on this[2] change.) > > > > Does the Security Team has any strong opinions? [...] > > Next steps > > ---------- > > > > If there is consensus on dropping those CPU-flags-as-traits that let you > > target vulnerable hosts, drop them. And add only those CPU flags as > > traits that provide either 'features' (what's the definition?) or those > > that reduce performance degradation. > > > my vote is for only adding tratis for cpu featrue. Noted; I'd like to hear other opinions. (And note that the word "feature" can get fuzzy in this context, I'll assume we're using it somewhat loosely to include things that help with reducing perf degradation, etc.) > PCID is a CPU feautre that was designed as a performce optiomistation ... except that "feature" was a 'no-op' and it wasn't even _used_, until Linux 4.1.4 enabled it (in November 2017) for Meltdown mitigation. So the presence of PCID in the hardware didn't matter one whit all these decades. (Source: http://archive.is/ma8Iw.) > and several generation later also was found to be useful in reducing > the performace impacts of the sepcter mitigation Nit: Not Spectre, but Meltdown. [...] > > Some think this is not "Nova's business", because: "just like how you > > don't want to stop based on CPU fan speed or temperature or firmware > > patch levels ...". > > i think it applies perfectly. It's a matter of scope. To be clear — I'm not "insisting" that it be done in Nova. Just thinking out loud. [...] > form a product perspective vendors shoudl ensure that they > provide tooling and software updated that are secure by default "Product perspective" is irrelevant here. Of course, it's obvious that vendors "should" provide the relevant tooling and sofware updates. > > But that argument doesn't quite apply, as CPU > > fan/speed are very different, and are not seen by the guest. If you > > take security seriously, it _is_ be fair game, IMHO, to make Nova warn > > (then stop) launching instances on Compute hosts with vulnerable Correcting myself: Okay, "stopping" / "refusing to launch" is too strict and unresonable; scratch that. (Because, as discussed before, there _are_ valid cases to be made that certain admins/operators intentionally will run on vulnerable hypervisors — e.g. because their CPUs are too old to receive microcode updates. Or may deliberately tolerate this risk, as they know their risk policy. Or they're running staging envs, or any number of other reasons.) > > hypervisors. > > the same aregument could be aplied to qemu or libvirt. No, that argument does not apply to QEMU or libvirt. Why? QEMU and libvirt are low-level primitives. They explicitly state that they don't, and will not, make such "policy" decisions. But Nova, as a management tool, _does_ make some policy decisions (e.g. how we generate a libvirt guest XML based on certain criteria, and others). And in this case, Nova _can_ take a stance that "orchestration tools" should do that — that's perfectly acceptable. [...] -- /kashyap

7 13

[openstack-helm] List of the current meeting times, and opinion on adjustment
by Jaesuk Ahn 20 May '19

20 May '19

Hi In PTG, I have put as one of agenda during openstack-helm PTG session, and it was then discussed during the Airship PTG session. The reason is, to encourage current/potential contributors from my region to show up at these community meetings, a little bit more preferable time would be great. (from https://etherpad.openstack.org/p/airship-ptg-train) - Meeting times - Use https://everytimezone.com/ - There is no good time for everyone - lots of folks west coast, europe, asia - Compromise -- two meeting times on same day, separated ~10 hours apart or some such - Outcome: +1 - use https://everytimezone.com/ to come up with a few options, including single meetings per week and multiple - Let people vote on it in the patchset to change the meeting time - Note: OSH to do something similar In reality, there are many people who are attending both openstack-helm and Airship meeting. I also totally agree with Pete (PTL) that it makes sense to ensure the meeting time for both projects work together. Therefore, FYI, here is the summary of meeting times for both Airship and OpenStack-Helm Here is the current Airship Meeting Time - Airship Design Call (Twice a Week untill airship 2.0 design settled) - Tuesday (1.5h) : 13:00 UTC (09:00 AM EST / 06:00 AM PST / 13:00 CEST / 22:00 Korea) - Thursday (1.5 h) : 15:00 UTC (11:00 AM EST / 08:00 AM PST / 15:00 CEST / 00:00 AM Korea Friday) - Airship Weekly IRC Meeting - Tuesday (1h) : 16:00 UTC (12:00 PM EST / 09:00 AM PST / 16:00 CEST / 01:00 AM Korea Wednesday) Current OpenStack-Helm Meeting Time - OSH Weekly IRC Meeting - Tuesday (1h) : 15:00 UTC (11:00 AM EST / 08:00 AM PST / 15:00 CEST / 00:00 AM Korea Friday) Now we have all the meeting time listed here in this email. I would like to discuss possible available options for the adjustment. I will start!. Here is my opinion. For me, first of all, 13:00 UTC (10PM) or 14:00 UTC (11PM) would be the reasonable time to have a weekly meetings (I am living in Korea). Current 15:00 UTC (midnight) is a bit difficult time to regularly attend the weekly meeting. It also make me difficult to ask someone else from my region to attend the meeting. Secondly, as mentioned during PTG, having two meetings on the same day will also be an option. Personally, I concern that having two meetings will put somewhat heavy burden on PTL and core reviewers. PLEASE share your opinion on possible options for meeting time. Thanks you. -- *Jaesuk Ahn*, Ph.D. Software R&D Center, SK Telecom

3 4

Fwd: Linux (RHEL 7.6 with OSP 14) Bugs
by Amer Hwitat 19 May '19

19 May '19

Dears, I have the following Bugs that crashed my VM, I reported it to RH, they didn't answer, and banned my developer account, the Bug is when you disable the network on RHEL with OSP 14 installed all in one, it crashes the system, I had a 12GB RAM, with 8 CPUs on the VM, and I found out that this crash report pissed off someone in RH, because they called me, and said what do you want from me!!, what I need is a Simple reply, is this a bug or not. here is the problem: [root@localhost network-scripts]# systemctl status network -l ? network.service - LSB: Bring up/down networking Loaded: loaded (/etc/rc.d/init.d/network; bad; vendor preset: disabled) Active: failed (Result: exit-code) since Sat 2019-01-19 03:47:01 EST; 21s ago Docs: man:systemd-sysv-generator(8) Process: 86319 ExecStop=/etc/rc.d/init.d/network stop (code=exited, status=0/SUCCESS) Process: 86591 ExecStart=/etc/rc.d/init.d/network start (code=exited, status=1/FAILURE) Tasks: 0 Jan 19 03:47:01 localhost.localdomain dhclient[86963]: Please report for this software via the Red Hat Bugzilla site: Jan 19 03:47:01 localhost.localdomain dhclient[86963]: http://bugzilla.redhat.com Jan 19 03:47:01 localhost.localdomain dhclient[86963]: ution. Jan 19 03:47:01 localhost.localdomain dhclient[86963]: exiting. Jan 19 03:47:01 localhost.localdomain network[86591]: failed. Jan 19 03:47:01 localhost.localdomain network[86591]: [FAILED] Jan 19 03:47:01 localhost.localdomain systemd[1]: network.service: control process exited, code=exited status=1 Jan 19 03:47:01 localhost.localdomain systemd[1]: Failed to start LSB: Bring up/down networking. Jan 19 03:47:01 localhost.localdomain systemd[1]: Unit network.service entered failed state. Jan 19 03:47:01 localhost.localdomain systemd[1]: network.service failed. [root@localhost network-scripts]# [root@localhost log]# Message from syslogd@localhost at Jan 23 02:23:31 ... kernel:NMI watchdog: BUG: soft lockup - CPU#3 stuck for 22s! [ovsdb-server:10088] [root@amer network-scripts]# Message from syslogd@amer at Jan 27 12:46:38 ... kernel:NMI watchdog: BUG: soft lockup - CPU#0 stuck for 22s! [nova-api:102738] Message from syslogd@amer at Jan 27 19:26:19 ... kernel:NMI watchdog: BUG: soft lockup - CPU#5 stuck for 26s! [swapper/5:0] Message from syslogd@amer at Jan 27 19:26:19 ... kernel:NMI watchdog: BUG: soft lockup - CPU#1 stuck for 27s! [dmeventd:71548] Message from syslogd@amer at Jan 27 19:27:30 ... kernel:NMI watchdog: BUG: soft lockup - CPU#5 stuck for 22s! [6_scheduler:64928] Message from syslogd@amer at Jan 27 19:31:25 ... kernel:NMI watchdog: BUG: soft lockup - CPU#5 stuck for 22s! [ksoftirqd/5:34] Message from syslogd@amer at Jan 27 19:32:42 ... kernel:NMI watchdog: BUG: soft lockup - CPU#3 stuck for 33s! [swift-object-up:11358] Message from syslogd@amer at Jan 27 19:33:55 ... kernel:NMI watchdog: BUG: soft lockup - CPU#3 stuck for 24s! [dmeventd:71548] Message from syslogd@amer at Jan 27 19:34:25 ... kernel:NMI watchdog: BUG: soft lockup - CPU#2 stuck for 65s! [kworker/2:0:59993] Message from syslogd@amer at Jan 27 19:37:50 ... kernel:NMI watchdog: BUG: soft lockup - CPU#2 stuck for 24s! [kworker/u256:3:8447] Message from syslogd@amer at Jan 27 19:37:50 ... kernel:NMI watchdog: BUG: soft lockup - CPU#5 stuck for 22s! [ksoftirqd/5:34] Message from syslogd@amer at Jan 27 19:37:51 ... kernel:NMI watchdog: BUG: soft lockup - CPU#0 stuck for 21s! [systemd:11968] The CPU has been disabled by the guest operating system. Power off or reset the virtual machine. snapshots attached [image: Red Hat Enterprise Linux 7 64-bit (2)-2019-01-28-03-57-27.png] [image: Red Hat Enterprise Linux 7 64-bit (2)-2019-01-28-04-26-41.png] [image: working solution.JPG] the last snapshot is from a successful installation of OSP 14 that specifically says that Kernel is not compatible with Firmware (Bios). I didn't test on Debian flavors but I think it's the same, the problem is with RabbitMQ heart beats, when the server is disconnected it times out causing this problem of kernel loop. Thanks and Best regards Amer

1 0

[openstack-discuss][openstack-helm] Nominating Itxaka Serrano Garcia to core review team
by Pete Birley 18 May '19

18 May '19

Hi OpenStack-Helm Core Team, I would like to nominate a new core reviewer for OpenStack-Helm: Itxaka Serrano Garcia (igarcia(a)suse.com) Itxaka has been doing many reviews and contributed some critical patches to OpenStack Helm, helping make the project both more approachable and better validated through his great tempest work. Also, he is a great ambassador for the project both in IRC and community meetings. Voting is open for 7 days. Please reply with your +1 vote in favor or -1 as a veto vote. Regards, Pete Birley (portdirect)

6 5

[telemetry][storyboard] Telemetry project bug trackers have been moved to Storyboard
by Trinh Nguyen 18 May '19

18 May '19

Hi team, Great news!!!!! We have moved all of the telemetry project bug trackers to Storyboard. You can find the project group link in [1] The projects are: - openstack/telemetry-tempest-plugin - Tempest Plugin for Telemetry projects - openstack/telemetry-specs - OpenStack Telemetry Specifications - openstack/python-pankoclient - Client library for Panko API - openstack/python-aodhclient - Client library for Aodh API - openstack/panko - Event storage and REST API for Ceilometer - openstack/ceilometermiddleware - OpenStack Telemetry (Ceilometer) Middleware - openstack/ceilometer - OpenStack Telemetry (Ceilometer) - openstack/aodh - OpenStack Telemetry (Ceilometer) Alarming All existing bugs, blueprints will be migrated shortly next week or so. For now, please refrain from firing new bugs/issues on the launchpad. [1] https://storyboard.openstack.org/#!/project_group/ceilometer Bests, -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

2 2