Earlier  
Posted Nick Remark
#openstack-nova - 2019-01-30
18:02:29 mgagne right.
18:02:34 mriedem they are a placeholder for quota until a quota 'claim' is either committed or rolled back
18:02:57 mriedem so if the server a given reservation is already gone or active, you don't need the reservation anymore
18:03:01 mgagne I'm wondering what deletes/expires them. I read somewhere it's the scheduler but I'm wondering in which case they get expired/deleted so I can see if I can flush them or not.
18:03:25 mriedem there is also a periodic task that reaps them i think, check for the "reservation_expire" option
18:03:53 mriedem anyway, i *think* (without looking at code) reservations are meant to be deleted once the quota claim is committed or rolled back
18:03:58 mgagne it's a custom patch for cellsv1 which I cherry-picked. But dumb me didn't set it to true.
18:04:08 mriedem reservation_expire is a timer
18:04:34 mgagne hmm, ok, I think it's cells/expire_reversations I had
18:05:13 mgagne ok, will look into the claim thing and see what I can do. there is just too many rows to filter them, it's gonna take forever to complete.
18:05:22 mriedem i don't see that in https://docs.openstack.org/nova/rocky/configuration/config.html
18:05:57 mgagne https://github.com/NeCTAR-RC/nova/commit/6a5a4e53a008ab4032917a9e682e32df1279d758
18:06:43 mriedem https://github.com/openstack/nova/blob/newton-eol/nova/cmd/manage.py#L306 existed in newton
18:06:52 mriedem you could check that, i'm not sure if it cleans up old reservations though
18:07:36 mriedem ah ok, well that's out of tree
18:07:44 mriedem sorrison is your man
18:08:25 mgagne yea, I just need to find a way to clear up my hmmm amount of reservations.
18:16:18 mriedem well this isn't good, "Updating service version for nova-osapi_compute on stein from 37 to 36"
18:16:21 mriedem on restart of n-api
18:17:00 cdent ruh roh
18:58:50 mriedem think i figured it out
19:03:50 mriedem i stacked with current master, then cherry picked an older change that needed to be rebased which backleveled the service version from 37 to 36 and then when restarting n-api/n-cpu they blew up (well, n-cpu blew up, n-api just logged it)
19:13:50 openstackgerrit Kashyap Chamarthy proposed openstack/nova-specs master: WIP: Gracefully handle QEMU machine types for guests https://review.openstack.org/631154
19:38:18 mriedem efried: alex_xu: regarding the shared snapshot image patch https://review.openstack.org/#/c/630769/ i tested that with devstack again and alex_xu is correct that when the non-admin project unshelves (or deletes) the server they don't have access to delete the image snapshot owned by the admin project, but it doesn't make either operation fail, it just logs a warning
19:38:22 mriedem i think that is OK
20:58:00 cfriesen stephenfin: sean-k-mooney: does https://github.com/openstack/nova-specs/blob/master/specs/queens/implemented/share-pci-between-numa-nodes.rst apply to SR-IOV and PCI-PT NICs?
20:59:46 efried mriedem: ack
21:00:07 efried Is a(ny) failure during spawn reschedulable?
21:00:24 efried (unrelated ^ )
21:07:27 mriedem efried: no
21:07:41 mriedem for example, anything out of _prep_block_devices that fails is an abort
21:07:50 mriedem oh spawn..
21:08:39 mriedem depends on what it is https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L2120
21:08:54 mriedem e.g. these don't get rescheduled https://github.com/openstack/nova/blob/master/nova/compute/manager.py#L2173
21:09:33 mriedem several more in the block below
21:09:38 mriedem anything not specifically caught is rescheduled
21:09:56 efried mriedem: Got it, thanks.
21:12:23 sean-k-mooney cfriesen yes and it used to have have both flavor extra specs and an image property to allwo you to set the policy
21:12:29 sean-k-mooney cfriesen: https://github.com/openstack/nova-specs/blob/f350472e627db1afbe5e32c35a9973124642ecf1/specs/queens/implemented/share-pci-between-numa-nodes.rst#proposed-change
21:12:41 sean-k-mooney cfriesen: but it was not implemanted and the spec was retroactivly updated.
21:13:11 sean-k-mooney cfriesen: i want to add those back in in train and complete the original spec
21:13:31 sean-k-mooney cfriesen: i discoverd this in novemebr but did not have time to work on it this cycle
21:13:41 cfriesen sean-k-mooney: right, I remember that. so how does the pci alias in the config file map to what gets used for SR-IOV?
21:14:07 sean-k-mooney cfriesen: the alias works assuming stepens patch merged
21:14:22 sean-k-mooney cfriesen: there was a bug were we were not storing the policy in the db
21:14:45 cfriesen sean-k-mooney: as I recall, we decided that setting the policy on the alias was sufficient since most likely all requests for a particular device would use the same PCI affinity (ie either you care about performacne on that device or not)
21:15:21 sean-k-mooney cfriesen: we need these https://review.openstack.org/#/q/status:open+project:openstack/nova+branch:master+topic:bug/1805891
21:15:42 sean-k-mooney cfriesen: https://bugs.launchpad.net/nova/+bug/1805891
21:15:44 openstack Launchpad bug 1805891 in OpenStack Compute (nova) "pci numa polices are not followed" [High,In progress] - Assigned to Stephen Finucane (stephenfinucane)
21:15:47 cfriesen sean-k-mooney: we don't specify an alias explicitly for SR-IOV networking though, right? it looks up the network in the pci whitelist. So how do we decide which alias to use?
21:16:42 sean-k-mooney oh right sorry ya there is no way to adjust the policy for srivo devices at all
21:17:00 sean-k-mooney i taught the policy was in teh whitelist for a second not the alais
21:17:18 cfriesen on reflection, that kind of seems like an oversight. :)
21:17:33 sean-k-mooney cfriesen: well it was in the spec for a reason
21:17:59 sean-k-mooney specifcally so that neutron sriov prot could be supported
21:18:32 cfriesen I think when we switched to putting it in the alias we probably missed the fact that the alias didn't apply to devices associated with neutron ports
21:19:14 cfriesen certainly I didn't realize it at the time
21:19:43 sean-k-mooney well the alias was never ment to be suported at all
21:20:55 sean-k-mooney i personally think we shoudl have followed the spec in the frist place.
21:24:20 sean-k-mooney cfriesen: anyway am im hoping to change this in train. i think i commented on the starlingx tread a few montsh ago about the histroy of this and the current state
21:24:56 cfriesen sean-k-mooney: okay, will keep an eye out
22:09:37 artom https://review.openstack.org/#/c/599208/
22:09:56 artom Please someone tell me I'm not the only struggling with almost every single line in that beast
22:14:24 efried artom: I admit I haven't looked at it again since a much earlier PS. It's on my list, and steadily creeping higher.
22:16:09 mriedem artom: i just realized that these bdm docs don't mention tags at all https://docs.openstack.org/nova/latest/user/block-device-mapping.html#block-device-mapping-v2
22:21:10 openstackgerrit Merged openstack/nova master: Consolidate inventory refresh https://review.openstack.org/615695
22:21:17 efried woot
22:28:39 openstackgerrit Matt Riedemann proposed openstack/nova master: Add microversion to expose virtual device tags https://review.openstack.org/631948
22:53:17 openstackgerrit Matt Riedemann proposed openstack/nova master: Fix config docs for handle_virt_lifecycle_events https://review.openstack.org/634058
23:09:45 artom mriedem, yeah, except the api-ref there's 0 device tagging documentation
23:10:02 artom It's been a low-ish priority item on my backlog for a long time
23:10:34 artom I wrote https://notartom.net/2017/06/20/virtual-device-role-tagging-better-explained/ but need to "upstream" it properly
23:56:03 openstackgerrit Takashi NATSUME proposed openstack/nova master: Remove deprecated 'os-flavor-manage' policy https://review.openstack.org/633656
23:56:17 openstackgerrit Takashi NATSUME proposed openstack/nova master: Fix a missing policy in test policy data https://review.openstack.org/633686
#openstack-nova - 2019-01-31
00:02:33 openstackgerrit Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (3) https://review.openstack.org/574104
00:02:45 openstackgerrit Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (4) https://review.openstack.org/574106
00:02:57 openstackgerrit Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (5) https://review.openstack.org/574110
00:03:07 openstackgerrit Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (6) https://review.openstack.org/574113
00:03:19 openstackgerrit Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (7) https://review.openstack.org/574974
00:03:30 openstackgerrit Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (8) https://review.openstack.org/575311
00:08:26 alex_xu mriedem: thanks. so we just need to ask admin to cleanup the image after user unshelve the instance
00:08:41 alex_xu that seems fine
00:16:37 openstackgerrit Hang Yang proposed openstack/nova stable/queens: Fix port dns_name reset https://review.openstack.org/633807
00:30:42 openstackgerrit Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (9) https://review.openstack.org/575581
00:31:37 openstackgerrit Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (10) https://review.openstack.org/576017
00:31:46 openstackgerrit Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (11) https://review.openstack.org/576018
00:31:57 openstackgerrit Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (12) https://review.openstack.org/576019
00:32:08 openstackgerrit Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (13) https://review.openstack.org/576020
00:32:18 openstackgerrit Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (14) https://review.openstack.org/576027
00:32:49 openstackgerrit Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (15) https://review.openstack.org/576031
00:33:03 openstackgerrit Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (16) https://review.openstack.org/576299
00:33:16 openstackgerrit Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (17) https://review.openstack.org/576344
00:33:27 openstackgerrit Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (18) https://review.openstack.org/576673
00:33:40 openstackgerrit Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (19) https://review.openstack.org/576676
00:33:56 openstackgerrit Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (20) https://review.openstack.org/576689
00:34:07 openstackgerrit Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (21) https://review.openstack.org/576709
00:34:21 openstackgerrit Takashi NATSUME proposed openstack/nova master: Remove mox in unit/network/test_neutronv2.py (22) https://review.openstack.org/576712
00:52:08 artom The transport_url is missing from nova_cell1.conf on the second compute node in multinode devstack, the compute couldn't "join"
00:52:13 artom Did I do something wrong?
01:15:08 bhagyashris artom: Hi,

Earlier   Later