Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2020-03-23
15:57:42 sean-k-mooney its non voting anyway so it wont block the build
15:57:59 sean-k-mooney and its in a seperate pipleline alreday so the check pipepline wont wait for it
15:58:04 sean-k-mooney so it wont slow down the gate
15:58:40 sean-k-mooney it proably makes sense to not merge it untill its closer to working but you can always recheck the patch
15:58:53 sean-k-mooney if you do that however i would suggest disableing the other jobs
15:59:07 sean-k-mooney so as to not was gate resouces
16:01:47 openstackgerrit Marcin Juszkiewicz proposed openstack/nova master: CI: add tempest-integrated-compute-aarch64 job https://review.opendev.org/714439
16:02:04 hrw ok, will reedit it then back
16:03:26 openstackgerrit Marcin Juszkiewicz proposed openstack/nova master: [WIP] CI: add tempest-integrated-compute-aarch64 job https://review.opendev.org/714439
16:04:25 hrw ok, my redeployment finished, can now teach tempest to use it
16:34:28 gibi /away
16:46:23 openstackgerrit John Garbutt proposed openstack/nova master: WIP: update quota apis with keystone limits and usage https://review.opendev.org/713499
16:55:27 hrw Took 15.46 seconds to build instance.
16:55:30 hrw now better
16:58:10 hrw uf. tempest even run with it
17:04:27 hrw Ran: 353 tests in 34.9147 sec.
17:04:27 hrw - Passed: 0
17:04:33 hrw so back to config
17:06:37 dansmith sean-k-mooney: gibi: we've got +2s pretty far up the stack, aside from one -1 from alex_xu on top of +2s, and then one -1 from gibi
17:07:05 dansmith sean-k-mooney: gibi: What do you think about dropping the -2 on the bottom patch to let some of those start to flow into the gate while Sundar fixes that one -1 from gibi?
17:07:20 sean-k-mooney dansmith: ya im trying to make my way through the stack today.
17:07:33 dansmith sean-k-mooney: okay you have +1s on a bunch of them too
17:07:46 sean-k-mooney i think the bottom patches i have looked at so far look sane to me
17:08:03 sean-k-mooney so i would be ok with droping the -2 and starting to merge those
17:08:24 sean-k-mooney i have not made it to the later patches in a while but if you feel comfortable with them then i would not be against droping the -2
17:14:26 openstackgerrit Lee Yarwood proposed openstack/nova stable/queens: Replace ansible --sudo with --become in live_migration/hooks scripts https://review.opendev.org/713844
17:14:26 openstackgerrit Lee Yarwood proposed openstack/nova stable/queens: nova-live-migration: Wait for n-cpu services to come up after configuring Ceph https://review.opendev.org/713845
17:18:56 openstackgerrit Lee Yarwood proposed openstack/nova stable/queens: nova-live-migration: Wait for n-cpu services to come up after configuring Ceph https://review.opendev.org/713845
17:21:42 dansmith sean-k-mooney: okay let's see what gibi thinks
17:26:32 gibi dansmith sean-k-mooney: I think it is in a good enough shape to start merging the bottom
17:26:50 dansmith gibi: ack, will drop and make sure those that can merge are +Wd
17:27:00 gibi dansmith: ack, thanks
17:27:24 Sundar dansmith, sean-k-mooney, gibi: Thanks. FWIW, I have started responding to gibi's -1 comments.
17:27:41 gibi Sundar: ack. thanks
17:27:59 dansmith Sundar: cool, if and when you propose fixes, be sure to use git review -R to avoid rebasing the patches that may be in the gate below
17:28:57 dansmith gibi: alex_xu's concern on the "create and bind" is an existing problem not a new one, AFAICT.. I don't want to override his -1 but I don't think there's going to be anything we can or should do in that patch
17:29:13 dansmith gibi: can you have a look at his concern and my response and see if you agree? https://review.opendev.org/#/c/631244
17:30:34 openstackgerrit Lee Yarwood proposed openstack/nova stable/pike: nova-live-migration: Wait for n-cpu services to come up after configuring Ceph https://review.opendev.org/713036
17:31:27 openstackgerrit Lee Yarwood proposed openstack/nova stable/queens: nova-live-migration: Wait for n-cpu services to come up after configuring Ceph https://review.opendev.org/713845
17:32:44 sean-k-mooney dansmith: the whole multi create process cause extra issues.. if you set like --min 2 --max 4 and 1 fails but you end up with 3 running vms then that fine right
17:33:03 gibi dansmith: will check soon
17:33:33 sean-k-mooney so if we do fail to create a binding im not sure if we should be killing the full multi create or just that vm. ideally we woudl reshdule just the one vm that filed right
17:34:02 sean-k-mooney but you were saying the way the funtion currenly works that is not easy to do
17:36:38 hrw is there a tool which takes tempest and gives user readable report? "here are tests which worked, here are skipped ones. and here are failed ones with their output" instead of "here you have @%@Y*T@TGWGHWERIGWYT$(@#YTGWEGHYW as a log"
17:36:53 sean-k-mooney dansmith: doing a continue after cleaning up the current instnace i think could work fine
17:37:04 sean-k-mooney well work in a more intuitive way
17:37:19 sean-k-mooney then killing the entire multi create because 1 instnace failed
17:38:11 sean-k-mooney hrw: you are using a non zuulv3 native job yes?
17:38:34 sean-k-mooney hrw: im guessing the logs you are looking at are double compressed
17:38:52 hrw sean-k-mooney: running tempest locally
17:39:08 sean-k-mooney if that is the issue then you can fix it by doing "curl <log url> | zcat | <program of choice or file>"
17:39:17 sean-k-mooney oh so its not that issue
17:39:36 gibi dansmith: responded. I think the current code is OK, that loop was never designed to try multiple hosts for a single instance
17:40:12 sean-k-mooney gibi: but should it contiue to the next iteration and try the other instnaces?
17:40:40 gibi sean-k-mooney: honestly I would not try that right now. Separately we can think about such enhancement
17:40:42 hrw sean-k-mooney: I start to think that at the end I will write a python script which with load that 10-20MB json file into memory and parse to provide some sane report
17:41:07 gibi sean-k-mooney: this is now simple and it cleans up properly as far as I see.
17:41:13 sean-k-mooney gibi: ok dansmith raised that question in https://review.opendev.org/#/c/631244/68/nova/conductor/manager.py@1621
17:41:44 gibi and I responded there
17:42:00 sean-k-mooney hrw: there is a tool upstream that renders a nice html output
17:42:03 dansmith otp, bbl
17:42:18 sean-k-mooney gibi: cool havent reloaded
17:42:27 sean-k-mooney im going to move on to the next patch in the chain
17:42:46 gibi sean-k-mooney: thanks.
17:42:51 gibi I'm going offline :)
17:42:53 gibi o/
17:44:50 hrw sean-k-mooney: it would be too good.
18:01:42 hrw sean-k-mooney: thanks
19:03:42 artom dansmith, got the energy to look at https://review.opendev.org/#/c/714228/ again?
19:04:53 openstackgerrit Merged openstack/nova master: Make serialize_args handle exception messages safely https://review.opendev.org/712697
19:08:34 artom stephenfin ^^ same, but you're probably done for the day by now
19:24:35 openstackgerrit Merged openstack/nova master: Store instance action event exc_val fault details https://review.opendev.org/694428
19:24:44 openstackgerrit Merged openstack/nova master: Enable unshelve with qos ports https://review.opendev.org/705475
19:38:09 openstackgerrit Merged openstack/nova master: Merge qos related renos for Ussuri https://review.opendev.org/706766
20:12:57 spatel sean-k-mooney: is rcp_thread_pool_size has been replaced with executor_thread_pool_size ?
20:13:04 spatel https://docs.openstack.org/nova/queens/configuration/config.html#executor_thread_pool_size
20:14:18 sean-k-mooney https://docs.openstack.org/nova/queens/configuration/config.html#DEFAULT.executor_thread_pool_size
20:14:31 sean-k-mooney according to the docs yes
20:15:39 spatel cool, i will use executor_thread_pool_size :)
20:32:01 spatel sean-k-mooney: what do you suggest about heal_instance_info_cache_interval value, its ok to keep it little high (default: 60)
20:33:01 sean-k-mooney in theory it should not be needed at all. it is intended to ensure that nova and neutron does not get out of sync if you modify attributes of the neutron port out of band of nova
20:33:21 sean-k-mooney so yes it can be set longer that said it should not be disabled
20:33:39 sean-k-mooney mainly because there is not testing for running without the healing.
20:34:25 spatel i am trying to reduce load on neutron-servers so trying to tune some value
20:35:18 spatel as VMs grows it put more pressure on neutron
20:38:44 sean-k-mooney you should be able to set it to 300 safely enough
20:41:10 spatel cool
21:15:00 sean-k-mooney dansmith: gibi Sundar just finished reviewing the cyborg series. i noticed a few nits all of which could be adressed in a follow up patch but one thing is definetly missing. i think we all agree that cyborg integration qualifies for a release note but i dont see one in the series
21:16:16 sean-k-mooney we could add it in the followup patch when adressing some fo the nits but strictly speaking i belive it should be added here https://review.opendev.org/#/c/673735/46 and then update by each of the follow on patches to reflect the different capablities
21:16:44 sean-k-mooney that said we can just add it in https://review.opendev.org/#/c/674726/9 which is the last functional patch
21:21:11 Sundar sean-k-mooney: Ack. I'll take a look
21:21:24 Sundar Thanks for the reviews.
21:21:44 Sundar Any luck with testing the rescheduling?
21:33:17 sean-k-mooney i have not had a chance to test it but i might get to do it tomororow. i will be redeploying the latest version tomorow in anycase
21:33:43 sean-k-mooney i was condiering locally modifying the spawn to fail on one node to then assert the correct behaviro for reschdule
21:42:06 sean-k-mooney artom: whitebox is breaking thing it should not be able to break...
21:42:08 sean-k-mooney https://zuul.opendev.org/t/openstack/build/bc5fd77019b74363ab3b06478fd386de
21:42:51 sean-k-mooney artom: its causing tempest-tox-plugin-sanity-check to fail
21:43:01 sean-k-mooney .
21:43:04 artom Whoa

Earlier   Later