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

[requirements][kuryr][flame] openshift dificulties
by Matthew Thode 14 Jun '19

14 Jun '19

Openshift upstream is giving us difficulty as they are capping the version of urllib3 and kubernetes we are using. -urllib3===1.25.3 +urllib3===1.24.3 -kubernetes===9.0.0 +kubernetes===8.0.1 I've opened an issue with them but not had much luck there (and their prefered solution just pushes the can down the road). https://github.com/openshift/openshift-restclient-python/issues/289 What I'd us to do is move off of openshift as our usage doesn't seem too much. openstack/kuryr-tempest-plugin uses it for one import (and just one function with that import). I'm not sure exactly what you are doing with it but would it be too much to ask to move to something else? x/flame has it in it's constraints but I don't see any actual usage, so perhaps it's a false flag. Please let me know what you think -- Matthew Thode

3 7

[charms] Proposing Sahid Orentino Ferdjaoui to the Charms core team
by Chris MacNaughton 14 Jun '19

14 Jun '19

Hello all, I would like to propose Sahid Orentino Ferdjaoui as a member of the Charms core team. Chris MacNaughton

5 4

Retiring TripleO-UI - no longer supported
by Jason Rist 13 Jun '19

13 Jun '19

Hi everyone - I’m writing the list to announce that we are retiring TripleO-UI and it will no longer be supported. It’s already deprecated in Zuul and removed from requirements, so I’ve submitted a patch to remove all code. https://review.opendev.org/661113 Thanks, Jason Jason Rist Red Hat <https://www.redhat.com/> jrist / knowncitizen <https://www.redhat.com/>`

3 7

[dev][keystone] M-1 check-in and retrospective meeting
by Colleen Murphy 11 Jun '19

11 Jun '19

Hi team, During the PTG, we agreed to have milestone-ly check-ins in order to try to keep momentum going throughout the cycle. Milestone 1 is already nearly upon us, so it's time to schedule this meeting. I'd like to schedule a two-hour video call during which we'll conduct a brief retrospective of the cycle so far, review our past action items, and refine and reevaluate our plans for the rest of the cycle. I've created a doodle poll[1] to schedule the session for either the week of M-1[2] or the following week. If you have questions, concerns, or thoughts about this meeting, let's discuss it in this thread (or you can message me privately). Colleen [1] https://doodle.com/poll/hyibxqp9h8sgz56p [2] https://releases.openstack.org/train/schedule.html

1 3

[nova] [cyborg] Impact of moving bind to compute
by Nadathur, Sundar 07 Jun '19

07 Jun '19

Hi, The feedback in the Nova - Cyborg interaction spec [1] is to move the call for creating/binding accelerator requests (ARQs) from the conductor (just before the call to build_and_run_instance, [2]) to the compute manager (just before spawn, without holding the build sempahore [3]). The point where the results of the bind are needed is in the virt driver [4] - that is not changing. The reason for the move is to enable Cyborg to notify Nova [5] instead of Nova virt driver polling Cyborg, thus making the interaction similar to other services like Neutron. The binding involves device preparation by Cyborg, which may take some time (ballpark: milliseconds to few seconds to perhaps 10s of seconds - of course devices vary a lot). We want to overlap as much of this as possible with other tasks, by starting the binding as early as possible and making it asynchronous, so that bulk VM creation rate etc. are not affected. These considerations are probably specific to Cyborg, so trying to make it uniform with other projects deserve a closer look before we commit to it. Moving the binding from [2] to [3] reduces this overlap. I did some measurements of the time window from [2] to [3]: it was consistently between 20 and 50 milliseconds, whether I launched 1 VM at a time, 2 at a time, etc. This seems acceptable. But this was just in a two-node deployment. Are there situations where this window could get much larger (thus reducing the overlap)? Such as in larger deployments, or issues with RabbitMQ messaging, etc. Are there larger considerations of performance or scaling for this approach? Thanks in advance. [1] https://review.opendev.org/#/c/603955/ [2] https://github.com/openstack/nova/blob/master/nova/conductor/manager.py#L15… [3] https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L1882 [4] https://github.com/openstack/nova/blob/master/nova/virt/libvirt/driver.py#L… [5] https://wiki.openstack.org/wiki/Nova/ExternalEventAPI Regards, Sundar

2 3

[openstack-ansible][powervm] dropping support
by Mohammed Naser 07 Jun '19

07 Jun '19

Hi everyone, I've pushed up a patch to propose dropping support for PowerVM support inside OpenStack Ansible. There has been no work done on this for a few years now, the configured compute driver is the incorrect one for ~2 years now which indicates that no one has been able to use it for that long. It would be nice to have this driver however given the infrastructure we have upstream, there would be no way for us to effectively test it and bring it back to functional state. I'm proposing that we remove the code here: https://review.opendev.org/662587 powervm: drop support If you're using this code and would like to contribute to fixing it and (somehow) adding coverage, please reach out, otherwise, we'll drop this code to clean things up. Thanks, Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

2 2

[nova] Validation for requested host/node on server create
by Matt Riedemann 06 Jun '19

06 Jun '19

