- openstack-discuss - lists.openstack.org

[placement] update 19-26
by Chris Dent 05 Jul '19

05 Jul '19

HTML: https://anticdent.org/placement-update-19-26.html Pupdate 19-26. Next week is R-15, two weeks until Train milestone 2. # Most Important The [spec for nested magic](https://docs.openstack.org/placement/latest/specs/train/approved/200… merged and significant progress has been made in the implementation. That work is nearly ready to merge (see below), after a few more reviews. Once that happens one of our most important tasks will be experimenting with that code to make sure it fully addresses the uses cases, has proper documentation (including "how do I use this?"), and is properly evaluated for performance and maintainability. # What's Changed * The implementation for mappings in allocation candidates had a bug which Eric [found](https://review.opendev.org/668302) and fixed and then I realized there was a [tidier way to do it](https://review.opendev.org/668724). This then led to the `same_subtree` work needing to manage less information, because it was already there. * The spec for [Consumer Types](https://docs.openstack.org/placement/latest/specs/train/approved/200… merged and work [has started](https://review.opendev.org/669170). * We're using os-traits 0.15.0 now. * There's a [framework in place](https://review.opendev.org/665695) for nested resource provider peformance testing. We need to update the provider topology to reflect real world situations (more on that below). * The `root_required` query parameter on `GET /allocation_candidates` has been merged as [microversion 1.35](https://docs.openstack.org/placement/latest/placement-api-microversio…. * I've sent [an email](http://lists.openstack.org/pipermail/openstack-discuss/2019-July/007… announcing my intent to not go to the Shangai (or any other) summit, and what changes that could imply for how Placement does the PTG. # Specs/Features All placement specs have merged. Thanks to everyone for the frequent reviews and quick followups. We've been maintaining some good velocity. 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). 2 (-2) are [bugs](https://storyboard.openstack.org/#!/worklist/574). 5 (0) are [cleanups](https://storyboard.openstack.org/#!/worklist/575). 11 (0) are [rfes](https://storyboard.openstack.org/#!/worklist/594). 4 (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: 4 (-1). # 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 These are the features required by modern nested resource provider use cases. We've merged mappings in allocation candidates and `root_required`. `same_subtree` and resourceless request groups are what's left and they are in: * <https://review.opendev.org/668376> Support `same_subtree` queryparam ## Consumer Types Adding a type to consumers will allow them to be grouped for various purposes, including quota accounting. * <https://review.opendev.org/#/q/topic:bp/support-consumer-types> ## Cleanup Cleanup is an overarching theme related to improving documentation, performance and the maintainability of the code. The changes we are making this cycle are fairly complex to use and are fairly complex to write, so it is good that we're going to have plenty of time to clean and clarify all these things. As mentioned above, one of the important cleanup tasks that is not yet in progress is updating the [gabbit](https://opendev.org/openstack/placement/src/branch/master/gate/gabb… that creates the nested topology that's used in nested performance testing. The topology there is simple, unrealistic, and doesn't sufficiently exercise the several features that may be used during a query that desires a nested response. Recently I've been seeing that the `placement-perfload` job is giving results that vary between `N` and `N*2` (usually .5 and 1 seconds) and the difference that I can discern is the type of CPUs being presented by the host (same number of CPUs (8) but different type). This supports something we've been theorizing for a while: when dealing with large result sets we are CPU bound processing the several large result sets returned by the database. Further profiling required… Another cleanup that needs to start is satisfying the community wide goal of [PDF doc generation](https://storyboard.openstack.org/#!/story/2006110). # Other Placement Miscellaneous changes can be found in [the usual place](https://review.opendev.org/#/q/project:openstack/placement+status:op…. There are three [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/#/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/662229> helm: WIP: add placement chart * <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/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/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/668930> tempest: Define the Integrated-gate-networking gate template * <https://review.opendev.org/669309> tempest: Define the Integrated-gate-placement gate template * <https://review.opendev.org/668263> Nova: Restore RT.old_resources if ComputeNode.save() fails * <https://review.opendev.org/669188> Remove assumption of http error if consumer not exists * <https://review.opendev.org/669253> TripleO: Add new parameter NovaSchedulerLimitTenantsToPlacementAggregate * <https://review.opendev.org/669252> puppet-nova: Expose limit_tenants_to_placement_aggregate parameter * <https://review.opendev.org/667952> nova: Support filtering of hosts by forbidden aggregates * <https://review.opendev.org/669079> blazar: Send global_request_id for tracing calls * <https://review.opendev.org/667417> nova: Implement update_provider_tree for hyperv * <https://review.opendev.org/668639> watcher: Improve Compute Data Model * <https://review.opendev.org/#/q/topic:bp/pre-filter-disabled-computes> Nova: pre filter disable computes * <https://review.opendev.org/668252> Nova: Update HostState.\*\_allocation_ratio earlier # End This space left intentionally blank. -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent

1 0

[Mistral] Guaranteed notification delivery
by Лапин Артем 05 Jul '19

05 Jul '19

Good day, please look at https://blueprints.launchpad.net/mistral/+spec/guaranteed-notifies. I would like to know your opinion about this feature.

1 0

[horizon] PTL on vacation
by Ivan Kolodyazhny 05 Jul '19

05 Jul '19

Hi team, I'll be on a vacation until July, 19th with a very limited internet connection. During the last weekly meeting [1] we agreed to skip the next two. I'll try to check my mail during the PTO but for any issues, I recommend to ask our great core team [2] via emails or IRC. [1] http://eavesdrop.openstack.org/meetings/horizon/2019/horizon.2019-07-03-15.… [2] https://review.opendev.org/#/admin/groups/43,members Regards, Ivan Kolodyazhny, http://blog.e0ne.info/

1 0

[kolla] Proposing yoctozepto as core
by Mark Goddard 05 Jul '19

05 Jul '19

Hi, I would like to propose adding Radosław Piliszek (yoctozepto) to kolla-core and kolla-ansible-core. While he has only recently started working upstream in the project, I feel that he has made some valuable contributions already, particularly around improving and maintaining CI. His reviews generally provide useful feedback, sometimes in advance of Zuul! Core team - please vote, and consider this my +1. I will keep this vote open for a week or until all cores have responded. Cheers, Mark

5 5

[kolla][kayobe] vote: kayobe as a kolla deliverable
by Mark Goddard 05 Jul '19

05 Jul '19

