| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2019-11-06 | |||
| 22:03:55 | kisahm | nova api/placement shows no errors. | |
| 22:04:13 | kisahm | the request timed out after 90 sec | |
| 22:05:19 | kisahm | openstack queens release, deployed with Juju | |
| 22:07:41 | mriedem | melwitt: dansmith: this isn't bad, but i'm not sure i want to pull the trigger on it - see if you have opinions https://review.opendev.org/#/c/688122/ | |
| 22:07:51 | mriedem | i like the idea of not hitting the synchronized stuff if we have the entry in the cache | |
| 22:10:22 | melwitt | I'm pretty sure Kevin_Zheng proposed the same thing in the past in a simpler way and got nacked. lemme see if I can find | |
| 22:12:11 | kisahm | the nova-api-os-compute.log shows this error: Timed out waiting for response from cell 79275f0e-86b1-4859-aeac-642382585ef4: CellTimeout: Timeout waiting for response from cell | |
| 22:12:57 | mriedem | kisahm: known http://status.openstack.org/elastic-recheck/#1844929 | |
| 22:13:13 | melwitt | mriedem: ^ https://review.opendev.org/#/c/595530/2/nova/context.py | |
| 22:16:00 | mriedem | uh oh, do i see dansmith talking about eventlet + locks in there?! | |
| 22:16:11 | mriedem | dropping that on booth might start a war | |
| 22:16:56 | melwitt | hah | |
| 22:27:28 | kisahm | mriedem does the bug also exists in openstack releases >queens? | |
| 22:28:26 | mriedem | kisahm: logstash says it started in the upstream gate in train, but mostly master jobs | |
| 22:30:20 | mriedem | do people see any issue with this? https://review.opendev.org/#/c/540962/ - if not i'll rev it to add the short release note | |
| 22:30:42 | mriedem | tl;dr allow CONF.enable_new_services to be configured per-host rather than globally | |
| 22:30:52 | mriedem | so you can start some computes as disabled to start but not others | |
| 22:33:16 | efried | mriedem: so previously you would put that in your conductor conf and it would disable all computes? | |
| 22:33:26 | mriedem | yup | |
| 22:33:32 | mriedem | well, newly created computes | |
| 22:34:57 | efried | right | |
| 22:34:59 | efried | hm | |
| 22:35:19 | efried | it's a pretty serious semantic change, really. | |
| 22:36:09 | mriedem | as in, if you used different configs for your controllers and computes, and you had this set in your controllers but not computes, you might now have new enabled comptues where you'd expect them to be disabled b/c you didn't move the config? | |
| 22:36:49 | efried | let me make sure I'm understanding: you would have the option set to False in your compute-side conf, and when you bootstrap your compute, it'll start out disabled; but once you re-enable it, it will stay enabled from that point on -- like, the conf opt will not have an effect on subsequent starts of the service | |
| 22:37:05 | mriedem | it would be ignored if set in compute conf | |
| 22:37:07 | mriedem | as the bug notes | |
| 22:37:16 | efried | I mean in the new world | |
| 22:37:28 | melwitt | yeah, I was thinking similar. I thought usually that sort of thing would have hit the ML. I can't think of any issue with it other than possible confusion, which the release note would address | |
| 22:37:29 | mriedem | correct | |
| 22:37:35 | mriedem | it's only when starting a new service and the record is created | |
| 22:38:04 | efried | different levels of conductor and compute are supported though, right? | |
| 22:38:10 | melwitt | I'd want to ask dansmith if there's any upgrade concerns I'm missing | |
| 22:38:12 | efried | which one upgrades first? | |
| 22:38:15 | mriedem | the whole point is, i want to deploy some new computes but not make them scheduable until i can kick their tires | |
| 22:38:17 | mriedem | then add them to the pool | |
| 22:38:48 | mriedem | efried: doesn't really have anything to do with rpc upgrade levels if that's what you mean | |
| 22:39:09 | efried | no, I mean train conductor, ussuri compute. If the option is set differently, what happens? | |
| 22:39:11 | mriedem | for an upgrade, if you care about this, you'd probably leave it to False in conductor until you upgrade all computes to the new code, then you can remove it from conductor config | |
| 22:39:22 | mriedem | train conductor ussuri compute isn't really a thing | |
| 22:39:42 | efried | okay, vice versa. | |
| 22:39:50 | mriedem | if you had that for some reason, obviously the train conductor code would override | |
| 22:39:58 | efried | "if you care about this" and you remembered that you set it years ago in your conductor conf | |
| 22:40:29 | efried | Have we considered instead creating a *new* opt that's compute-only? Because then I could have the conductor "default" and the per-compute "override". | |
| 22:40:31 | mriedem | once everything is upgraded, having it set in your conductor conf would be a noop | |
| 22:40:37 | efried | yeah, I get that. | |
| 22:40:55 | mriedem | i mentioned moving the option to the [compute] group in a follow up | |
| 22:41:22 | mriedem | i didn't think about 2 options | |
| 22:42:32 | mriedem | i also don't know how much this is even used, so i don't know that we should boil the ocean over it | |
| 22:42:44 | mriedem | but 2 options could be a transition plan | |
| 22:43:01 | mriedem | DEFAULT.enable_new_services gets deprecated, compute.enable_new_services gets added | |
| 22:44:49 | efried | on compute it makes more sense to be singular | |
| 22:53:37 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Improve error log when snapshot fails https://review.opendev.org/356020 | |
| 22:54:07 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Improve error log when snapshot fails https://review.opendev.org/356020 | |
| 23:06:39 | mriedem | stephenfin: remember that when you rebase a patch that contains a bug fix, the bug is automatically assigned to you in launchpad and it's probably good to go back into launchpad and re-assign it to the owner, | |
| 23:07:01 | mriedem | looks like during your old review scan/cleanup you did a lot of rebases for old patches (like the one above) and now you own all of the bugs | |
| 23:22:28 | openstackgerrit | Matt Riedemann proposed openstack/nova master: Regression test for bug 1849657 https://review.opendev.org/693248 | |
| 23:22:29 | openstack | bug 1849657 in OpenStack Compute (nova) " allocation key is missing from the binding:profile of the neutron qos port when the server is created by a non-admin user" [Medium,In progress] https://launchpad.net/bugs/1849657 - Assigned to Balazs Gibizer (balazs-gibizer) | |
| #openstack-nova - 2019-11-07 | |||
| 00:44:15 | donnyd | sean-k-mooney: ioni Would love to see some action in the LXC department. LXC is A awesome and B super useful and C much lighter weight than a full vm... but I also understand it will take a bit to get there | |
| 00:44:29 | donnyd | Happy to anything I can to help move the ball forward on it | |
| 01:54:15 | openstackgerrit | Merged openstack/nova stable/train: Revert "openstack server create" to "nova boot" in nova docs https://review.opendev.org/693241 | |
| 03:07:21 | openstackgerrit | Merged openstack/nova master: Improve error log when snapshot fails https://review.opendev.org/356020 | |
| 07:47:57 | openstackgerrit | Merged openstack/nova master: Remove unused 'nova-dsvm-base' job https://review.opendev.org/688389 | |
| 07:54:30 | openstackgerrit | Merged openstack/nova master: cleanup to objects.fields https://review.opendev.org/688600 | |
| 08:00:23 | openstackgerrit | Adit Sarfaty proposed openstack/nova master: Avoid fetching metadata when no subnets found https://review.opendev.org/679247 | |
| 08:01:31 | gibi_ptg | #nova now Cinder cross project at Cinder's table | |
| 08:01:40 | mnaser | mdbooth: feel free to ping me if you end up starting to discuss the flavors thing today | |
| 08:04:18 | gibi_ptg | mnaser: I will try not to forget to ping you | |
| 08:04:48 | mnaser | gibi_ptg: thanks, do you think it might be today or is it likely going tobe moved onto tomorrow? | |
| 08:15:43 | gibi_ptg | mnaser: it seems we have one topic for cinder cross project so there is still chance to have the flavor discussion today | |
| 08:16:10 | mnaser | gibi_ptg: ok cool, im around | |
| 08:19:00 | mnaser | gibi_ptg: looks like it shuts down here at 4:30 so probably tomorrow thing | |
| 09:36:24 | kisahm | hi, i'm using openstack queens on ubuntu bionic and i see this error messges in my horizon error log: Forbidden (CSRF token missing or incorrect.): /api/policy/does someone knows this problem? i see this if horizon tries to connect to nova api | |
| 11:11:15 | openstackgerrit | Lee Yarwood proposed openstack/nova master: Revert "nova shared storage: rbd is always shared storage" https://review.opendev.org/682523 | |
| 11:11:15 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Rename _is_storage_shared_with to _is_instance_path_shared_with https://review.opendev.org/693337 | |
| 11:12:27 | sean-k-mooney | efried: by the way if its a completely clean node i found out you dont need the symlink and reboot | |
| 11:13:00 | sean-k-mooney | efried: basicaly apparmor does not ship with a libvirt profile and the way its compiled currently we dont install one so it just works | |
| 11:13:24 | sean-k-mooney | so you only need to disable it if you have previously installed libvirt form the package manager | |
| 11:19:19 | openstackgerrit | Lee Yarwood proposed openstack/nova master: libvirt: Rename _is_storage_shared_with to _is_instance_path_shared_with https://review.opendev.org/693337 | |
| 12:07:58 | sean-k-mooney | gibi_ptg: quick question what move operations did you land for ports with bandwith requests in train. was it resize+cold migrate? live migrate and shelve are still pending right? | |
| 12:45:51 | openstackgerrit | Matt Riedemann proposed openstack/nova stable/stein: Revert "openstack server create" to "nova boot" in nova docs https://review.opendev.org/693242 | |
| 12:54:26 | mriedem | pretty easy fix for the qos stuff when using a non-admin user https://review.opendev.org/#/c/691900/ | |
| 12:54:30 | mriedem | that whole series has to go back to stein | |
| 13:40:49 | sean-k-mooney | mriedem: ya that seriese looks sane to me. i did not really see anything that would be abackport issue either so stien should be doable without too much headache | |
| 13:43:55 | mriedem | sean-k-mooney: nova-next is a zuulv3 job | |
| 13:44:04 | mriedem | the post_test_hook is just a script run in a post-run task | |
| 13:44:22 | sean-k-mooney | ok ok so its already been converted and that works cool | |
| 13:44:37 | sean-k-mooney | we had a question about if that would work downstream so i can say yes | |
| 13:45:23 | mriedem | yes, it's also likely how the remaining legacy jobs need to be converted to zuulv3 | |
| 13:45:37 | mriedem | since they run the nova/tests/functional/live_migration hook scripts | |
| 13:45:58 | mriedem | and those scripts themselves should probably be broken down into proper ansible tasks, but that's a bigger job | |
| 13:46:25 | mriedem | *gate/live_migration/hooks | |
| 13:46:43 | sean-k-mooney | sure but it give us an easy way to achive the comunity goal and then we can break them donw later | |
| 13:46:54 | mriedem | ^ runs remove ansible commands on the subnode to set it up which we could just do with proper tasks that run on the subnode | |
| 13:47:04 | mriedem | s/remove/remote/ | |
| 13:49:03 | sean-k-mooney | when you say set up the subnode you are refering to thing that need to be change post install right | |
| 13:49:08 | sean-k-mooney | e.g. not running devstack | |
| 13:50:34 | sean-k-mooney | if it was runnign devstack that can obviroulsy be done with the native devstack multinode supprot but im guessing they are doing other stuff | |
| 13:50:50 | mriedem | post-install, | |
| 13:51:04 | mriedem | the hook runs some live migration tests post default devstack deploy, | |