| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-23 | |||
| 11:17:06 | kashyap | stephenfin or anyone: Do we have a precendence in Nova where we allow comma-separated values for a config attribute? | |
| 11:17:26 | stephenfin | kashyap: Look at oslo_config.types | |
| 11:17:33 | stephenfin | I'm guessing ListOpt is what you want | |
| 11:18:13 | stephenfin | I _think_ ListOpt uses CSV, but it should be easy enough to verify (look for existing usages in the nova tree) | |
| 11:19:08 | kashyap | stephenfin: I see, will look once I make quick lunch | |
| 11:19:50 | kashyap | nova/conf/libvirt.py: cfg.ListOpt('hw_machine_type', | |
| 11:19:50 | kashyap | nova/conf/libvirt.py: cfg.ListOpt('disk_cachemodes', | |
| 11:19:50 | kashyap | $> git grep ListOpt nova/conf/libvirt.py | |
| 11:19:50 | kashyap | stephenfin: So there is some precedence: | |
| 11:19:51 | kashyap | nova/conf/libvirt.py: cfg.ListOpt('uid_maps', | |
| 11:19:53 | kashyap | nova/conf/libvirt.py: cfg.ListOpt('gid_maps', | |
| 11:19:55 | kashyap | nova/conf/libvirt.py: cfg.ListOpt('enabled_perf_events', | |
| 11:19:58 | kashyap | nova/conf/libvirt.py: cfg.ListOpt('vzstorage_mount_opts', | |
| 11:20:55 | stephenfin | kashyap: Then you're golden. That's the approach I'd take | |
| 11:21:06 | stephenfin | Offloads all the hard work (parsing) to oslo.config | |
| 11:22:06 | kashyap | I see, noted. | |
| 11:22:27 | kashyap | stephenfin: So, what I'm looking to do is something like: | |
| 11:23:03 | kashyap | If you specify: | |
| 11:23:10 | kashyap | cpu_model_extra_flags="+pcid,-mtrr,pdpe1gb" | |
| 11:23:10 | kashyap | cpu_model=IvyBridge | |
| 11:23:10 | kashyap | [libvirt] | |
| 11:23:28 | kashyap | Which means: Add the PCID feature and 'pdpel1gb' feature (assume '+' is | |
| 11:23:29 | kashyap | given if it's not specified), and *remove* the 'mtrr' feature. | |
| 11:23:38 | kashyap | Then Nova should be able to generate an XML something like: | |
| 11:23:46 | kashyap | <feature policy='require' name='pdpe1gb'/> | |
| 11:23:46 | kashyap | <feature policy='require' name='pcid'/> | |
| 11:23:46 | kashyap | <vendor>Intel</vendor> | |
| 11:23:46 | kashyap | <model fallback='forbid'>IvyBridge</model> | |
| 11:23:46 | kashyap | <cpu match='exact'> | |
| 11:23:49 | kashyap | </cpu> | |
| 11:23:56 | kashyap | stephenfin: Makes sense? | |
| 11:24:37 | stephenfin | Sounds sane. Why would you remove something though? | |
| 11:24:41 | kashyap | The +/- in nova.conf will be optional. If nothing is specified, assume '+'. | |
| 11:24:57 | stephenfin | I assume 'mtrr' would be added by default if you didn't explicitly add '-mtrr'? | |
| 11:25:16 | kashyap | stephenfin: If an advanced operator wants to generate a baseline CPU config, and a certain CPU flag is causing performance issue or other nuisance | |
| 11:25:34 | kashyap | And if she isolated the problem to _that_ specific CPU flag | |
| 11:25:40 | kashyap | Thens she may want to remove it. | |
| 11:25:43 | kashyap | Reasonable? | |
| 11:26:01 | kashyap | stephenfin: Yep, your assumption about 'mtrr' is true. | |
| 11:26:58 | stephenfin | Yum, that sounds reasonable to me | |
| 11:27:04 | stephenfin | *Yup | |
| 11:27:06 | stephenfin | :) | |
| 11:27:14 | kashyap | I.e. if you specified: 'mtrr', then it will be '+mtrr'. (Additional note: some named libvirt CPU models _already_ included 'mtrr') | |
| 11:27:25 | kashyap | Heh, noted. | |
| 11:27:29 | kashyap | Thanks | |
| 11:27:59 | kashyap | Now to figure out the XML spaghetti | |
| 12:00:21 | openstackgerrit | Chris Dent proposed openstack/nova master: Fix nits in allocation candidate limit handling https://review.openstack.org/536784 | |
| 12:00:38 | cdent | stephenfin: that ^ gets some cleanups you asked for | |
| 12:02:42 | ameeda | alex_xu : can you please check this for me ? https://review.openstack.org/#/c/526900/ | |
| 12:39:10 | openstackgerrit | int32bit proposed openstack/nova master: Set server status to ERROR if rebuild failed https://review.openstack.org/536268 | |
| 12:43:04 | openstackgerrit | int32bit proposed openstack/nova master: Refix disk size during live migration with disk over-commit https://review.openstack.org/536351 | |
| 12:49:37 | ilyashakhat | hi! may I have cores attention to https://review.openstack.org/#/c/519664/ ? the patch is approved, but Zuul did not merge it | |
| 12:49:55 | ilyashakhat | most probably needs another +W to trigger the gate | |
| 12:51:20 | alex_xu | ilyashakhat: done | |
| 12:51:22 | openstackgerrit | Lee Yarwood proposed openstack/nova master: DNM: Test LM with encrypted volumes https://review.openstack.org/536350 | |
| 12:51:43 | ilyashakhat | alex_xu: thanks! | |
| 12:52:46 | alex_xu | ameeda: sorry, really busy on freeze, will get chance after freeze | |
| 12:52:49 | alex_xu | ilyashakhat: np | |
| 12:54:25 | ameeda | alex_xu: np :) | |
| 13:17:44 | openstackgerrit | sahid proposed openstack/nova master: libvirt: add support for virtio-net rx/tx queue sizes https://review.openstack.org/484997 | |
| 13:29:15 | lyarwood | mdbooth: *facepalm* how did I screw up that if volume_id block *sigh* | |
| 13:29:33 | mdbooth | lyarwood: Hehe, it totally doesn't matter. | |
| 13:41:41 | mdbooth | lyarwood: Bet ^^^ is your fault :P | |
| 13:42:22 | lyarwood | mdbooth: you're welcome! :) | |
| 13:42:39 | lyarwood | mdbooth: pretty sure your swap volume test removal patch also caused a conflict this morning | |
| 13:42:49 | lyarwood | mdbooth: so it works both ways :) | |
| 13:43:10 | Spazmotic | This I will say is the one benefit from working the XenAPI drivers | |
| 13:43:14 | mdbooth | Indeed. | |
| 13:43:15 | Spazmotic | No merge conflicts :p | |
| 13:43:33 | mdbooth | Spazmotic: And also the curse :) How do you find getting core reviews on it? | |
| 13:43:49 | Spazmotic | Not sure if that burn was incidental or on purpose hehehehe | |
| 13:44:13 | Spazmotic | My last and first commit ac tually went through pretty quick, but that was back in Liberty | |
| 13:44:27 | Spazmotic | Now that i'm trying to get more active, struggling ot get any love with Xenapi, hence why i'm trying to learn placement | |
| 13:45:39 | bauzas | cdent: all cool | |
| 13:45:46 | bauzas | reviewing https://review.openstack.org/#/c/519462/ | |
| 13:47:04 | mdbooth | Spazmotic: It's a perennial problem that it's harder to get core reviews in areas of the codebase cores are less familiar with. Doesn't even help to become a core, because you can't core review your own stuff :/ | |
| 13:47:38 | Spazmotic | Hahah nah I certainly understand.. I know XenAPI isn't the hotness right now, so i try to be patient and wait :) | |
| 13:49:25 | cdent | efried_back_wed: you're not supposed to be here. I haven't rechecked the things you just rechecked yet to try to make less noise while the stuff before it is still being chewed on | |
| 13:50:56 | efried_back_wed | cdent It's a toss-up whether it'll be slower to check them serially (and have to wait for N to merge before rechecking N+1) or keep 'em all in the pipe in parallel so that maybe, just maybe, more than one will merge at once. | |
| 13:51:26 | efried_back_wed | cdent And I promise, I'll bugger off to my appointment in a few minutes. | |
| 13:51:45 | cdent | efried_back_wed: given that most of the failures are timeouts I tend to not want to parellelize | |
| 13:52:01 | cdent | which is probably illogical since something else will just take the spot, but meh | |
| 13:52:30 | efried_back_wed | cdent It had occurred to me to ask the infra folks whether we could increase whatever timeouts those are. I imagine they've already weighed the pros and cons of that, though. | |
| 13:52:44 | cdent | 'spect so | |
| 13:52:55 | cdent | this is going to merge very soon: https://review.openstack.org/#/c/526540/ | |
| 13:57:16 | efried_back_wed | Now you've jinxed it | |
| 14:02:23 | Spazmotic | Feels good to have a +1 on my code finally, and from someone at citrix with that.. makes me breathe easier hehe | |
| 14:05:47 | ildikov | #success OpenStack now supports to attach a Cinder volume to multiple VM instances managed by Nova. | |
| 14:05:50 | openstackstatus | ildikov: Added success to Success page | |
| 14:05:51 | ildikov | Miracles exist when we have amazing and dedicated people to make them happen. :) | |
| 14:06:00 | gibi | ildikov: \o/ | |
| 14:06:02 | rgerganov | efried_back_wed, no luck trying to register a nested RP with the provider_tree | |
| 14:06:12 | ildikov | gibi: :) | |
| 14:07:00 | efried_back_wed | rgerganov Okay; leave some words on the patch, or send me an email, and I can dig in some more tomorrow (or maybe for a few minutes tonight) | |
| 14:07:33 | rgerganov | efried_back_wed, sure, I am digging into this right now, will post all findings that I have at the end of the day | |
| 14:07:48 | efried_back_wed | rgerganov ++ | |
| 14:08:11 | openstackgerrit | Radoslav Gerganov proposed openstack/nova master: WIP: VMware: implement update_provider_tree() https://review.openstack.org/536348 | |
| 14:09:01 | openstackgerrit | Sylvain Bauza proposed openstack/nova master: Avoid suspending guest with attached vGPUs https://review.openstack.org/535693 | |
| 14:10:44 | mriedem | andreykurilin: can you take a look at the novaclient change to support 2.59 https://review.openstack.org/#/c/516168/ and the small patch after it for 2.60? | |
| 14:11:11 | andreykurilin | looking | |