Hi, In the most recent kolla meeting [1] we discussed the possibility of kayobe becoming a deliverable of the kolla project. This follows on from discussion at the PTG and then on here [3]. The two options discussed are: 1. become a deliverable of the Kolla project 2. become an official top level OpenStack project There has been some positive feedback about option 1 and no negative feedback that I am aware of. I would therefore like to ask the kolla community to vote on whether to include kayobe as a deliverable of the kolla project. The electorate is the kolla-core and kolla-ansible core teams, excluding me. The opinion of others in the community is also welcome. If you have questions or feedback, please respond to this email. Once you have made a decision, please respond with your answer to the following question: "Should kayobe become a deliverable of the kolla project?" (yes/no) Thanks, Mark [1] http://eavesdrop.openstack.org/meetings/kolla/2019/kolla.2019-06-19-15.00.l… [2] https://etherpad.openstack.org/p/kolla-train-ptg [3] http://lists.openstack.org/pipermail/openstack-discuss/2019-June/006901.html

4 6

[horizon] Unable to boot instance from volume if image size doesn't fit in flavor root disk size
by Krzysztof Klimonda 04 Jul '19

04 Jul '19

Hi, In order to avoid creating spurious flavors just to match image size requirements, I’d like to be able to spawn instances from volume even if the flavor disk is too small - this is possible via CLI/API but Horizon doesn’t let me launch the instance unless either flavor root disk is sized correctly, or the root disk size is 0(?). Is that a bug in Horizon, or is there something that I’m missing? Regards, -Chris

2 1

[placement] [tc] PTL not going to summit?
by Chris Dent 04 Jul '19

04 Jul '19

I've decided [1] that I'm going to resist going to tech conferences and summits in particular by air travel, unless it becomes an existential issue. For a variety of reasons described in [1] and the two other posts it links to. I know for some people that this will present some concerns about my efficacy as PTL of placement, so I thought I better mention it sooner than later so we can make some decisions on how we want to proceed: * Should I take myself out of the running for U PTL? In which case we need to get a shadow warmed up. * If I'm not there, but still PTL, should we still hold the usual regularly placement things (project update and onboarding, PTG things)? In which case we need to prepare chairs/moderators for those sessions. Given my positions on the exclusive properties of conferences, I'd prefer that we turn update and onboarding activities into asynchronous, document-oriented affairs that anyone can utilize at any time, not just those wanting and able to go to summit. Similarly, given how useful the placement pre-PTG was for Train, the very small amount of time spent discussing placement issues in person in Denver, and the team's strategy of focusing on a relatively small number of changes, I'm not certain we need "time" in Shanghai. We can spread that work out. Thoughts or questions from anyone? [1] https://anticdent.org/remote-maintainership.html -- Chris Dent ٩◔̯◔۶ https://anticdent.org/ freenode: cdent

5 4

[Glance] No meeting today 4th of July
by Erno Kuvaja 04 Jul '19

04 Jul '19

Hi all, We had no proposed agenda for today so Happy Independence Day for all our American fellows and we will have meeting again next Thu the 11th. Best, Erno jokke Kuvaja

1 0

[magnum][queens] kume master error in clout-init-output.log
by Ignazio Cassano 04 Jul '19

04 Jul '19

Hi All, I 've just installed openstack kolla queens and wen I try to run a kubernetes cluster, the master node reports the following in the cloud init log file: Cloud-init v. 0.7.9 running 'modules:config' at Wed, 03 Jul 2019 18:57:19 +0000. Up 20.40 seconds. + CA_FILE=/etc/pki/ca-trust/source/anchors/openstack-ca.pem + '[' -n '' ']' /var/lib/cloud/instance/scripts/part-007: line 57: /etc/etcd/etcd.conf: No such file or directory /var/lib/cloud/instance/scripts/part-007: line 70: /etc/etcd/etcd.conf: No such file or directory /var/lib/cloud/instance/scripts/part-007: line 86: /etc/etcd/etcd.conf: No such file or directory Cloud-init v. 0.7.9 running 'modules:final' at Wed, 03 Jul 2019 18:57:21 +0000. Up 21.93 seconds. 2019-07-03 18:59:23,121 - util.py[WARNING]: Failed running /var/lib/cloud/instance/scripts/part-007 [1] The image I am using is suggested in the openstack documentation: $ wget https://download.fedoraproject.org/pub/alt/atomic/stable/Fedora-Atomic-27-2… The volume driver is cinder and the docker storage driver is overlay. The docker volume size is 5 GB and THE VOLUME SIZE OF THE FLAVOR IS 20gb. Seems image is missing some packeages :-( Anyone could help me, please ? Ignazio

3 6

[neutron][ci] Gate broken
by Slawek Kaplonski 04 Jul '19

04 Jul '19

Hi, Currently we have broken our functional and fullstack jobs due to patch [1] merged in Devstack. So functional and fullstack jobs are finishing with RETRY_LIMIT now. Fix is already proposed in [2]. So if Your patch failed on those jobs now, please don’t recheck it until [2] will be merged. [1] https://review.opendev.org/#/c/619562/ [2] https://review.opendev.org/#/c/669067/ — Slawek Kaplonski Senior software engineer Red Hat

1 1

[Mistral] PTL is on vacation till July 17
by Renat Akhmerov 04 Jul '19

04 Jul '19

Hi, Just letting you know that I’ll be on vacation till July 17. With all the urgent requests/issue please contact Dougal Matthews (d0gal), Oleg Ovcharuk (vgoleg) or Adriano Petrich (apetrich). Thanks Renat Akhmerov @Nokia

1 0

reply: [lists.openstack.org][nova] API updates week 19-26
by Brin Zhang(张百林) 04 Jul '19

04 Jul '19

