Earlier  
Posted Nick Remark
#openstack-nova - 2019-07-29
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 ^
19:36:58 efried stephenfin: that probably wants your sphinx expertise ^
19:37:12 openstackgerrit Erik Olof Gunnar Andersson proposed openstack/nova master: Cleanup when hitting MaxRetriesExceeded from no host_available https://review.opendev.org/672855
19:39:51 openstack bug 1837955 in OpenStack Compute (nova) "MaxRetriesExceeded sometime fails with messaging exception" [Medium,In progress] https://launchpad.net/bugs/1837955 - Assigned to Erik Olof Gunnar Andersson (eandersson)
19:39:51 openstackgerrit Matt Riedemann proposed openstack/nova master: Add functional regression test for bug 1837955 https://review.opendev.org/673357
19:39:54 mriedem eandersson: efried: sean-k-mooney: ^ here is the functional test, i'll rebase the fix on top of it - was kind of a pain to make sure it would work on queens
19:42:55 openstackgerrit Matt Riedemann proposed openstack/nova master: Cleanup when hitting MaxRetriesExceeded from no host_available https://review.opendev.org/672855
19:42:58 mriedem rebased
20:08:00 openstackgerrit Eric Fried proposed openstack/nova master: Cleanup when hitting MaxRetriesExceeded from no host_available https://review.opendev.org/672855
20:09:24 eandersson Thanks efried
20:09:40 efried thanks for the fix
20:09:58 efried now we just need someone to send mriedem's test
20:28:29 sean-k-mooney dumb question but we have a bunch of tempest test that end in TestJSON what makes them different form normal tempest tests. are then calling the api with json payloads or somthing?
20:43:01 sean-k-mooney ... i is confused
20:43:32 sean-k-mooney the tempest-fully-py3 job supports depends-on against neutron patches right
20:44:07 sean-k-mooney because my patch failed with an error message i deleted form the neutron code base so it really looks like it didnt work
20:45:41 sean-k-mooney yat http://logs.openstack.org/32/602432/12/check/tempest-full-py3/39b553b/job-output.txt.gz#_2019-07-23_17_51_24_263888 it looks like it didnt check out my patch
20:46:28 sean-k-mooney yep it ran with master ... http://logs.openstack.org/32/602432/12/check/tempest-full-py3/39b553b/job-output.txt.gz#_2019-07-23_17_54_02_352110
21:01:33 openstackgerrit sean mooney proposed openstack/nova master: libvirt: delegate ovs plug to os-vif https://review.opendev.org/602432
21:16:38 eandersson btw is it just RamFilter that is being removed? Or is AggregateRamFilter being removed as well?
21:16:52 eandersson Because I see AggregateRamFilter is still a thing in Stein
21:17:46 sean-k-mooney both
21:18:13 sean-k-mooney and the core and disk filter both aggreagte and non aggrate forms
21:18:52 sean-k-mooney eandersson: all 6 filter have been depreacted since ocata
21:19:10 sean-k-mooney we removed the caching scudler i think in stien which was the last valid usecase for them
21:19:23 eandersson I see
21:20:19 sean-k-mooney we still actully have the filter on master but i dont think they work properly anymore
21:20:55 eandersson I did like how you could orchestrate aggregates
21:21:25 sean-k-mooney you can still do that in a sligtly different way via placmenet
21:21:47 sean-k-mooney but its perfromce before did nto scale well and there were a bunch of edgcases
21:22:04 sean-k-mooney it looks like https://github.com/openstack/nova/commit/78645e61c63bf042453d1f822ae8b3f1ee6a311b missed the aggrate versions
21:22:18 openstackgerrit Artom Lifshitz proposed openstack/nova master: New objects for NUMA live migration https://review.opendev.org/634827
21:22:18 openstackgerrit Artom Lifshitz proposed openstack/nova master: [WIP-until-series-is-ready] Introduce live_migration_claim() https://review.opendev.org/635669
21:22:19 openstackgerrit Artom Lifshitz proposed openstack/nova master: LM: add support for augmenting migrate_data with info from claims https://review.opendev.org/634828
21:22:20 openstackgerrit Artom Lifshitz proposed openstack/nova master: NUMA live migration support https://review.opendev.org/634606
21:22:20 openstackgerrit Artom Lifshitz proposed openstack/nova master: RPC changes to prepare for NUMA live migration https://review.opendev.org/634605
21:22:20 openstackgerrit Artom Lifshitz proposed openstack/nova master: LM: add support for updating NUMA-related XML on the source https://review.opendev.org/635229
21:22:21 openstackgerrit Artom Lifshitz proposed openstack/nova master: [WIP] Functional test for NUMA live migration https://review.opendev.org/672595
21:22:21 openstackgerrit Artom Lifshitz proposed openstack/nova master: Deprecate CONF.workarounds.enable_numa_live_migration https://review.opendev.org/640021
21:23:10 artom Probably broke a whole bunch of unit tests with that, will let CI tell me what's up.
21:25:26 artom But the problems that were left at the end of Stein have been fixed
21:32:46 sean-k-mooney the main one was saving the updated xml right
21:33:17 sean-k-mooney when i tested it at the end of stien it more or less worked bar the quirk
21:34:47 artom The two problems were: 1. not saving the new instance_numa_topology 2. If the resource audit ran during the LM, it wouldn't pick up the migrating instance, and would remove its resources from usage
21:35:29 sean-k-mooney oh ok and they are fixed in the patches you just pushed
21:36:18 sean-k-mooney im going to redeploy my 2 node ovn setup to something more more useful
21:36:23 artom Yeah. But like I said, I probably broke other things, just by changing some method names and removing that PinMapping object
21:36:33 sean-k-mooney should i pull down your latest patches and give them a try?
21:36:45 artom Not yet :)
21:36:56 artom I'll email the ML when it's ready (should be this week)
21:37:17 artom I know Windriver (and Cisco too, apparently?) would like to test it out
21:37:19 sean-k-mooney ok i might try and test numa + sriov next week

Earlier   Later