| Posted | Nick | Remark | |
|---|---|---|---|
| #openstack-nova - 2018-01-23 | |||
| 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 | |
| 14:12:56 | cdent | rgerganov: is your code that's not working viewable somewhere? | |
| 14:13:13 | rgerganov | cdent: https://review.openstack.org/#/c/536348/3 | |
| 14:13:16 | cdent | oh never mind, actually read the log | |
| 14:13:18 | cdent | thanks | |
| 14:14:24 | mriedem | avolkov: i had some questions in the osc-placement patch for aggregates, which is the first one to add microversion support https://review.openstack.org/#/c/505643/ | |
| 14:14:41 | mriedem | avolkov: i'm not sure how to expose in the help output that --os-placement-api-version 1.1 needs to be used | |
| 14:14:52 | mriedem | besides just adding it directly into the help | |
| 14:18:21 | Roamer` | mriedem, sorry if I'm starting to annoy you, I guess you didn't have time yesterday to take a look at 140733 - the StorPool driver? It's just that it seems that there might not be much time for us to make changes if something should appear to be not quite right... and yes, I do realize that you have a lot to look at, and an exception for a new driver is kind of low priority, I know | |
| 14:19:48 | jroll | mriedem: you didn't secretly fix the segfault thing yesterday, did you? seems to be passing now. | |
| 14:21:56 | openstackgerrit | Alex Xu proposed openstack/nova master: placement: enable required traits from the flavor extra specs https://review.openstack.org/536085 | |
| 14:22:11 | cdent | rgerganov: two things: a) what kind of error are you getting with regard to "no luck", b) if you're putting some vcpus (and other inventory classes) in resource pools child providers, then they can't also be in the parent. it appears that's what your code is currently doing? | |
| 14:22:22 | alex_xu | gibi: I added the release note, thanks for the review | |
| 14:22:46 | alex_xu | bauzas: efried_back_wed I will address the nits tommorow, thanks for the review | |
| 14:22:59 | alex_xu | gibi: also the functional test! | |
| 14:23:24 | gibi | alex_xu: I'm totally OK to have the functional test in a separate followup | |
| 14:23:55 | rgerganov | cdent, you mean that we can't have VCPU in both parent and childs? | |
| 14:23:57 | mriedem | jroll: nope | |
| 14:24:23 | alex_xu | gibi: thanks, will try to submit a separate followup tomorrow | |
| 14:24:24 | jroll | yay | |
| 14:24:48 | cdent | rgerganov: it can be in both places, but they cannot overlap. Any inventory of the same type associated with the child provider needs to be subtracted from the parent. | |
| 14:25:03 | mriedem | Roamer`: i still have the tab open | |
| 14:25:13 | rgerganov | cdent, this is not the problem that I have now | |
| 14:25:30 | rgerganov | cdent, when you start nova-compute udpate_provider_tree is being called twice | |
| 14:25:37 | cdent | rgerganov: yeah, I get that, was just noting it for future reference | |
| 14:26:03 | cdent | first in init and then in the periodic job? | |
| 14:26:54 | rgerganov | cdent, both calls come from _update_available_resource in the RT | |
| 14:28:08 | rgerganov | cdent, on the first call the provider tree seems to be correct and both parent and child RP are updated in placement | |