| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-19 | |||
| 09:26:22 | Spazmotic | I would love to get my Xenapi piddly poop in the gate this week but I definately don't see it happening hehe. So will just learn Placements code and maybe fix this local delete bug | |
| 09:27:00 | ildikov | bauzas: thanks | |
| 09:27:28 | bauzas | Spazmotic: bugs are not impacted by the queens-3 deadline | |
| 09:27:45 | Spazmotic | Well I just mean because the core reviewers are so busy, sir :) | |
| 09:31:19 | bauzas | Spazmotic: I'm French, we did cut the head of all our lords in the past, so you don't need to call me "sir" | |
| 09:31:28 | bauzas | I'm neither too old nor too lordy | |
| 09:32:07 | Spazmotic | Hehe it's a respect thing, I'll do my best. | |
| 09:47:40 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Recreate mediated devices on reboot https://review.openstack.org/533642 | |
| 09:47:40 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: libvirt: create vGPU for instance https://review.openstack.org/528832 | |
| 09:47:41 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: WIP: Fix suspending guest with attached vGPUs https://review.openstack.org/535693 | |
| 09:47:41 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: libvirt: pass the mdevs when rebooting the guest https://review.openstack.org/533818 | |
| 09:48:15 | Spazmotic | Ah yeah I meant to tell you those hit merge conflictr | |
| 09:48:17 | Spazmotic | Sorry I Forgot | |
| 09:53:11 | bauzas | gibi: need again your +W, I needed to rebase https://review.openstack.org/#/c/528832/ | |
| 09:53:17 | bauzas | (merge conflict) | |
| 09:54:01 | bauzas | gibi: also, I just rebased https://review.openstack.org/#/c/533642 but it lost your +2 due to a merge solve | |
| 09:57:00 | lyarwood | mdbooth: https://review.openstack.org/#/c/523958/11/nova/tests/unit/virt/libvirt/test_driver.py@6604 - remind me again what you mean by autospec here? | |
| 09:57:26 | mdbooth | lyarwood: IIRC I wasn't overly exercised by that as we don't do it consistently | |
| 09:57:41 | mdbooth | However, I was just wondering if you wanted to mock the class with an autospec | |
| 09:57:53 | mdbooth | Which you've done in a few other places, and is generally awesome | |
| 09:57:54 | vish_18 | frickler: hello | |
| 09:58:17 | vish_18 | frickler: https://bugs.launchpad.net/keystone/+bug/1714937. i am not able to reproduce this issue on Pike | |
| 09:58:18 | openstackgerrit | Alex Xu proposed openstack/nova master: placement: support traits in allocation candidates API https://review.openstack.org/535642 | |
| 09:58:18 | openstack | Launchpad bug 1714937 in OpenStack Identity (keystone) "keystone returns 500 on password change" [Low,Confirmed] - Assigned to Vishakha Agarwal (vishakha.agarwal) | |
| 09:59:34 | gibi | bauzas: I will check those soon | |
| 09:59:38 | lyarwood | mdbooth: kk, can you actually do that with @mock.patch directly? | |
| 09:59:41 | vish_18 | frickler: kindly help me to reproduce | |
| 10:00:12 | mdbooth | lyarwood: I think so, but as I say it wasn't a top priority to me | |
| 10:00:21 | bauzas | gibi: cool thanks | |
| 10:00:37 | bauzas | gibi: oh, fuuuuu, did you run a nova meeting yesterday evening ? | |
| 10:00:45 | bauzas | totally forgot it | |
| 10:01:47 | mdbooth | Over my dead body > problem > would prefer > nit > suggestion | |
| 10:02:13 | lyarwood | mdbooth: haha :) | |
| 10:03:05 | lyarwood | mdbooth: cool, so I'm obviously sorting the tests out this morning, I've given up on the P to Q LM tests for now, I think we can add them to the legacy-grenade-dsvm-neutron-multinode-live-migration pretty easily, just can't get grenade to play nice with f26 at the moment | |
| 10:03:18 | gibi | bauzas: no I didn't but I think efried did | |
| 10:03:27 | bauzas | k | |
| 10:03:35 | bauzas | will look at the minutes then | |
| 10:03:44 | mdbooth | lyarwood: Yeah. I wanted to do the tests for you yesterday but got unexpectedly bogged down. Sorry about that. | |
| 10:03:52 | lyarwood | mdbooth: np | |
| 10:11:08 | openstackgerrit | Deepak Mourya proposed openstack/nova master: Handle TZ change in iso8601 >=1.12.0 https://review.openstack.org/535700 | |
| 10:27:24 | gmann | vish_18: better to ask on keystone channel. | |
| 11:41:05 | openstackgerrit | Merged openstack/nova master: Updated from global requirements https://review.openstack.org/535030 | |
| 11:41:20 | openstackgerrit | Merged openstack/nova master: conf: Remove 'vendordata_driver' opt https://review.openstack.org/397835 | |
| 11:47:35 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: QEMU native LUKS decryption for encrypted volumes https://review.openstack.org/523958 | |
| 11:47:57 | lyarwood | mdbooth, stephenfin; ^ if you have time, should be almost ready to go now | |
| 11:48:21 | mdbooth | lyarwood: Looking now | |
| 11:49:44 | lyarwood | hmmm merge conflict, let me rebase the series | |
| 11:50:43 | lyarwood | oh nice, the multi-attach stuff landed overnight :) | |
| 11:52:34 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Collocate encryptor and volume driver calls https://review.openstack.org/460243 | |
| 11:52:35 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: QEMU native LUKS decryption for encrypted volumes https://review.openstack.org/523958 | |
| 11:52:35 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Introduce disk encryption config classes https://review.openstack.org/464008 | |
| 11:52:44 | lyarwood | aaaaaaaaaand done. | |
| 11:57:08 | Spazmotic | There are so few ways to clean up allocations in the current Placement API to a point that i think i'm missing something here | |
| 11:58:57 | Spazmotic | How in the world are single allocations cleaned up.. | |
| 12:02:13 | Spazmotic | ew.. | |
| 12:09:08 | Spazmotic | Ew so it's just zeroing out the allocations | |
| 12:12:34 | Spazmotic | This can't be the openstack way to handle this.. | |
| 12:13:19 | Spazmotic | Allocations are not using the updated_at and deleted_at standards and in order to update an allocation you have to pass the entire list of their current allocations plus changes into the JSON because it purges the entire list for a "Clean slate"? | |
| 12:13:46 | Spazmotic | The only other place i've seen this is how neutron handles Static IP addresses in Ports which isn't so bad since it's an internal dictionary.. not database sets. | |
| 12:14:10 | Spazmotic | This must be ridiculously unwieldy for large consumers.. not to mention dangerous. | |
| 12:15:00 | Spazmotic | And I don't understand why ad esire for a clean slate every time a minor new allocation wants to be set for a consumer. | |
| 12:15:06 | Spazmotic | efried, can you shine any light on this? | |
| 12:18:46 | Spazmotic | This local delete issue.. the best way I can see to resolve this is to allow a new API call to empty a resource provider, but the way that allocations are being handled is incredibly gross and would make that process extremely top heavy. Each alloc per RP would have to pull the consumer, then pull their allocs and reconstruct the allocs without the chosen alloc and then submit the entire list. | |
| 12:24:47 | ttallgren | Hi all, I hit a bug in Nova 17.0.0.1b2 with automated Ansible testing (OPNFV XCI): http://p.ip.fi/a733 | |
| 12:26:05 | rabel | hi there. there seems to be a problem with building the docs in nova. running tox -e docs i get an error message: | |
| 12:26:10 | ttallgren | It is calling nova-manage cell_v2 discover_hosts and the final error is Duplicate entry 'compute01' for key 'uniq_host_mappings0host | |
| 12:26:18 | rabel | nova/nova/policies/config_drive.py", line 46, in <module> deprecated_since='17.0.0'),TypeError: __init__() got an unexpected keyword argument 'deprecated_since' | |
| 12:31:37 | frickler | vish_18: commented on the bug report. also lyarwood is right, this is a keystone issue | |
| 13:05:22 | efried | Spazmotic \o Gimme a sec to catch up... | |
| 13:05:54 | Spazmotic | Hehe no worries.. just trying to make sure I understand correctly because it seems crazy | |
| 13:07:03 | fried_rice | bauzas Yes, I ran the meeting yesterday, such as it was. Got minutes? http://eavesdrop.openstack.org/meetings/nova/2018/nova.2018-01-18-21.00.log.html | |
| 13:09:58 | jaypipes | alex_xu: will make it a priority this morning. | |
| 13:10:10 | fried_rice | gibi Congrats, add self to https://etherpad.openstack.org/p/nova-ptg-rocky attendance list | |
| 13:10:48 | Spazmotic | The korean word for fried rice is 볶음밥 .. for the curious hehehe | |
| 13:13:53 | fried_rice | lyarwood I can help you with autospeccing. Though claudiub is the real expert. | |
| 13:14:10 | claudiub | o/ | |
| 13:14:14 | claudiub | wassup | |
| 13:15:17 | Spazmotic | poor man now I feel bad for spamming you :D | |
| 13:16:17 | fried_rice | Spazmotic Okay, now I'm caught up. But not sure I'm fully understanding which part you're saying is gross. | |
| 13:17:05 | Spazmotic | Doesn't really feel like it follows any of the standards of how we handle data sets generally and doesn't allow for granular level of control over allocations without touching entire consumers data sets | |
| 13:17:07 | Spazmotic | Feels dirty | |
| 13:18:06 | fried_rice | Spazmotic You mean because you have to set/replace an entire consumer_uuid's allocations all at once? | |
| 13:18:12 | Spazmotic | Yeah | |
| 13:18:23 | Spazmotic | Is that really the elegant solution? | |
| 13:18:35 | Spazmotic | I guess i'm not sure what we gain by clean sweeping | |
| 13:19:29 | fried_rice | Spazmotic I can see where that's going to be suboptimal in the long game of placement, where we could have multiple control points managing resources for a single consumer. Each one would have to GET the current state, make its changes, PUT back the changed set, and deal with 409s if a concurrent update beat them to it. | |
| 13:20:17 | fried_rice | Spazmotic I'm guessing it was designed this way as the most expeditious and convenient for the initial use case, which is nova compute host as single resource provider, nova instance as consumer. | |
| 13:21:05 | Spazmotic | It defiantely could get racey, it also allows for less control of allocations except for directly outside of consumers which may make it a little more unwiedy in a larger multi-control point environment for same tenant | |
| 13:22:05 | fried_rice | Spazmotic Actually, yeah, I don't see a consistency marker like we have for traits & inventories. | |
| 13:22:54 | fried_rice | leakypipes Has this been considered ^ ? | |
| 13:23:32 | mdbooth | lyarwood: Hey, found a test problem. Still reviewing but I'm going to drop what I've got right now as I think you need to fix it. | |
| 13:24:49 | lyarwood | mdbooth: the py35 failures? | |
| 13:25:03 | mdbooth | I hadn't even seen those. | |
| 13:25:19 | lyarwood | mdbooth: awesome, so more issues to fix :) | |
| 13:25:20 | mdbooth | The problem in test_migration. I don't think that test is right. | |
| 13:25:28 | lyarwood | mdbooth: kk | |
| 13:27:14 | lyarwood | mdbooth: right, the old secret should be replaced by the new secret but we aren't creating a new secret UUID here, that's just passed in via migrate_data | |
| 13:27:44 | lyarwood | the device replace is odd and something copied over from the above test | |
| 13:28:01 | mdbooth | Yeah, I saw that. It's weird there, too. | |
| 13:28:15 | Spazmotic | Would be very nice if we could extend that API a bit for more functionality and ease of use. | |