- openstack-discuss - lists.openstack.org

[nova] TPM passthrough
by Jim Rollenhagen 27 Jun '19

27 Jun '19

Hey y'all, We have an internal use case which requires a VM with a TPM, to be used to store a private key. Libvirt has two ways to present a TPM to a VM: passthrough or emulated. Per kashyap and the #qemu IRC channel, libvirt stores the TPM's state on disk, unencrypted. Our risk profile includes "someone walks away with a disk", so this won't work for our use case. The QEMU devs have asked for RFEs to implement vTPMs where the state never touches the disk, so I have hopes that this will be done eventually. However, I suspect that this will still take some time, especially as nobody has volunteered to actually do the work yet. So, I'd like to propose we implement TPM passthrough in Nova. My team is happy to do the work, but I'd love some guidance as to the best way to implement this so we can get a spec done (I assume it's "just another resource class"?). If Nova doesn't want this feature in, and would rather just wait for the features in QEMU, we'll carry it downstream, I guess. :) Thoughts? // jim

5 9

[dev][requirements] Upcoming changes to constraints handling in tox.ini
by Tony Breeds 27 Jun '19

27 Jun '19

Hi folks, This is a heads-up to describe 3 sets of changes you'll start seeing starting next week. 1) lower-constraints.txt handling TL;DR: Make sure projects do not specify a constraint file in install_command 2) Switch to the new canonical constraints URL on master TR;DR: Make sure you use https://releases.openstack.org/constraints/upper/master 3) Switch to the new canonical constraints URL on stable branches TR;DR: Make sure you use https://releases.openstack.org/constraints/upper/$series These will be generated from a member of the requirements team[1], and will be on the gerrit topic constraints-updates. We'll start next week to give y'all a few days to digest this email Now for slightly more details: 1) lower-constraints.txt handling If a projects has an install_command that includes a constraint file *and* the also have a lower-constraints test env what may happen is something like: given a tox.ini that contains: --- [testenv] install_command = pip install -U -c upper-constraints.txt {opts} {deps} deps = -r requirements.txt -r test-requirements.txt [testenv:lower-constraints] deps = -c lower-constrtaints.txt -r requirements.txt -r test-requirements.txt --- pyXX: virtualenv -p $python_version .tox/$testenv_name .tox/$testenv_name/bin/pip install -U -c upper-constratints.txt -r requirements.txt -rtest-requirements.txt .tox/$testenv_name/bin/pip install . lower-constraints: virtualenv -p $python_version .tox/$testenv_name .tox/$testenv_name/bin/pip install -U -c upper-constratints.txt -c lower-constrtaints.txt -r requirements.txt -rtest-requirements.txt .tox/$testenv_name/bin/pip install . pip will constrain a library to the first item it encounters, which pretty much means that the lower-constraints testenv is still testing against upper-constraints.txt[3] The fix is to move all constraints into deps rather than install_command. This impacts ~40 projects and will be fixed by hand, rather than a tool so we can preserve each projects style for tox.ini. There's a pretty good chance that this change will break the lower-constraints testenv, project teams are encouraged to help identify the incorrect values in lower-constraints, the requirements team will pick the current value in upper-constraints which almost certainly raises a value well past the minimum. https://review.opendev.org/#/c/601188/ is the change we did for keystone way back when Some projects have upper-constraints.txt in install_command but explicitly override it in lower-constratints.txt this works and wont be changed at this point but ideally all projects will use the same format to reduce the impact in switching between projects. 2) Switch to the new canonical constraints URL on master Way back at the first Denver PTG thr requirements, release and infrastructure teams discussed avoiding using gitweb urls for constraints urls. This was discussed[4] in more detail after the liberty EOL broke consumers still wanting to use tox as: https://git.openstack.org/cgit/openstack/requirements/plain/upper-constrain… 'vanished' The idea was re-raised[5] in Feb. this year where we devised a plan to create URLs that abstract the git hosting and allow us to switch between branches and tags at the right times in the OpenStack life-cycle. Other, more dynamic, ideas were discussed but over complicate things and make OpenStack slightly harder to understand or create more work. for example we could: a. Add an install_script that looks up $metadata and grab the right constraints We're trying avoid scripts like this as it very rapidly gets us to the point where we're doing "managed copy-and-paste" between projects *or* projects install scripts diverge b. Add to tox itself the ability to derive the URL from $metadata This is doable but frankly requires more time than we have right now. So what we have is: redirect 301 /constraints/upper/master http://git.openstack.org/cgit/openstack/requirements/plain/upper-constraint… redirect 301 /constraints/upper/train http://git.openstack.org/cgit/openstack/requirements/plain/upper-constraint… redirect 301 /constraints/upper/stein http://git.openstack.org/cgit/openstack/requirements/plain/upper-constraint… redirect 301 /constraints/upper/rocky http://git.openstack.org/cgit/openstack/requirements/plain/upper-constraint… redirect 301 /constraints/upper/queens http://git.openstack.org/cgit/openstack/requirements/plain/upper-constraint… redirect 301 /constraints/upper/pike http://git.openstack.org/cgit/openstack/requirements/plain/upper-constraint… redirect 301 /constraints/upper/ocata http://git.openstack.org/cgit/openstack/requirements/plain/upper-constraint… redirect 301 /constraints/upper/newton http://git.openstack.org/cgit/openstack/requirements/plain/upper-constraint… redirect 301 /constraints/upper/mitaka http://git.openstack.org/cgit/openstack/requirements/plain/upper-constraint… redirect 301 /constraints/upper/liberty http://git.openstack.org/cgit/openstack/requirements/plain/upper-constraint… redirect 301 /constraints/upper/kilo http://git.openstack.org/cgit/openstack/requirements/plain/upper-constraint… redirect 301 /constraints/upper/juno http://git.openstack.org/cgit/openstack/requirements/plain/upper-constraint… [Yes I know we need to use opendev that's tomorrows problem] so that means that: http{s,}://releases.openstack.org/constraints/upper/master http{s,}://releases.openstack.org/constraints/upper/$series will always do the right thing based on the state of each OpenStack release. So we're going to generate changes that point to the right place. For master we have 2 options: a. Use .../train If we use train in the constraints URLs now things will work and when we branch for 'U' we'd need to update master to point to the right series name. This is very doable. The release team already generates a change on master at this point in time to update reno. We also need to update the new stable branch so that .gitreview points to the new branch. b. Use .../master If we use 'master' in the constratints URLs master will always work and when we branch for 'U' we'd need to update the stable/train branch to point to train. The release team already does this today along with the .gitreview change. So the bottom line is that using master (over train) is *slighty* less work for the release team and *slightly* less work for each project team. as such that's what we're going to do. There are several changes in the works that set the constraints url to either https://opendev.org/openstack/requirements/raw/branch/master/upper-constrai… or https://releases.openstack.org/constraints/upper/train These will work and will not break anything when the project branches, however for the sake of OpenStack wide consistency, and avoiding merge conflicts project teams are discouraged from merging them, or if the change also fixes other references to git.openstack.org just have the tox.ini updates removed. Once tox.ini is done the requirements team will look for additional places where the 'old style' urls are used and follow-up but right now there's a lot of noise to sift through 3) Switch to the new canonical constraints URL on stable branches Hopefully with all the background from 2 above this should be pretty self-explanatory. This is however much lower priority and probably wont start until the bulk of 1 and 2 is complete Yours Tony. [1] https://review.opendev.org/#/admin/groups/131,members [2] [2] Probably me actually ;P [3] There is some nuance here but this is the general rule [4] In the thread that starts with: http://lists.openstack.org/pipermail/openstack-dev/2017-September/122333.ht… [5] In the thread that starts with: http://lists.openstack.org/pipermail/openstack-discuss/2019-February/002682…

6 7

Backup solutions
by Alfredo De Luca 27 Jun '19

27 Jun '19

Hi all. Just a quick one. Other than freezer openstack project as backup solution, are there any other opensource/commercial project/software/solutions for that? Cheers -- *Alfredo*

3 3

[glance] Openstack Glance Image custom properties issue
by Hemant Sonawane 27 Jun '19

27 Jun '19

Hello, My self Hemant Sonawane. Recently I am working on openstack and I am getting some strange error when I installed openstack dashboard and tried to edit the visibility of images and update their metadata it dosent work I get *Forbidden : Redirecting to login *and *Unable to edit the image custom properties *such errors. I also tried to see the glance-api logs and found this *"2019-06-26 13:11:51,705.705 1 WARNING glance.api.v2.images [-] Could not find schema properties file schema-image.json. Continuing without custom properties"* Is there any glance policy in horizon? that might cause this error I think. The detail log file attached for your ready reference. So please look into my concern and let me know if there is any solution to resolve my issue. Thanks and Regards, Hemant Sonawane

1 0

Reply： [nova]Bug #1829696: qemu-kvm process takes 100% CPU usage whenrunning redhat/centos 7.6 guest OS
by 钱熙 26 Jun '19

