Earlier  
Posted Nick Remark
#openstack-nova - 2017-12-18
06:58:38 openstackgerrit Takashi NATSUME proposed openstack/nova stable/pike: Add 'delete_host' command in 'nova-manage cell_v2' https://review.openstack.org/513717
07:07:17 openstackgerrit OpenStack Proposal Bot proposed openstack/nova master: Imported Translations from Zanata https://review.openstack.org/524795
07:53:03 openstackgerrit Yikun Jiang (Kero) proposed openstack/python-novaclient master: Microversion 2.58 - Instance actions list pagination https://review.openstack.org/528601
07:56:44 openstackgerrit Yikun Jiang (Kero) proposed openstack/nova master: Add pagination and Changes-since filter support for os-migrations. https://review.openstack.org/330406
08:08:30 openstackgerrit Ahmed Zaid proposed openstack/nova master: Flavors with illegal names. https://review.openstack.org/528563
08:12:06 openstackgerrit Ahmed Zaid proposed openstack/nova master: Flavors with illegal names. https://review.openstack.org/528563
09:01:45 openstackgerrit Merged openstack/nova stable/pike: Fix CellDatabases fixture swallowing exceptions https://review.openstack.org/519702
09:14:14 openstackgerrit rahul bardia proposed openstack/python-novaclient master: nova limits ERROR (Exception): Field names must be unique https://review.openstack.org/527922
09:17:08 openstackgerrit Lajos Katona proposed openstack/nova master: WIP: Add nested resources to server moving tests https://review.openstack.org/527728
09:23:33 gibi happy Monday nova!
09:24:03 openstackgerrit Merged openstack/nova stable/pike: Handle InstanceNotFound when setting password via metadata https://review.openstack.org/519659
09:31:19 maciejjozefczyk gibi: I wish it could be happy :)
09:31:55 openstackgerrit Lajos Katona proposed openstack/nova master: WIP: Add nested resources to server moving tests https://review.openstack.org/527728
09:37:07 openstackgerrit Yikun Jiang (Kero) proposed openstack/python-novaclient master: Microversion 2.58 - Instance actions list pagination https://review.openstack.org/528601
09:41:13 mdbooth lyarwood: https://review.openstack.org/#/c/460243/6 interesting.
09:41:50 mdbooth lyarwood: For the other recent encryptor bug, I was thinking of folding attach/detach encryptor into attach/detach volume
09:42:07 mdbooth So the caller would never actually worry about encryptors at all, just volumes.
09:42:25 mdbooth Which is nearly where you've gone with that. Any reason not to go all the way?
09:43:23 lyarwood mdbooth: iirc just booting from a volume wouldn't call attach/detach volume
09:43:32 lyarwood mdbooth: see _create_domain_and_network
09:44:54 mdbooth lyarwood: That's a bug, though, right?
09:45:32 mdbooth In that, that specifically was the cause of the other problem. We worked round it.
09:45:33 lyarwood mdbooth: why? you can't attach to a domain that isn't running
09:45:34 gibi maciejjozefczyk: only 3 working day left for me from this year so I this is my last work Monday, therefore I feel happy :)
09:46:28 mdbooth lyarwood: How do we boot from volume?
09:46:59 mdbooth Do we not call attach in that flow?
09:49:00 lyarwood mdbooth: pretty sure we don't, we just connect the volume and encryptors before starting the domain
09:49:16 maciejjozefczyk gibi: Good for you :)
09:50:24 mdbooth Although I guess the binding would be specifically to connect/disconnect
09:50:48 kashyap If anyone looking for a simple +2 to warm up their Monday - https://review.openstack.org/#/c/527691/
09:50:53 mdbooth Mounting a volume on a host without connecting its encryptor would always be a bug, I think
09:51:06 mdbooth lyarwood: Anyway, I'm not saddling up for a -1 on your patch for this :)
09:51:40 mdbooth lyarwood: I'd just been looking at combining this logic recently to make it harder to make mistakes.
09:51:55 mdbooth And you're simplifying it somewhat here, which is good.
10:00:58 mdbooth lyarwood: incidentally, I suspect all connect calls go through driver._connect_volume
10:02:12 mdbooth So if the arguments lined up, I'd put the volume encryptor stuff in there, and remove all other calls.
10:03:07 mdbooth That makes sense to me, anyway. May require some refactoring to make reality match theory.
10:04:34 lyarwood mdbooth: urgh that's going to mess with the exception handling we currently have
10:11:47 openstackgerrit Surya Seetharaman proposed openstack/nova master: update_cell allows more than once cell to have the same db/transport url https://review.openstack.org/518556
10:13:42 mdbooth lyarwood: Doesn't need to happen now, I'm just firming up a related idea.
10:13:57 mdbooth Although I do think it would be much more robust.
10:15:10 lyarwood mdbooth: kk, tbh my own reason for doing this refactor is to limit the number of conditionals when switching to native LUKS via QEMU
10:15:14 lyarwood only*
10:59:51 openstackgerrit Chen Hanxiao proposed openstack/nova master: libvirt: don't call sync_guest_time if qga is not enabled https://review.openstack.org/524836
11:54:24 openstackgerrit Yikun Jiang (Kero) proposed openstack/python-novaclient master: Microversion 2.58 - Instance actions list pagination https://review.openstack.org/528601
12:22:30 openstackgerrit Claudiu Belu proposed openstack/nova master: tests: autospecs all the mock.patch usages https://review.openstack.org/470775
12:42:43 openstackgerrit Claudiu Belu proposed openstack/nova master: tests: autospecs all the mock.patch usages https://review.openstack.org/470775
12:59:30 openstackgerrit sahid proposed openstack/nova master: libvirt: disconnect volume from host during detach https://review.openstack.org/515008
13:13:59 openstackgerrit Artom Lifshitz proposed openstack/nova master: DNM: Test making column Text -> MediumText without migration https://review.openstack.org/528712
13:40:18 leakypipes edleafe: mornin. we doing a scheduler meeting today?
13:41:02 cdent leakypipes: do you want one, or are you more about trying to manage your schedule?
13:41:14 leakypipes cdent: more managing my schedule
13:41:24 leakypipes cdent: and just curious who's here :)
13:41:29 leakypipes cdent: and good morning sir
13:41:38 cdent mawrnin'
13:43:02 cdent I am basically here, but still have not shed my cold.
13:46:02 bauzas cdent: leakypipes: honestly, I'm working on implementing the VGPU change, so only if needed, I'd prefer to work
13:46:17 leakypipes ack
13:46:39 bauzas shit for libvirt btw
13:47:15 bauzas cdent: <3
13:48:08 cdent this is what I'm going to do henceforth: hang out in irc and pass people nice stuff.
13:52:20 bauzas cdent: thanks for the hot cocoa https://photos.app.goo.gl/qLBp2ZnFcJc2pvAp2
13:58:15 edleafe leakypipes: yes, this is the last meeting of the year
13:58:26 edleafe and plug your leak
13:58:51 stephenfin bauzas, leakypipes: I've a question on the PCI NUMA policies spec for the two of you
13:59:09 bauzas ack
13:59:20 leakypipes stephenfin: yes>?
13:59:29 stephenfin Per leakypipes' comments, I've been moving the storing of the resulting policy to the InstancePCIRequests object
13:59:52 alex_xu leakypipes: morning, do we still need a separate microversionf or the traits parameter in allocationcandidates, or Eric's granular request's patch will cover that?
14:00:17 stephenfin But that's thrown up a question cfriesen had asked me previously - should we be doing this policy configuration on an instance-level basis or on a PCI request-level basis?
14:00:59 leakypipes stephenfin: probably instance-level (i.e. the RequestSpec)
14:01:08 leakypipes alex_xu: scheduler meeting... discuss in there?
14:01:21 alex_xu leakypipes: ok, got it
14:02:02 leakypipes stephenfin: unless the policy knob can be toggled per-device, then of course it would be more appropriate to live in InstancePCIRequest I think. thoughts?
14:02:30 stephenfin leakypipes: I've been avoiding that solely because it involves a lot of rewiring. We don't use RequestSpec objects on any of the code paths where we do NUMA'y scheduling
14:02:47 stephenfin That was cfriesen's suggestion, yes
14:03:08 leakypipes ack
14:03:18 leakypipes stephenfin: InstancePCIRequest it is then. :)
14:03:29 leakypipes stephenfin: it won't *hurt* to put them in there.
14:04:30 stephenfin leakypipes: So that would suggest we don't use flavour extra specs + image metadata, and instead extend '[pci] aliases' to allow for a 'numa_policy' field, right?
14:05:42 leakypipes stephenfin: unfortunately, since that is how PCI device requests are constructed. :(
14:06:45 stephenfin leakypipes: Yeah, that thing is ugly as sin. Cool, I'll rework this as appropriate so and fix up the spec to reflect reality
14:09:06 leakypipes stephenfin: danke
14:34:32 bauzas leakypipes: crazy problem, since libvirt allows the possibility to create mediated devices on the fly and just assign them, I need to introspect all the mediated devices we have and see whether they are assigned to a guest
14:34:55 bauzas leakypipes: in theory, a magical libvirt API would just tell me if it's assigned or not, but that's not existing
14:35:27 bauzas leakypipes: so the only way I found would be to loop over all the instances and see their XML
14:36:03 bauzas leakypipes: worst case scenario, one created mdev and 10K instances on a host, you can imagine the performance to find which guest is assigned to that mdev
14:36:30 bauzas leakypipes: so, tbh, the only reasonable way I see is to persist the guest assignment information we do in nova
14:37:09 bauzas and consider that if for some specific mdev, we don't have the assignment in the Nova DB, then it means it's free to be allocated
14:37:09 ildikov mriedem: hi
14:37:26 bauzas leakypipes: but you see my point, it would require some persistence model...
14:37:38 ildikov mriedem: IIRC you were pointing me at some point to a review that added some locking similar to what I will need to add for multi-attach
14:37:40 bauzas thoughts on that ?
14:38:18 ildikov mriedem: in case it really is a memory and not a dream and you know what I'm talking about it would be great if you could point me to that one again :)
14:39:48 ebbex mdbooth: nova/virt/libvirt/imagecache.py function "_scan_base_images", should that have changes/deprecations in pike?
14:40:02 mriedem ildikov: i think that's pseudocode in the multiattach spec
14:40:07 bauzas leakypipes: wait, I think about a possible way to hack that without needing to persist that
14:40:17 mdbooth ebbex: Yep, but mriedem wanted changes and I never followed it up.
14:40:30 mdbooth ebbex: Lemme dig out the review, maybe you have time
14:40:44 ildikov mriedem: oh, ok, I will re-read that one again then :)

Earlier   Later