> Spec Ready for Review: 5. Add flavor group https://review.opendev.org/#/c/663563/ Brin Zhang Hello Everyone, Please find the Nova API updates of this week. API Related BP : ============ COMPLETED: 1. Support adding description while locking an instance: - https://blueprints.launchpad.net/nova/+spec/add-locked-reason Code Ready for Review: ------------------------------ 1. Add host and hypervisor_hostname flag to create server - Topic: https://review.opendev.org/#/q/topic:bp/add-host-and-hypervisor-hostname-fla g-to-create-server+(status:open+OR+status:merged) - Weekly Progress: patch is updated with review comment. ready for re-review. I will re-review it tomorrow. 2. Specifying az when restore shelved server - Topic: https://review.opendev.org/#/q/topic:bp/support-specifying-az-when-restore-s helved-server+(status:open+OR+status:merged) - Weekly Progress: Review comments is fixed and ready to re-review. 3. Nova API cleanup - Topic: https://review.opendev.org/#/c/666889/ - Weekly Progress: Code is up for review. A lot of files changed but should be ok to review. I have pushed a couple of patches for missing tests of previous microversions. 4. Detach and attach boot volumes: - Topic: https://review.openstack.org/#/q/topic:bp/detach-boot-volume+(status:open+OR +status:merged) - 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:ope n+OR+status:merged) - 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-n ames - https://review.openstack.org/#/q/topic:bp/servers-ips-non-unique-network-nam es+(status:open+OR+status:merged) 2. Volume multiattach enhancements: - https://blueprints.launchpad.net/nova/+spec/volume-multiattach-enhancements - https://review.openstack.org/#/q/topic:bp/volume-multiattach-enhancements+(s tatus:open+OR+status:merged) Bugs: ==== No progress report in this week too. I will start the bug triage next 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

tripleO undercloud import failing in stein
by Ruslanas Gžibovskis 04 Jul '19

04 Jul '19

Hi team, I am using CentOS7 with repos installed from stein package (centos-openstack-stein) in CentOS7. I just enable rdo-trunk-stein-tested because undercloud install do not work from centos-openstack-stein due to unable to mount some path, found that it is known and was fixed in stein tested. so I succeeded to boot and build everything. but when I use "time openstack --debug overcloud node import setup/hosts.yaml" step, it stops at: HTTP POST https://undercloud_public_host:13989/v2/executions 201 Started Mistral Workflow tripleo.baremetal.v1.register_or_update. Execution ID: 55f14621-cabd-4783-a611-d5b822ad0833 Waiting for messages on queue 'tripleo' with no timeout. I can reach iDRAC over ssh, and I can boot Physical HW to PXE. Physical HW state do not change, it do not change power state. current state is poweroff of physical hosts I am adding. any ideas? more info can be found here: https://ask.openstack.org/en/question/122870/valueerror-no-json-object-coul… -- Ruslanas Gžibovskis +370 6030 7030

1 0

Instance (vm guest) not getting PCI card
by Mauricio Tavares 03 Jul '19

03 Jul '19

Newbie and easy questions: I have two cards, one in each stein (centos) compute node setup for kvm, which I want to be able to handle to a vm guest (instance). Following https://docs.openstack.org/nova/latest/admin/pci-passthrough.html, I 1. Setup both computer nodes to vt-t and iommu. 2. On the controller 2.1. Create a PCI alias based on the vendor and product ID alias = { "vendor_id":"19fg", "product_id":"4000", "device_type":"type-PF", "name":"testnic" } - The PCI address for the card is different on each compute node 2.2. Create a flavor, say, n1.large openstack flavor create n1.large --id auto --ram 8192 --disk 80 --vcpus 4 --property "pci_passthrough:alias"="testnic:1" 2.3. Restart openstack-nova-api 3. On each compute node 3.1. Create a PCI alias based on the vendor and product ID alias = { "vendor_id":"19fg", "product_id":"4000", "device_type":"type-PF", "name":"testnic" } 3.2. Create passthrough_whitelist entry passthrough_whitelist = { "vendor_id":"19fg", "product_id":"4000" } 3.3. Restart openstack-nova-compute 4. Create instance (vm guest) using the n1.large flavor. 5. Login to instance and discover dmesg and lspci does not list card 6. Do a "virsh dumpxml" for the instance on its compute node and discover there is no entry for the card listed in the xml file. I take nova would automagically do what I would if this was a kvm install, namely ensure card cannot be accessed/used by the host and then edit the guest xml file so it can see said card. Questions: Q1: If a device is sr-iov capable, do I have to use that or can I just pass the entire card to the vm guest? Q2: Is there anywhere I can look for clues to why is the libvirt xml file for the instance not being populated with the pci card info? So far I only looked in the controller node's nova_scheduler.log file.

2 2

[magnum][queens] Floating ip error
by Ignazio Cassano 03 Jul '19

03 Jul '19

Hello All, I've just install queens kolla openstack qith magnum but when I try to create a docker swarm cluster the magnum conductor reports: <file:///var/lib/kolla/venv/lib/python2.7/site-packages/magnum/drivers/common/templates/lb.yaml>: : The Resource Type (Magnum::Optional::Neutron::LBaaS::FloatingIP) could not be found. I tried lbaas and floating ip works of magnum context. Does it requires octavia ? Regards Ignazio

1 0

[all][qa] Tempest jobs are swapping
by Clark Boylan 03 Jul '19

03 Jul '19

I've been working to bring up a new cloud as part of our nodepool resource set and one of the things we do to sanity check that is run a default tempest full job. The first time I ran tempest it failed because I hadn't configured swap on the test node and we ran out of memory. I added swap, reran things and tempest passed just fine. Our base jobs configure swap as a last ditch effort to avoid failing jobs unnecessarily but the ideal is to avoid swap entirely. In the past 8GB of memory has been plenty to run the tempest testsuite so I think something has changed here and I think we should be able to get us running back under 8GB of memory again. I bring this up because in recent weeks we've seen different groups attempt to reduce their resource footprint (which is good), but many of the approaches seem to ignore that making our jobs as quick and reliable as possible (eg don't use swap) will have a major impact. This is due to the way gating works where a failure requires we discard all results for subsequent changes in the gate, remove the change that failed, then re enqueue jobs for the changes after the failed change. On top of that the quicker our jobs run the quicker we return resources to the pool. How do we debug this? Devstack jobs actually do capture dstat data as well as memory specific information that can be used to identify resource hogs. Taking a recent tempest-full job's dstat log we can see that cinder-backup is using 785MB of memory all on its own [0] (scroll to the bottom). Devstack also captures memory usage of a larger set of processes in its peakmem_tracker log [1]. This includes RSS specifically which doesn't match up with dstat's number making me think dstat's number may be virtual memory and not resident memory. This peakmem_tracker log identifies other processes which we might look at for improving this situation. It would be great if the QA team and various projects could take a look at this to help improve the reliability and throughput of our testing. Thank you. [0] http://logs.openstack.org/81/665281/3/check/tempest-full/cf5e17e/controller… [1] http://logs.openstack.org/81/665281/3/check/tempest-full/cf5e17e/controller…

3 2

[Scientific] No Scientific SIG meeting Jul 3rd
by Martial Michel 02 Jul '19

