Earlier  
Later
New Search
Posted Nick Remark
#openstack-nova - 2018-11-01
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
15:19:40 mriedem "because AWS and Alibaba have it" is something i hear every week
15:20:05 sean-k-mooney dansmith: because we are exposing configuration via the api or somethign else
15:20:51 dansmith sean-k-mooney: it would literally be an api call that would make an rpc call to scheduler to return a chunk of config, which shouldn't be visible externally anyway. and if you're running multiple schedulers, which do you cal?
15:20:52 mriedem the only reason i could see for doing something like that (scheduler filters and such) is to tell users, via the api, which hints are available
15:21:01 johnthetubaguy sean-k-mooney: discovery of available scheduler hints was something we once said we would consider, which is a bit different
15:21:08 dansmith yep
15:21:16 mriedem right, it would only be feasible if it was a list of hints
15:21:24 mriedem which is totally pluggable btw
15:21:39 sean-k-mooney johnthetubaguy: its related to this tempest change https://review.openstack.org/#/c/570207/12
15:21:43 johnthetubaguy yeah, that was the downside, in the general case, it means nothing useful
15:22:02 sean-k-mooney johnthetubaguy: the issue i have with the change is it require use to keep the nova and tempest default in sync
15:22:03 dansmith sean-k-mooney: tempest has always been blackbox, requiring you to tell it the nova side scheduler config for this reason
15:22:16 artom sean-k-mooney, don't you dare bring more people into this. I will fly to Ireland and cut you, I swear.
15:22:28 artom We already can't agree downstream
15:22:33 dansmith tempest is a testing/validation tool.. keeping the two configs in sync is a few lines of bash
15:22:36 mriedem right, devstack configures the filters in both nova and tempest
15:22:40 dansmith right
15:22:51 sean-k-mooney dansmith: the issue is making triplo do that
15:23:06 mriedem devstack also adds the same/different host filtesr which aren't in the default enabled_filters list for nova
15:23:09 dansmith sean-k-mooney: s/bash/puppet/
15:23:28 mriedem for any nfv ci, they'd also need to configure to numa/pci filters
15:23:28 mriedem etc
15:23:30 sean-k-mooney dansmith: ya i know its just triplo is a pain to make work instead of devstack
15:23:44 dansmith sean-k-mooney: adding an api to nova to work around tripleo not being able to communicate config to another module is INSANITY
15:23:51 sean-k-mooney mriedem: yes today they only need to enable it in nova however
15:24:18 johnthetubaguy I think sdague convinced me about this in the past, you don't want auto discovery, you want to tell the test system what you expect to happen, else there be dragons
15:24:32 artom dansmith, it's not communicate per se - if tripleo doens't set the nova value, it shouldn't have to set the corresponding tempest value
15:25:06 dansmith artom: find another way
15:25:12 dansmith seriously.
15:25:22 johnthetubaguy matching defaults?
15:25:23 artom dansmith, my other way is https://review.openstack.org/#/c/570207/12
15:25:23 sean-k-mooney johnthetubaguy: ya well it was jut a taught my main issue with artom change is that we would have to keep it in sync if we add filter in the futre to the default set
15:25:28 artom johnthetubaguy, that's what ^^ is
15:25:39 artom But apparently everyone is literally willing to fight to the death over this.
15:25:44 dansmith I am
15:25:50 dansmith let's do it.

Earlier   Later