| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-08-11 | |||
| 13:38:22 | openstackgerrit | Stephen Finucane proposed openstack/nova master: manager: Move context manager up one level https://review.opendev.org/745674 | |
| 13:38:22 | openstackgerrit | Stephen Finucane proposed openstack/nova master: compute: Add type hints for resize functions https://review.opendev.org/745341 | |
| 13:38:22 | openstackgerrit | Stephen Finucane proposed openstack/nova master: Don't unset Instance.old_flavor, new_flavor until necessary https://review.opendev.org/744958 | |
| 13:38:22 | openstack | bug 1879878 in OpenStack Compute (nova) "VM become Error after confirming resize with Error info CPUUnpinningInvalid on source node " [Medium,In progress] https://launchpad.net/bugs/1879878 - Assigned to Stephen Finucane (stephenfinucane) | |
| 13:38:22 | openstackgerrit | Stephen Finucane proposed openstack/nova master: tests: Add reproducer for bug #1879878 https://review.opendev.org/744950 | |
| 15:15:49 | sean-k-mooney | stephenfin: lyarwood can i get some priority review on https://review.opendev.org/#/c/738432/ | |
| 15:16:13 | sean-k-mooney | i want to get that backported sooner rather then later | |
| 15:16:20 | sean-k-mooney | perferably strating it this week | |
| 15:17:19 | sean-k-mooney | i would like to see if we can get that in 16.1.1 maybe 16.1.2 downstream but would prefer to do that by backporting upstream | |
| 15:17:44 | sean-k-mooney | this only need to go back to train but its important to fix | |
| 15:51:08 | artom | melwitt, if you're online already, could you give https://review.opendev.org/#/c/743710/5 a look? It's blocking a bugfix on top | |
| 16:59:45 | sean-k-mooney | alex_xu: maybe you could take a look at the patch artom linked above ^ https://review.opendev.org/#/c/743710/5 | |
| 16:59:54 | sean-k-mooney | if melwitt is not about | |
| 17:00:13 | sean-k-mooney | its pretty small and would be nice to get landed to unblock the other | |
| 17:20:34 | melwitt | artom, sean-k-mooney: I can look if no one else gets to it first | |
| 17:20:41 | artom | melwitt, cheers! | |
| 17:37:09 | lyarwood | sean-k-mooney: I'll look this evening | |
| 17:38:23 | artom | lyarwood, you can't, you're the author | |
| 17:38:44 | artom | With gibi and bauzas on PTO, melwitt and alex_xu are the only 2 cores who can +A it | |
| 17:43:38 | melwitt | and dansmith | |
| 17:47:00 | dansmith | artom: ouch artom, ouch | |
| 17:47:16 | artom | dansmith, not my fault you're off in 1/4 U2 land | |
| 17:47:24 | artom | U0.5 | |
| 17:53:35 | lyarwood | artom: sorry I was talking about another patch | |
| 17:53:49 | artom | lyarwood, whoops, apologies, here I go assuming stuff | |
| 17:53:51 | lyarwood | https://review.opendev.org/#/c/738432/ | |
| 17:54:14 | artom | dansmith, aww, thanks, you're bumped to U1 now ;) | |
| 17:56:35 | artom | You think I'm just going to stop making lame puns? | |
| 19:04:52 | openstackgerrit | Merged openstack/nova stable/queens: objects: Update keypairs when saving an instance https://review.opendev.org/743271 | |
| 19:55:02 | lyarwood | sean-k-mooney: http://paste.openstack.org/show/796745/ - getting this in a two node stable/queens env, any ideas? | |
| 19:55:45 | openstack | Launchpad bug 1749972 in os-vif "`brctl setageing $bridge 0` fails on Ubuntu 16.04 4.4.0-21-generic" [Undecided,Invalid] | |
| 19:55:45 | lyarwood | https://bugs.launchpad.net/os-vif/+bug/1749972 - of course I've hit this before lol | |
| 19:56:09 | lyarwood | virt-builder is both awesome and a PITA sometimes | |
| 19:57:31 | openstackgerrit | Merged openstack/nova master: func: Introduce a server_expected_state kwarg to InstanceHelperMixin._live_migrate https://review.opendev.org/743710 | |
| 20:48:43 | openstack | bug 1879787 in OpenStack Compute (nova) "post_live_migration does not handle Neutron errors" [Medium,In progress] https://launchpad.net/bugs/1879787 - Assigned to Artom Lifshitz (notartom) | |
| 20:48:43 | openstackgerrit | Merged openstack/nova master: Add regression test for bug 1879787 https://review.opendev.org/741230 | |
| 21:55:12 | sean-k-mooney | lyarwood: just so its still on your list https://review.opendev.org/#/c/738432/ :) | |
| 21:59:39 | artom | sean-k-mooney, FWIW it's on mine, I normally do reviews on Thursdays | |
| 21:59:48 | artom | (yes, I've compartmentalized my week like that) | |
| 21:59:57 | artom | Tbh, it would help if the commit message was in better English :/ | |
| 22:00:17 | sean-k-mooney | artom: cool but i would really like to get that merged before the end of the week | |
| 22:00:24 | artom | No shade on the original author, I realize writing commit messae (or anything, really), in a second language is hard | |
| 22:00:49 | artom | sean-k-mooney, it's not your patch though... are you going to iterate on it? | |
| 22:01:22 | sean-k-mooney | if need but i want to get this downstream into 16.1 sooner rather then later | |
| 22:01:30 | sean-k-mooney | i have just been trying to get people to review | |
| 22:01:51 | sean-k-mooney | i tested the first verision but i need to retet the latest version | |
| 23:45:43 | artom | nova-grenade-multinode just failed twice in a row with apparently the same errors | |
| #openstack-nova - 2020-08-12 | |||
| 02:12:31 | artom | Dammit, again. Looks like it's a real thing, will debug tomorrow. | |
| 02:50:13 | melwitt | artom: http://lists.openstack.org/pipermail/openstack-discuss/2020-August/016446.html | |
| 07:34:39 | openstack | bug 1891274 in OpenStack Compute (nova) "100% of nova-grenade-multinode zuul task run failed" [High,New] https://launchpad.net/bugs/1891274 | |
| 07:34:39 | brinzhang | sean-k-mooney, dansmith, stephenfin, gmann: report bug 1891274 | |
| 07:35:11 | openstack | Launchpad bug 1891244 in OpenStack Identity (keystone) "*-grenade-multinode jobs fail with UnicodeDecodeError: 'utf-8' codec can't decode byte 0x87 in position 3: invalid start byte" [Undecided,In progress] - Assigned to melanie witt (melwitt) | |
| 07:35:11 | melwitt | I already reported that here https://launchpad.net/bugs/1891244 | |
| 07:37:46 | openstack | bug 1891274 in OpenStack Compute (nova) "100% of nova-grenade-multinode zuul task run failed" [High,New] https://launchpad.net/bugs/1891274 | |
| 07:37:46 | brinzhang | melwitt: is it the same thing? bug 1891274 said the nova-grenade-multinode task failed | |
| 07:37:49 | brinzhang | will check | |
| 07:38:50 | melwitt | yes, it should be the same thing. and nova-grenade-multinode passes with the fix I proposed to keystone https://review.opendev.org/745752 | |
| 07:42:11 | brinzhang | melwitt:ack, thanks, after this patch merged, and I will set this bug to repeat | |
| 08:13:19 | tosky | melwitt: for the record, cinder is impacted by the msgpack bump too | |
| 08:13:25 | tosky | melwitt: namely here: https://zuul.opendev.org/t/openstack/builds?job_name=cinder-grenade-mn-sub-volbak&project=openstack/cinder | |
| 08:22:34 | sean-k-mooney | this looks like a byte vs text type issue | |
| 08:23:15 | sean-k-mooney | the fix looks straitgh forward if you can find the correct place to do it | |
| 09:44:23 | sean-k-mooney | dumb question | |
| 09:44:40 | sean-k-mooney | is there any reason we cant support resize for shelved instances | |
| 09:45:15 | sean-k-mooney | it would just be a flavor update in the db right and asserting there are no conflict with the image | |
| 10:19:09 | sean-k-mooney | in the shelve offloaded case that is | |
| 13:01:55 | kklimonda | is there a... saner way to extend nova APIs than forking entire repo? We have a rather specific set of requirements for spawning new instances that can't really be done with just the oslo_policy | |
| 13:11:58 | gmann | kklimonda: you cannot extend the APIs with upstream code, forking is anyways you can do anything. if i understand correctly, you do not want oslo policy checks in API right? | |
| 13:12:44 | kklimonda | @gmann well, oslo_policy can't really handle our usecase by itself | |
| 13:13:25 | gmann | policy checks are configurable and you can allow API to everyone acess | |
| 13:42:51 | openstack | Launchpad bug 1854992 in OpenStack Compute (nova) "Frequent instances stuck in BUILD with no apparent failure" [Undecided,Incomplete] | |
| 13:42:51 | sean-k-mooney | melwitt: bnemec by the way i finally got aroudn to trying to repoduce https://bugs.launchpad.net/nova/+bug/1854992 since we are talking about adding a ping | |
| 13:43:18 | sean-k-mooney | melwitt: bnemec deleting the queue will not triggere it because oslo messaging just recreates the queue | |
| 13:43:49 | sean-k-mooney | melwitt: bnemec but unbinding the queue form the topic does break the ablity for the compute node to recive rpcs | |
| 13:44:16 | sean-k-mooney | but its still considered alive since it can still send the heartbeats back fine | |
| 13:53:53 | sean-k-mooney | melwitt: bnemec can you let me know what you think of the two options to fix this? | |
| 13:58:34 | kklimonda | @gmann right, but policy checks don't receive much context about server create request, and without that I can't really say whether it should be allowed or denied | |
| 14:00:22 | gmann | kklimonda: ohk, currently we pass only project-id, user-id and AZ - https://github.com/openstack/nova/blob/5b79ec8670619ece92ac8bb43d84d2412778a182/nova/api/openstack/compute/servers.py#L648 | |
| 14:00:57 | gmann | kklimonda: we can add more targets there to enhance the policy control | |
| 14:01:22 | gmann | or pass instance object itself for wider use case | |
| 14:03:40 | sean-k-mooney | dpending on what api it is you might not have an instance objet at the policy time but you do get one failrly quilcly. the build request or request spec might work in those casess | |
| 14:03:48 | sean-k-mooney | im thinking of create server | |
| 14:04:07 | sean-k-mooney | but for other apis we proably could pass the instance object ya | |
| 14:04:18 | gmann | sean-k-mooney: yeah, the request body of instance request we can pass in case of create server | |
| 14:05:11 | sean-k-mooney | yes ideally we would pass a copy too | |
| 14:05:12 | gmann | or best will be add attr by attr based on use case we get to know | |
| 14:05:15 | sean-k-mooney | so that you can modify anything | |
| 14:05:23 | gmann | true | |
| 14:05:29 | sean-k-mooney | *can't | |
| 14:06:09 | sean-k-mooney | body looks like its a dict | |
| 14:06:36 | sean-k-mooney | for this kind of think i generally prefer to be lazy and pass the whole thing | |
| 14:06:48 | sean-k-mooney | rahter then attr by attr | |
| 14:06:58 | sean-k-mooney | but it depned on how strong a contract we want to give | |
| 14:07:21 | sean-k-mooney | e.g. if we change a field name if we just pass the body it can break things | |
| 14:07:26 | sean-k-mooney | so there is a trade off there | |
| 14:07:35 | gmann | yeah, for some APIs that is ok but for many passing everything is just unnecessary for oslo policy | |
| 14:07:36 | sean-k-mooney | at least form an upgrades point of vew | |
| 14:08:11 | gmann | you mean if API change the request attr etc? | |
| 14:08:35 | gmann | and overridden policy were relying on that | |
| 14:08:55 | sean-k-mooney | if we renamed say body['os:scheduler_hints'] to body['os:scheduler_hint'] and the polocy was relying on that then it would break | |