It seems we've come to an impasse on this change [1] because of a concern about where to validate the requested host and/or hypervisor_hostname. The change is currently validating in the API to provide a fast fail 400 response to the user if the host and/or node don't exist. The concern is that the lookup for the compute node will be done again in the scheduler [2]. Also, if the host is not provided, then to validate the node we have to iterate the cells looking for the given compute node (we could use placement though, more on that below). I've added this to the nova meeting agenda for tomorrow but wanted to try and enumerate what I see are the options before the meeting so we don't have to re-cap all of this during the meeting. The options as I see them are: 1. Omit the validation in the API and let the scheduler do the validation. Pros: no performance impact in the API when creating server(s) Cons: if the host/node does not exist, the user will get a 202 response and eventually a NoValidHost error which is not a great user experience, although it is what happens today with the availability_zone forced host/node behavior we already have [3] so maybe it's acceptable. 2. Only validate host in the API since we can look up the HostMapping in the API DB. If the user also provided a node then we'd just throw that on the RequestSpec and let the scheduler code validate it. Pros: basic validation for the simple and probably most widely used case since for non-baremetal instances the host and node are going to be the same Cons: still could have a late failure in the scheduler with NoValidHost error; does not cover the case that only node (no host) is specified 3. Validate both the host and node in the API. This can be broken down: a) If only host is specified, do #2 above. b) If only node is specified, iterate the cells looking for the node (or query a resource provider with that name in placement which would avoid down cell issues) c) If both host and node is specified, get the HostMapping and from that lookup the ComputeNode in the given cell (per the HostMapping) Pros: fail fast behavior in the API if either the host and/or node do not exist Cons: performance hit in the API to validate the host/node and redundancy with the scheduler to find the ComputeNode to get its uuid for the in_tree filtering on GET /allocation_candidates. Note that if we do find the ComputeNode in the API, we could also (later?) make a change to the Destination object to add a node_uuid field so we can pass that through on the RequestSpec from API->conductor->scheduler and that should remove the need for the duplicate query in the scheduler code for the in_tree logic. I'm personally in favor of option 3 since we know that users hate NoValidHost errors and we have ways to mitigate the performance overhead of that validation. Note that this isn't necessarily something that has to happen in the same change that introduces the host/hypervisor_hostname parameters to the API. If we do the validation in the API I'd probably split the validation logic into it's own patch to make it easier to test and review on its own. [1] https://review.opendev.org/#/c/645520/ [2] https://github.com/openstack/nova/blob/2e85453879533af0b4d0e1178797d26f026a… [3] https://docs.openstack.org/nova/latest/admin/availability-zones.html -- Thanks, Matt

4 6

[ops] database archiving tool
by Pierre-Samuel LE STANG 06 Jun '19

06 Jun '19

Hi all, At OVH we needed to write our own tool that archive data from OpenStack databases to prevent some side effect related to huge tables (slower response time, changing MariaDB query plan) and to answer to some legal aspects. So we started to write a python tool which is called OSArchiver that I briefly presented at Denver few days ago in the "Optimizing OpenStack at large scale" talk. We think that this tool could be helpful to other and are ready to open source it, first we would like to get the opinion of the ops community about that tool. To sum-up OSArchiver is written to work regardless of Openstack project. The tool relies on the fact that soft deleted data are recognizable because of their 'deleted' column which is set to 1 or uuid and 'deleted_at' column which is set to the date of deletion. The points to have in mind about OSArchiver: * There is no knowledge of business objects * One table might be archived if it contains 'deleted' column * Children rows are archived before parents rows * A row can not be deleted if it fails to be archived Here are features already implemented: * Archive data in an other database and/or file (actually SQL and CSV formats are supported) to be easily imported * Delete data from Openstack databases * Customizable (retention, exclude DBs, exclude tables, bulk insert/delete) * Multiple archiving configuration * Dry-run mode * Easily extensible, you can add your own destination module (other file format, remote storage etc...) * Archive and/or delete only mode It also means that by design you can run osarchiver not only on OpenStack databases but also on archived OpenStack databases. Thanks in advance for your feedbacks. -- Pierre-Samuel Le Stang

5 10

[oslo] Bandit Strategy
by Ben Nemec 06 Jun '19

06 Jun '19

Nefarious cap bandits are running amok in the OpenStack community! Won't someone take a stand against these villainous headwear thieves?! Oh, sorry, just pasted the elevator pitch for my new novel. ;-) Actually, this email is to summarize the plan we came up with in the Oslo meeting this morning. Since we have a bunch of projects affected by the Bandit breakage I wanted to make sure we had a common fix so we don't have a bunch of slightly different approaches in each project. The plan we agreed on in the meeting was to push a two patch series to each repo - one to cap bandit <1.6.0 and one to uncap it with a !=1.6.0 exclusion. The first should be merged immediately to unblock ci, and the latter can be rechecked once bandit 1.6.1 releases to verify that it fixes the problem for us. We chose this approach instead of just tweaking the exclusion in tox.ini because it's not clear that the current behavior will continue once Bandit fixes the bug. Assuming they restore the old behavior, this should require the least churn in our repos and means we're still compatible with older versions that people may already have installed. I started pushing patches under https://review.opendev.org/#/q/topic:cap-bandit (which prompted the digression to start this email ;-) to implement this plan. This is mostly intended to be informational, but if you have any concerns with the plan above please do let us know immediately. Thanks. -Ben

8 32

[nova][cinder][glance][Barbican]Finding Timeslot for weekly Image Encryption IRC meeting
by Josephine Seifert 04 Jun '19

04 Jun '19

Hello, as a result from the Summit and the PTG, I would like to hold a weekly IRC-meeting for the Image Encryption (soon to be a pop-up team). As I work in Europe I have made a doodle poll, with timeslots I can attend and hopefully many of you. If you would like to join in a weekly meeting, please fill out the poll and state your name and the project you are working in: https://doodle.com/poll/wtg9ha3e5dvym6yt Thank you Josephine (Luzi)

2 4