Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-11-01
12:23:10 jaypipes johnthetubaguy: not actually using oslo.limits, but with a bunch of "TODO(jaypipes): This should be ported to oslo.limits" notes. :) Along with a health dose of "NOTE(jaypipes): Under no circumstances should this infect oslo.limits"
12:23:26 johnthetubaguy ah, OK, got you
12:23:38 johnthetubaguy sounds good
12:23:49 jaypipes johnthetubaguy: yeah, I'm tackling the limit-getting stuff first, placement queries second.
12:24:28 jaypipes johnthetubaguy: obviously, the limit-*setting* stuff along with quota classes are the things marked "under no circumstances should this infect oslo.limits" :)
12:25:37 johnthetubaguy jaypipes: I was thinking along the lines of a parallel quota system, so we just ditch all the old stuff, its too infected with junk like user limits
12:26:17 johnthetubaguy well, its clearly not quite that simple, but anyways, looking forward to seeing the PoC
12:27:03 jaypipes johnthetubaguy: yeah, I haven't touched any of the "develop a system to migrate nova to use unified limits" stuff. that part of your spec would still very much be needed.
12:27:44 jaypipes johnthetubaguy: that said, I've added the infrastructure to be able to configure CONF.quota.driver to something like "unified" and have that switch the underlying mechanisms for limits retrieval.
12:28:00 jaypipes johnthetubaguy: so hopefully that data migration stuff can build on top of my work.
12:28:36 jaypipes johnthetubaguy: hopefully it should all make sense when I push the code today or tomorrow.
12:28:50 jaypipes (I'm OOO this afternoon)
12:29:42 johnthetubaguy jaypipes: ah, I don't have code for it yet, only a plan. Yeah, I think I get what you mean, but will look out for the patches
12:30:31 jaypipes johnthetubaguy: cool, thanks. I'll add you to the reviews.
12:51:42 openstackgerrit OpenStack Proposal Bot proposed openstack/nova stable/rocky: Imported Translations from Zanata https://review.openstack.org/614757
13:38:38 sean-k-mooney bauzas: mriedem we have a regression in the os-vif 1.12.0 release which is fixed in one of my patches already so we are going to blacklist 1.12.0 in the global requirements. https://review.openstack.org/#/c/614764/1
13:39:36 sean-k-mooney im going to work on geting 2 new os-vif gate jobs to test ovs with iptables and linux brige next sprint to catch these kind of thing going forward
13:40:01 sean-k-mooney ill likely start on that next week however.
13:40:13 sean-k-mooney bauzas: as the nova release liasion could you comment on
13:40:21 sean-k-mooney https://review.openstack.org/#/c/614764/1
13:43:09 mnaser ok please forgive me if this sound silly but
13:43:21 mnaser microversion 1.4 > microversion 1.25, right?
13:45:33 sean-k-mooney no
13:45:44 sean-k-mooney its not a desimal point
13:45:55 sean-k-mooney it semantic versioning
13:46:50 mnaser ok
13:46:54 mnaser explains things
13:46:59 mnaser thanks sean-k-mooney
13:50:33 johnthetubaguy mnaser: its more like version 4.0 vs version 25.0 actually, as any micro-version can drop functionality
13:51:17 mnaser Okay, so trying to figure out why this upgrade somehow is causing nova to request a micro version 1.25 but the service is not providing that
13:51:23 mnaser Could be a super screwed up deployment too.
13:51:39 johnthetubaguy oh right, request the version from cinder or ironic?
13:52:21 johnthetubaguy we usually have a minimum version we need, which implies a minimum version of all the dependent services
13:53:28 johnthetubaguy mnaser: who is requesting 1.25 from whom?
13:55:54 mnaser johnthetubaguy: so it looks like os_region_name is not a valid option inside the placement section
13:56:22 mnaser So this multiregion deployed was probably hitting the wrong region. os_region_name was silently dropped?
13:56:38 mnaser So it was hitting an older region
13:56:44 johnthetubaguy good question, that sounds bad
13:57:37 mnaser It was removed after one cycle..
13:57:39 sean-k-mooney mnaser: the simplest thing to do it pretend ther is no .
13:58:02 mnaser https://github.com/openstack/nova/commit/3db815957324f4bd6912238a960a90624d97c518
13:58:12 mriedem nova meeting in 2 minutes
13:58:15 mnaser A bit quick to remove it after just a cycle?
14:01:37 johnthetubaguy mnaser: that has always been the norm for config, we just don't usually remember to do it
14:04:48 mnaser johnthetubaguy: ah okay
14:06:06 johnthetubaguy mnaser: now the whole skip version upgrades thing clearly makes that less of a good policy... not sure if we have an answer for that one yet.
14:07:45 mnaser johnthetubaguy: yeah, i dont do that (nor do i support that idea).. so i should look at logs :p
14:09:47 johnthetubaguy mnaser: heh :)
14:15:51 mriedem oslo.config has a new thing for FFU with config stuff
14:19:44 johnthetubaguy mriedem: ah, cool
14:20:07 sean-k-mooney on the meeting ended quicking then i taught it would
14:21:20 sean-k-mooney i was going to ask peole to asses https://blueprints.launchpad.net/nova/+spec/libvirt-neutron-sriov-livemigration and the related spec if they can to indicate if this can proceed for this cycle
14:21:46 sean-k-mooney i have spec update to make but they will be done later today.
14:23:39 mriedem johnthetubaguy: mnaser: this thing https://specs.openstack.org/openstack/oslo-specs/specs/rocky/handle-config-changes.html
14:23:48 mriedem i think that is still a WIP
14:24:28 mriedem jackding: if https://review.openstack.org/#/c/609180/ is ready for review please put it in the runways queue https://etherpad.openstack.org/p/nova-runways-stein
14:42:27 openstack Launchpad bug 1800755 in OpenStack Compute (nova) "The instance_faults table is too large, leading to slow query speed of command: nova list --all-tenants" [Undecided,New]
14:42:27 mriedem hmm, did something regress with performance? https://bugs.launchpad.net/nova/+bug/1800755
14:42:36 mriedem that was fixed with https://bugs.launchpad.net/nova/+bug/1800755
14:42:38 mriedem oops
14:42:41 mriedem https://review.openstack.org/#/c/409943/
14:43:30 mriedem is there any reason we don't purge old faults?
14:43:32 mriedem we only show the latest
14:43:50 mriedem and we don't provide any API or nova-manage CLI to show *all* faults for a given instance
14:44:26 jackding mriedem: sure, will do
14:45:02 sean-k-mooney mriedem: would that mess with audit logs?
14:45:40 mriedem you mean that config/api that no one uses?
14:45:43 sean-k-mooney mriedem: a nova-manage command could make sense or an admin only api
14:45:44 mriedem https://developer.openstack.org/api-ref/compute/?expanded=list-server-usage-audits-detail#server-usage-audit-log-os-instance-usage-audit-log
14:46:31 sean-k-mooney mriedem: no i was thinking that for some deployment there may be requiremetn to record falts for audit/sla reasons
14:46:52 sean-k-mooney i was not thinking of any feature in partaclar
14:47:43 sean-k-mooney im just not sure if auto cleanup of old faluts would be somehting we would want in all cases
14:47:59 mriedem i'm not suggest an auto cleanup,
14:48:06 mriedem but a nova-manage db purge_faults
14:48:35 openstackgerrit Surya Seetharaman proposed openstack/nova master: [WIP] Make _instances_cores_ram_count() be smart about cells https://review.openstack.org/569055
14:48:36 openstackgerrit Surya Seetharaman proposed openstack/nova master: [WIP] Add os_compute_api:servers:create:cell_down policy https://review.openstack.org/614783
14:48:36 openstackgerrit Surya Seetharaman proposed openstack/nova master: WIP: API microversion bump for handling-down-cell https://review.openstack.org/591657
14:48:44 sean-k-mooney ya that i think makes total sense. the same way keystone allows you to purge the expired uuid tokens from its db
14:50:08 sean-k-mooney mriedem: where you thinking it would drop the fault older then X from the db or move them to an archive table?
14:51:57 mriedem i'm not really putting much thought into this
14:54:09 sean-k-mooney its one of those things that if you brought it up at the ptg i woudl be like "sure go for it" but it also does not should like a supper high prioity either so ya in any case i cant really think of a reason not to allow it off the top of my head
14:58:43 mriedem tssurya: in case you haven't started yet, i was thinking about how to do 2.68 down-cell functional api samples testing, which will require some kind of fixture to simulate a down cell,
14:58:48 mriedem and i think i have an idea of how to write that
15:00:16 tssurya mriedem: I saw your todos but I haven't started, feel free to start if you have the time your tests are surely going to be more thorough than mine.
15:00:24 tssurya bug thanks
15:00:27 tssurya big*
15:00:58 mriedem ok i think i'll just hack on a DownCellFixture in a separate patch below the API microversion one at the end, and then it could be used in the functional api samples tests,
15:01:04 mriedem the nice thing with fixtures is they are also context managers,
15:01:19 mriedem so you could create a server while the cell is 'up' and then do something like:
15:01:26 mriedem with down_cell_fixture:
15:01:40 mriedem get('/servers')
15:01:50 mriedem and you should get the minimal construct back
15:02:27 tssurya oh nice
15:02:42 tssurya there was a doubt however with the sample tests, the jsons you have created.. I thought they were supposed to be created automatically once we write the tests ?
15:02:51 mriedem i think they are,
15:02:58 mriedem i was just trying to get the api-ref build to pass
15:03:07 tssurya ah okay :)
15:07:40 mriedem lyarwood: don't forget to add an etherpad for your forum session to https://wiki.openstack.org/wiki/Forum/Berlin2018
15:07:46 mriedem i think i have crap to dump in there
15:09:19 mriedem melwitt: were you going to send https://etherpad.openstack.org/p/nova-forum-stein to the ML for the list of xp sessions to have warm nova bodies in attendance?

Earlier   Later