| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-11-01 | |||
| 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 | |
| 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 | |
| 15:16:33 | mriedem | lyarwood: no i'm not getting pushed for it from our product people | |
| 15:16:36 | mriedem | as far as i know anyway | |
| 15:17:06 | mriedem | but it's one of those things that comes up every so often, like proxying the volume type on bfv | |
| 15:17:43 | mriedem | i don't think it's much work, it's just updating the DB | |
| 15:17:54 | mriedem | and taking a new parameter on attach | |
| 15:18:09 | mriedem | updating existing attachments is difficult b/c of our already f'ed up api | |
| 15:18:21 | mriedem | https://developer.openstack.org/api-ref/compute/#update-a-volume-attachment | |
| 15:18:36 | dansmith | it's not a major amount of heavy lifting, | |
| 15:18:45 | dansmith | but the gain seems very minor to me | |
| 15:19:02 | sean-k-mooney | so random quest. would peole object to an api to list the currently enabled schduler filters? specifically to enabel tempest and other multicloud services to detect what schuler featres they can expect | |
| 15:19:12 | dansmith | the strongest argument I've seen for it is that AWS has it and thus the standalone EC2 thing needs to be able to proxy that in | |
| 15:19:16 | sean-k-mooney | *question however it could become a quest | |
| 15:19:18 | dansmith | but afaik, that's pretty much dead these days | |
| 15:19:30 | dansmith | sean-k-mooney: yes I would object | |