| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-05-23 | |||
| 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 | |
| 17:14:25 | efried | okay | |
| 17:14:38 | efried | up to you, I'm fine either way. | |
| 17:15:08 | aspiers | hah, just found some other reimplementations | |
| 17:17:31 | aspiers | https://opendev.org/openstack/nova/src/branch/master/nova/tests/unit/virt/disk/mount/test_nbd.py | |
| 17:17:41 | aspiers | but those conditions are more specific | |
| 17:17:43 | aspiers | hmm | |
| 17:19:06 | efried | one of them is. the other could be swapped out as it stands. | |
| 17:20:52 | efried | You could juice up patch_exists so the path arg can be a str or a regex :) | |
| 17:21:03 | efried | that would satisfy the other one. | |
| 17:22:22 | efried | oh, no it wouldn't. | |
| 17:22:36 | efried | aspiers: You could make it a str or a callable... | |
| 17:22:47 | efried | starts to smell a lot like side_effect at that point | |
| 17:27:50 | aspiers | efried: yeah, I was thinking of supporting callables, but ... scope creep, I dunno | |
| 17:31:41 | efried | aspiers: Feel free to push it to the wishlist for later. Add a `TODO(aspiers): figure out how to use patch_exists here` and move on. | |
| 17:35:38 | openstackgerrit | Merged openstack/nova stable/stein: Handle placement error during re-schedule https://review.opendev.org/657602 | |
| 17:35:48 | openstackgerrit | Merged openstack/nova stable/stein: Only call _fill_provider_mapping if claim succeeds https://review.opendev.org/657603 | |
| 17:36:53 | aspiers | efried: good idea | |
| 17:42:53 | openstackgerrit | Merged openstack/nova stable/stein: Stop logging traceback when skipping quiesce https://review.opendev.org/660325 | |
| 18:32:16 | ganso | lyarwood: Hi! Could you please take a look at this patch? https://review.opendev.org/#/c/659338 Thanks in advance! | |
| 18:43:46 | openstackgerrit | melanie witt proposed openstack/nova master: Count instances from mappings and cores/ram from placement https://review.opendev.org/638073 | |
| 18:43:46 | openstackgerrit | melanie witt proposed openstack/nova master: Set [quota]count_usage_from_placement = True in nova-next https://review.opendev.org/653146 | |
| 18:43:47 | openstackgerrit | melanie witt proposed openstack/nova master: Use instance mappings to count server group members https://review.opendev.org/638324 | |
| 18:43:47 | openstackgerrit | melanie witt proposed openstack/nova master: Add documentation for counting quota usage from placement https://review.opendev.org/653845 | |
| 19:04:02 | tasker | I'm running Pike and trying to turn the logging level down to WARNING ( instead of the default INFO ), and "verbose = False" no longer works. The documentation at pike/admin/manage-logs.html and pike/configuration/config.html provide non-matching information. | |
| 19:04:45 | tasker | one ( admin ) says to use "log-config" while the other ( configuration ) says "log-config" is deprecated and that all other log items will be ignored if the new "log_config_append" is used. | |
| 19:04:57 | tasker | what's the easiest way to turn Nova's output down to WARNING? | |
| 19:34:10 | sean-k-mooney | efried: do you know what the policy on deprecating parts of config vaules is | |
| 19:34:39 | sean-k-mooney | efried: i want to deprecate and remove one of the ways of whitelisting device in the pci_white_list this cycle | |
| 19:34:51 | sean-k-mooney | efried: specificly the devicename parmater | |
| 19:35:09 | efried | that's interesting. | |
| 19:35:41 | sean-k-mooney | would it need a blueprint and or spec? or jsut a bug ? | |
| 19:35:53 | efried | For something like that, you would just have to note the deprecation in the help text of the opt and in a reno; and add a warning log to the code that parses it. | |
| 19:35:58 | efried | oh, you mean *paperwork* | |
| 19:36:23 | efried | depends, is there a bug? :) | |
| 19:36:28 | sean-k-mooney | ya so we woudl need to keep it around for train and log a warning if its used | |
| 19:36:47 | sean-k-mooney | not for this but there are bugs caused by that parmaater | |
| 19:36:50 | efried | I would think so, yes. | |
| 19:37:32 | sean-k-mooney | the issue is if your kernel is configured not to bind back the PFs/VFs to the nic driver e.g. they stay boudn to vfio | |
| 19:37:52 | sean-k-mooney | then if you restart the compute agent it cant dicover the VFs or PFs again | |
| 19:38:21 | sean-k-mooney | because the PF/VF does not have a netdev and therfore you cant find it by name | |