| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-19 | |||
| 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: Introduce disk encryption config classes https://review.openstack.org/464008 | |
| 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: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. | |
| 13:28:38 | mdbooth | lyarwood: The pattern of those tests is xml=old xml | |
| 13:29:01 | mdbooth | new_xml = s/old thing/thing which should be changed upon migration in this test/ | |
| 13:29:17 | mdbooth | assert(we got new_xml) | |
| 13:30:34 | mdbooth | I didn't look hard at why the test above would expect device name to change on live migration. I can't imagine why we'd ever want that. However, it's SEP right now. | |
| 13:31:11 | lyarwood | mdbooth: ah, the sdb / sdc thing is also a migrate_data thing | |
| 13:31:26 | mdbooth | Yes. It's passed in. | |
| 13:31:32 | lyarwood | mdbooth: so it's the target device changing | |
| 13:31:32 | mdbooth | Still looks bogus. | |
| 13:31:36 | lyarwood | mdbooth: not in the instance | |
| 13:31:50 | lyarwood | mdbooth: so on the host, the block device is just wired up under /dev/sdc | |
| 13:31:53 | lyarwood | mdbooth: that's valid | |
| 13:31:59 | lyarwood | mdbooth: just confusing as the test is using rbd | |
| 13:32:04 | mdbooth | Ah... you looked harder :) | |
| 13:32:17 | mdbooth | Ok, that makes sense | |
| 13:32:47 | Spazmotic | fried_rice, it also feels a little bit like they intended to use the zeroing out of the resources in the allocation for something but forgot. If no allocations are set for a tenant it assumes you want a clean sweep so it goes through and sets them all to 0, but then goes through and deletes them anyway from the dB after that | |
| 13:33:13 | mdbooth | lyarwood: Anyway, following the pattern of those tests, the search/replace we want to see there is old secret for new secret | |
| 13:33:16 | Spazmotic | Kinda wierd.. i'll need to continue looking but it's almost time for me to head to bed and dream about the process hehe | |
| 13:33:23 | lyarwood | mdbooth: ack, done | |
| 13:33:26 | fried_rice | Spazmotic That may have been for the original migration case | |
| 13:34:11 | fried_rice | Spazmotic Which was found to have some pretty hairy implications (read: bugs). Which is why we introduced the POST API there, to allow us to "move" the allocations from one consumer to another in a single atomic operation. | |
| 13:34:34 | fried_rice | dansmith and cdent (neither of whom is here at the moment) ought to be able to shed more light on what happened there. | |
| 13:35:11 | lyarwood | mdbooth: re https://review.openstack.org/#/c/523958/15/nova/tests/unit/virt/libvirt/test_driver.py@10526 - the only values of src_supports_native_luks are True and None, testing both of these above | |
| 13:35:28 | Spazmotic | Sounds good sir.. i'll continue to poke it and will read scrollback when I wake up to see if anything new :) | |
| 13:35:43 | mdbooth | lyarwood: Is it never set to False? | |
| 13:35:56 | Spazmotic | I see now what you mean about the migrations.. that would be useful in that case. | |
| 13:36:02 | fried_rice | Spazmotic But I can definitely see the need for concurrency management of allocations; and also the usefulness of a more granular API to add/remove/update individual allocations - but concurrency management would have to be a prereq of that. | |
| 13:36:09 | lyarwood | mdbooth: https://review.openstack.org/#/c/523958/15/nova/virt/libvirt/driver.py@6253 - nope | |
| 13:36:19 | lyarwood | mdbooth: it's really checking that n-cpu is >= Queens | |
| 13:36:33 | lyarwood | mdbooth: not that the src host can actually decrypt LUKS via QEMU | |