26 Jun '19

Thanks very much. I will upgrade the virt tools software on the host and check if it still happens. Later, I hope I could update you guys. Thanks again. Best regards QianXi------------------ 原始邮件 ------------------ 发件人: "Kashyap Chamarthy"<kchamart(a)redhat.com> 发送时间: 2019年6月21日(星期五) 凌晨0:32 收件人: "钱熙"<qianxi416(a)foxmail.com>; 抄送: "openstack-discuss"<openstack-discuss(a)lists.openstack.org>; 主题: Re: [nova]Bug #1829696: qemu-kvm process takes 100% CPU usage whenrunning redhat/centos 7.6 guest OS On Thu, Jun 20, 2019 at 10:06:11PM +0800, 钱熙 wrote: > Hi there, Hi, > > I am struggling with qemu-kvm 100% CPU usage problem. > When running redhat or centos 7.6 guest os on vm, > the cpu usage is very low on vm(almost 100% idle when no tasks run), but on the host, > qemu-kvm reports 100% cpu busy usage. > > > https://bugs.launchpad.net/nova/+bug/1829696 > I opened the bug above, however it did not find some interest. > > > After searching some related bugs report, > I suspect that it is due to the clock settings in vm's domain xml. > My settings are as follows: > <clock offset='utc'> > <timer name='rtc' tickpolicy='catchup'/> > <timer name='pit' tickpolicy='delay'/> > <timer name='hpet' present='no'/> > </clock> > And details about the bug, please see https://bugs.launchpad.net/nova/+bug/1829696 I don't think it is related to clock settings at all. > It shows that only the version 7.6 of redhat or centos affected by this bug behavior. > In my cluster, it is OK for versions from redhat or centos 6.8 to 7.5. > > > Any clue or suggestion? Please see DanPB's response in comment#2; I agree with it. (Note that I've changed the bug component from 'openstack-nova' --> 'qemu') https://bugs.launchpad.net/qemu/+bug/1829696/comments/2 -- /kashyap

2 1

[goal][python3] Train unit tests weekly update (goal-11)
by Corey Bryant 26 Jun '19

26 Jun '19

This is the goal-11 weekly update for the "Update Python 3 test runtimes for Train" goal [1]. There are 11 weeks remaining for completion of Train community goals [2]. == What's the Goal? == To ensure (in the Train cycle) that all official OpenStack repositories with Python 3 unit tests are exclusively using the 'openstack-python3-train-jobs' Zuul template or one of its variants (e.g. 'openstack-python3-train-jobs-neutron') to run unit tests, and that tests are passing. This will ensure that all official projects are running py36 and py37 unit tests in Train. For complete details please see [1]. == Ongoing Work == Open patches needing reviews: https://review.openstack.org/#/q/topic:python3-train+is:open Failing patches: https://review.openstack.org/#/q/topic:python3-train+status:open+(+label:Ve… Patch automation scripts needing review: https://review.opendev.org/#/c/666934 Some notes on 2 issues I came across this week: 1) I've updated the patch automation scripts to drop py34,py35,py36 and add py37 to default tox targets as discussed with smcginnis, fungi, and gmann in #openstack-tc this week. 2) While trying to proposed and urge the move to py37-only default tox targets, some projects have decided to keep both py36 and py37 targets and some projects have decided to run with the generic py3-only target. == Completed Work == Merged patches: https://review.openstack.org/#/q/topic:python3-train+is:merged == How can you help? == Please take a look at the failing patches and help fix any failing unit tests for your project(s). Python 3.7 unit tests will be self-testing in Zuul. If you're interested in helping submit patches, please let me know. == Reference Material == [1] Goal description: https://governance.openstack.org/tc/goals /train/python3-updates.html [2] Train release schedule: https://releases.openstack.org/train/schedule.html (see R-5 for "Train Community Goals Completed") Storyboard: https://storyboard.openstack.org/#!/story/2005924 Porting to Python 3.7: https://docs.python.org/3/whatsnew/3.7.html#porting-to-python-3-7 Python Update Process: https://opendev.org/openstack/governance/src/branch/master/resolutions/2018… Train runtimes: https://opendev.org/openstack/governance/src/branch/master/reference/runtim… Thanks, Corey

1 0

[stable][sahara] Changes to the stable team
by Tony Breeds 26 Jun '19

26 Jun '19

Hello all, In the middle of last week Telles asked[1] for a couple of the current Sahara core team (Jeremy and Luigi) to be added to the stable group. Upon review there isn't enough data (either reviews or backports) to verify that Jeremy and Luigi understand the stable policy. So I'd like to try an experiment and I've added both to the stable core team but I ask neither +W a backport and ping me (or another stable team member) for the final approval. I'd like to suggest dropping: * Elise Gafford egafford(a)redhat.com * Sergey Lukjanov slukjanov(a)mirantis.com * Sergey Reshetnyak sreshetniak(a)mirantis.com * Vitaly Gridnev gridnevvvit(a)gmail.com from the sahara-stable-maint group given[2] is empty. Yours Tony. [1] http://eavesdrop.openstack.org/irclogs/%23openstack-stable/%23openstack-sta… [2] https://review.opendev.org/#/q/(project:openstack/python-saharaclient+OR+pr…

2 2

[nova] Spec Review Day: Tuesday July 2nd
by Eric Fried 26 Jun '19

26 Jun '19

Esteemed Nova contributors and maintainers- With about a month until spec freeze [1], we need to fish or cut bait [2] on open specs. To that end, I have recycled the Spec Review Day etherpad [3] and populated it with all open Train specs (those with a file under specs/train/approved) [4]. I seeded their initial status in the etherpad, including noting from whom the next action is expected. Authors: Look for your specs, especially if they say "Action: author", and update them ASAP. (Having done so, you can toggle to "Action: reviewer".) Reviewers and Cores: Scan the list for Action: "reviewer" and/or "approver" and dive in. (You may wish to start by intersecting with [5], which narrows [4] down to specs you've already reviewed at some point.) You do not need to wait until, or limit your activity to, Tuesday. Especially if you're going to be unavailable then. Thanks, efried [1] https://wiki.openstack.org/wiki/Nova/Train_Release_Schedule [2] https://en.wiktionary.org/wiki/fish_or_cut_bait [3] https://etherpad.openstack.org/p/nova-spec-review-day [4] https://review.opendev.org/#/q/project:openstack/nova-specs+status:open+pat… [5] https://review.opendev.org/#/q/project:openstack/nova-specs+status:open+pat…

1 1

[stackalytics] Reported numbers seem inaccurate
by Mark Goddard 26 Jun '19

26 Jun '19

Hi, I've heard a couple of people say they don't feel the numbers reported by Stackalytics accurately reflect reality. I've been trying to gather a few stats for my Kolla update session in Denver, and am finding the same. I'll try to give some concrete examples. Reviews for all kolla deliverables in Stein [1]. Here the company stats don't reflect the individual stats. Also, the total reviews in the 'Kolla Official' module does not equal the sum of the reviews of its submodules (kolla, kolla-ansible, kolla-cli). If I look at the contribution summary for Kolla Official in the last 90 days [2], they are actually greater than those for the last 180 days [3]! There are also similar issues with commit metrics, and none seem to match what I see in git. Thanks, Mark [1] https://www.stackalytics.com/?metric=marks&module=kolla-group [2] https://www.stackalytics.com/report/contribution/kolla-group/90 [3] https://www.stackalytics.com/report/contribution/kolla-group/180

10 11

[nova] FYI for out-of-tree virt drivers: deprecating non-update-provider-tree compat
by Matt Riedemann 26 Jun '19

26 Jun '19

I have a change up [1] to deprecate the backward compatibility code in the ResourceTracker for virt drivers that do not implement the update_provider_tree interface. Starting in Train you'll get a warning in the nova-compute logs every time the update_available_resource periodic runs (we could only log on startup, that's up for debate in the change) until the driver is updated and in the U release we'll drop that compatibility code. The only out-of-tree virt driver I checked was nova-lxd and it does *not* implement update_provider_tree so for those that care about that driver you should implement the interface. The patch has a link to the reference docs on implementing that interface for your driver (it's pretty simple). [1] https://review.opendev.org/#/c/667442/ -- Thanks, Matt

1 0

Shanghai CFP CLOSING Soon!
by Jimmy McArthur 26 Jun '19

26 Jun '19