02 Jul '19

Sending this email to inform you that we will not be having a Scientific SIG meeting Today. Hopefully next week -- Martial

1 0

[Shanghai Summit] CFP Deadline TONIGHT
by Ashlee Ferguson 02 Jul '19

02 Jul '19

Hi everyone, The Shanghai Summit Call for Presentations [1] deadline is TONIGHT, July 2 at 11:59 pm PT (July 3, 2019 at 15:00 China Standard Time)! Submit your presentations, panels, and Hands-on Workshops for the Open Infrastructure Summit [2] by the end of 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. Tracks [4]: 5G, NFV & Edge AI, Machine Learning & HPC CI/CD Container Infrastructure Getting Started Hands-on Workshops Open Development Private & Hybrid Cloud Public Cloud Security Other Helpful Shanghai Summit & PTG Information-- * 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. More information 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, Ashlee [1] https://cfp.openstack.org/ <https://cfp.openstack.org/> [2] https://www.openstack.org/summit/shanghai-2019/ <https://www.openstack.org/summit/shanghai-2019/> [3] https://cfp.openstack.org/ <https://cfp.openstack.org/> [4] https://www.openstack.org/summit/shanghai-2019/summit-categories/ <https://www.openstack.org/summit/shanghai-2019/summit-categories/> [5] https://www.openstack.org/summit/shanghai-2019/ <https://www.openstack.org/summit/shanghai-2019/> [6] https://openstackfoundation.formstack.com/forms/travelsupportshanghai <https://openstackfoundation.formstack.com/forms/travelsupportshanghai> [7] https://www.openstack.org/summit/shanghai-2019/travel/ <https://www.openstack.org/summit/shanghai-2019/travel/> [8] https://www.openstack.org/summit/shanghai-2019/sponsors/ <https://www.openstack.org/summit/shanghai-2019/sponsors/>

3 2

RE: HPE 3PAR Cinder driver-Multiattach: Fails to detach second instance from volume
by RAI, SNEHA 02 Jul '19

02 Jul '19

Hi All, Is there a way to find in cinder how many instances are attached to a volume? Thanks & Regards, Sneha Rai From: RAI, SNEHA Sent: Monday, July 1, 2019 5:26 PM To: openstack-dev(a)lists.openstack.org Subject: HPE 3PAR Cinder driver-Multiattach: Fails to detach second instance from volume Hi Team, There is a bug on 3PAR Cinder driver https://bugs.launchpad.net/cinder/+bug/1834660. I am able to attach multiple instances to 3PAR volume but only the first instance gets detached successfully. For the second instance, volume goes into detaching status due to "Host does not exist" error. What is happening here is, the first detach call invokes _delete_3par_host() which removes the compute host entry from 3PAR which ideally should be done only when the last instance is to be detached. It would be great if someone could help me understand if this needs to be handled in driver code or nova would internally take care of it. Code changes done to support multiattach-https://review.opendev.org/#/c/659443 Thanks & Regards, Sneha Rai

3 2

[Watcher] team meeting at 08:00 UTC today
by li.canwei2＠zte.com.cn 02 Jul '19

02 Jul '19

Hi all, Watcher team 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

1 0

[PTL] update FC_SIG liaison list reminder
by Matthew Oliver 02 Jul '19

02 Jul '19

Hey PTLs, I'm one of your friendly First Contact SIG (FC_SIG) representatives, and previously emailed you fine folk asking if you could take a look at the FC_SIG liaison list[0] and update it as needed. As mentioned in the PTL guide[1]. For those of you who have already done that thing, awesome, thanks so much. If you haven't had a chance yet it would be fantastic if you could! What is a FC_SIG liaison, they will be the person we contact or add to a review when a new contributor contacts us and wants to work on your project or we find a new patch from a new contributor and we want to make sure they get all the love they need to get them engaged. So what's important here is having the liaison's details, including timezone, up to date. Also note more then 1 liaison in more then 1 timezone would be preferred (if it can be manged), so we can connect new contributors with someone closer to them. If a project doesn't have a liaison then it'll default to the PTL, but we'd still rather have the PTL in the list with timezones as that makes it easier for us. So talk about it in your teams. Thanks, Matt [0] - https://wiki.openstack.org/wiki/CrossProjectLiaisons#First_Contact_SIG [1] - https://docs.openstack.org/project-team-guide/ptl.html#at-the-beginning-of-…

1 0

[Zun][Kata] Devstack plugin for installing Kata container
by Hongbin Lu 02 Jul '19

02 Jul '19

Hi all, I have a patch [1] that adds support for installing kata Container in devstack. Right now, it configures kata container to run with Docker. In the future, I plan to add support for containerd's cri plugin, which basically allows running pods with kata container. Initially, OpenStack Zun will use this plugin to install Kata container, but I believe it would be beneficial for other projects. Appreciate if anyone interest to cast your feedback on the patch. [1] https://review.opendev.org/#/c/668490/ Best regards, Hongbin

2 1

[TripleO] The Transformation Squad meeting canceled - 4 July, 2019
by Kevin Carter 02 Jul '19

02 Jul '19

Hello all, I wanted to let everyone know that the Transformation Squad team meeting will be canceled this coming Thursday; 4 July, 2019 @ 13:00UTC. We will continue with regular meetings on 11 July, 2019 @ 13:00UTC. If there are questions about this cancellation, or anything else, please let us know. Thank you and have a great week. -- Kevin Carter IRC: cloudnull

1 0

[keystone][oslo] oslo.limt implementation update
by Lance Bragstad 02 Jul '19

02 Jul '19

Today in keystone's office hours, we went through a group code review of what's currently proposed for the oslo.limit library [0]. This is a summary of the action items that came out of that meeting. * We should implement a basic functional testing framework that exercises keystoneauth connections (used for pulling limit information for keystone). Otherwise, we'll be mocking things left and right in unit tests to get decent test coverage with the current keystoneauth code. * Investigate alternatives to globals for keystoneauth connections [1]. * Investigate adopting a keystoneauth-like way of loading enforcement models (similar to how ksa loads authentication plugins) [2]. * Figure out if we want to use endpoint_id or service name + region name for service configuration [3]. * Build out functional testing for flat enforcement * Implement strict-two-level enforcement model This existing rewrite was mostly stolen from John's patches to his fork oslo.limit [4]. Hopefully the current series moves things in that direction. Feel free to chime in if you have additional notes or comments. Lance [0] https://review.opendev.org/#/q/topic:rewrite+(status:open+OR+status:merged)… [1] https://bugs.launchpad.net/oslo.limit/+bug/1835103 [2] https://bugs.launchpad.net/oslo.limit/+bug/1835104 [3] https://bugs.launchpad.net/oslo.limit/+bug/1835106 [4] https://github.com/JohnGarbutt/oslo.limit/commit/a5b908046fd904c25b6cd15c65…

