| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2017-12-20 | |||
| 18:08:21 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/newton: Use instance.project_id when creating request specs for old instances https://review.openstack.org/529389 | |
| 18:08:48 | cdent | mriedem: hmmm, jay's comment from when he added the retry is potentially derailing, he's got a diferent theory of what could be causing the issues: https://github.com/openstack/nova/commit/e001b0538a9d413f864 | |
| 18:10:06 | mriedem | that likely makes more sense, the inventory thing | |
| 18:10:43 | mriedem | but in that case, the deadlock isn't on the insert, it's on the generation update yeah? https://github.com/openstack/nova/commit/e001b0538a9d413f864#diff-a040eef16b56cc7862fb2a334c757deaR1855 | |
| 18:12:02 | cdent | right, which I'm not sure we have any way of knowing | |
| 18:12:59 | cdent | the easiest fix is just simply not doing alloc.id = lastrowid | |
| 18:13:05 | mriedem | http://logs.openstack.org/84/529184/2/check/legacy-tempest-dsvm-py35/888d647/logs/screen-placement-api.txt.gz#_Dec_20_15_15_19_616413 | |
| 18:13:13 | mriedem | Dec 20 15:15:19.616413 ubuntu-xenial-citycloud-lon1-0001533915 devstack@placement-api.service[15195]: DEBUG oslo_db.api [None req-d117a878-c8e0-4c3b-a073-848d73575036 service placement] Performing DB retry for function nova.objects.resource_provider.AllocationList._set_allocations {{(pid=15198) wrapper /usr/local/lib/python3.5/dist-packages/oslo_db/api.py:149}} | |
| 18:13:20 | mriedem | at least it gets logged :) | |
| 18:13:49 | cdent | oh, hmmm | |
| 18:13:59 | cdent | that's saying it is on the insert | |
| 18:14:17 | mriedem | where does it say that? | |
| 18:14:23 | cdent | previous line? | |
| 18:14:30 | mdbooth | artom: Hey, I just added a patch which makes it meaningful to tag a local disk | |
| 18:14:43 | mdbooth | As local disks can now have serial numbers | |
| 18:15:11 | artom | mdbooth, https://review.openstack.org/#/c/529380/? | |
| 18:15:18 | mdbooth | The way disk tagging works, though, is that when deleting disk metadata it 'matches' based on device.serial, which it assumes to be volume_id | |
| 18:15:22 | mdbooth | Although.......... | |
| 18:15:32 | mdbooth | Wait a sec, I might be trying to solve a problem which doesn't exist | |
| 18:15:40 | mdbooth | This is only relevant in detach_volume | |
| 18:15:46 | mdbooth | And as you can't detach a local disk.... | |
| 18:15:49 | mdbooth | There's no problem here | |
| 18:16:26 | mdbooth | artom: That's the one, yeah. | |
| 18:16:36 | mdbooth | artom: Ok, stand down. I don't think this is a thing. | |
| 18:16:43 | mdbooth | However, if you want to review that series ;) | |
| 18:16:53 | artom | Also, if I read your patch correctly, it still uses volume UUID as the serial for volumes | |
| 18:16:56 | artom | So nothing changes there | |
| 18:17:05 | mdbooth | artom: Right, that's correct. | |
| 18:17:12 | artom | Then we should be fine | |
| 18:17:12 | mdbooth | So this will continue to work for detach_volume. | |
| 18:17:23 | mdbooth | But it wouldn't work for detach_ephemeral | |
| 18:17:23 | artom | Let me check whether I included this in the tempest tests | |
| 18:17:29 | mdbooth | ...which doesn't exist. | |
| 18:17:30 | artom | ... | |
| 18:17:34 | artom | which haven't merged yet | |
| 18:17:40 | mdbooth | orly? | |
| 18:17:47 | mdbooth | I need to write tempest tests for my stuff. | |
| 18:17:56 | mdbooth | Can you ping me the reviews? | |
| 18:17:58 | artom | mdbooth, they'll merge in time for brexit | |
| 18:18:20 | artom | mdbooth, https://review.openstack.org/#/c/391947/ | |
| 18:18:44 | mdbooth | artom: You mean they're a complete trainwreck with inexplicable momentum marching inevitably towards their doom? | |
| 18:18:48 | artom | Yeah, they only test the attach case | |
| 18:18:51 | artom | I should add the detach case | |
| 18:19:03 | artom | mdbooth, isn't that all of openstack? ;) | |
| 18:19:19 | mdbooth | Ooh, harsh! :) | |
| 18:19:32 | artom | I'm an arse because I care? | |
| 18:21:14 | mdbooth | artom: Ok, looks like that needs a rebase. | |
| 18:21:47 | mdbooth | I'll take a look at that tomorrow, as I also need to write a test which boots with a tagged root/ephemeral/swap disk. | |
| 18:23:58 | openstackgerrit | rahul bardia proposed openstack/python-novaclient master: nova limits ERROR (Exception): Field names must be unique https://review.openstack.org/527922 | |
| 18:29:13 | artom | mdbooth, sure, thanks :) | |
| 18:29:22 | artom | I'll try to get to yours as well | |
| 18:29:24 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Add nova-status check for ironic flavor migration https://review.openstack.org/527541 | |
| 18:45:34 | rybridges | Hey guys I have a quick question. Is there a way to list all instances for a particular user across all projects? | |
| 18:46:24 | rybridges | Is that what openstack server list --user <username> does? | |
| 18:49:21 | openstackgerrit | Chris Dent proposed openstack/nova master: Do not set allocation.id in AllocationList.create_all() https://review.openstack.org/529397 | |
| 18:49:41 | cdent | mriedem: there's ^ a first stab, I went for the simplest thing, for reasons listed in the commit message, gonna dine now. | |
| 18:52:17 | melwitt | rybridges: it appears so, it might require user uuid. and you might also need to pass --all-projects | |
| 18:53:21 | rybridges | ok | |
| 18:53:27 | rybridges | Thanks i will give it a shot! | |
| 18:55:38 | melwitt | let me know if it doesn't work. not that familiar with openstackclient but a glance at the code looks like it should do what you want | |
| 18:56:59 | rybridges | looks like this works: openstack server list --user rybridges --all-projects | |
| 18:57:09 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Pass RequestSpec to ConductorTaskAPI.build_instances https://review.openstack.org/515495 | |
| 18:57:10 | rybridges | but this does not: openstack server list --user rybridges | |
| 18:57:16 | rybridges | so ya you need --all-projects | |
| 18:58:27 | melwitt | rybridges: okay, thanks for confirming. without --all-projects it will default to filtering that user under the project making the request | |
| 18:58:47 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Pass RequestSpec to ConductorTaskAPI.build_instances https://review.openstack.org/515495 | |
| 18:59:30 | rybridges | that is correct melwitt | |
| 19:04:48 | edleafe | cdent: huh, that was way simpler than I thought it would be. | |
| 19:25:01 | cfriesen | maybe odd python style question, but why does nova code use super(ClassName, self).func() rather than super(type(self), self).func()? | |
| 19:25:43 | melwitt | I dunno. is the latter a more common pattern elsewhere? | |
| 19:26:58 | cfriesen | melwitt: well, in python 3 you can just use super(). the nice thing about the second one is that you don't need to update it if you subclass it and copy/paste a snippet of code. | |
| 19:29:03 | cfriesen | melwitt: heh...some additional googling answered my question. turns out in python2 it needs to be explicit to allow for multiple levels of inheritance. | |
| 19:29:39 | melwitt | ah, okay. now I know | |
| 19:39:22 | cdent | edleafe: I could have made it way more complex, but figured, what's the point? | |
| 19:45:59 | openstackgerrit | Chris Dent proposed openstack/nova master: Do not set allocation.id in AllocationList.create_all() https://review.openstack.org/529397 | |
| 19:46:33 | edleafe | cdent: I'm not disagreeing | |
| 19:47:56 | cdent | I know | |
| 19:50:56 | mriedem | edleafe: i think we're pretty close on https://review.openstack.org/#/c/511358/ but i don't know why you had to modify the FilterScheduler in there | |
| 19:52:50 | mriedem | i think you might be working around something in the claims code in the conductor build_instances method that i pointed out | |
| 19:53:07 | mriedem | also, i think claim_resources might be the wrong method to call from conductor, seems put_allocations is what we want instead | |
| 19:55:15 | cdent | I got things done today, but none of the things I mean to to do, so I'm giving up | |
| 19:55:38 | mriedem | that's most of my days | |
| 19:55:55 | cdent | true | |
| 19:56:14 | cdent | but today seemed especially bad. or maybe I just feel guilty for not doing the stuff I said I'd do for efried_cya_jan | |
| 19:56:16 | cdent | anyway | |
| 19:56:19 | cdent | goodnight | |
| 19:56:26 | SamYaple | /win/win 20 | |
| 20:03:05 | edleafe | mriedem: the filter scheduler change was because the functional tests turned up an issue: that the Selection objects in the alternates had no allocation_request in them. Since the Selection objects weren't used until this patch, it never showed up | |
| 20:03:47 | mriedem | ummm | |
| 20:04:15 | mriedem | edleafe: then what is this? https://github.com/openstack/nova/blob/master/nova/scheduler/filter_scheduler.py#L380 | |
| 20:04:36 | mriedem | i realize the first selected host doesn't have an allocation_request in it https://github.com/openstack/nova/blob/master/nova/scheduler/filter_scheduler.py#L348 | |
| 20:04:51 | mriedem | which you did by design because you said conductor wouldn't need it, because we claim on that host during scheduling | |
| 20:05:01 | mriedem | but the alternates should have the allocation requests | |
| 20:08:59 | openstackgerrit | Chris Dent proposed openstack/nova master: [placement] Enable limiting GET /allocation_candidates https://review.openstack.org/513526 | |
| 20:09:04 | edleafe | mriedem: it looks like when I rebased on your patch, it pulled an older version. I'm not sure how | |
| 20:09:12 | mriedem | also realized just now that the claim logic in conductor won't work for the caching scheduler, which does have alternates but doesn't do claims | |
| 20:09:24 | mriedem | edleafe: ok, it seems like this is easily fixed | |
| 20:09:26 | edleafe | well, maybe no | |
| 20:09:41 | edleafe | yeah, I'll fix it, but I'm curious how that happened | |
| 20:09:53 | mriedem | my guess would just be like you said, rebase wonk | |