| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-05-31 | |||
| 12:36:55 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: WIP abort live migration in queue. https://review.openstack.org/568542 | |
| 12:37:33 | openstackgerrit | Jan Gutter proposed openstack/nova master: Convert vrouter legacy plugging to os-vif https://review.openstack.org/571325 | |
| 12:37:34 | openstackgerrit | Jan Gutter proposed openstack/nova master: Use vif.vif_name in _set_config_VIFGeneric https://review.openstack.org/571461 | |
| 12:37:35 | openstackgerrit | Jan Gutter proposed openstack/nova master: Pass virtio multiqueue info to os-vif plugins https://review.openstack.org/571462 | |
| 12:51:44 | openstackgerrit | Yikun Jiang (Kero) proposed openstack/nova master: WIP: Adapt _validate_instance_group_policy to new policy model https://review.openstack.org/571465 | |
| 13:13:47 | openstackgerrit | Surya Seetharaman proposed openstack/nova master: Delete orphaned RS and IM records of archived instances https://review.openstack.org/560042 | |
| 13:14:19 | openstackgerrit | Chen proposed openstack/nova master: WIP Closes-Bug: #1449221 https://review.openstack.org/571472 | |
| 13:14:20 | openstack | bug 1449221 in OpenStack Compute (nova) "Nova doesn't allow cleanup of volumes stuck in 'attaching' or 'detaching' status" [High,Confirmed] https://launchpad.net/bugs/1449221 | |
| 13:50:29 | melwitt | nova meeting in 10 minutes | |
| 13:53:00 | mriedem | dansmith: can you get this queens backport? https://review.openstack.org/#/c/571425/ | |
| 13:54:13 | mriedem | lyarwood: looks like you have something to fix in this one https://review.openstack.org/#/c/571433/ | |
| 13:57:02 | dansmith | hmm, not sure why that depends on the update resource patch | |
| 13:57:59 | lyarwood | mriedem: yeah, couldn't run tox locally for Ocata for some reason, I'll get to it later today | |
| 13:58:44 | lyarwood | dansmith: it just keeps the backport clean, I was already looking to backport the resource patch anyway so... | |
| 13:59:24 | dansmith | hmm, okay | |
| 14:00:55 | openstackgerrit | sahid proposed openstack/os-vif master: Add virtio_multiqueue field to InstanceInfo https://review.openstack.org/570959 | |
| 14:04:13 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: always create consumer records https://review.openstack.org/567678 | |
| 14:04:14 | openstackgerrit | Jay Pipes proposed openstack/nova master: add consumers generation field https://review.openstack.org/557958 | |
| 14:04:15 | openstackgerrit | Jay Pipes proposed openstack/nova master: placement: Allocation.consumer field https://review.openstack.org/565405 | |
| 14:04:16 | openstackgerrit | Jay Pipes proposed openstack/nova master: rework allocation handler _allocations_dict() https://review.openstack.org/565407 | |
| 14:04:17 | openstackgerrit | Jay Pipes proposed openstack/nova master: Add a microversion for consumer generation support https://review.openstack.org/565604 | |
| 14:09:00 | jaypipes | btw, dansmith, fixed the silly pep8 error in ^ | |
| 14:09:16 | dansmith | ack | |
| 14:09:18 | jaypipes | dansmith: let me know if you'd like further tests added for ensure_consumer() | |
| 14:09:27 | dansmith | you know I will | |
| 14:09:30 | jaypipes | :) | |
| 14:10:07 | mriedem | i had some random thoughts about a nova-status upgrade check for the missing consumer stuff, | |
| 14:10:14 | mriedem | but haven't thought about it much | |
| 14:10:25 | mriedem | basically query the api db for allocations w/o a consumer | |
| 14:10:36 | mriedem | but not sure what to do if we find them | |
| 14:10:42 | jaypipes | mriedem: the bottom patch on that series adds an online db migration for "incomplete" consumers. | |
| 14:10:46 | dansmith | you want nova-status to connect directly to the placement database? | |
| 14:11:03 | mriedem | nova-status already connects directly to the nova_api db, which is the placement db today | |
| 14:11:09 | mriedem | jaypipes: yeah i forgot about that | |
| 14:11:17 | dansmith | right, but it muddies the water for a split | |
| 14:12:16 | mriedem | yeah if we have an online data migration i'm not sure we need an upgrade status check thing | |
| 14:13:34 | mriedem | i think i was thinking, | |
| 14:13:53 | mriedem | somehow healing the allocations / creating missing consumers based on the actual instance for the allocation, rather than the config options | |
| 14:13:59 | mriedem | which is what jay's online data migration is using it looks like | |
| 14:14:51 | dansmith | hmm | |
| 14:15:17 | dansmith | I mean, I guess we can do that now, but we won't be able to do things like that past the split, so I would think we should stick to being cleanly separated even before | |
| 14:15:42 | jaypipes | mriedem: your heal_allocations() work would already do that (once the always create consumer patch is merged, of course) | |
| 14:16:00 | mriedem | jaypipes: the heal_allocations CLI won't do anything if the instance already has allocations | |
| 14:16:06 | mriedem | but it doesn't check if the project/user is missing | |
| 14:16:17 | jaypipes | mriedem: ah, yes, true nuf | |
| 14:16:41 | mriedem | https://review.openstack.org/#/c/565886/9/nova/cmd/manage.py@1794 | |
| 14:21:14 | sahid | jangutter: i have question for you in the osvif patch | |
| 14:21:27 | jangutter | shoot! | |
| 14:21:50 | mriedem | jaypipes: having said that, we could make heal_allocations look to see if the existing allocations are missing consumer/project and re-post the allocations w/ the consumer/project if so | |
| 14:22:40 | sahid | jangutter: is that could help whether we have that new virtio_multiqueu attribute an integer, so we can pass the exact number of queue enabled? | |
| 14:23:35 | jangutter | sahid: I dunno, this is weird territory for me... literally the only code I could find used iproute2 to enable "multiqueue" and that's it. | |
| 14:23:52 | jaypipes | mriedem: IIRC, that was my original suggestion that I could do that in the online DB migration | |
| 14:24:14 | jaypipes | mriedem: but it was decided that the single CONF option was a simpler solution for the majority case. | |
| 14:24:37 | sahid | jangutter: it's not something that will be used by vrouter so? | |
| 14:24:51 | jaypipes | mriedem: part of the issue with that is that I would have to import nova objects and DB into the placement object files in order to grab instance information. | |
| 14:24:59 | jangutter | sahid: It seems to be a bit of an aberration, almost all of the other VIF types can learn the multiqueue configs from the hypervisor, just TAP seem to need something on the plug side. | |
| 14:25:31 | dansmith | jaypipes: which we can't do post-split, so we shouldn't do now, if we're serious about maintaining that separation | |
| 14:25:32 | jangutter | sahid: yeah I think vrouter's the only remaining bit that requires that... | |
| 14:26:18 | jangutter | sahid: I think things like vhostuser negotiates it over-the-wire or something. I haven't looked closely. | |
| 14:26:24 | jaypipes | dansmith: right, that was the concern. | |
| 14:28:02 | mriedem | jaypipes: sure i get that, | |
| 14:28:11 | mriedem | the heal_allocations CLI is all REST API stuff wrt placement | |
| 14:28:21 | mriedem | so there is no mixed db naughtiness | |
| 14:29:47 | mriedem | if we ever get to counting quotas using placement, i think we'll have to fix those consumer records to use the same project/user as the instance, one way or another | |
| 14:30:07 | mriedem | because counting quotas against a "real" project/user won't include any usage marked against the config options | |
| 14:30:43 | dansmith | yes, definitely, but I think jaypipes' plan was to make sure that happened first, and I thought heal_allocations was the way | |
| 14:30:43 | mriedem | heal_allocations could be told to also compare the allocation project/user against the instance project/user and if not the same, update the allocation | |
| 14:30:45 | jaypipes | mriedem: agreed. | |
| 14:30:53 | jaypipes | dansmith: yes, it was. | |
| 14:31:21 | mriedem | right so i think we're on the same page: fill the hole we have now with the config options, then rely on heal_allocations to properly update the allocations per instance later | |
| 14:31:31 | dansmith | yup | |
| 14:31:32 | mriedem | ok | |
| 14:31:34 | mriedem | whew | |
| 14:31:40 | jaypipes | perfecto | |
| 14:31:47 | mriedem | we should write this down... | |
| 14:33:01 | mriedem | i might amend something into https://specs.openstack.org/openstack/nova-specs/specs/rocky/approved/add-consumer-generation.html#upgrade-impact later just as a reminder | |
| 14:33:37 | melwitt | ++ reminders are good | |
| 14:33:54 | sahid | jangutter: ok so i just checked on code, yes it seems that vrouter is the only which needs to created tap device with multiqueue bit so far | |
| 14:34:00 | sahid | so let keep that simple | |
| 14:34:18 | melwitt | takashin: thanks for fixing the meeting times on the agenda -- I didn't realize I had incorrectly swapped them after summit week | |
| 14:34:34 | jangutter | sahid: yeah, it can spiral out of control quickly, txqueues, rxqueues.... | |
| 14:36:56 | sahid | jangutter: yes right... | |
| 14:37:57 | sahid | but i think we do not have any other choice, "normally" it's libvirt which creates the tap and configures the queues | |
| 14:38:38 | sahid | but vrouter is using ethernet interface | |
| 14:42:05 | takashin | melwitt: I'm glad to help. | |
| 14:44:12 | dansmith | mriedem: so I need to raise upper constraints for oslo.messaging prior to my patch to use the new version yeah? that's not automatic I assume... | |
| 14:45:24 | dansmith | actually maybe it gets auto-proposed/ | |
| 14:45:31 | dansmith | I see a bunch of those in requirements right now | |
| 14:48:32 | mriedem | it's automatic | |
| 14:48:42 | mriedem | you'll have to bump lower-constraints in your nova change | |
| 14:49:19 | dansmith | um | |
| 14:49:42 | mriedem | upper-constraints in the requirements repo gets updated automatically via a bot | |
| 14:49:57 | dansmith | okay I guess I'm not sure why we have lower-constraints in our tree | |
| 14:50:01 | mriedem | the in-tree lower-constraints file (and requirements.txt i guess) in nova will need to be updated | |
| 14:50:21 | mriedem | it's in all trees, to run the lower-constraints job | |
| 14:50:26 | mriedem | since all other jobs run against upper-constraints | |
| 14:50:40 | mriedem | and to decouple g-r from a minimum baseline across all projects | |
| 14:50:52 | dansmith | I guess because we how have our own set of lowers or whatev3er | |
| 14:50:53 | mriedem | i guess, i'm not really following all of that work, but it's what i know | |
| 14:50:53 | dansmith | okay | |