2 2

[ops] Ops Meetups Team meeting 2019-7-2
by Chris Morgan 02 Jul '19

02 Jul '19

Meeting minutes for todays meeting are linked below. Two key decisions from today that you might like to know about: 1. The team will attempt to run an ops day at the Shanghai summit if there is a) sufficient interest and b) space to hold it. To gauge the interest level we will run a twitter poll. We have found that the engagement we get via twitter is actually better than via mailing lists. 2. The current consensus for the next meetups is as follows: September, NYC (USA) - this is under preparation 2020 meetup #1 EU region 2020 meetup #2 APAC region Calls for hosting the 2020 meetups will be issued by the meetups team soon. Thanks Chris Morgan (on behalf of the openstack ops meetups team) Meeting ended Tue Jul 2 14:48:24 2019 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) 10:48 AM Minutes: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2019/ops_meetup_tea… 10:48 AM Minutes (text): http://eavesdrop.openstack.org/meetings/ops_meetup_team/2019/ops_meetup_tea… 10:48 AM Log: http://eavesdrop.openstack.org/meetings/ops_meetup_team/2019/ops_meetup_tea… -- Chris Morgan <mihalis68(a)gmail.com>

1 0

[tc][ops] reviving osops- repos
by Mohammed Naser 02 Jul '19

02 Jul '19

Hi everyone, So we've realized that we have a few operational tools that we keep around that live all over the place and it would probably be the best for the community to have access to them. I did a bit of research and it looks like the openstack/osops-* repos used to exist between operators to maintain things like this, however, they've gone pretty abandoned over time. I'd like to pick up this effort and as part of doing that, I'd like to move them into a GitHub organization and rename them out of x/ to make them not seem so .. 'dead'. I've requested to move x/osops-* to openstack-operators/* in GitHub so that I can setup the appropriate mirroring in post pipeline (and then propose a patch to rename things inside Gerrit as well). There was concern around the idea of using 'openstack' as it's a copyrighted term and a TC discussion was brought up as an idea which makes sense. I'd like to ask if everyone else feels like it's okay so move things into that org and host them there. Thanks, Mohammed -- Mohammed Naser — vexxhost ----------------------------------------------------- D. 514-316-8872 D. 800-910-1726 ext. 200 E. mnaser(a)vexxhost.com W. http://vexxhost.com

9 15

[neutron][ci] Gate failure
by Slawek Kaplonski 02 Jul '19

02 Jul '19

Hi, It looks that we (again) have some broken gate. This time it’s problem with neutron-tempest-plugin-designate-scenario job which is failing 100% times. See [1] for details. Patch [2] is proposed so now lets wait until it will be merged and You can than rebase Your neutron patches to make Zuul happy again :) [1] https://bugs.launchpad.net/devstack/+bug/1834849 [2] https://review.opendev.org/#/c/668447/ — Slawek Kaplonski Senior software engineer Red Hat

3 5

Does networking-ovn support fwaas ?
by Frank Wang 01 Jul '19

01 Jul '19

Hi all, I'm investigating ovn as the neutron backend recently, networking-ovn is a great project, but one thing confuses me, I'd like to know if networking-ovn support fwaas? Security protection for network level, not port leve like security group, I looked up lots of materials, didn't find a clue. Any comments would be appreciated.

1 0

[kolla][ceph] Cache OSDs didn't stay in the root=cache after ceph deployment.
by Eddie Yen 01 Jul '19

01 Jul '19

Hi, I'm using stable/rocky to try ceph cache tiering. Now I'm facing a one issue. I chose one SSD to become cache tier disk. And set below options in globals.yml. ceph_enable_cache = "yes" ceph_target_max_byte= "<size num>" ceph_target_max_objects = "<object num>" ceph_cache_mode = "writeback" And the default OSD type is bluestore. It will bootstrap the cache disk and create another OSD container. And also create the root bucket called "cache". then set the cache rule to every cache pools. The problem is, that OSD didn't stay at "cache" bucket, it still stay at "default" bucket. That caused the services can't access to the Ceph normally. Especially deploying Gnocchi. When error occurred, I manually set that OSD to the cache bucket then re-deploy, and everything is normal now. But still a strange issue that it stay in the wrong bucket. Did I miss something during deployment? Or what can I do? Many thanks, Eddie.

2 2

[octavia] HTTP/2 support
by Volodymyr Litovka 01 Jul '19

01 Jul '19

Dear colleagues, - since haproxy supports HTTP/2 starting 1.9 (released on Dec 2018) for both frontends and backends - due to wide adoption of HTTP/2 (34% of all sites are now support HTTP/2 according to W3techs) - support for HTTP/2 is in all browsers and web-servers whether Octavia team has plans to add support for HTTP/2 as well? Thank you. -- Volodymyr Litovka "Vision without Execution is Hallucination." -- Thomas Edison

2 1

[tripleo] TripleO CI Summary: Sprint 32
by Rafael Folco 01 Jul '19

01 Jul '19

Greetings, The TripleO CI team has just completed Sprint 32 / Unified Sprint 11 (June 06 thru Jun 26). The following is a summary of completed work during this sprint cycle: - Created image and container build jobs on RHEL 7 in the internal instance of Software Factory as a prep work for RHEL8 jobs on RDO Software Factory. - Started creating RHEL8 jobs to build a periodic pipeline in the RDO Software Factory and provide feedback for CentOS8 coverage. - Promotion status: green on all branches at most of the sprint. The planned work for the next sprint [1] are: - Prepare the grounds for moving RDO on RHEL8 jobs from the internal instance of Software Factory to the RDO instance. This includes building a nodepool image w/ RHUI for base repos and enabling RHEL8 on tripleo-repos for delorean repos. - Get RDO on RHEL8 build jobs working and address dependency issues. - Continue the design document for a staging environment to test changes in the promoter server. This will benefit CI team with less breakages in the promoter server and also prepare the grounds for the multi-arch builds. The Ruck and Rover for this sprint are Arx Cruz (arxcruz) and Sagi Shnaidman (sshnaidm). Please direct questions or queries to them regarding CI status or issues in #tripleo, ideally to whomever has the ‘|ruck’ suffix on their nick. Ruck/rover notes are being tracked in etherpad [2]. Thanks, rfolco [1] https://tree.taiga.io/project/tripleo-ci-board/taskboard/unified-sprint-12 [2] https://etherpad.openstack.org/p/ruckroversprint12

