| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-05-23 | |||
| 13:30:37 | efried | what this means to you is: no reason to hold off "moving" those traits in your patch. | |
| 13:31:51 | openstackgerrit | Adam Spiers proposed openstack/nova master: Move patch_exists() to nova.test.TestCase for reuse https://review.opendev.org/660500 | |
| 13:32:08 | aspiers | efried: ^^^ this feels like the cleanest approach to me | |
| 13:33:01 | kashyap | efried: Thank you ... "For backward compatibility reasons, we have to continue exposing those versions of those traits" :-) | |
| 13:33:05 | aspiers | efried: I'm working on something similar for open() | |
| 13:33:17 | aspiers | but for now I need to go vote and get lunch. biab | |
| 13:33:35 | kashyap | efried: So my patch, shall I go back to making it a new PS of the older PS to preserve history? (Sorry for not doing that to begin with) | |
| 13:33:53 | kashyap | Or shall I just mention it in this new one, saying: "please read here for history"? | |
| 13:34:06 | efried | I would like someone libvirt-y, like stephenfin and aspiers, to have a look at that solution and make sure it's not insane. | |
| 13:34:25 | efried | kashyap: I would like it all kept in the original patch please. | |
| 13:34:42 | efried | aspiers: Well, you were the last one to touch the CPU_TRAITS_MAPPING anyway :) | |
| 13:34:47 | aspiers | true | |
| 13:35:08 | aspiers | reminder to self: voting and lunching means not being here :-/ | |
| 13:35:10 | kashyap | efried: Will keep it in the original (then you need to update your PS, too) | |
| 13:35:37 | efried | kashyap: Thanks. Yeah, at this point I've proven the concept; I'll just wait until your patch is merged and released and then update mine properely. | |
| 13:35:39 | efried | properly | |
| 13:35:44 | efried | (sean-k-mooney moment) | |
| 13:36:18 | kashyap | efried: Yeah, noted. Tomm I'm off the afternoon. Can get to it only next week. Since there's no urgency here, hope that's OK | |
| 13:36:39 | efried | kashyap: Sure, that's fine, no hurry from my end | |
| 13:36:45 | kashyap | efried: Also you might want to have a gander at this (which I'll submit as a doc to Nova): https://kashyapc.fedorapeople.org/Nova-Mitigation-for-Intel-MDS-Flaws.txt | |
| 13:37:58 | openstackgerrit | Dan Smith proposed openstack/nova master: Make nova-next archive using --before https://review.opendev.org/661002 | |
| 13:39:35 | efried | kashyap: lgtm | |
| 13:39:49 | efried | I'll have a few comments when it's up in gerrit | |
| 13:39:58 | efried | but overall clear and concise | |
| 13:40:23 | kashyap | efried: Thx; sure. Posting a variant of it now...before I forget. | |
| 13:40:43 | kashyap | Anything that improves clarity. | |
| 13:42:02 | mfeder | # as regular user : | |
| 13:42:02 | mfeder | E.g. | |
| 13:42:02 | mfeder | I would like to access regular-user's key pair using admin user. | |
| 13:42:02 | mfeder | Is there any option how to execute command as another user (linux way : "sudo -u user `command`") ? | |
| 13:42:02 | mfeder | Hi all, | |
| 13:42:03 | mfeder | # as admin user: | |
| 13:42:03 | mfeder | `openstack keypair create kp1` | |
| 13:42:04 | mfeder | `openstack keypair show kp1 ` | |
| 13:42:38 | mfeder | Thanks for any hint ! | |
| 13:44:49 | mfeder | There seems to be an option in the nova API to specify a user ID for keypair requests: https://developer.openstack.org/api-ref/compute/?expanded=list-keypairs-detail,create-or-import-keypair-detail#keypairs-keypairs But I don't know how to do this via `openstack` command | |
| 13:55:06 | frickler | mfeder: there's a patch proposed for that, so currently it isn't possible yet, see https://review.opendev.org/576507 . you may want to ask dtroyer or mordred in #openstack-sdks for help with getting this merged and released | |
| 13:56:01 | mfeder | frickler: Thank you ! | |
| 14:09:07 | openstackgerrit | Merged openstack/nova stable/stein: Skip _exclude_nested_providers() if not nested https://review.opendev.org/659206 | |
| 14:36:21 | mordred | frickler: wow. that's 10 months old | |
| 14:37:10 | frickler | mordred: yeah, progress in osc land is ... not fast | |
| 14:37:12 | efried | aspiers: +2, some tweaks if you feel so inclined. | |
| 14:38:17 | openstackgerrit | Merged openstack/python-novaclient master: Set the lower limit of api_version for volume_type https://review.opendev.org/660861 | |
| 14:43:07 | mriedem | get'ya simple perf optimizations hey! https://review.opendev.org/#/c/651647/ | |
| 14:54:21 | openstackgerrit | Brin Zhang proposed openstack/python-novaclient stable/stein: Set the lower limit of api_version for volume_type https://review.opendev.org/661024 | |
| 14:57:06 | openstackgerrit | Adam Spiers proposed openstack/nova master: Move patch_exists() to nova.test.TestCase for reuse https://review.opendev.org/660500 | |
| 14:57:21 | aspiers | efried: ^^^ | |
| 14:58:01 | aspiers | doh | |
| 14:58:04 | aspiers | docstring error | |
| 14:58:58 | openstackgerrit | Adam Spiers proposed openstack/nova master: Move patch_exists() to nova.test.TestCase for reuse https://review.opendev.org/660500 | |
| 14:59:27 | efried | yeah, you could even remove the word 'static' entirely to convey the meaning. | |
| 14:59:36 | efried | as the call doesn't change regardless | |
| 14:59:43 | aspiers | true | |
| 14:59:49 | aspiers | well, it says "static method" now | |
| 14:59:54 | aspiers | that should be good enough | |
| 14:59:58 | efried | yup | |
| 15:00:09 | efried | stephenfin: easy and fun if you're so inclined --^ | |
| 15:00:58 | aspiers | I hadn't previously realised that @contextlib.contextmanager gives you something which can be both a decorator and a context manager. Pretty nice | |
| 15:05:35 | efried | I didn't know that either. TIL | |
| 15:13:09 | aspiers | this is comically wrong https://www.stackalytics.com/?metric=commits&release=train&project_type=all&module=nova | |
| 15:13:41 | aspiers | efried: if there were only 16 commits so far this release, I guess you'd be feeling a lot more relaxed :) | |
| 15:14:16 | aspiers | I've already reported the issue, BTW | |
| 15:20:40 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Avoid unnecessary joins in InstanceGroup.get_hosts https://review.opendev.org/661032 | |
| 15:20:43 | mriedem | another easy optimization ^ | |
| 15:26:06 | efried | aspiers: Yup, saw the thread, thanks for reporting. | |
| 15:26:26 | mriedem | mlavalle: sean-k-mooney: btw i fixed the revert cross-cell cold migration port binding thing from the other day - activating the source host binding before deleting the dest host binding did the trick as expected | |
| 15:29:42 | mlavalle | mriedem: good to know :-) | |
| 15:35:42 | sean-k-mooney | mriedem: cool good to know. i need to add that review serise back to my review queue | |
| 15:36:29 | sean-k-mooney | mriedem:are you are only using the mulitple port binding flow for cross cell by the way or will it now be ussed for all resizes/cold migrations too | |
| 15:36:44 | mriedem | the former | |
| 15:36:50 | sean-k-mooney | ok | |
| 15:37:46 | sean-k-mooney | i guess we can expand it after in U to non cross cell migration too if it makes sense | |
| 15:46:26 | openstackgerrit | Merged openstack/nova-specs master: Train Cycle Themes https://review.opendev.org/657171 | |
| 15:58:55 | openstackgerrit | Matt Riedemann proposed openstack/nova master: libvirt: check job status for VIR_DOMAIN_EVENT_SUSPENDED_MIGRATED event https://review.opendev.org/594527 | |
| 16:06:10 | openstackgerrit | Matt Riedemann proposed openstack/nova master: WIP: Enable cross-cell resize in the nova-multi-cell job https://review.opendev.org/656656 | |
| 16:34:49 | stephenfin | efried: I have a "remove-nova-consoleauth specless blueprint" topic on the agenda for the team meeting today but I won't be around (it's 10pm my time). If you've any questions, stick my nick in there and I'll revisit tomorrow | |
| 16:36:14 | stephenfin | (*remove-consoleauth, fwiw) | |
| 16:43:00 | efried | stephenfin: roger that. | |
| 16:43:27 | efried | main question was, have we gotten the all-clear from... whoever we thought might care? | |
| 16:44:20 | mriedem | consoleauth != console | |
| 16:44:25 | mriedem | the latter is xen specific | |
| 16:44:27 | mriedem | the former is not | |
| 16:44:32 | efried | o | |
| 16:45:30 | stephenfin | what mriedem said | |
| 16:46:09 | stephenfin | the only reason to keep consoleauth around was cells v1 so that should deem it no longer necessary | |
| 16:46:33 | stephenfin | nova-console and nova-xvpvncproxy and on my chopping block too though but later, after nove-network | |
| 16:46:39 | stephenfin | remove allll the code | |
| 16:47:19 | mriedem | there is also a migration involved in the consoleauth stuff, need to determine if that is done before we remove it, using a blocker migration or something perhaps, | |
| 16:47:29 | mriedem | i know we have an upgrade check but not sure if it fails or warns | |
| 16:49:00 | melwitt | it warns. and I don't think there's a migration about it, just an upgrade status check to advise whether to enable the [workarounds] config option or not | |
| 16:52:11 | mriedem | ok so workarounds.enable_consoleauth is already deprecated, that's good at least | |
| 16:53:54 | mriedem | would we change the upgrade check from warning to failure? | |
| 16:54:27 | mriedem | it only warns if there are non-deleted, enabled nova-consoleauth service records in any cell and there are computes < rocky | |
| 16:55:16 | mriedem | the latter shouldn't be the case by the time someone upgrades to train | |
| 17:07:32 | melwitt | I guess if it would fail for the combo of both service records and computes < rocky, that seems like it would be ok. I wouldn't be sure about failing it for the service records alone, because I'm not sure operators definitely deleted the services after they stopped running nova-consoleauth | |
| 17:13:30 | aspiers | efried: I've got the patch_open() helper ready now - should I submit that separately to switching stuff over to it? | |
| 17:13:52 | efried | aspiers: I don't see why | |
| 17:14:07 | aspiers | so, altogether then? | |
| 17:14:12 | efried | If you've identified instances where it can be used, yeah, fo sho. | |
| 17:14:14 | aspiers | there's a whole bunch of other stuff which could be converted to use patch_exists() too | |