Sorry everyone. I completely messed up the subject. So for real... it's already here, but it won't be for long! Details below. The July 2 deadline to submit a presentation [1] for the Open Infrastructure Summit [2] in Shanghai is in less than one week! Submit your session today and join the global community in Shanghai, November 4-6, 2019. Sessions will be presented in both Mandarin and English, so you may submit your presentation in either language. Submit your presentations, panels, and hands-on workshops [3] before July 2 at 11:59 pm PT (July 3, 2019 at 15:00 China Standard Time). Tracks [4]: Container Infrastructure Hands-on Workshops AI, Machine Learning & HPC Private & Hybrid Cloud Public Cloud 5G, NFV & Edge Open Development Getting Started CI/CD Security Upcoming Shanghai Summit Deadlines * Register now [5] before the early bird registration deadline in early August (USD or RMB options available) * Apply for Travel Support [6] before August 8. For more information on the Travel Support Program, go here [7]. * Interested in sponsoring the Summit? [8]. * The content submission process for the Forum and Project Teams Gathering will be managed separately in the upcoming months. We look forward to your submissions! Cheers, Jimmy [1] https://cfp.openstack.org/ [2] https://www.openstack.org/summit/shanghai-2019/ [3] https://cfp.openstack.org/ [4] https://www.openstack.org/summit/shanghai-2019/summit-categories/ [5] https://www.openstack.org/summit/shanghai-2019/ [6] https://openstackfoundation.formstack.com/forms/travelsupportshanghai [7] https://www.openstack.org/summit/shanghai-2019/travel/ [8] https://www.openstack.org/summit/shanghai-2019/sponsors/ > >

1 0

Shanghai CFP Coming Soon!
by Jimmy McArthur 26 Jun '19

26 Jun '19

Hi Everyone! The July 2 deadline to submit a presentation [1] for the Open Infrastructure Summit [2] in Shanghai is in less than one week! Submit your session today and join the global community in Shanghai, November 4-6, 2019. Sessions will be presented in both Mandarin and English, so you may submit your presentation in either language. Submit your presentations, panels, and hands-on workshops [3] before July 2 at 11:59 pm PT (July 3, 2019 at 15:00 China Standard Time). Tracks [4]: Container Infrastructure Hands-on Workshops AI, Machine Learning & HPC Private & Hybrid Cloud Public Cloud 5G, NFV & Edge Open Development Getting Started CI/CD Security Upcoming Shanghai Summit Deadlines * Register now [5] before the early bird registration deadline in early August (USD or RMB options available) * Apply for Travel Support [6] before August 8. For more information on the Travel Support Program, go here [7]. * Interested in sponsoring the Summit? [8]. * The content submission process for the Forum and Project Teams Gathering will be managed separately in the upcoming months. We look forward to your submissions! Cheers, Jimmy [1] https://cfp.openstack.org/ [2] https://www.openstack.org/summit/shanghai-2019/ [3] https://cfp.openstack.org/ [4] https://www.openstack.org/summit/shanghai-2019/summit-categories/ [5] https://www.openstack.org/summit/shanghai-2019/ [6] https://openstackfoundation.formstack.com/forms/travelsupportshanghai [7] https://www.openstack.org/summit/shanghai-2019/travel/ [8] https://www.openstack.org/summit/shanghai-2019/sponsors/

3 2

[magnum] weekly meetings
by Bharat Kunwar 26 Jun '19

26 Jun '19

Hello all I was wondering if there was a reason there hasn’t been a regular weekly meeting recently. The last one I traced back in the IRC log was back in 4 June. It would be good if there was an up to date schedule somewhere with definite dates where there is a chair available. Best Bharat

2 2

[nova] Strict isolation of group of hosts for image
by Kamde, Vrushali 26 Jun '19

26 Jun '19

Hi, Working on implementation of 'Support filtering of allocation_candidates by forbidden aggregates' spec. Here we are trying to Test granular resource request. Facing issue in configuring inventories for 'CUSTOM_RESOURCE_CLASS' and resulting into 'No Valid host found' whereas expecting host from placement. So kindly help me here how one can set inventory for 'CUSTOM_RESOURCE_CLASS' because when the inventory is added for the custom resource class 'CUSTOM_RESOURCE_CLASS', it's getting removed when the compute service periodic task updates the inventory. FYI, here are the steps followed: 1. Data configured at nova: * Create three aggregates 'agg1', 'agg2', 'agg3' by using: 'POST'-- /os-aggregates(Create aggregate) * Setting metadata on aggregates: i. Setting metadata (trait:HW_CPU_X86_SGX) on the aggregate agg1 by using: 'POST'-- /os-aggregates/{aggregate_id}/action(set metadata) ii. Setting metadata (trait:STORAGE_DISK_SSD) on the aggregate agg2 by using: 'POST'-- /os-aggregates/{aggregate_id}/action(set metadata) iii. Setting metadata (trait:CUSTOM_MAGIC, trait:HW_CPU_X86_MMX) on the aggregate agg3 by using: 'POST'-- /os-aggregates/{aggregate_id}/action(set metadata) * Associate aggregates 'agg3' to host say 'RP1' by using: 'POST'-- /os-aggregates/{aggregate_id}/action(Add host) * Setting Extra-specs on Flavor(trait:HW_CPU_X86_MMX, trait1:CUSTOM_MAGIC, resources1:CUSTOM_RESOURCE_CLASS): 'POST'-- /flavors/{flavor_id}/os-extra_specs 1. Data configured at placement: * Setting traits (CUSTOM_MAGIC, HW_CPU_X86_MMX) on host 'RP1'. 'PUT'-- /resource_providers/{uuid}/traits * Create a new Resource class 'CUSTOM_RESOURCE_CLASS': 'POST'-- /resource_classes 1. Assigned inventories to the new resource class: openstack resource provider inventory set --resource CUSTOM_RESOURCE_CLASS:total=78 <RP1_uuid> 'PUT'-- /resource_providers/{uuid}/inventories/{resource_class} 1. When we boot the instance : * The final url of allocation_candidates which we get is as follows: '/allocation_candidates?limit=1000&member_of=%21in%3A442ca580-fd07-433c-9b67-c18fdeccbca1%2C61b8bb02-01e0-4e28-af4c-0ea4c828539a &required=HW_CPU_X86_MMX&required1=CUSTOM_MAGIC&resources=DISK_GB%3A1%2CMEMORY_MB%3A512%2CVCPU%3A1&resources1=CUSTOM_RESOURCE_CLASS%3A1' * Observed after the inventory is added for the custom resource class 'CUSTOM_RESOURCE_CLASS', it's getting removed when the compute service periodic task updates the inventory. Therefore the instance is not getting booted on 'RP1'. The error faced which we get is 'No Valid host found'. Regards, Vrushali Kamde. Disclaimer: This email and any attachments are sent in strictest confidence for the sole use of the addressee and may contain legally privileged, confidential, and proprietary data. If you are not the intended recipient, please advise the sender by replying promptly to this email and then delete and destroy this email and any attachments without any further use, copying or forwarding.

2 1

Best practices to restart / repair broken Octavia LoadBalancer
by Pawel Konczalski 26 Jun '19

26 Jun '19

2 1

Re: [Nova][Ironic] Reset Configurations in Baremetals Post Provisioning
by Alex Xu 26 Jun '19

26 Jun '19