1 0

[manila] no meeting July 4
by Tom Barron 01 Jul '19

01 Jul '19

We just agreed in freenode #openstack-manila to skip this week's Manila community meeting since several regular attendees including the chair are on holiday. We'll plan to meet as usual the following Thursday, 11 July, at 1500 UTC in #openstack-meeting-alt. Feel free to add to the agenda here: https://wiki.openstack.org/wiki/Manila/Meetings -- Tom Barron

1 0

Re: [Release-job-failures] Release of openstack/ansible-role-redhat-subscription failed
by Thierry Carrez 01 Jul '19

01 Jul '19

zuul(a)openstack.org wrote: > Build failed. > > - release-openstack-python http://logs.openstack.org/59/59f40f154a5302df1ee4230f35f87d261e0bf9eb/relea… : POST_FAILURE in 2m 09s > - announce-release announce-release : SKIPPED > - propose-update-constraints propose-update-constraints : SKIPPED Upload to PyPI at the end of the release was rejected due to: "The description failed to render in the default format of reStructuredText. See https://pypi.org/help/#description-content-type for more information." Impact: ansible-role-redhat-subscription 1.0.3 was produced and published, but not uploaded to PyPI. Remediation: once the description is fixed, we'll have to request a 1.0.4 to fix the situation. -- Thierry Carrez (ttx)

3 3

[searchlight] Cannot hold meeting today
by Trinh Nguyen 01 Jul '19

01 Jul '19

Daer team, Unfortunately, I'm in the middle of job transition and cannot hold the meeting today. I will propose a new meeting time this week. Please do not hesitate to contact me if you have any questions. Bests, -- *Trinh Nguyen* *www.edlab.xyz <https://www.edlab.xyz>*

1 0

[cinder] Deprecating driver versions
by Erlon Cruz 01 Jul '19

01 Jul '19

Hey folks, Driver versions has being a source of a lot of confusions with costumers. Most of our drivers have a version number and history that are updated as the developers adds new fixes and features. Drivers also have a VERSION variable in the version class that should be bumped by developers. The problem with that is: - sometimes folks from the community just push patches on drivers, and its hard to bump every vendor version correctly; - that relies in the human factor to remember adding it, and usually that fails; - if we create a bugfix and bump the version, the backport to older branches will carry the version, which will not reflect the correct driver code; So, the solution I'm proposing for this is that we use the Cinder versions[1] and remove all version strings for drivers. Every new release we get a version. For stable versions, from time to time the PTL bumps the stable version and we have an accurate ways to describe the code. If we need to backport and send something to the costumer, we can do the backport, poke the PTL, and he will generate another version which can be downloaded on github or via PIP, and present the version to our costumers. So, what are your thought around this? Anyone else has had problems with that? What would be the implications of removing the driver version strings? Erlon [1] https://releases.openstack.org/teams/cinder.html [2] https://github.com/openstack/cinder/blob/master/cinder/volume/drivers/solid…

4 5

[neutron] bug deputy report for week of 2019-06-24
by Bence Romsics 01 Jul '19

01 Jul '19

Hi Everybody, These are the new bugs of last week: Critical: * https://bugs.launchpad.net/neutron/+bug/1834298 Neutron-fwaas python 3.7 job is broken Fix tested, needs +2 from neutron-fwaas cores: https://review.opendev.org/667736 * https://bugs.launchpad.net/neutron/+bug/1833902 Revert resize tests are failing in jobs with iptables_hybrid fw driver A nova bug breaking neutron gate. Fix merged: https://review.opendev.org/667035 High: * https://bugs.launchpad.net/neutron/+bug/1834257 dhcp-agent can overwhelm neutron server with dhcp_ready_on_ports RPC calls Fix in progress: https://review.opendev.org/659274 * https://bugs.launchpad.net/neutron/+bug/1834484 [QoS] qos_plugin._extend_port_resource_request is killing port retrieval performance Fix in progress: https://review.opendev.org/667981, https://review.opendev.org/667998 Medium: * https://bugs.launchpad.net/neutron/+bug/1834308 [DVR][DB] too many slow query during agent restart Needs more information to reproduce * https://bugs.launchpad.net/neutron/+bug/1834753 TC filter priority parameter in Pyroute is "prio" Fix in progress: https://review.opendev.org/668308 * https://bugs.launchpad.net/neutron/+bug/1834825 Rule to prevent SNAT for router's internal traffic is wrong Fix in progress: https://review.opendev.org/668378 RFE: * https://bugs.launchpad.net/neutron/+bug/1834174 [RFE] Add support for IPoIB interface driver * https://bugs.launchpad.net/neutron/+bug/1834176 [RFE] Add support for per-physnet interface driver Cheers, Bence (rubasov)

1 0

glance image upload error [Errno 32] Broken pipe
by Satish Patel 01 Jul '19

01 Jul '19

I have installed opnestack-ansible and integrate glance with ceph storage, first day when i upload image it works but today when i am trying to upload image i am getting this error [root@ostack-infra-2-1-utility-container-c166f549 ~]# openstack image create --file cirros-0.3.4-x86_64-disk.raw --container-format bare --disk-format raw --public cirros-0.3.4-tmp Error finding address for http://172.28.8.9:9292/v2/images/8f3456aa-52fc-4b4a-8b11-dfbadb8e88ca/file: [Errno 32] Broken pipe I do have enough space on ceph storage, i am not seeing any error on glance logs also which help me. [root@ostack-infra-01-ceph-mon-container-692bea95 root]# ceph df detail GLOBAL: SIZE AVAIL RAW USED %RAW USED OBJECTS 9314G 3526G 5787G 62.14 245k POOLS: NAME ID QUOTA OBJECTS QUOTA BYTES USED %USED MAX AVAIL OBJECTS DIRTY READ WRITE RAW USED images 6 95367M N/A 22522M 3.62 584G 2839 2839 2594k 36245 67568M vms 7 N/A N/A 1912G 76.58 584G 248494 242k 6567M 3363M 5738G volumes 8 N/A N/A 0 0 584G 0 0 0 0 0 backups 9 N/A N/A 0 0 584G 0 0 0 0 0 metrics 10 N/A N/A 0 0 584G 0 0 0 0 0

