| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-11-01 | |||
| 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? | |
| 15:09:20 | lyarwood | mriedem: unfortunately I'm no longer attending, sent a note to the foundation when I found out yesterday. | |
| 15:09:33 | mriedem | lyarwood: hmm, i could possibly run that session | |
| 15:09:38 | mriedem | or we could find *someone* | |
| 15:09:48 | dansmith | I vote for mriedem | |
| 15:09:59 | mriedem | random berliner on the street | |
| 15:10:03 | mriedem | i'll pay them in sausage | |
| 15:10:06 | dansmith | he needs more stuff to do and I hear he loves volumes, especially multi-attached ones | |
| 15:10:32 | mriedem | i'll gladly moderate any number of forum sessions if it means i don't have to do any presentations | |
| 15:12:44 | mriedem | lyarwood: well if the foundation doesn't pull the session, it looks like i had it marked on my calendar to attend anyway so if you want i can moderate it | |
| 15:12:50 | mriedem | and just assign all of the work to you | |
| 15:13:56 | lyarwood | mriedem: haha so nothing would ever get done | |
| 15:14:15 | lyarwood | mriedem: but yeah let me ping them quickly and see if I can save that session | |
| 15:14:38 | mriedem | there are a few volume-related specs for stein that would be good to discuss there, like this one to specify delete_on_termination when attaching a volume (and changing that value for existing attachments) | |
| 15:15:12 | mriedem | which reminds me, i dusted this off too https://review.openstack.org/#/c/393930/ | |
| 15:15:16 | mriedem | getting device tags out of the API | |
| 15:15:24 | mriedem | dansmith: i think you've been on board with that in the past ^ | |
| 15:15:59 | lyarwood | mriedem: ha the delete_on_termination issue just came up downstream and we NACK'd assuming it would be lots of work for little gain | |
| 15:16:13 | lyarwood | mriedem: are you getting pushed for that as well given users can do this in AWS? | |
| 15:16:16 | mriedem | the major problem i see with that one is we already have a PUT API for volume attachments, | |
| 15:16:19 | mriedem | the dreaded swap volume API | |