Mark Goddard <mark(a)stackhpc.com> 于2019年6月12日周三下午2:45写道： > > > On Wed, 12 Jun 2019, 06:23 Alex Xu, <soulxu(a)gmail.com> wrote: > >> >> >> Mark Goddard <mark(a)stackhpc.com> 于2019年6月12日周三上午1:39写道： >> >>> On Mon, 10 Jun 2019 at 06:18, Alex Xu <soulxu(a)gmail.com> wrote: >>> > >>> > >>> > >>> > Eric Fried <openstack(a)fried.cc> 于2019年6月7日周五上午1:59写道： >>> >> >>> >> > Looking at the specs, it seems it's mostly talking about changing >>> VMs resources without rebooting. However that's not the actual intent of >>> the Ironic use case I explained in the email. >>> >> > Yes, it requires a reboot to reflect the BIOS changes. This reboot >>> can be either be done by Nova IronicDriver or Ironic deploy step can also >>> do it. >>> >> > So I am not sure if the spec actually satisfies the use case. >>> >> > I hope to get more response from the team to get more clarity. >>> >> >>> >> Waitwait. The VM needs to be rebooted for the BIOS change to take >>> >> effect? So (non-live) resize would actually satisfy your use case just >>> >> fine. But the problem is that the ironic driver doesn't support resize >>> >> at all? >>> >> >>> >> Without digging too hard, that seems like it would be a fairly >>> >> straightforward thing to add. It would be limited to only "same host" >>> >> and initially you could only change this one attribute (anything else >>> >> would have to fail). >>> >> >>> >> Nova people, thoughts? >>> >> >>> > >>> > Contribute another idea. >>> > >>> > So just as Jay said in this thread. Those CUSTOM_HYPERTHREADING_ON and >>> CUSTOM_HYPERTHREADING_OFF are configuration. Those >>> > configuration isn't used for scheduling. Actually, Traits is designed >>> for scheduling. >>> > >>> > So yes, there should be only one trait. CUSTOM_HYPERTHREADING, this >>> trait is used for indicating the host support HT. About whether enable it >>> in the instance is configuration info. >>> > >>> > That is also pain for change the configuration in the flavor. The >>> flavor is the spec of instance's virtual resource, not the configuration. >>> > >>> > So another way is we should store the configuration into another >>> place. Like the server's metadata. >>> > >>> > So for the HT case. We only fill the CUSTOM_HYPERTHREADING trait in >>> the flavor, and fill a server metadata 'hyperthreading_config=on' in server >>> metadata. The nova will find out a BM node support HT. And ironic based on >>> the server metadata 'hyperthreading_config=on' to enable the HT. >>> > >>> > When change the configuration of HT to off, the user can update the >>> server's metadata. Currently, the nova will send a rpc call to the compute >>> node and calling a virt driver interface when the server metadata is >>> updated. In the ironic virt driver, it can trigger a hyper-threading >>> configuration deploy step to turn the HT off, and do a reboot of the >>> instance. (The reboot is a step inside deploy-step, not part of ironic virt >>> driver flow) >>> > >>> > But yes, this changes some design to the original deploy-steps and >>> deploy-templates. And we fill something into the server's metadata which >>> I'm not sure nova people like it. >>> > >>> > Anyway, just put my idea at here. >>> >>> We did consider using metadata. The problem is that it is >>> user-defined, so there is no way for an operator to restrict what can >>> be done by a user. Flavors are operator-defined and so allow for >>> selection from a 'menu' of types and configurations. >>> >> >> The end user can change the BIOS config by the ipmi inside the guest OS, >> and do a reboot. It is already out of control for the operator. >> (Correct me if ironic doesn't allow the end user change the config inside >> the guest OS) >> > > It depends. Normally you can't configure BIOS via IPMI, but need to use a > vendor interface such as racadm or on hardware that supports it, Redfish. > Access to the management controller can and should be locked down though. > It's also usually possible to reconfigure via serial console, if this is > exposed to users. > It sounds that breaking the operator control partially. (Sorry for drop the mallist thread again...I will paste a note to the wall "click the "Reply All"...") > >> So Flavor should be thing to strict the resource( or resource's capable) >> which can be requested by the end user. For example, flavor will say I need >> a BM node has hyper-thread capable. But enable or disable can be controlled >> by the end user. >> >> >>> >>> What might be nice is if we could use a flavor extra spec like this: >>> >>> deploy-config:hyperthreading=enabled >>> >>> The nova ironic virt driver could pass this to ironic, like it does with >>> traits. >>> >>> Then in the ironic deploy template, have fields like this: >>> >>> name: Hyperthreading enabled >>> config-type: hyperthreading >>> config-value: enabled >>> steps: <deploy steps> >>> >>> Ironic would then match on the config-type and config-value to find a >>> suitable deploy template. >>> >>> As an extension, the deploy template could define a trait (or list of >>> traits) that must be supported by a node in order for the template to >>> be applied. Perhaps this would even be a standard relationship between >>> config-type and traits? >>> >>> Haven't thought this through completely, I'm sure it has holes. >>> >>> > >>> >> efried >>> >> . >>> >> >>> >>

4 10

RE: Openstack Glance Image custom properties issue
by Hemant Sonawane 26 Jun '19

26 Jun '19

Hello, My self Hemant Sonawane. Recently I am working on openstack and I am getting some strange error when I installed openstack dashboard and tried to edit the visibility of images and update their metadata it dosent work I get *Forbidden : Redirecting to login *and *Unable to edit the image custom properties *such errors. I also tried to see the glance-api logs and found this *"2019-06-26 13:11:51,705.705 1 WARNING glance.api.v2.images [-] Could not find schema properties file schema-image.json. Continuing without custom properties"* Is there any glance policy in horizon? that might cause this error I think. The detail log file attached for your ready reference. So please look into my concern and let me know if there is any solution to resolve my issue. Thanks and Regards,

1 0

[nova] Can we drop the kilo era ComputeNode host/service_id compat code now?
by Matt Riedemann 26 Jun '19

26 Jun '19

There are still quite a few TODOs in the code [1][2][3] from a kilo era blueprint [4]. At this point I'm pretty sure you can't startup the nova-compute service without having a ComputeNode record without a host and hypervisor_hostname field set (we don't set the ComputeNode.service_id anywhere anymore as far as I can tell, except in some ComputeNode RPC compat code [5]). I've stumbled across all of this code before, but was looking at it again today because I have a very simple change I need to make which is going from a ComputeNode object and getting the related nova-compute Service object for that node. Looking at the code one might think this is reasonable: service = objects.Service.get_by_id(ctxt, compute_node.service_id) But compute_node.service_id is likely None. Or how about: service = objects.Service.get_by_compute_host(ctxt, compute_node.host) But ComputeNode.host is also nullable (though likely should have a value as noted above). This is a long way of me saying this code is all gross and we should clean it up, which means making sure all of this Kilo era compat code for old records is no longer necessary, which means all of those records should be migrated by now but how should we check? I *think* this might just be as simple as a "nova-status upgrade check" check which scans the cells looking for (non-deleted) compute_nodes records where host is NULL and report an error if any are found. I believe the recovery action for an operator that hits this is to delete the busted compute_nodes record and restart the nova-compute service so a new compute node record is created. I would really think that anything this scan would find would be orphaned compute_nodes records that could just be deleted since another compute_nodes record probably already exists for the same hypervisor_hostname value. IOW, I don't think we need an online data migration routine for this. Hopefully at least one person (Sylvain) can agree with me here and the plan of action I've put forth. [1] https://github.com/openstack/nova/blob/91647a9b711a8102c79bb17c6b4dff24ad6f… [2] https://github.com/openstack/nova/blob/91647a9b711a8102c79bb17c6b4dff24ad6f… [3] https://github.com/openstack/nova/blob/91647a9b711a8102c79bb17c6b4dff24ad6f… [4] https://blueprints.launchpad.net/nova/+spec/detach-service-from-computenode [5] https://github.com/openstack/nova/blob/91647a9b711a8102c79bb17c6b4dff24ad6f… -- Thanks, Matt

3 2

OSA with cumulus linux
by Grant Morley 26 Jun '19

26 Jun '19

Hi All, Just wondered if anyone was using OSA with cumulus linux at all? - We are starting a new POC and have cumulus switches for a new environment. We currently use OSA and wondered if there was any support / playbooks for it using cumulus linux? Or if anyone is running cumulus, have you had to write your own playbooks with it alongside OSA? Happy to do the latter, but didn't know if anyone has already done this or can point me to any documentation that would be useful. I couldn't find anything when I looked here: https://docs.openstack.org/project-deploy-guide/openstack-ansible/latest/ Regards, -- Grant Morley Cloud Lead, Civo Ltd www.civo.com <https://www.civo.com/>| Signup for an account! <https://www.civo.com/signup>

2 2

[mistral] No office hours meeting today
by Renat Akhmerov 26 Jun '19

26 Jun '19

Hello, Since a number of key people can’t attend today’s meeting we’re cancelling it. See you next week. Thanks Renat Akhmerov @Nokia

1 0

Installation of Cinder in multi compute environment
by Jyoti Dahiwele 25 Jun '19

25 Jun '19

Dear Team, What is the best practise of installation of Cinder service on a controller node or separate node in multi compute openstack installation?

1 0

[tc] July meeting host
by Alexandra Settle 25 Jun '19

25 Jun '19

Hi team, The next TC meeting is set to be on the 5th of July, 2019. As I have every intention of leaving my laptop in the UK whilst I vacay on the sunny shores of US, I need a volunteer to host the meeting. I am currently going through the process of updating the meeting agenda, so minimum effort required :) just turn up, and ensure your gif game is strong, and run the commands. Any takers? I'll return for the following meeting on the 1st of August. Cheers, Alex

11 18

[scientific-sig] IRC meeting shortly: Shanghai summit CFP and planning
by Stig Telfer 25 Jun '19

25 Jun '19

Hi all - We have a Scientific SIG IRC meeting at 2100 UTC (about 20 minutes) in channel #openstack-meeting. Everyone is welcome. This week with the Shanghai summit CFP approaching we’d like to kick off the planning for Scientific SIG activities for the summit. Cheers, Stig

1 0

[heat] Resource replacement terminates at DELETE_COMPLETE
by Erik McCormick 25 Jun '19

25 Jun '19

HI everyone! I have a situation with a heat stack where it has an Octavia Load Balancer resource which it thinks it's already replaced and so will not recreate it. Resource api_lb with id 3978 already replaced by 3999; not checking check /var/lib/kolla/venv/lib/python2.7/site-packages/heat/engine/check_resource.py:310 : It goes to a DELETE_COMPLETED state and just sits there. The stack stays UPDATE_IN_PROGRESS and nothing else moves. It doesn't even time out after 4 hours. Doing a stack check puts everytinng as CHECK_COMPLETE, even the non-existent load balancers. I can mark the LB and its components unhealthy and start another update, but this just repeats the cycle. This all started with some Octavia shenanigans which ended with all the load balancers being deleted manually. I have 2 similar stacks which recreated fine, but this one went through the cycle several other times as we were trying to fix the LB problem. This is a super edge case, but hopefully someone has another idea how to get out of it. Thanks! Erik

2 1

[devel] Fast flake8 testing
by Zane Bitter 25 Jun '19

25 Jun '19

Those of you who work on a fairly large project will have noticed that running flake8 over all of it takes some time, and that this slows down development. Nova (at least) has a solution to this, in the form of a "fast8" tox environment that runs flake8 only against the files that have changed in the latest patch + the working directory. This is *much* faster, but that approach has some limitations: the script is buggy, it only tests the top-most patch, it creates a second tox environment (which is slow) that can then get out of sync with your regular pep8 environment, and of course it requires the project to add it explicitly. If you're interested in a solution with none of those limitations, here is a script that I've been using: https://gist.github.com/zaneb/7a8c752bfd97dd8972756d296fc5e41f It tests all changes on the branch, using your existing pep8 tox environment, handles deleted files and changes to non-python files correctly, and should be usable for every OpenStack project. I hope this is helpful to someone. (Note that the pep8 environment on many projects includes other test commands in addition to flake8 - such as bandit - so you should still run the pep8 tox tests once before submitting a patch.) cheers, Zane.

3 2

[magnum] nodegroups
by Bharat Kunwar 25 Jun '19

25 Jun '19

Hi Theodoros, Just replying to your message on IRC here as you appear offline. > if you don't care for what you have in the db i would do this: > - stop both api and conductor > - drop magnum db > - checkout master > - run the migrations (from master) After getting this far, I tried running `magnum-db-manage upgrade` but I hit this: sqlalchemy.exc.InternalError: (pymysql.err.InternalError) (1049, u"Unknown database 'magnum'") (Background on this error at: http://sqlalche.me/e/2j85) > - start the services I can’t start the services either but that is probably due to lack of a database… > - create a cluster > - checkout magnum_nodegroups > - stop services > - run migrations > - start the services > I know it's not great… Would you mind letting me know where I’m going wrong? Thanks Bharat

2 1

How to reduce image size?
by Manuel Sopena Ballesteros 25 Jun '19

25 Jun '19

Dear Openstack community, I would like to reduce the size of an image, I wrote this command: # openstack image set --property size=700000 centos7.6-kudu-image Unable to set 'size' to '700000'. Reason: '700000' is not of type u'null', u'integer' Failed validating u'type' in schema[u'properties'][u'size']: {u'description': u'Size of image file in bytes', u'readOnly': True, u'type': [u'null', u'integer']} On instance[u'size']: '700000' I guess the real issue is u'readOnly': True How can I reduce the image size? Thank you very much Manuel NOTICE Please consider the environment before printing this email. This message and any attachments are intended for the addressee named and may contain legally privileged/confidential/copyright information. If you are not the intended recipient, you should not read, use, disclose, copy or distribute this communication. If you have received this message in error please notify us at once by return email and then delete both messages. We accept no liability for the distribution of viruses or similar in electronic communications. This notice should not be removed.

2 1

[kolla][octavia][openstack-ansible][tripleo] octavia in kolla ansible
by Mark Goddard 25 Jun '19

25 Jun '19

Hi, In the recent kolla meeting [1] we discussed the usability of octavia in kolla ansible. We had feedback at the Denver summit [2] that this service is difficult to deploy and requires a number of manual steps. Certificates are one of the main headaches. It was stated that OSA [3] may have some useful code we could look into. As a starting point to improving this support, I'd like to gather information from people who are using octavia in kolla ansible, and what they have had to do to make it work. Please respond to this email. I've also tagged openstack-ansible and Tripleo - if there is any useful information those teams have to share about this topic, it is most welcome. Alternatively if your support for octavia also falls short perhaps we could collaborate on improvements. Thanks, Mark [1] http://eavesdrop.openstack.org/meetings/kolla/2019/kolla.2019-06-19-15.00.l… [2] https://etherpad.openstack.org/p/DEN-train-kolla-feedback [3] https://opendev.org/openstack/openstack-ansible-os_octavia

7 11

[ironic] To not have meetings?
by Julia Kreger 25 Jun '19

25 Jun '19

Last week the discussion came up of splitting the ironic meeting to alternate time zones as we have increasing numbers of contributors in the Asia/Pacific areas of the world[0]. With that discussion, an additional interesting question came up posing the question of shifting to the mailing list instead of our present IRC meeting[1]? It is definitely an interesting idea, one that I'm personally keen on because of time zones and daylight savings time. I think before we do this, we should collect thoughts and also try to determine how we would pull this off so we don't forget the weekly checkpoint that the meeting serves. I think we need to do something, so I guess now is a good time to provide input into what everyone thinks would be best for the project and facilitating the weekly check-in. What I think might work: By EOD UTC Monday: * Listed primary effort participants will be expected to update the whiteboard[2] weekly before EOD Monday UTC * Contributors propose patches to the whiteboard that they believe would be important for reviewers to examine this coming week. * PTL or designee sends weekly email to the mailing list to start an update thread shortly after EOD Monday UTC or early Tuesday UTC. ** Additional updates, questions, and topical discussion (new features, RFEs) would ideally be wrapped up by EOD UTC Tuesday. With that, I think we would also need to go ahead and begin having "office hours" as during the week we generally know some ironic contributors will be in IRC and able to respond to questions. I think this would initially consist of our meeting time and perhaps the other time that seems to be most friendly to the contributors int he Asia/Pacific area[3]. Thoughts/ideas/suggestions welcome! -Julia [0]: http://eavesdrop.openstack.org/irclogs/%23openstack-ironic/%23openstack-iro… [1]: http://eavesdrop.openstack.org/irclogs/%23openstack-ironic/%23openstack-iro… [2]: https://etherpad.openstack.org/p/IronicWhiteBoard [3]: https://doodle.com/poll/bv9a4qyqy44wiq92

6 5

[neutron] Provider/External Networking
by Jan Marquardt 25 Jun '19

25 Jun '19

Hallo, we have/are planning an Openstack cluster which is supposed to look like this: http://paste.openstack.org/show/753337/ We are currently struggling with the external/provider networks. Is there any way/best practice to terminate the provider networks directly on the network nodes and announce the prefixes through BGP to the upstream routers? Any experience report or hint would really be appreciated. Best regards Jan -- Artfiles New Media GmbH | Zirkusweg 1 | 20359 Hamburg Tel: 040 - 32 02 72 90 | Fax: 040 - 32 02 72 95 E-Mail: support(a)artfiles.de | Web: http://www.artfiles.de Geschäftsführer: Harald Oltmanns | Tim Evers Eingetragen im Handelsregister Hamburg - HRB 81478

2 1

NetApp E-series infiniband support for Cinder
by Grant Morley 24 Jun '19

24 Jun '19

Hi All, Just a quick one to see if anybody knows if there is currently any infiniband support for cinder using a NetApp E-Series SAN. I have had a look at: https://docs.openstack.org/cinder/queens/configuration/block-storage/driver… and: https://docs.openstack.org/cinder/rocky/reference/support-matrix.html They seem to suggest that only iSCSI and FC are supported. I just want to make sure before I start trying to do a POC with the E-series and infiniband. Any advice would be much appreciated. Kind Regards, -- Grant Morley Cloud Lead, Civo Ltd www.civo.com <https://www.civo.com/>| Signup for an account! <https://www.civo.com/signup>

4 5

[neutron] CI issue
by Slawomir Kaplonski 24 Jun '19

24 Jun '19

Hi neutrinos, Since about 2 days we have some problem with iptables_hybrid jobs in Neutron CI. See [1] for details. I’m now trying to find out what can be the problem there but if I will not find it anything soon I will propose temporary patch to skip those 3 failing tests for now. Please don’t recheck Your patches if it failed on those 2 jobs - this will fail again :/ [1] https://bugs.launchpad.net/neutron/+bug/1833902 — Slawek Kaplonski Senior software engineer Red Hat

2 6

Re: https://review.opendev.org/#/c/663089
by Goutham Pacha Ravi 24 Jun '19

24 Jun '19

Hi Helen, On Mon, Jun 24, 2019 at 3:18 AM Walsh, Helen <Helen.Walsh(a)dell.com> wrote: > Hi Ravi, > > A request for information if I may. I will need some direction on how to > generate manila-powermax.inc > > I am not finding anything online > > https://review.opendev.org/#/c/663089 > Thank you for checking. I'm assuming you want to update the file rendered to: https://docs.openstack.org/manila/latest/configuration/shared-file-systems/… Manila currently doesn't have a way to automatically generate these configuration files. Please see associated bug: https://bugs.launchpad.net/manila/+bug/1713062. So for now, you can manually modify those files; we'll look to prioritizing https://bugs.launchpad.net/manila/+bug/1713062. Contributions to add the config option automation would be welcome! Thanks, Goutham > > > Thank you, > > Helen >

1 0

[cinder] ceph multiattach details?
by Bernd Bausch 24 Jun '19

24 Jun '19

The Stein release notes mention that the RBD driver now supports multiattach, but i have not found any details. Are there limitations? Is there a need to configure anything? In the RBD driver <https://opendev.org/openstack/cinder/src/branch/master/cinder/volume/driver…>, I find this: def _enable_multiattach(self, volume): multipath_feature_exclusions = [ self.rbd.RBD_FEATURE_JOURNALING, self.rbd.RBD_FEATURE_FAST_DIFF, self.rbd.RBD_FEATURE_OBJECT_MAP, self.rbd.RBD_FEATURE_EXCLUSIVE_LOCK, ] This seems to mean that journaling and other features (to me, it's not quite clear what they are) will be automatically disabled when switching on multiattachment. Further down in the code I see that replication and multiattach are mutually exclusive. Is there some documentation about the Ceph multiattach feature, even an email thread? Thanks, Bernd ||

6 8

[all] Long overdue cleanups of Zuulv2 compatibility base configs
by Clark Boylan 24 Jun '19

24 Jun '19

As part of our transition to Zuulv3 a year and a half ago, we carried over some compatibility tooling that we would now like to clean up. Specifically, we add a zuul-cloner (which went away in zuulv3) shim and set a global bindep fallback file value in all jobs. Zuulv3 native jobs are expected to use the repos zuul has precloned for you (no zuul-cloner required) as well as supply an in repo bindep.txt (or specify a bindep.txt path or install packages via some other method). This means that we should be able to remove both of these items from the non legacy base job in OpenDev's zuul. The legacy base job will continue to carry these for you so that you can write new native jobs over time. We have two changes [0][1] ready to go for this; however, due to the potential for disruption we would like to give everyone some time to test and prepare for this change. Fungi has a change to base-test [2] which will remove the zuul-cloner shim. Once this is in you can push "Do Not Merge" changes to your zuul config that reparent your tests from "base" to "base-test" and that will run the jobs without the zuul-cloner shim. Testing the bindep fallback removal is a bit more difficult as we set that in zuul's server config globally. What you can do is check your jobs' job-output.txt log files for usage of "bindep-fallback.txt". Our current plan is to merge these changes on June 24, 2019. We will be around to help debug any unexpected issues that come up. Jobs can be updated to use the "legacy-base" base job instead of the "base" base job if they need to be reverted to the old behavior quickly. Finally, Fungi did some excellent spelunking through history to understand how we got here. If you are curious you can find more details at: http://lists.openstack.org/pipermail/openstack-discuss/2019-June/006881.html. [0] https://review.opendev.org/656195 [1] https://review.opendev.org/663151 [2] https://review.opendev.org/663135 Clark

3 4

[Watcher] team meeting and agenda
by li.canwei2＠zte.com.cn 24 Jun '19

24 Jun '19

Hi, Watcher will have a meeting at 08:00 UTC today in the #openstack-meeting-alt channel. The agenda is available on https://wiki.openstack.org/wiki/Watcher_Meeting_Agenda feel free to add any additional items. Thanks! Canwei Li

2 1

[designate] DKIM TXT record problem
by Ionut Biru 24 Jun '19

24 Jun '19

Hello guys, I'm running Rocky and as backend for designate I have powerdns. Whenever I try to add a TXT record for DKIM, the API returns that the specified record is not a TXT record. https://paste.xinu.at/OOz7/ It seems that is due to the length of the record It has a maxim a 255 limit. How should I proceed in this case? -- Ionut Biru - https://fleio.com

2 2

[Watcher] about inactive core members
by li.canwei2＠zte.com.cn 23 Jun '19

23 Jun '19

Hi Watcher team, Last week in the Watcher IRC meeting we discussed to remove inactive core members. It's welcome if you can take some time to review, and I wish you can reply before the end of this week if you want to get back. Best Regards, Canwei Li

1 0

Openstack cinder HA
by Md. Farhad Hasan Khan 22 Jun '19

22 Jun '19

Hi, In my environment openstack volume service running on compute node. When the openstack-cinder-volume service goes down on, the Block Storage volumes which were created using the openstack-cinder-volume service cannot be managed until the service comes up again. I need help how to configure openstack cinder volume HA. Thanks & B'Rgds, Rony

2 4

[neutron] bug deputy report for the week of June 17th
by Takashi Yamamoto 22 Jun '19

22 Jun '19

hi, this week i have looked at the following bugs. a few of them still need triage. i will have a travel tomorrow and i'm not sure if i will have time to triage them. i don't think i can attend the team meeting next week. (sorry!) Still need triage: https://bugs.launchpad.net/neutron/+bug/1833175 pptp vpn doesn't work with openvswitch firewall https://bugs.launchpad.net/neutron/+bug/1833156 neutron fwaas v2 log function does not work https://bugs.launchpad.net/neutron/+bug/1832636 Error creating IPv6 subnet on routed network segment High: https://bugs.launchpad.net/neutron/+bug/1833257 By default Horizon sets Firewall group admin state to False when user trying to set it true Firewall always remains in DOWN state Medium: https://bugs.launchpad.net/neutron/+bug/1833279 TestNeutronServer: start function not called (or not logged in the temp file) https://bugs.launchpad.net/neutron/+bug/1833653 We should cleanup ipv4 address if keepalived is dead https://bugs.launchpad.net/neutron/+bug/1833589 neutron-dynamic-routing broken by introduction of agent_timestamp to _log_heartbeat() https://bugs.launchpad.net/neutron/+bug/1833721 ip_lib synchronized decorator should wrap the privileged one Low: https://bugs.launchpad.net/neutron/+bug/1833125 Remaining neutron-lbaas relevant code and documentation RFE: https://bugs.launchpad.net/neutron/+bug/1832758 [RFE] Allow/deny custom ethertypes in security groups https://bugs.launchpad.net/neutron/+bug/1833674 [RFE] Improve profiling of port binding and vif plugging

1 0

[keystone] Keystone Team Update - Week of 17 June 2019
by Colleen Murphy 21 Jun '19

21 Jun '19

# Keystone Team Update - Week of 17 June 2019 ## News ### Next steps for oslo.limit In order to make progress on having a usable interface for oslo.limit, we discussed[1][2] simplifying the current implementation. Lance has some patches[3] that remove the ideas of claims and context managers, which sacrifices the risk of race conditions and performance penalties in favor of simplicity for the time being. [1] http://eavesdrop.openstack.org/meetings/keystone/2019/keystone.2019-06-18-1… [2] http://eavesdrop.openstack.org/irclogs/%23openstack-keystone/%23openstack-k… [3] https://review.opendev.org/665708 ## Open Specs Train specs: https://bit.ly/2uZ2tRl Ongoing specs: https://bit.ly/2OyDLTh Train specs need to be merged by July 26. Please help review these specs and be mindful of feedback. ## Recently Merged Changes Search query: https://bit.ly/2pquOwT We merged 20 changes this week. ## Changes that need Attention Search query: https://bit.ly/2tymTje There are 44 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. ## Bugs This week we opened 6 new bugs and closed 5. Bugs opened (6) Bug #1833085 (keystone:High) opened by Sebastian Riese https://bugs.launchpad.net/keystone/+bug/1833085 Bug #1833739 (keystone:High) opened by David Orman https://bugs.launchpad.net/keystone/+bug/1833739 Bug #1833311 (keystone:Undecided) opened by Michael Carpenter https://bugs.launchpad.net/keystone/+bug/1833311 Bug #1833340 (keystone:Undecided) opened by cnaik https://bugs.launchpad.net/keystone/+bug/1833340 Bug #1833554 (keystone:Undecided) opened by Chason Chan https://bugs.launchpad.net/keystone/+bug/1833554 Bug #1833207 (keystoneauth:Undecided) opened by Jagatjot Singh https://bugs.launchpad.net/keystoneauth/+bug/1833207 Bugs closed (2) Bug #1832005 (keystone:Undecided) https://bugs.launchpad.net/keystone/+bug/1832005 Bug #1833340 (keystone:Undecided) https://bugs.launchpad.net/keystone/+bug/1833340 Bugs fixed (3) Bug #1750676 (keystone:High) fixed by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1750676 Bug #1818844 (keystone:Medium) fixed by Lance Bragstad https://bugs.launchpad.net/keystone/+bug/1818844 Bug #1649735 (keystonemiddleware:Medium) fixed by Colleen Murphy https://bugs.launchpad.net/keystonemiddleware/+bug/1649735 ## Milestone Outlook https://releases.openstack.org/train/schedule.html Milestone 2 is in 5 weeks. Train specs need to be merged by then. Feature proposal freeze is in 8 weeks. ## Shout-outs Shout out to Nathan Oyler, whose first patch to OpenStack[4] fixed a major omission in our audit notifications. Thanks, Nathan! [4] https://review.opendev.org/664618 ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter

1 0

[goal][python3] Train unit tests weekly update (goal-12)
by Corey Bryant 21 Jun '19

21 Jun '19

This is the goal-12 weekly update for the "Update Python 3 test runtimes for Train" goal [1]. There are 12 weeks remaining for completion of Train community goals [2]. == What's the Goal? == To ensure (in the Train cycle) that all official OpenStack repositories with Python 3 unit tests are exclusively using the 'openstack-python3-train-jobs' Zuul template or one of its variants (e.g. 'openstack-python3-train-jobs-neutron') to run unit tests, and that tests are passing. This will ensure that all official projects are running py36 and py37 unit tests in Train. For complete details please see [1]. == Ongoing Work == I've submitted patch automation scripts for review: https://review.opendev.org/#/c/666934 And I've started submitting patches that were generated using the above scripts. Open patches needing reviews: https://review.openstack.org/#/q/topic:python3-train+is:open Failing patches: https://review.openstack.org/#/q/topic:python3-train+status:open+(+label:Ve… Some notes on 2 issues I came across this week: 1) Some projects that have a valid reason to keep old tox.ini py3 environments or setup.cfg classifiers. For example, the OpenStack Charms project is a deployment project that still supports deployments on xenial, and keeping the py35 environment in tox.ini makes sense. In scenarios like this I plan to continue with the Zuul switch to openstack-python3-train-jobs without removing py35 tox.ini or Python 3.5 classifier from setup.cfg. 2) Some projects are missing Zuul config. Not to pick on any projects in particular but as an example there are projects that I'd expect to have .zuul.yaml or equivalent, such as python-adjutant, however it doesn't. In scenarios like this I plan to skip the project entirely. == Completed Work == Merged patches: https://review.openstack.org/#/q/topic:python3-train+is:merged == How can you help? == Please take a look at the failing patches and help fix any failing unit tests for your project(s). Python 3.7 unit tests will be self-testing in Zuul. If you're interested in helping submit patches, please let me know. == Reference Material == [1] Goal description: https://governance.openstack.org/tc/goals /train/python3-updates.html [2] Train release schedule: https://releases.openstack.org/train/schedule.html (see R-5 for "Train Community Goals Completed") Storyboard: https://storyboard.openstack.org/#!/story/2005924 Porting to Python 3.7: https://docs.python.org/3/whatsnew/3.7.html#porting-to-python-3-7 Python Update Process: https://opendev.org/openstack/governance/src/branch/master/resolutions/2018… Train runtimes: https://opendev.org/openstack/governance/src/branch/master/reference/runtim… Thanks, Corey

1 0

[ThirdParty][CI] : CI-watch is not updating with latest patchset
by Sharma, Virendra Sharma 21 Jun '19

21 Jun '19

Hi Team, >From last few days unable to see latest patch set entry in CI-WATCH (http://ciwatch.mmedvede.net/project?project=cinder&time=7+days) However third party CI running on latest patch set and reporting its vote to Gerrit accordingly. Currently it is visible for last 7 days but soon it will also go off, if it won't reflect updated one. Please help me to understand if any update regarding this or else provide way to get it resolved from my end. Regards, Virendra

2 1

[openstack-operators][neutron][olso.db] connection pool configuration
by Arnaud Morin 21 Jun '19

21 Jun '19

Hey all, I am wondering what configuration the operators in this mailing list are using in [oslo.db] section. For example, the max_pool_size default value is 5, which seems very low to me (our deployment is having more than 1000 neutron agents). So, is there any recommendation somewhere for those settings? Thanks for any tip. -- Arnaud Morin

1 0

[placement] update 19-24
by Chris Dent 21 Jun '19

21 Jun '19

HTML: https://anticdent.org/placement-update-19-24.html Here's a 19-24 pupdate. Last week I said there wouldn't be one this week. I was wrong. There won't be one next week. I'm taking the week off to reset (I hope). I've tried to make sure that there's nothing floating about in Placement land that is blocking on me. # Most Important The [spec for nested magic](https://review.opendev.org/662191) is close. What it needs now is review from people outside the regulars to make sure it doesn't suffer from tunnel vision. The features discussed form the foundation for Placement being able to service queries for real world uses of nested providers. Placement can already model nested providers but asking for the right one has needed some work. # Editorial I read an article this morning which touches on the importance of considering [cognitive load in software design](https://techbeacon.com/app-dev-testing/forget-monoliths-vs-microser…. It's fully of glittering generalities, but it reminds me of some of the reasons why it was important to keep a solid boundary between Nova and Placement and why, now that Placement is extracted, the complexity of this nested magic is something we need to measure against the cognitive load it will induce in the people who come after us as developers and users. # What's Changed * Support for mappings in allocation candidates has merged as [microversion 1.34](https://docs.openstack.org/placement/latest/placement-api-microversio…. * Gibi made it so [OSProfiler](https://docs.openstack.org/osprofiler/latest/) works with placement again. # Specs/Features * <https://review.opendev.org/654799> Support Consumer Types. This has some open questions that need to be addressed, but we're still go on the general idea. * <https://review.opendev.org/662191> Spec for nested magic 1. See "Most Important" above. Some non-placement specs are listed in the Other section below. # Stories/Bugs (Numbers in () are the change since the last pupdate.) There are 23 (3) stories in [the placement group](https://storyboard.openstack.org/#!/project_group/placement). 0 (0) are [untagged](https://storyboard.openstack.org/#!/worklist/580). 4 (1) are [bugs](https://storyboard.openstack.org/#!/worklist/574). 5 (-1) are [cleanups](https://storyboard.openstack.org/#!/worklist/575). 11 (0) are [rfes](https://storyboard.openstack.org/#!/worklist/594). 3 (1) are [docs](https://storyboard.openstack.org/#!/worklist/637). If you're interested in helping out with placement, those stories are good places to look. * Placement related nova [bugs not yet in progress](https://goo.gl/TgiPXb) on launchpad: 16 (0). * Placement related nova [in progress bugs](https://goo.gl/vzGGDQ) on launchpad: 5 (-1). [1832814: Placement API appears to have issues when compute host replaced](https://bugs.launchpad.net/nova/+bug/1832814) is an interesting bug. In a switch from RDO to OSA, resource providers are being duplicated because of a change in node name. # osc-placement osc-placement is currently behind by 11 microversions. * <https://review.opendev.org/666542> Add support for multiple member_of. # Main Themes ## Nested Magic The overview of the features encapsulated by the term "nested magic" are in a [story](https://storyboard.openstack.org/#!/story/2005575) and [spec](https://review.opendev.org/662191). Code related to this: * <https://review.opendev.org/663009> PoC: resourceless request, including some code from <https://review.opendev.org/657510> WIP: Allow RequestGroups without resources * <https://review.opendev.org/#/q/topic:story/2005575-33753> Support for the new root_required query parameter. Introduces the useful concepts of required wide params and a request wide search context. ## Consumer Types Adding a type to consumers will allow them to be grouped for various purposes, including quota accounting. A [spec](https://review.opendev.org/654799) has started. There are some questions about request and response details that need to be resolved, but the overall concept is sound. ## Cleanup We continue to do cleanup work to lay in reasonable foundations for the nested work above. As a nice bonus, we keep eking out additional performance gains too. * <https://review.opendev.org/#/q/topic:story/2005443> Add a nested-perfload job, using gabbi to create the trees. Unsurprisingly, nested topologies are slower than non; having this job will help us track that. # Other Placement Miscellaneous changes can be found in [the usual place](https://review.opendev.org/#/q/project:openstack/placement+status:op…. There are five [os-traits changes](https://review.opendev.org/#/q/project:openstack/os-traits+status:… being discussed. And one [os-resource-classes change](https://review.opendev.org/#/q/project:openstack/os-resource-classe…. # Other Service Users New discoveries are added to the end. Merged stuff is removed. Anything that has had no activity in 4 weeks has been removed. * <https://review.openstack.org/601596> Nova: spec: support virtual persistent memory * <https://review.openstack.org/#/q/topic:bug/1819923> Nova: nova-manage: heal port allocations * <https://review.openstack.org/650188> nova-spec: Allow compute nodes to use DISK_GB from shared storage RP * <https://review.opendev.org/659233> Cyborg: Placement report * <https://review.opendev.org/657801> rpm-packaging: placement service * <https://review.opendev.org/662229> helm: WIP: add placement chart * <https://review.opendev.org/662164> kolla-ansible: Add a explanatory note for "placement_api_port" * <https://review.opendev.org/656023> Nova: Use OpenStack SDK for placement * <https://review.opendev.org/612497> Nova: Spec: Provider config YAML file * <https://review.opendev.org/623558> Nova: single pass instance info fetch in host manager * <https://review.opendev.org/634551> libvirt: report pmem namespaces resources by provider tree * <https://review.opendev.org/660852> Nova: Remove PlacementAPIConnectFailure handling from AggregateAPI * <https://review.opendev.org/#/q/topic:bp/support-move-ops-with-qos-ports> Nova: support move ops with qos ports * <https://review.opendev.org/665168> TripleO: Enable Request Filter for Image Types * <https://review.opendev.org/664689> Nova: get_ksa_adapter: nix by-service-type confgrp hack * <https://review.opendev.org/664862> OSA: Add nova placement to placement migration * <https://review.opendev.org/657796> Nova: Defaults missing group_policy to 'none' * <https://review.opendev.org/666202> Blazar: Create placement client for each request * <https://review.opendev.org/666298> OSA: Fix aio_distro_metal jobs for openSUSE # End Go outside. Reflect a bit. Then do. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent

1 0

[Security SIG] Weekly Newsletter June 13th & June 20th
by Gage Hugo 20 Jun '19

20 Jun '19

So I wrote the newsletter for last week, but forgot to send out the actual email, so this week will have double the content! #Week of: 20 June 2019 - Security SIG Meeting Info: http://eavesdrop.openstack.org/#Security_SIG_meeting - Weekly on Thursday at 1500 UTC in #openstack-meeting - Agenda: https://etherpad.openstack.org/p/security-agenda - https://security.openstack.org/ - https://wiki.openstack.org/wiki/Security-SIG #Meeting Notes - Summary: http://eavesdrop.openstack.org/meetings/security/2019/security.2019-06-20-1… - This week we discussed cleaning up the security.openstack.org page - Overall there are many outdated sections, we came up with a current rough plan that is outlined in the security-agenda notes for this week's meeting - Retiring Syntribos - On the topic of cleaning up the security.openstack.org page, one section is security tools, which currently lists bandit and syntribos. - Looking at the Syntribos repo, it seems like lately there's only been changes related to doc fixes and overall zuul updates, with a couple actual updates to the project. - If there's anyone still with interest in updating/using Syntribos, please reach out to us. ## News - [nova] TPM thread: http://lists.openstack.org/pipermail/openstack-discuss/2019-June/007258.html # VMT Reports - A full list of publicly marked security issues can be found here: https://bugs.launchpad.net/ossa/ - No new public security bugs this week ======================================================================================================== #Week of: 13 June 2019 - Security SIG Meeting Info: http://eavesdrop.openstack.org/#Security_SIG_meeting - Weekly on Thursday at 1500 UTC in #openstack-meeting - Agenda: https://etherpad.openstack.org/p/security-agenda - https://security.openstack.org/ - https://wiki.openstack.org/wiki/Security-SIG #Meeting Notes - Summary: http://eavesdrop.openstack.org/meetings/security/2019/security.2019-06-13-1… - This week we finalized the details and settings for the [openstack-security] mailing list. The list will be used to provide purely automated notifications about security-related changes and bug reports within OpenStack. Anyone looking to reach out to the security SIG can either use the [openstack-discuss] mailing list or use the #openstack-security channel on freenode IRC. ## News - Storyboard: The security team autoassignment feature landed - If a new story is marked as "security" upon creation, it will automatically become private, however it can be edited to become public after it is created. # VMT Reports - A full list of publicly marked security issues can be found here: https://bugs.launchpad.net/ossa/ - No new public security bugs this week

1 0

[nova]Bug #1829696: qemu-kvm process takes 100% CPU usage when running redhat/centos 7.6 guest OS
by 钱熙 20 Jun '19

20 Jun '19

Hi there, I am struggling with qemu-kvm 100% CPU usage problem. When running redhat or centos 7.6 guest os on vm, the cpu usage is very low on vm(almost 100% idle when no tasks run), but on the host, qemu-kvm reports 100% cpu busy usage. https://bugs.launchpad.net/nova/+bug/1829696 I opened the bug above, however it did not find some interest. After searching some related bugs report, I suspect that it is due to the clock settings in vm's domain xml. My settings are as follows: <clock offset='utc'> <timer name='rtc' tickpolicy='catchup'/> <timer name='pit' tickpolicy='delay'/> <timer name='hpet' present='no'/> </clock> And details about the bug, please see https://bugs.launchpad.net/nova/+bug/1829696 It shows that only the version 7.6 of redhat or centos affected by this bug behavior. In my cluster, it is OK for versions from redhat or centos 6.8 to 7.5. Any clue or suggestion? ------------------ Thanks a lot! Best regards QianXi

2 1

[nova] API updates week 19-25
by Ghanshyam Mann 20 Jun '19

20 Jun '19

Hi All, Please find the Nova API updates of this week. API Related BP : ============ Code Ready for Review: ------------------------------ 1. Support adding description while locking an instance: - Topic: https://review.opendev.org/#/q/topic:bp/add-locked-reason+(status:open+OR+s… - Weekly Progress: OSC patch has been updated by tssurya. mriedem is +1. 2. Add host and hypervisor_hostname flag to create server - Topic: https://review.opendev.org/#/q/topic:bp/add-host-and-hypervisor-hostname-fl… - Weekly Progress: patch is updated with review comment. ready for re-review. 3. Specifying az when restore shelved server - Spec: https://review.opendev.org/#/q/topic:bp/support-specifying-az-when-restore-… - Weekly Progress: Spec is merged and code is up for review. 4. Nova API cleanup - Spec: https://review.openstack.org/#/c/603969/ - Weekly Progress: working on code, seems like a lot of tests changes. Should be able to push code by next report. 5. Detach and attach boot volumes: - Topic: https://review.openstack.org/#/q/topic:bp/detach-boot-volume+(status:open+O… - Weekly Progress: No Progress Spec Ready for Review: ----------------------------- 1. Nova API policy improvement - Spec: https://review.openstack.org/#/c/547850/ - PoC: https://review.openstack.org/#/q/topic:bp/policy-default-refresh+(status:op… - Weekly Progress: Under review and updates. 2. Support for changing deleted_on_termination after boot -Spec: https://review.openstack.org/#/c/580336/ - Weekly Progress: No update this week. 3. Support delete_on_termination in volume attach api -Spec: https://review.openstack.org/#/c/612949/ - Weekly Progress: No updates this week. 4. Add API ref guideline for body text - ~8 api-ref are left to fix. Previously approved Spec needs to be re-proposed for Train: --------------------------------------------------------------------------- 1. Servers Ips non-unique network names : - https://blueprints.launchpad.net/nova/+spec/servers-ips-non-unique-network-… - https://review.openstack.org/#/q/topic:bp/servers-ips-non-unique-network-na… 2. Volume multiattach enhancements: - https://blueprints.launchpad.net/nova/+spec/volume-multiattach-enhancements - https://review.openstack.org/#/q/topic:bp/volume-multiattach-enhancements+(… Bugs: ==== No progress report in this week. NOTE- There might be some bug which is not tagged as 'api' or 'api-ref', those are not in the above list. Tag such bugs so that we can keep our eyes. -gmann

1 0

[sigs][publiccloud][publiccloud-wg][publiccloud-sig][billing] Cancellation todays meeting for the Public Cloud SIG
by Tobias Rydberg 20 Jun '19

20 Jun '19

Hi all, Unfortunate I need to cancel today meeting for the Public Cloud SIG since I can't manage to make it. Feel free to use the time if you will to continue our ongoing discussions regarding the billing initiative. I'm happy to schedule a meeting next week at the same time, please respond to this email or drop a message in the channel if that i suitable for you. I also want to bring the new User Survey to attention to you all if you have missed that and haven't taken it. Please also spread the word to fellow colleagues, customers and what not. URL to survey: https://www.openstack.org/user-survey/survey-2019/ Cheers, Tobias -- Tobias Rydberg Senior Developer Twitter & IRC: tobberydberg www.citynetwork.eu | www.citycloud.com INNOVATION THROUGH OPEN IT INFRASTRUCTURE ISO 9001, 14001, 27001, 27015 & 27018 CERTIFIED

1 0

[placement][docs][packaging] rpm- and deb- related placement install docs
by Chris Dent 20 Jun '19

20 Jun '19

The placement install docs [1] have the following warning plastered on top: These installation documents are a work in progress. Some of the distribution packages mentioned are not yet available so the instructions will not work. It is likely that packages are now available, but the docs have not been updated to reflect that, nor have the docs been verified against those packages. None of the regular and active contributors to placement are involved with distro-related packaging. In addition they are all already fully booked. Are there members of the community who are involved with the distros, and who can update and verify these docs? If not, we will likely need to remove the distro related install documents before the end of the Train release and solely maintain the install-from-pypi docs [2] (which are up to date). This is because the existing docs are now misleading, and thus potentially dangerous and extra-work-inducing, as suggested by a recent bug [3]. If you are interested in helping out, please follow up. If you're unable to help out, but know people involved with packaging who should know about this concern, please let them know. Thanks for your help. [1] https://docs.openstack.org/placement/latest/install/index.htmlk [2] https://docs.openstack.org/placement/latest/install/from-pypi.html [3] https://storyboard.openstack.org/#!/story/2005910 -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent

4 3