Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2019-07-29
16:29:46 sean-k-mooney >>> val_error.__traceback__
16:29:48 sean-k-mooney >>>
16:30:13 sean-k-mooney >>> raise val_error
16:30:15 sean-k-mooney Traceback (most recent call last):
16:30:17 sean-k-mooney File "<stdin>", line 1, in <module>
16:30:19 sean-k-mooney ValueError
16:30:39 sean-k-mooney >>> val_error.__traceback__
16:30:41 sean-k-mooney <traceback object at 0x7fc44ac5db48>
16:30:46 efried aspiers: yup. But urgency again reduced by the fact that there's a big not-reviewable-by-me thingy in front of it again/still.
16:30:51 sean-k-mooney so it looks like the tracback is only compute when its raised
16:30:57 efried sean-k-mooney: ack, but that only matters if the traceback is being used somewhere up the chain
16:31:00 efried which afaict it isn't.
16:31:06 efried all we're doing is printing the exception
16:31:11 efried which is the same whether it's raised or not.
16:31:14 sean-k-mooney its not its just being logged
16:31:19 efried right
16:31:26 sean-k-mooney so i dont know if we care
16:31:29 efried I didn't -1 before
16:31:32 efried right, I don't know either.
16:31:37 sean-k-mooney i think we dont
16:31:42 efried I would have accepted either explanation, really.
16:31:55 sean-k-mooney just you were asking if they were the same and they technically arnt
16:32:01 efried Even if we want to say "this is future proofing in case someone wants to print this stack trace somewhere"
16:32:03 sean-k-mooney but not in a way that matters for our usecase
16:32:12 efried ++ thanks for the clarification.
16:32:53 sean-k-mooney ill copy that example into a comment and change my +0 to a +1
16:53:38 mriedem eandersson: re https://review.opendev.org/#/c/672855/ i might write a functional regression test for the issue (separate patch) and stack your change on top
16:53:48 mriedem that code is too shitty for just unit tests
16:54:00 eandersson Yea that would be great
16:54:14 eandersson It's a pretty big problem for services like Senlin if this happens
16:54:32 eandersson It exposed a bug in Senlin as well of course
16:55:47 mriedem i worry about a refactor of that code in the future to remove the non-reschedule logic to drop the error handling
16:56:22 sean-k-mooney it is certenly not the most intuitive code i have seen
16:56:42 mriedem years and years of piling more stuff into it
16:58:33 sean-k-mooney eandersson: well its a problem in general. senlin is proably more sensitive but haveing a server always in build and nerver erroring out becasue we miseed that exception being raised is going to break alot of workflows
16:59:30 sean-k-mooney eandersson: if you use something like heat that had a timeout onf the whole heat stack create process it would clean it up but only after doing a lot of work that got thrown away and after waiting for the timeout to fire
16:59:40 mriedem ok i'm going to get lunch and then i'll write a functional regression test and rebase the fix on top
17:07:14 openstackgerrit sean mooney proposed openstack/nova master: Libvirt: add support for vPMU configuration. https://review.opendev.org/671338
17:08:52 sean-k-mooney stephenfin: by the way when your back from PTO tommorow can you take a look at this os-vif change i wrote https://review.opendev.org/#/c/672834/
17:12:20 openstackgerrit Dustin Cowles proposed openstack/nova master: WIP: Provider config file https://review.opendev.org/673341
17:17:14 efried sean-k-mooney: https://review.opendev.org/#/c/666604/ I think I may have said the same thing as you, in different words...
17:18:48 sean-k-mooney more or less yes
17:19:17 efried okay, cool
17:20:37 sean-k-mooney im not sure if we store teh compute capablities in the nova db or if they only live in memory in the compute agent
17:20:56 sean-k-mooney that said i think they must be in the db for the compute capbalites fiter to work
17:21:54 openstackgerrit Merged openstack/nova master: libvirt: harden Host.get_domain_capabilities() https://review.opendev.org/670189
17:22:24 sean-k-mooney so its not really clear to me if 1 the info is avialble outside the compute node and 2 if retriving the info from placmenet would be cheaper then an rpc or db call. (ignoring if the traits is a thing we want for the sake of argument)
17:23:42 sean-k-mooney you could proably retrive it form placement in 1 call by looking the RP up by name which should match the instance.host
17:24:12 sean-k-mooney and if you pull back the full RP i assume that would contian the traits too
17:26:24 sean-k-mooney actully your right it would need 2 quires
17:27:15 sean-k-mooney since we just have the link to the traits endpoint and not the tratis in the responce from /resource_providers?name={instance.host}
17:34:52 openstackgerrit Eric Fried proposed openstack/nova master: Move adding vlans to interfaces to privsep. https://review.opendev.org/635436
17:54:31 mriedem sean-k-mooney: it's not available outside the compute node
17:54:35 mriedem and not stored *in* the compute node object
17:55:10 mriedem as i said in my reply to chris, a pre-filter might not make sense
17:55:15 mriedem it would likely be logic in the api itself
17:55:31 mriedem to either ignore or not the current instance.host
17:56:07 mriedem this is also a super latent issue and at the bottom of my priority list
18:09:51 sean-k-mooney ok i was guessing it was someing like that. e.g. not available out side of the compute
18:10:32 sean-k-mooney a trait on the RP would be less expensive to check then intoducing a new rpc call
18:14:20 mriedem and consistent with all of the compute capabilities as traits stuff we've been doing since rocky
18:23:56 sean-k-mooney ya im aware of the other traits but i was not sure if we did it that way only because they are only available on the compute node or because they are usefult to schdule on
18:24:16 sean-k-mooney e.g. the multi attach trait is useful to shcduler on if you are booting with a multi attach volume
18:25:03 sean-k-mooney but im not sure i see a usecase for passing this new trait as a requried trait on boot but i understand how it coudl be used on migrate/resize
18:25:57 sean-k-mooney maybe there is a usecase where you would want to require it on spawn but it just felt a little different then the other capablity traits we have
18:27:31 aspiers big achievement just unlocked: booting a fully functional SEV guest via nova
18:27:48 aspiers that only took what - 9 months?
18:28:26 sean-k-mooney :)
18:28:52 sean-k-mooney you mean you didnt hardcode it quickly to test it works 9 months ago
18:30:57 sean-k-mooney hehe when im doing stuff that requires new xml i have often hard coded enabling the featuer just in the compute ndoe to make sure it actully can boot followint the upstream(libvirt/qemu) docs then work backwards to figure out how to report it to the RT/schduler and how to request it form the api
18:31:15 sean-k-mooney just to sanity check that teh libvirt/qemu part works as expected.
18:31:35 sean-k-mooney so i dont spend 9 months trying to enable somthing that broken.
18:40:12 aspiers sean-k-mooney: we already had other guys boot it successfully without nova
18:40:27 aspiers sean-k-mooney: the reference XML is even linked from the SEV nova spec
18:40:57 aspiers persuading nova to achieve a working config was the hard bit
18:40:59 sean-k-mooney sure it just make me feel better when i do it myself pluse the xml generation is usually the simplest part
18:41:36 aspiers since the reference XMLs were not generated from nova, therefore it was a question of gradually shrinking the differences until nova generated a working config
18:41:47 aspiers like boring from opposite ends of a tunnel and meeting in the middle
18:42:28 aspiers now I have like 2 days to backport the whole thing to rocky
18:43:42 sean-k-mooney your goign to backport it before it merges
18:44:02 aspiers yes just for this demo
18:44:14 aspiers downstream only
18:44:29 aspiers the backport would never get accepted upstream anyway
18:46:21 sean-k-mooney well yes but if its a demo i would personally use master
18:46:34 sean-k-mooney it would make your life a lot simpler
18:53:52 aspiers it won't because SUSE OpenStack Cloud doesn't run on master
18:54:29 aspiers having said that, plan B will just be to use devstack I guess
18:55:03 sean-k-mooney aspiers: i was assuming you would demo with devstack yes
18:55:43 sean-k-mooney i fixed the typos you spotted in the vpmu patch by the way.
18:56:18 sean-k-mooney im going to go have dinner so talk to you tomorow/later
19:00:03 openstackgerrit Gage Hugo proposed openstack/nova master: Update config doc policy file type https://review.opendev.org/673349
19:14:46 aspiers sean-k-mooney: thanks
19:15:00 aspiers something in my devstack changed and now I get this when I try to delete instances:
19:15:03 aspiers ERROR oslo_messaging.rpc.server RemoteError: Remote error: IncompatibleObjectVersion Version 1.1 of ConsoleAuthToken is not supported, supported version is 1.0
19:15:45 aspiers I know that's an OVO thing, but I have no idea how to fix it except for redeploying devstack which would take ages and hose a bunch of setup I want to keep - any ideas?
19:16:47 aspiers ah, I see the patch which added 1.1 recently - that explains why it happened, but not how I can migrate my objects
19:24:36 aspiers doh, I just had to restart *all* nova services
19:24:42 aspiers must have been a mismatch with n-cpu
19:35:03 openstackgerrit Eric Fried proposed openstack/nova-specs master: tox -e fast-specs https://review.opendev.org/673356
19:35:10 efried sean-k-mooney, mriedem: as we discussed the other day ^

Earlier   Later