2 1

[kolla] [ceph] Ceph using cluster network for replication
by vladimir franciz blando 30 Jun '19

30 Jun '19

Hi, In my globals.yml file --- cluster_interface: "bond1" --- but after deployment, there's nothing on the ceph.conf file that indicates that it's using the cluster interface --- # docker exec ceph_mon cat /etc/ceph/ceph.conf [global] log file = /var/log/kolla/ceph/$cluster-$name.log log to syslog = false err to syslog = false log to stderr = false err to stderr = false fsid = f8ff1404-bead-422b-9076-21583012ad30 mon initial members = 172.16.43.22, 172.16.43.11, 172.16.43.12 mon host = 172.16.43.22, 172.16.43.11, 172.16.43.12 mon addr = 172.16.43.22:6789, 172.16.43.11:6789, 172.16.43.12:6789 auth cluster required = cephx auth service required = cephx auth client required = cephx setuser match path = /var/lib/ceph/$type/$cluster-$id [mon] mon compact on start = true mon cluster log file = /var/log/kolla/ceph/$cluster.log --- I was expecting cluster network = <cluster_network_cidr>. I even tried making a custom config (/etc/kolla/config/ceph/ceph.conf) which includes the cluster network = <cluster_network_cidr> public network = <public_network_cidr> and run "kolla-ansible -i multinode reconfigure" but it did nothing, was there something missing on what I did? - Vlad ᐧ

2 1

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

28 Jun '19

# Keystone Team Update - Week of 24 June 2019 ## News ### Virtual Midcycle Planning We've begun planning our midcycle[1], which we will hold virtually sometime around or after milestone 2. Please participate in suggesting topics and the scheduling poll. [1] http://lists.openstack.org/pipermail/openstack-discuss/2019-June/007344.html ## Open Specs Train specs: https://bit.ly/2uZ2tRl Ongoing specs: https://bit.ly/2OyDLTh ## Recently Merged Changes Search query: https://bit.ly/2pquOwT We merged 13 changes this week, including some advances in the oslo.limit and application credential access rules implementations. ## Changes that need Attention Search query: https://bit.ly/2tymTje There are 45 changes that are passing CI, not in merge conflict, have no negative reviews and aren't proposed by bots. ## Bugs This week we opened 3 new bugs and closed none. Bugs opened (3) Bug #1834294 (keystone:Undecided) opened by Eivinas https://bugs.launchpad.net/keystone/+bug/1834294 Bug #1834304 (keystone:Undecided) opened by Rohit Londhe https://bugs.launchpad.net/keystone/+bug/1834304 Bug #1834342 (keystone:Undecided) opened by Benoît Knecht https://bugs.launchpad.net/keystone/+bug/1834342 ## Milestone Outlook https://releases.openstack.org/train/schedule.html Spec freeze is in 4 weeks. Our midcycle will be held some time around or just after that, and feature proposal freeze closely follows. ## Help with this newsletter Help contribute to this newsletter by editing the etherpad: https://etherpad.openstack.org/p/keystone-team-newsletter

1 0

[nova] API updates week 19-26
by Ghanshyam Mann 28 Jun '19

28 Jun '19

Hello Everyone, Please find the Nova API updates of this week. API Related BP : ============ COMPLETED: 1. Support adding description while locking an instance: - https://blueprints.launchpad.net/nova/+spec/add-locked-reason Code Ready for Review: ------------------------------ 1. 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. I will re-review it tomorrow. 2. Specifying az when restore shelved server - Topic: https://review.opendev.org/#/q/topic:bp/support-specifying-az-when-restore-… - Weekly Progress: Review comments is fixed and ready to re-review. 3. Nova API cleanup - Topic: https://review.opendev.org/#/c/666889/ - Weekly Progress: Code is up for review. A lot of files changed but should be ok to review. I have pushed a couple of patches for missing tests of previous microversions. 4. 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 too. I will start the bug triage next 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

3 3

[openstack-dev] [neutron] Cancelling Neutron Drivers meeting
by Miguel Lavalle 28 Jun '19

28 Jun '19

Dear Neutrinos, Next week, the 4th of July Holiday (Independence Day) will be observed in the USA. Since several members of the drivers team live in that country and will enjoy a long weekend, we are cancelling the meeting on the 5th. We will resume our meeting normally on the 12th. Best regards Miguel

1 0

[nova] Last chance to weigh in on nova adopting the SDK for inter-service comms
by Matt Riedemann 28 Jun '19

28 Jun '19

John and I are +2 and Eric is +1 (would be +2 if not involved in the effort) on the nova spec [1] to adopt the openstacksdk for nova communicating with other services rather than the python-*clients. There are several motivations within the spec itself and in review comments for doing this, but since it's a major change to nova across the board I want to make sure other cores and contributors are aware and at least not against this before it's approved. I think a reasonable timeline for waiting to approve is until EOD July 2 (next week) since that's our third and final spec review sprint. [1] https://review.opendev.org/#/c/662881/ -- Thanks, Matt

1 0

[infra] Stepping down as infra-root
by Paul Belanger 28 Jun '19

28 Jun '19

Greetings! 10 months ago my role at Red Hat changed, which saw my day to day job move away from OpenStack, specifically the Infrastructure team. Since then, I've be contributing to OpenStack in my spare time however it isn't going as well I as would like. Unfortunately, there is never enough time in the day to do everything and as a result I believe it is best for me to step day, and remove myself as infra-root: https://review.opendev.org/668192 In the 7 years I've been contributing to the infra team, I've learned a great many things (and still learning). Thank you to all the awesome humans, past and present, for making my day to day much better. To the community, I do ask if you are at all interested in how the infrastructure works / operates, reach out to the #openstack-infra channel and get involved. I refer you to the help wanted list: https://governance.openstack.org/tc/reference/help-most-needed.html#communi… Paul

2 1

https://github.com/openstack/nova/blob/master/nova/virt/vmwareapi/ds_util.py
by Keith Berger 28 Jun '19

28 Jun '19

