| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-11-01 | |||
| 11:15:20 | johnthetubaguy | stephenfin: yeah, it makes sense not to disrupt the chain. | |
| 11:50:16 | openstackgerrit | huanhongda proposed openstack/nova master: AZ operations: check host has no instances https://review.openstack.org/611833 | |
| 12:19:11 | openstackgerrit | Zhenyu Zheng proposed openstack/nova master: WIP support attach/detach root volume 2 https://review.openstack.org/614750 | |
| 12:20:20 | jaypipes | johnthetubaguy: re: the unified limits thing... I should have some PoC code to show you by end of week. It will give us something more concrete to discuss. It doesn't impact the REST API in nova at all. | |
| 12:21:24 | johnthetubaguy | jaypipes: OK, cool. Which bit are you looking at, using placement or the oslo.limits piece, or both? | |
| 12:22:18 | johnthetubaguy | jaypipes: was hoping to start work on a PoC soon, how I have finished the previous project that has been distracting me full time! | |
| 12:22:19 | jaypipes | johnthetubaguy: both. | |
| 12:22:56 | johnthetubaguy | at the PTG we seemed to land on doing the placement thing second, but I would certainly like to see the two together | |
| 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 | mriedem | hmm, did something regress with performance? https://bugs.launchpad.net/nova/+bug/1800755 | |
| 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: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: API microversion bump for handling-down-cell https://review.openstack.org/591657 | |
| 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: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 | |