| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2020-12-14 | |||
| 10:39:40 | lyarwood | hmm does Depends-On work across branches with grenade? | |
| 10:40:35 | openstackgerrit | Lee Yarwood proposed openstack/nova stable/train: [stable-only] Cap bandit to 1.6.2 and raise hacking and flake8 in LC https://review.opendev.org/c/openstack/nova/+/766171 | |
| 10:41:18 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Reproduce bug 1907522 in functional test https://review.opendev.org/c/openstack/nova/+/766791 | |
| 10:41:18 | openstack | bug 1907522 in OpenStack Compute (nova) "test_*_with_qos_min_bw_allocation fails in the nova-multi-cell job with: nova.exception.MigrationPreCheckError: Migration pre-check error: Failed to create port bindings for host |
|
| 10:42:50 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: Fallback to same-cell resize with qos ports https://review.opendev.org/c/openstack/nova/+/766925 | |
| 10:44:15 | openstackgerrit | Balazs Gibizer proposed openstack/nova master: DNM: test how multi-cell job behaves now https://review.opendev.org/c/openstack/nova/+/766926 | |
| 11:09:54 | elod | lyarwood: fyi, bandit 1.6.3 is yanked, so hopefully that error is now history :) >>> https://pypi.org/project/bandit/#history | |
| 11:11:05 | elod | lyarwood: sorry, my bad. it seems 1.7.0 is still universal :'( | |
| 11:11:38 | lyarwood | /o\ | |
| 11:13:24 | elod | quite frustrating :/ | |
| 11:14:55 | elod | the new bug report: https://github.com/PyCQA/bandit/issues/665 | |
| 11:17:03 | lyarwood | I'm going to close out my bandit changes either way as this should eventually get resolved there | |
| 11:17:29 | lyarwood | did we want to switch our LC jobs to non-voting btw while we wait for an agreement on dropping them out right or not? | |
| 11:18:07 | elod | lyarwood: maybe we could even remove them (at least from old branches) | |
| 11:18:52 | lyarwood | elod: personally I'd like to wait for distros to comment more, I wanted to chase up with the RDO folks for example | |
| 11:18:53 | elod | where it's clearly contradicts with constraints (i.e. LC fails) | |
| 11:19:19 | lyarwood | elod: switching to non-voting at least gives them a chance to respond and later fix these issues if they find it useful | |
| 11:19:25 | elod | lyarwood: hmmm, yes, you are right. Let's just set them non-voting | |
| 11:19:54 | lyarwood | kk | |
| 11:20:33 | lyarwood | oh it's a template | |
| 11:20:37 | lyarwood | my bad | |
| 11:20:44 | lyarwood | can we mark templates as non-voting? | |
| 11:21:17 | elod | we should be able to | |
| 11:22:18 | elod | worst case the job needs to be added in .zuul.yaml outside of the template | |
| 11:22:35 | elod | and then set non-voting | |
| 11:22:56 | lyarwood | yup true | |
| 11:26:35 | openstackgerrit | Lee Yarwood proposed openstack/nova master: zuul: Make lower-constraints jobs non-voting https://review.opendev.org/c/openstack/nova/+/766931 | |
| 11:27:30 | elod | lyarwood: btw, if now the lower-constraints do work on master and victoria then maybe it's enough to set non-voting from ussuri. what do you think? | |
| 11:29:56 | elod | as the main problem is where the LC's are kinda irreparable | |
| 11:33:54 | elod | or time-consuming to fix and involves lots of LC changes (a real "butterfly effect" :P) | |
| 11:33:59 | lyarwood | elod: tbh I'd still like to mark them all as non-voting to signal that we don't think they are useful going forward | |
| 11:37:12 | elod | lyarwood: you are probably right. however it feels now almost useful - if the constraints are really kept with the new pip resolver. But I'm okay with setting it non-voting on master. | |
| 12:28:16 | ftarasenko | hi! Team, can someone help my colleague with review of tiny commit? https://review.opendev.org/c/openstack/nova/+/764927 | |
| 12:38:52 | sean-k-mooney | ftarasenko: im not sure that makes sense | |
| 12:39:38 | sean-k-mooney | the constuction of the loop is such that we sleep for 1 seconed on every iteration | |
| 12:40:04 | sean-k-mooney | i understand the logic but just addint that while keeping the current looping seams odd | |
| 12:41:59 | sean-k-mooney | we shoudl proably drop the loop var and instead just do a while loop instead | |
| 12:43:19 | sean-k-mooney | ftarasenko: as written the current look will at most be off by the time it takes for the body to execute | |
| 12:43:52 | sean-k-mooney | so i agree it can be longer then you expect but not by a large interval | |
| 12:46:26 | ftarasenko | Thank you, your explanation seems good to me. Forwarded to my colleague. He says that he can rewrite it to while loop, if someone will review) | |
| 12:47:06 | ftarasenko | Is it ok to ask for review here? I'm new to nova project. | |
| 12:47:20 | sean-k-mooney | yes its ok | |
| 12:49:47 | sean-k-mooney | ftarasenko: we encorage people to ask question about developement here espcially if they are new | |
| 12:55:27 | sean-k-mooney | ftarasenko: by the way they should ingore the lower constraints failure. | |
| 12:55:45 | sean-k-mooney | ftarasenko: we have an ongoing issue with that and the new pip depency resolver | |
| 12:57:26 | lyarwood | gibi: https://zuul.opendev.org/t/openstack/build/02576a8cc541451bb8add7f1423d14bf - is that a known issue? | |
| 12:57:38 | lyarwood | openstack.exceptions.BadRequestException: BadRequestException: 400: Client Error for url: https://199.204.45.203/compute/v2.1/os-aggregates/openstack.tests.functional.cloud.test_aggregate.TestAggregate.test_aggregates-1, Invalid input received: id must be an integer' | |
| 12:57:59 | lyarwood | ah sorry I thought that was part of test_qos_minimum_bandwidth_rule_lifecycle | |
| 12:58:01 | sean-k-mooney | well it must be yes | |
| 12:58:03 | ftarasenko | sean-k-mooney: tnx! | |
| 12:58:11 | lyarwood | it isn't ignore me | |
| 13:00:58 | sean-k-mooney | lyarwood: its not part of the serise but the error is correct https://docs.openstack.org/api-ref/compute/?expanded=show-aggregate-details-detail | |
| 13:02:10 | sean-k-mooney | lyarwood: there is an osc bug in a few cases where it passes the a name to the /os-aggregates/{aggregate_id} instead of checking if its an id or not | |
| 13:02:28 | sean-k-mooney | it then calls the list endpoint and filters in python | |
| 13:02:50 | sean-k-mooney | at least that is what it does in the server show case | |
| 13:03:57 | sean-k-mooney | we had a downstream bz for the server show case but i suspect its a incorrect pattern that exits in many cases that needs to be corrected. osc is just not doing input validation to determin which api to call | |
| 13:04:42 | sean-k-mooney | i assume tempest has the same bug | |
| 13:10:57 | hemanth_n | sean-k-mooney, lyardwood: As discussed on Friday, i started backporting Iabe37dbdc244b019cb68099739b2c1c81b94a30d, and it requires I999fc4aaf14cca02e4ed730afb844a043b59530c for the tests to be successful. So, i am going ahead with backport of I999fc4aaf14cca02e4ed730afb844a043b59530c (after some tests on my local).. hope this is ok | |
| 13:11:20 | openstackgerrit | Mamduh proposed openstack/os-vif stable/ussuri: Refactor code of linux_net to more cleaner and increase performace https://review.opendev.org/c/openstack/os-vif/+/765419 | |
| 13:11:30 | ygk_12345 | hi all | |
| 13:11:53 | ygk_12345 | I am facing this error in nova-api log in the Train nova setup. http://paste.openstack.org/raw/801004/ | |
| 13:11:58 | ygk_12345 | is this a known bug ? | |
| 13:12:32 | sean-k-mooney | hemanth_n: that touches more files then i would like but i think its ok | |
| 13:12:47 | sean-k-mooney | hemanth_n:looking at the change its minimal | |
| 13:13:06 | hemanth_n | sean-k-mooney: yep more backports, ack i will test in local before i submit a patch | |
| 13:14:31 | sean-k-mooney | ygk_12345: that looks like you have not run the required db migration our your backporint some with a db change which is not allowed | |
| 13:14:51 | ygk_12345 | sean-k-mooney what would be the exact command ? | |
| 13:15:13 | openstackgerrit | Mamduh proposed openstack/os-vif stable/train: Refactor code of linux_net to more cleaner and increase performace https://review.opendev.org/c/openstack/os-vif/+/765912 | |
| 13:15:49 | sean-k-mooney | ygk_12345: hum it was added in pike https://github.com/openstack/nova/commit/3674a4268d177230375fa1b581dbdf6f62755cee | |
| 13:16:08 | sean-k-mooney | ygk_12345: "nova-manage db sync" | |
| 13:16:41 | sean-k-mooney | but given how long ago it was added its unlikely you have not run any db migration since pike | |
| 13:16:57 | ygk_12345 | sean-k-mooney is this the one "su -s /bin/sh -c "nova-manage db sync" nova" ? | |
| 13:18:14 | sean-k-mooney | ygk_12345: more or less yes although it proably not the issue | |
| 13:18:23 | ygk_12345 | sean-k-mooney now I got this after the command http://paste.openstack.org/raw/801005/ | |
| 13:18:43 | openstackgerrit | Mamduh proposed openstack/os-vif stable/stein: Refactor code of linux_net to more cleaner and increase performace https://review.opendev.org/c/openstack/os-vif/+/765914 | |
| 13:19:53 | sean-k-mooney | so this is train | |
| 13:20:11 | sean-k-mooney | was the cloud initall deploy as train or upgraded form a previous release | |
| 13:20:11 | ygk_12345 | sean-k-mooney yes | |
| 13:20:21 | ygk_12345 | intially as train only | |
| 13:22:10 | sean-k-mooney | so that failing here https://github.com/openstack/nova/blob/0e7cd9d1a95a30455e3c91916ece590454235e0e/nova/db/sqlalchemy/migrate_repo/versions/316_add_disk_ratio_for_compute_nodes.py | |
| 13:22:59 | ygk_12345 | sean-k-mooney yes exactly | |
| 13:23:32 | sean-k-mooney | so if the migration is failing there which is mitaka then ist possbale that the rest fo the migration have not been run either | |
| 13:23:45 | sean-k-mooney | the service uuid was added in a later migration | |
| 13:24:29 | sean-k-mooney | lyarwood: gibi do you know if we ahve a way to print the crrent db version via nova manage | |
| 13:24:51 | ygk_12345 | sean-k-mooney so what would be the workaround now ? | |
| 13:24:52 | sean-k-mooney | stephenfin: maybe you know ^ | |
| 13:25:16 | sean-k-mooney | ygk_12345: well we need to figure out what version your db actull is | |
| 13:25:35 | sean-k-mooney | it sound like your deployment didnt actully work properly | |
| 13:25:40 | ygk_12345 | sean-k-mooney i am following the train minimal nova installation guide | |
| 13:25:50 | ygk_12345 | sean-k-mooney oh ok | |
| 13:26:35 | ygk_12345 | sean-k-mooney i used this on ubuntu18 add-apt-repository cloud-archive:train | |
| 13:27:22 | sean-k-mooney | the install gudies are not really tested at least not by the project teams | |
| 13:27:25 | lyarwood | sean-k-mooney: yeah isn't there a version subcommand or something? | |
| 13:27:55 | lyarwood | https://docs.openstack.org/nova/latest/cli/nova-manage.html#nova-database - nova-manage db version | |
| 13:28:37 | ygk_12345 | sean-k-mooney its version 315 | |
| 13:28:56 | ygk_12345 | lyarwood sean-k-mooney its db version 315 | |
| 13:28:56 | sean-k-mooney | ygk_12345: ya so that pre mitaka | |
| 13:29:05 | openstackgerrit | Mamduh proposed openstack/os-vif stable/rocky: Refactor code of linux_net to more cleaner and increase performace https://review.opendev.org/c/openstack/os-vif/+/765962 | |
| 13:29:35 | ygk_12345 | sean-k-mooney so what would be the workaroud now ? | |
| 13:29:35 | sean-k-mooney | ygk_12345: so at that point you should not have the disk_allocation_ratio column in that table | |