Gary, I hope you are doing well. I was trying to understand the logic in this code when using datastore_regex. It seems even if you set that parameter and it matches some N datastores, the "free capacity " being returned by nova-compute is only from a single/best datastore. def get_available_datastores(session, cluster=None, datastore_regex=None): """Get the datastore list and choose the first local storage.""" ds = session._call_method(vutil, "get_object_property", cluster, "datastore") ... ... if _is_datastore_valid(propdict, datastore_regex, allowed_ds_types): new_ds = ds_obj.Datastore( ref=obj_content.obj, name=propdict['summary.name'], capacity=propdict['summary.capacity'], freespace=propdict['summary.freeSpace']) # favor datastores with more free space if (best_match is None or new_ds.freespace > best_match.freespace): best_match = new_ds return best_match The issue we are seeing is a customer has for example 5 x 10 GB data stores (DS1,..DS5.) For whatever reason , DS1 was filled more fully and once it hit close to 100% no new instances could launch as the were blocked by the Nova DiskFilter. I know we can use the disk_allocation to "fool" this but why is not using to total cumulative storage as opposed to the one with most free or first one. I am wondering if there is some configuration issue. If it is supposed to use best_match, should that dynamically change among the matched regex Datastore to the one with most free space? Could it be it is somehow skipping the "best_match" and always using " first local storage" I appreciate any suggestions or comments you have. Keith -- Keith Berger Master Software Engineer SUSE (P)+1 470.237.2012 (M)+1 404.664.9610 keith.berger(a)suse.com

1 0

[kolla] How can I change package version when building the image?
by Eddie Yen 28 Jun '19

28 Jun '19

Hi, I'm using stable/rocky from git now, but I want to build the prometheus images with latest version since there're few exporters that too previous that can't use most Grafana dashboards in default. I already know I have to edit templates in kolla-ansible since the newer exporters has using the different launch commands. But Idk how to set the version because the document didn't say how to override the Dockerfile. Is that OK to change package version inside Dockerfile? Many thanks, Eddie.

3 4

performance issue with opendev gitea interface.
by Sean Mooney 27 Jun '19

27 Jun '19

i have started this as a separate thread form the Github organization management but it has been in the back of my mind as we are considering not syncing to gitub going forward. for larger project like nova https://opendev.org/openstack/nova preforms quite poorly in both firefox and chome i am seeing ~ 15second before the first response form opendev.org for nova. os-vif or other smaller projects seem to respond ok but for nova it makes navigating the code or liking code to other via opendev quite hard. i brought this up on the infra irc a few weeks ago and asked if gitea had any kind of caching and while the initial response was "we do not believe so". before archiving or stopping syncing to github i was wondering if we could explore options to improve the performace. if opendev.org is not currently fronted by a cdn perhaps that would help. Similarly looking at https://docs.gitea.io/en-us/config-cheat-sheet/ it may be possible to either change the cache or database parameters to improve performance. I really don't know how gitea has been deployed but at present the web interface is not usable in nova in a responsive manner so i have continued to use github when linking code to others but it would be nice to be able to use opendev instead. regards sean.

4 3

[sig][api] API-SIG office hours cancelled for 4 July
by Michael McCune 27 Jun '19

27 Jun '19

due the holiday in the united states and travel by our other members, the api-sig will not hold office hours next thursday, 4 july. thank you =) peace o/

1 0

[security sig] Weekly Newsletter June 27th & July 4th Meeting Canceled
by Gage Hugo 27 Jun '19

27 Jun '19

Just a heads up, but since next Thursday is the 4th of July, we will be canceling next week's Security SIG meeting. Have a safe holiday everyone! #Week of: 27 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-27-1… - Slow week, discussed the TC approving the Image Encryption pop-up team & TPM passthrough - Next week's meeting will be canceled due to July 4th 🎆 ## News - The TC approved adding "Image Encryption" as a pop-up team - https://review.opendev.org/#/c/661983/ - https://governance.openstack.org/tc/reference/popup-teams.html#image-encryp… - Physical TPM passthrough PoC - https://review.opendev.org/#/c/667926/ - spec - https://review.opendev.org/#/c/667928/ # 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

[sahara] Cancelling Sahara meeting July 4
by Jeremy Freudberg 27 Jun '19

27 Jun '19

Hi all, There will be no Sahara meeting this upcoming Thursday, July 4. Holler if you need anything. Thanks, Jeremy

1 0

Re: [nova] Questions on Force refresh instance info_cache during heal
by Matt Riedemann 27 Jun '19

27 Jun '19

On 6/26/2019 4:39 AM, 胡丽娜 wrote: > Dear Matt Riedemann : > I am quiet interested in your recently published > patch https://review.opendev.org/#/c/591607/ , there is a question i > met ，If we spawn VM with port id and then update db , set > network_info='[]' , Afert periodic task_heal_instance_info_cache , > Preserve On Delete turn into False , in face ,it's corret value is True . > Steps to reproduce: > 1.Spawn vm with port id : nova boot --flavor xx --nic port-id --image xx > vm_name > 2.View the value of Preserve On Delete , it'value is True > 3.Update the DB row ,drop interface_list > 4.View the value of Preserve On Delete , it turns into False > Have you ever had this question ? Look forward to your reply ! > Best wishes ! > > 胡丽娜 BC-EC > 中国移动苏州研发中心云计算产品部 > 中移（苏州）软件技术有限公司 > 苏州高新区科技城昆仑山路58号中移软件园 +openstack-discuss mailing list The problem in this case is that nova relies on the network info cache to determine which ports were created by nova and which were pre-existing and provided by the user, either during server create or attached to the server after it was created. When building the network info model we determine the pre-existing port IDs here [1] and then pass that to _build_vif_model here [2]. We then determine the preserve_on_delete value if the port ID is in that pre-existing ports set [3]. What we should probably be doing is if we have lost the cache is always set preserve_on_delete=True since we don't have the cache information to know if we should delete the port when the server is deleted, and it could be an SR-IOV port or something that the user does not want deleted. The worst case in this scenario is the server is deleted and some ports are unbound and left hanging around that the user has to manually cleanup but that's arguably better than deleting something they didn't want to be deleted. I used some similar logic in this related patch [4]. If people agree with this (being conservative when we've lost the cache), then please report a bug and we can make the change (it should be pretty simple). [1] https://review.opendev.org/#/c/591607/25/nova/network/neutronv2/api.py@2826 [2] https://review.opendev.org/#/c/591607/25/nova/network/neutronv2/api.py@2906 [3] https://review.opendev.org/#/c/591607/25/nova/network/neutronv2/api.py@2764 [4] https://review.opendev.org/#/c/640516/ -- Thanks, Matt

1 1