Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-12-14
13:47:21 sean-k-mooney if it gets to 402 then your good to go with starting the services
13:48:30 ygk_12345 yes its 402. awesome
13:49:36 sean-k-mooney feel free to submit a patch to update the install guide with this and any other issue you find
13:50:26 sean-k-mooney as i said in this case it should have had you install just nova-manage then set up the db then install the other nova packages for the api conducort and scheduler
13:51:11 sean-k-mooney ygk_12345: when you install the packages the post init script starts the service automatically which can cause issues as you found
13:51:25 ygk_12345 sean-k-mooney ok sure thanks for your time as well
13:51:39 sean-k-mooney no worries
14:28:29 gibi lyarwood: sorry I was away, but I see you found the reasons
14:59:14 sean-k-mooney gibi: i suspect the conductor proably created the column not really sure what actully did it but yes
14:59:46 sean-k-mooney gibi: i have seen that with devstack often enought to know that running the service before the db is ready end is weired issue like that
15:00:48 gibi sean-k-mooney: oh I referred to the aggregate question from lyarwood
15:00:59 sean-k-mooney oh ok
15:01:04 sean-k-mooney sorry
15:12:39 openstackgerrit Lance Bragstad proposed openstack/placement master: Pass context objects to oslo.policy directly https://review.opendev.org/c/openstack/placement/+/766785
15:12:40 openstackgerrit Lance Bragstad proposed openstack/placement master: Implement secure RBAC for resource providers https://review.opendev.org/c/openstack/placement/+/760240
15:41:53 openstackgerrit Jan Gutter proposed openstack/os-vif stable/train: DNM: testing lower-constraints https://review.opendev.org/c/openstack/os-vif/+/766975
15:45:08 openstack bug 1908075 in OpenStack Compute (nova) "Nova allows a non-multiattach volume to be attached to multiple instances *if* its volume state is reset by an admin" [Undecided,New] https://launchpad.net/bugs/1908075 - Assigned to Lee Yarwood (lyarwood)
15:45:08 openstackgerrit Lee Yarwood proposed openstack/nova master: Add regression test for bug #1908075 https://review.opendev.org/c/openstack/nova/+/766976
16:01:20 gibi lyarwood: do you happen to know if all the issues we fixed in https://review.opendev.org/c/openstack/nova/+/765749 for stable/victoria needs to be backported to stable/ussuri? if yes I can do the cherry-pick
16:03:41 lyarwood gibi: there are other issues to resolve on the older branches, I've been waiting to see if people wanted to drop the LC jobs
16:03:54 gibi lyarwood: ack, then I
16:03:55 lyarwood gibi: and for the bandit issue to be resolved
16:04:22 gibi then I'm not pushing the backport now, the qos bug is targeted to ussuri
16:09:27 openstack Launchpad bug 1907511 in OpenStack Compute (nova) ussuri "nova-multi-cell fails on stable branches with: Failed to compute_task_migrate_server: 'NoneType' object has no attribute 'version'" [Undecided,New]
16:09:27 melwitt gibi: wondering why is this considered closed? this one is about the lack of cell targeting for lookup of the service record, not really about the lack of multi-cell support for min bw requests? https://bugs.launchpad.net/nova/+bug/1907511
16:09:49 melwitt *closed for victoria
16:10:23 gibi melwitt: my thinking is to backport his fix to victoria instead https://review.opendev.org/c/openstack/nova/+/766925
16:10:47 gibi melwitt:
16:11:12 openstack Launchpad bug 1907511 in OpenStack Compute (nova) ussuri "nova-multi-cell fails on stable branches with: Failed to compute_task_migrate_server: 'NoneType' object has no attribute 'version'" [Undecided,New]
16:11:12 gibi melwitt: I considered https://bugs.launchpad.net/nova/+bug/1907511 as a gate blocker bug which we resolved with turning off the test
16:11:26 gibi but I can reopen it and close it with https://review.opendev.org/c/openstack/nova/+/766925 if that make more sense
16:11:26 melwitt oh, I didn't see that
16:11:39 gibi I just wanted to limit the number of bugs to track
16:12:05 openstack Launchpad 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 <host>" [High,In progress] - Assigned to Balazs Gibizer (balazs-gibizer)
16:12:05 gibi I would keep https://bugs.launchpad.net/nova/+bug/1907522 open until https://review.opendev.org/c/openstack/nova/+/766925 is merged
16:12:13 melwitt yeah, I see now. without context of the other approach in the bug, it didn't make sense to me
16:12:34 gibi melwitt: I can add more context to the bug I closed
16:13:20 melwitt I am ok, just explaining why I asked. but it might help to add that info for reading back in history
16:13:30 melwitt I will abandon my patch
16:13:57 gibi sure
16:14:00 gibi I will add it
16:14:39 melwitt cool thanks
16:16:04 gibi done
16:26:32 prometheanfire melwitt: how goes the mock updates? :P
16:27:14 melwitt prometheanfire: will start on it maybe today, last week our gate was failing 100% so was focused on things related to that
16:27:47 prometheanfire yep
16:28:40 prometheanfire offhand, is it possible to switch a flavor from public to private via the API? I'm thinking no
16:32:46 melwitt prometheanfire: looks like no, can't switch flavor from public to private via the API
16:33:36 gmann prometheanfire: melwitt: yeah, only modification allowed in flavor is description or add/remove tenant access.
16:34:17 gmann gibi: melwitt lyarwood looks like placement l-c is also broken. https://review.opendev.org/c/openstack/placement/+/764394
16:34:47 gmann any fix up otherwise i can work on that
16:35:05 lyarwood gmann: nothing from me, hack away :)
16:35:12 gmann k
16:35:15 gibi gmann: same,
16:35:17 melwitt me either, feel free
16:35:33 melwitt thanks gmann
16:35:43 gmann sure
16:47:57 openstackgerrit Ghanshyam proposed openstack/placement master: Fix l-c job for pyflakes version conflict https://review.opendev.org/c/openstack/placement/+/766994
17:39:25 gibi stephenfin: regarding https://review.opendev.org/c/openstack/nova/+/765300 do you happen to know how to retry a unit test with all the setup and teardown executed properly?
17:40:04 gibi just plugging a retry decorator to the test function will not execute teardown, cleanup and the setup again
17:40:49 sean-k-mooney gibi: stephenfin is on pto today but im not sure we have an example of that in our code bases
17:41:10 sean-k-mooney you could do it manually i guess
17:41:33 sean-k-mooney call tear down and setup on failure excpet for the last execution
17:42:02 sean-k-mooney you can acess them via the self argument passed to the inner funciton
17:44:14 gibi sean-k-mooney: my grep failed me to find that example. Yeah I can try calling all these manually I'm just affraid I will miss something that the unit test framework does
17:45:04 sean-k-mooney i know some other project like pip have a @flaky decorator
17:45:25 sean-k-mooney they call pypi in some of there unit tests
17:45:34 sean-k-mooney so the have to retry them ocationally
17:48:38 gibi flaky is for nose a pytest :/
17:51:58 gibi ok I don't think I can make it work without digging too deep into the internals of the untit test framework. So I
17:52:03 gibi So I stop here
17:52:36 openstack Launchpad bug 1823251 in OpenStack Compute (nova) "Spike in TestNovaMigrationsMySQL.test_walk_versions/test_innodb_tables failures since April 1 2019 on limestone-regionone" [High,Confirmed]
17:52:36 gibi honestly I don't know what we can do with https://bugs.launchpad.net/nova/+bug/1823251
17:53:28 sean-k-mooney gibi: what is it ment to be testing
17:53:40 sean-k-mooney gibi: e.g. shoud we just remove the test and be done with it
17:53:47 gibi db migrations as far as I understand
17:54:03 sean-k-mooney but what does walk version mean
17:54:32 sean-k-mooney ah ok
17:54:32 gibi version by version do the db migrations
17:54:42 sean-k-mooney do we need to do that for mysql?
17:54:47 sean-k-mooney is sqlight enough
17:54:53 gibi we do it for sqlite mysql and postgres
17:55:09 sean-k-mooney yep because fo the opertunistic testing code
17:55:19 sean-k-mooney but im wondering if we should exclude it form that
17:55:24 gibi I guess we added all these because we thought there are differences between the db engines regarding schema upgrade
17:55:45 gibi but I don't have historical context to say more
17:55:55 sean-k-mooney should that not be caught but the indivual upgrade check
17:56:10 sean-k-mooney https://github.com/openstack/nova/blob/7dcc4cfea7da2ef1163e0a65618cb784f5159c6d/nova/tests/unit/db/test_migrations.py#L253-L254
17:56:15 sean-k-mooney is the one that fails right
17:57:08 gibi all the walk_versions can fail
17:57:20 gibi at least I saw failures both form the unit and the functional one
17:57:23 sean-k-mooney ah ok so its not jsut for mysql
17:57:34 gibi yes, the api_db is tested in the func env the cell db tested in the unit env
17:58:06 gibi now I'm not sure I see other than mysql failures
17:58:08 sean-k-mooney right but is it only with mysql backend that if fails or with any db backend
18:00:20 gibi the e-r query filters for mysql
18:00:41 gibi but I think I did not see non-mysql failures
18:01:20 sean-k-mooney ya i only recall mysql but that could just be my falut human memory
18:01:42 sean-k-mooney which was why i was ondering would running it with sqlithg only be an option
18:02:29 gibi the question is, do we lose test coverage?

Earlier   Later