Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-05-22
12:56:01 efried (from line 77)
12:56:15 alex_xu sean-k-mooney: not too much, but have involve lm for the lm with numa patche, anyway I will put that to my review list, give a try
12:56:50 abhi89 efried: yes.. Unauthorized: Unknown auth type: None (HTTP 401)
12:56:59 sean-k-mooney alex_xu: no worries
12:57:19 efried abhi89: Do you have service_auth set up?
12:58:30 abhi89 efried: service_auth? where?
13:00:15 efried abhi89: https://docs.openstack.org/nova/stein/configuration/config.html#service-user
13:01:21 efried You're saying the symptom is rare, which leads me to suspect it's happening over long-running operations when your user token is expiring. That's what service auth was designed for. If you configure this, it wraps your user token in a service token so that when your user token expires, subsequent operations in that thread will still succeed (using the service token).
13:02:37 efried The way it's manifesting is odd, though. That code path should only be happening under admin context.
13:05:25 abhi89 efried: hmm.. let me try adding service_auth section to nova.conf.. thanks for the info..
13:05:37 efried abhi89: That's probably not it.
13:05:44 efried it's probably I3c35bba43fee81baebe8261f546c1424ce3a3383
13:06:04 efried abhi89: https://review.opendev.org/#/c/522112/
13:06:19 efried read the commit message and the bugs tagged there...
13:06:38 efried if you've got a situation similar to what's described, then you *do* need to set up admin auth for cinder to resolve it.
13:09:05 efried stephenfin, cdent: What's the thing that has to be in place for Depends-On to work? Something tox something sibling? Specifically, is that currently set up to work from nova to os-traits?
13:09:39 cdent it is not set up for os-traits unless add a required-project of openstack/os-traits
13:09:53 cdent (to the zuul job config)
13:10:22 openstackgerrit Eric Fried proposed openstack/nova master: Support old & new versions of svm and avx traits https://review.opendev.org/660515
13:10:34 efried o
13:10:53 abhi89 efried: ok.. let me check on that..
13:11:02 efried cdent: for the base job?
13:11:03 sean-k-mooney cadding os-traits to the required projects will add it to LIB_FROM_GIT and cause the zuul clone to prepar it in the workspace
13:11:15 sean-k-mooney but that will result in the job running with master of os-tratis
13:11:20 sean-k-mooney not the releaded version
13:11:30 sean-k-mooney so we normally dont want that to be the case
13:11:42 efried mm
13:11:45 cdent sean-k-mooney: why not?
13:11:53 efried because we would get false positives
13:12:09 cdent meh
13:12:09 sean-k-mooney cdent: because we wont be testing with the released version or the version listed in upperconstriats
13:12:26 sean-k-mooney so we wont be testing with what people actullly will be deploying
13:12:30 efried right
13:12:34 efried and that would be bad.
13:12:47 sean-k-mooney we could do it in nova-next or a specific job
13:13:01 sean-k-mooney we just dont wnat to do that in all jobs
13:13:05 cdent or constraints in general
13:13:17 sean-k-mooney cdent: do you use arch
13:13:19 cdent hell, I'm going the whole way: I don't like
13:14:11 aarents efried: Hi, about https://review.opendev.org/#/c/659054 I had to rebase, it is ok now, can you have a look on it please?
13:14:23 sean-k-mooney hehe look im fine with deploying with os-traits from master as long as we have at least one job that is testing the released version
13:15:02 sean-k-mooney maybe there is a feature request here to zuul for a way to add peoject dynamiclaly per patch
13:15:36 efried sean-k-mooney: ^ this
13:15:38 sean-k-mooney e.g. Depends-on: xyw Require: openstack/os-traits
13:15:45 efried ooo
13:16:16 sean-k-mooney that said we still would not want to merge the patch without the release so not sure how useful that is
13:16:22 efried As it stands, I have to hand-edit .zuul.yaml. And for inherited jobs/templates, I would have to write whole derived jobs for them.
13:16:32 efried sean-k-mooney: It's useful for me to validate that my patch is correct.
13:16:56 efried Because as always I don't want to run all of the nova unit test and functional suites locally.
13:17:04 sean-k-mooney efried: right but outside of that not sure.
13:17:43 sean-k-mooney efried: i recently set up rtox to run my unit tests over ssh on my desktop. they now take ~ 2 mins to run
13:17:44 efried Sure, outside of that it's not very helpful, and needs to be negated once the dep merges, so I can't accidentally merge that patch.
13:18:14 efried aarents: looking...
13:18:15 sean-k-mooney efried: it woudl be useful for test only patch on top of the actul change
13:18:26 sean-k-mooney *test only -> DNM
13:19:59 cdent efried: clone yourself and fix the core problem: tests are too slow
13:20:24 mriedem this contributes to ^ https://bugs.launchpad.net/nova/+bug/1829896
13:20:24 openstack Launchpad bug 1829896 in OpenStack Compute (nova) "libvirt: "Instance failed to shutdown in 60 seconds." in the gate" [Undecided,New]
13:20:28 sean-k-mooney cdent: not if you throw 48 cores at them
13:21:20 cdent 48!? luxury
13:21:57 sean-k-mooney cdent: the full nova py37 tox env takes 72 seconds to run on my desktop or about 2 minutes totoal when you account for the tox startup time and report generation
13:22:16 cdent try the placement tests, I suspect you will go backwards in time
13:22:44 sean-k-mooney cdent: i decomisined the tower server i baught do some ci
13:24:21 sean-k-mooney ======
13:24:22 sean-k-mooney Totals
13:24:24 sean-k-mooney ======
13:24:26 sean-k-mooney Ran: 152 tests in 0.7772 sec.
13:24:28 sean-k-mooney - Passed: 152
13:24:30 sean-k-mooney - Skipped: 0
13:24:32 sean-k-mooney - Expected Fail: 0
13:24:34 sean-k-mooney - Unexpected Success: 0
13:24:36 sean-k-mooney - Failed: 0
13:24:38 sean-k-mooney Sum of execute time for each test: 0.4916 sec.
13:24:40 sean-k-mooney not quite
13:25:25 sean-k-mooney and the time output
13:25:29 sean-k-mooney real 0m5.681s
13:25:30 sean-k-mooney user 1m33.494s
13:25:32 sean-k-mooney sys 0m9.505s
13:26:00 sean-k-mooney that said before i got that working yesterday i would agree way to slow
13:28:30 gibi hehe this rtox python package implements what I have in bash for years. I independently named that bash script 'rtox'
13:29:39 openstackgerrit Eric Fried proposed openstack/nova master: WIP: Support old & new versions of svm and avx traits https://review.opendev.org/660515
13:29:57 efried iiuc, ^ stands a chance of passing functional and tempest, but will still fail unit.
13:30:40 efried which does kind of defeat the purpose, as it's unit tests I've changed.
13:30:56 sean-k-mooney gibi: ya im proably goign to stop using it. the python version takes way to long to actully output to stdout
13:31:07 efried The tests I changed succeed locally though. shrug.
13:31:55 sean-k-mooney efried: wait why are we reported avx and svm in a vendor speficic way
13:32:54 sean-k-mooney oh we are not at least for AVX
13:32:56 efried because they're vendor-specific flags
13:33:12 sean-k-mooney efried: you ment VMX not AVX
13:33:14 efried point is, we weren't, but we should have been, so now we are.
13:33:27 efried oh, did I misspell something? :P
13:33:42 sean-k-mooney :)
13:34:10 openstackgerrit Eric Fried proposed openstack/nova master: WIP: Support old & new versions of svm and vmx traits https://review.opendev.org/660515
13:34:10 efried thanks sean-k-mooney, nice catch
13:34:19 sean-k-mooney are the only spelling mistakes i can spot instruction sets?
13:34:29 efried I'll take it.
13:34:49 efried we have plenty of other anal-retentive people to catch the rest.
13:35:04 efried community development ftw
13:35:11 sean-k-mooney that was more a self commentry on how deep the intel brainwashing must have penetrated :P
13:36:01 sean-k-mooney it bypassed my in ability to spell and inserted an instruction set filter into my brain lol

Earlier   Later