| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-05-23 | |||
| 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 | |
| 19:38:22 | efried | And this is the best way to "fix" the bug? Deprecating/removing the ability to specify a device by name? | |
| 19:38:33 | sean-k-mooney | but also the name can somethime change after it rebound | |
| 19:38:42 | sean-k-mooney | efried: ya basically | |
| 19:38:46 | efried | are there not scenarios where identifying a device by name *doesn't* break? | |
| 19:39:02 | efried | (s/not// for same meaning with fewer negatives) | |
| 19:39:21 | sean-k-mooney | it only works if the device is reliable bound back to the nic driver when nolonger used by the guest and the name does not change whne it rebound to the host | |
| 19:39:37 | sean-k-mooney | so it can work but its really fragile | |
| 19:40:28 | sean-k-mooney | using vendor id and product id or useing the pci address are both more robost as they dont depned on teh driver or the semanitc of the nic vendor | |
| 19:40:39 | efried | sean-k-mooney: I guess what I would do in this case is write the patch and start a thread on the ML with your intent, soliciting opinions on whether this is okay to kill. Link the patch and ML thread from each other. IMO that's sufficient paperwork. And if someone thinks otherwise, you can always write a bug/bp later. | |
| 19:41:21 | efried | though it sounds like what you're talking about actually *is* a bug, and this is just one possible remedy. | |
| 19:41:33 | sean-k-mooney | efried: ok sound good. | |
| 19:41:54 | efried | In my ignorance, another remedy could be "blow up if devname is used for devices it has the potential to break on" | |
| 19:42:02 | sean-k-mooney | it depend on how you configre your driver at the kernel levle | |
| 19:42:17 | sean-k-mooney | and to some extent the nic vendor | |
| 19:42:20 | efried | no way to detect it, other than going all the way through until you hit the bug?? | |
| 19:42:47 | sean-k-mooney | i belive intel nics prefer the networkign driver over vfio-pci but i think it depend on the model to some extend and your udev rules | |
| 19:43:57 | sean-k-mooney | efried: the main issue comes down to will udev/systemd chose to bind the driver to i40e or leave it bound to vfio-pci | |
| 19:44:27 | sean-k-mooney | so its not really a nova issue | |
| 19:44:43 | sean-k-mooney | its more a distro/packaging/install/confituion thing on the host | |
| 19:45:13 | sean-k-mooney | which is what make it hard for nova to dectet and or warn about | |
| 19:45:15 | efried | tasker: Does | |
| 19:45:15 | efried | [DEFAULT] | |
| 19:45:15 | efried | default_log_levels = nova=WARNING | |
| 19:45:15 | efried | not work? | |
| 19:46:00 | efried | sean-k-mooney: ack, and shrug. I hope we can soon deprecate *all* of [pci]passthrough_whitelist and [pci]alias. | |
| 19:46:14 | sean-k-mooney | efried: maybe in U | |
| 19:46:37 | sean-k-mooney | of course then we woudl have a cyborg whitelist and device profile | |
| 19:46:46 | sean-k-mooney | but then its there problem :) | |
| 19:46:50 | efried | heh | |