Earlier  
Posted Nick Remark
#openstack-nova - 2017-04-07
17:10:23 mriedem samarendra: different options are used by different services
17:10:30 samarendra it doesn't seem like it configures the api according to it because i am able to have and use different capabilities on the hypervisor than what is on the hypervisor
17:11:19 samarendra i have disk_cachemodes different on my compute node and controller and the compute node options take precedence when spinning up the vm
17:12:05 mriedem that's because disk_cachemodes is only read from the nova-compute service
17:12:23 samarendra mriedem: ok
17:12:39 samarendra so i can remove the option completely from controller ?
17:12:42 mriedem yes
17:12:50 samarendra ok.
17:13:40 samarendra mriedem: also on the same note, is there actually a detailed doc (apart from code :)) telling how disk_cachemodes can be configured?
17:13:49 samarendra last i saw in the doc it was a bit confusing
17:14:26 mriedem besides https://docs.openstack.org/developer/nova/sample_config.html you mean?
17:14:46 samarendra mriedem: yes
17:15:08 samarendra it talks of only file and block
17:15:17 mriedem there has been a multi-release effort underway to provide better help text to all of the config options, but unfortunately it looks like one hasn't been done yet
17:15:40 samarendra ok i just found another one on https://docs.openstack.org/developer/openstack-ansible/mitaka/install-guide/configure-nova.html
17:16:34 samarendra mriedem: ok. i will try and contribute something on that front from our experience
17:16:40 mriedem thanks
17:16:59 mriedem samarendra: this is the blueprint for the cleanup effort by the way https://blueprints.launchpad.net/nova/+spec/centralize-config-options-pike
17:18:14 mriedem samarendra: fyi https://review.openstack.org/#/c/18042/
17:18:28 samarendra ok. i guess we using mitaka may mean not many useful things can be contributed.
17:18:40 mriedem sure it odes
17:18:41 mriedem *does
17:18:49 mriedem the option is basically unchanged
17:19:03 mriedem the option was introduced in grizzly
17:19:05 mriedem without docs
17:19:09 samarendra oh ok
17:20:30 mriedem from https://libvirt.org/formatdomain.html
17:20:35 mriedem The optional cache attribute controls the cache mechanism, possible values are "default", "none", "writethrough", "writeback", "directsync" (like "writethrough", but it bypasses the host page cache) and "unsafe" (host may cache all disk io, and sync requests from guest are ignored). Since 0.6.0, "directsync" since 0.9.5,
17:20:35 mriedem "unsafe" since 0.9.7
17:21:48 mriedem sfinucan: is it possible to use choices with ListOpt?
17:22:14 samarendra mriedem: if by choices you mean x=y, a=b, then we are already using it :)
17:22:37 mriedem no sorry i meant something else
17:23:07 samarendra mriedem: ok. btw thanks for the links! i never thought of looking at libvirt docs
17:30:55 mriedem also https://www.ibm.com/support/knowledgecenter/linuxonibm/liaat/liaatbpkvmguestcache.htm
17:35:25 openstackgerrit Tadas Ustinavičius proposed openstack/nova master: Adding unit test for the patch https://review.openstack.org/445558
17:36:23 samarendra mriedem: thanks. have seen that already :)
17:36:36 mriedem i'm shamelessly copying it into the config option help
17:43:51 samarendra mriedem: where can i find bugs for openstack nova? i was looking if anyone reported any issues with attaching and detaching volumes on ppc64le arch. or would that be in the domain of openstack-cinder?
17:44:26 mriedem samarendra: https://bugs.launchpad.net/nova/
17:44:26 openstackgerrit Matt Riedemann proposed openstack/nova master: Expand help text for [libvirt]/disk_cachemodes https://review.openstack.org/454823
17:44:31 mriedem samarendra: also ^
17:45:02 samarendra review.openstack.org would be where people submit patches for the bugs on launchpad, right?
17:45:08 mriedem yes
17:45:17 samarendra ok
17:45:28 mriedem see if https://review.openstack.org/#/c/454823/ looks ok
17:49:46 samarendra mriedem: +1
18:01:01 mriedem no jaypipes huh
18:01:21 mriedem dansmith: re: https://review.openstack.org/#/c/407228/ do you know if we changed to always pre-load instances with 'tags' loaded by default now?
18:01:42 mriedem i'm not really sure why we care about sending instance tags on every instance action payload
18:01:55 dansmith mriedem: I have a -1 on the patch to do that
18:02:05 dansmith https://review.openstack.org/#/c/415298/15
18:02:10 dansmith haven't really gotten an answer on it
18:02:39 mriedem hmm, so that comes AFTER https://review.openstack.org/#/c/407228/
18:02:53 mriedem and ^ will lazy-load instance tags on every instance action notification
18:02:54 dansmith I imagine the desire to have it in notifications is so you can do something for all instances tagged a certain way,
18:02:56 mriedem which is a buttload
18:02:57 dansmith but it does seem expensive
18:03:00 dansmith mriedem: yeah I know
18:03:24 mriedem seems we should figure out the lazy-load thing before we start blasting that everywhere
18:03:32 mriedem it'd be one thing if it were instance create/update
18:03:43 dansmith maybe I'm being silly, but it seems like we should pre-load tags anywhere we need to avoid that patch getting any more lazy-loads, then merge that patch
18:03:55 dansmith without making it default
18:03:56 dansmith agree
18:04:34 mriedem yeah i agree with you
18:05:23 dansmith you gonna slap the sad trombone on that bottom one?
18:06:24 mriedem wa mfing wa
18:06:45 mriedem sneti: are you around?
18:07:42 mriedem i think we basically just send tags for instance create and update
18:07:47 mriedem and none of the action payloads
18:08:15 mriedem i believe the whole intent of this is to get instance tags into searchlight for filling in the compute rest api server show response
18:08:26 mriedem to do that, i don't need to blast out tags for suspend/resume actions
18:08:43 dansmith ah, yeah
18:09:13 mriedem it even says in the bp
18:09:13 mriedem https://blueprints.launchpad.net/nova/+spec/additional-notification-fields-for-searchlight
18:09:17 mriedem Step1: Add simple fields to instance.create and instance.update
18:10:56 dansmith sonofa bee
18:11:14 mriedem alright cool, next thing
18:11:22 mriedem so on your workaround patch,
18:11:37 mriedem i wasn't sure if we should call that option out in the track_instance_changes option help text too or not
18:11:42 mriedem or if we should mention it in a reno
18:11:55 dansmith mriedem: or both, yeah I was going to do that
18:12:03 dansmith I'm currently unfscking my discover patch you conflicted with :P
18:12:04 mriedem i mean, a reno might raise eyebrows, which maybe you want or don't want
18:12:15 mriedem given it's the default behavior maybe it's better to not ruffle feathers, idk
18:12:34 dansmith I dunno, I think it's a good highlight for getting claims in the scheduler
18:12:38 mriedem sure
18:12:46 mriedem if you do a reno, i'd just put it in the 'other' section
18:12:52 mriedem not sure it's really a feature or issue or anything
18:12:56 mriedem maybe known issue
18:12:56 dansmith okay
18:13:27 mriedem like, hey, if you plan on having a big deployment and you don't want upcalls from all computes to the api, set this thing, which is temporary until claims in the scheduler
18:13:35 mriedem which is why it's a known issue and we're adding the backdoor workarsound
18:14:09 dansmith ack
18:15:02 mriedem melwitt: the first 4 changes here have my +2 https://review.openstack.org/#/c/442162/ they are super fun i swear - after the first one it's pretty easy
18:15:07 mriedem the first one is mostly just mechanics
18:18:35 jbernard melwitt: not yet, i plan to look at that next
18:23:52 mriedem efried: the long awaited +2 https://review.openstack.org/#/c/438119/11
18:24:01 efried Wohoo!!!
18:24:10 efried thorst ^^
18:25:01 thorst omg

Earlier   Later