Monday, 2018-03-26

*** chhagarw has joined #openstack-powervm04:48
*** arunman has joined #openstack-powervm05:25
*** AlexeyAbashkin has joined #openstack-powervm06:19
*** AlexeyAbashkin has quit IRC06:24
*** openstackgerrit has joined #openstack-powervm07:12
openstackgerritArun Mani proposed openstack/nova-powervm master: Add affinity score check attribute to flavor  https://review.openstack.org/55530907:12
*** AlexeyAbashkin has joined #openstack-powervm07:50
*** k0da has joined #openstack-powervm08:03
*** chhagarw has quit IRC09:02
*** chhavi__ has joined #openstack-powervm09:02
*** AlexeyAbashkin has quit IRC11:14
*** arunman has quit IRC11:24
*** AlexeyAbashkin has joined #openstack-powervm11:29
openstackgerritChhavi Agarwal proposed openstack/nova-powervm master: iSCSI pre-live-migration implementation  https://review.openstack.org/55649511:41
openstackgerritChhavi Agarwal proposed openstack/nova-powervm master: [WIP]:iSCSI pre-live-migration implementation  https://review.openstack.org/55649512:07
*** edmondsw has joined #openstack-powervm12:13
*** chhavi__ has quit IRC12:16
*** chhagarw has joined #openstack-powervm13:13
*** tjakobs has joined #openstack-powervm13:44
*** arunman has joined #openstack-powervm13:53
*** arunman has quit IRC14:30
*** arunman has joined #openstack-powervm14:41
*** esberglu has joined #openstack-powervm14:54
esbergluedmondsw: efried: https://review.openstack.org/#/c/554688/14:55
esbergluNo longer seeing the not enough procs failure on IT runs14:55
efriednoyce14:55
esbergluDo we want to expose that as a conf option or just set it?14:55
efriedgood question.14:56
efriedactually14:56
efriedI wonder if we should set it based on the cpu_allocation_ratio14:56
efried'cept that has some pretty serious baggage.14:59
esbergluefried: And set it to what if cpu_allocation_ration is 0 (default)15:04
esbergluKeep it at 0.1 to stay consistent with OOT?15:04
edmondswI take it the issue with just setting it is backward compat?15:05
efriedNot really IMO15:05
efriedIt's that we'd be hardcoding an override of a default.15:05
edmondswyeah, I wouldn't think a backward compat argument would hold much water15:05
edmondswefried I don't have a problem hardcoding an override of a default15:06
efriedSo... yeah, I guess let's dup the conf option we have OOT so we can moot both issues.15:06
edmondswwhen doing so makes us consistent with OOT15:06
efrieddoes it?  Is the OOT conf default 0.1?15:06
edmondswI thought so... am I wrong?15:07
esbergluOOT defaults to 0.115:07
edmondswyep, that's what I thought I remembered from last week15:08
efriedokay, didn't know whether we were overriding it via local.conf in CI.  Because of this very issue having been encountered two years ago.15:08
edmondswnope https://github.com/openstack/nova-powervm/blob/master/nova_powervm/conf/powervm.py#L2815:09
efriedPath of least resistance is to monkey-patch it into the CI.  But I guess eventually someone is going to want it to be configurable in tree.15:09
efriedIIRC, we just took out as many conf options as we could get away with to reduce the size of the initial patches.15:09
edmondswI don't want to monkey patch15:09
efriedAt this point we can trickle 'em back in hopefully fairly easily.15:10
esbergluYeah we're gonna have to start exposing conf options eventually15:10
edmondswI think the path of least resistance is change it 0.1 hardcoded IT, and then talk about adding conf settings in a later patch15:10
edmondswwhen we do introduce conf settings, the default will be 0.1 for the conf setting, so hardcoding 0.1 first is fine15:11
esbergluI'm on board with that15:11
efriedshrug15:13
efriedPersonally I think the hardcoding will be a harder sell to nova cores, but worth a shot.15:13
edmondswsell it as consistency with the OOT driver and fixes a CI issue15:14
esbergluedmondsw: Is there a reason you don't want to expose it now?15:14
edmondswesberglu honestly I thought it would be easier to sell hardcoding than a conf option15:14
edmondswif the cores want a conf setting, I'm fine with that, as long as the default can be 0.115:14
edmondswI think they'll have a bigger issue about the default changing than about whether we have a conf setting or not15:15
edmondswand the default needs to change15:15
edmondswwe need consistency with OOT15:15
edmondswefried?15:15
efriedSo then the really path of least resistance would be to make the conf option default to None or 0.5 and then override it in our CI.15:16
efriedBut I think we can sell consistency with OOT.15:16
edmondswI totally didn't follow that15:16
edmondswdefault to None or 0.5 doesn't seem like an option...15:17
edmondswoh, you mean if we can't sell consistency... yeah, I think we have to15:18
edmondswefried you're needed on slack15:18
efriedoh, look, I wasn't signed in for some reason.15:18
esbergluedmondsw: efried: So we're going hardcode for now on the basis of consistency with a fall back plan of exposing it as a conf option?15:20
esbergluI just need to update the commit message then15:20
edmondswesberglu I think so15:20
edmondswI added something about introducing conf options on the todo etherpad15:22
esbergluedmondsw: Okay. The localdisk IT change introduces some conf options already15:22
esbergludisk_driver and volume_group_name15:22
edmondswsure15:23
edmondswI think it's ok to start introducing conf options as needed15:23
edmondswand if efried wants to lead with that here, I'm fine with it15:24
edmondswso long as the default is 0.115:24
efriedI think that's preferable to hardcoding, yes.15:24
edmondswI yield to whatever option he thinks will be best15:24
esbergluIf we expose conf options here it will also reduce the localdisk footprint15:24
esbergluOkay conf option it is, patch incoming15:25
*** k0da has quit IRC15:25
efrieddig15:26
*** arunman has quit IRC15:36
*** arunman has joined #openstack-powervm15:42
*** arunman has quit IRC15:47
*** arunman has joined #openstack-powervm15:49
*** arunman has quit IRC15:54
*** arunman has joined #openstack-powervm15:56
*** arunman has quit IRC16:01
*** arunman has joined #openstack-powervm16:24
openstackgerritArun Mani proposed openstack/nova-powervm master: Add affinity score check attribute to flavor  https://review.openstack.org/55530916:37
*** arunman has quit IRC16:45
*** chhagarw has quit IRC16:53
*** arunman has joined #openstack-powervm17:06
openstackgerritArun Mani proposed openstack/nova-powervm stable/queens: Add affinity score check attribute to flavor  https://review.openstack.org/55659317:11
edmondswefried I think ^ is good now, ready for you to look17:11
*** AlexeyAbashkin has quit IRC17:15
efrieddone17:18
*** arunman has quit IRC17:43
*** arunman has joined #openstack-powervm17:47
*** arunman has quit IRC17:52
*** k0da has joined #openstack-powervm18:05
*** k0da has quit IRC18:26
*** AlexeyAbashkin has joined #openstack-powervm18:42
esbergluefried: edmondsw: Localdisk is ready for you guys to start reviewing18:43
edmondswack18:43
efriedack18:43
edmondswesberglu just left you a comment on the proc_unit_factor change18:43
esbergluedmondsw: ack18:44
esbergluedmondsw: efried: I did have one q on localdisk.18:47
esbergluOOT we have https://github.com/openstack/nova-powervm/blob/master/nova_powervm/virt/powervm/disk/driver.py#L34918:47
*** k0da has joined #openstack-powervm18:47
esbergluWhich will retry _create_disk_from_image() a few times18:47
esbergluFor SSP IT, we didn't include that retry logic at all18:48
esbergluI also didn't include it for localdisk18:48
esbergluBut didn't have any context on why that retry logic was in there in the 1st place18:49
edmondswesberglu good question...  I have no idea why that's there though18:50
esbergluedmondsw: I'm inclined to leave it as is (no retries) unless I hit something live testing18:51
edmondswyeah18:51
esbergluedmondsw: efried: We also need to decide how to handle conf options IT18:52
esbergluSo that we don't get duplicate opt errors OOT18:52
efriedhum, I had this answer in my head once.18:53
edmondswI remember that coming up the other day18:53
esbergluedmondsw: I don't think we ever came to a decision, we just discussed it IIRC18:53
*** AlexeyAbashkin has quit IRC18:54
edmondswwould we have to put something IT first, to check for nova settings with the same name and not register in that case?18:54
efriedThe retry thing I think is bogus.  We were experiencing intermittent failures of the upload and had no idea why, so we put the retry in to work around it.  We've since completely reworked the upload mechanisms from soup to nuts and are no longer having those failures (or we're retrying some other way, or something).18:56
efriedActually I think we killed it with pypowervm.util.retry_io_command.18:56
edmondswso it should come out IT then18:56
edmondswesberglu add a TODO for that?18:57
efriedSounds like it's already out IT.  Isn't that what we said?18:57
esbergluOOT you mean18:57
efriedyeah18:57
edmondswright, OOT, sorry18:57
*** AlexeyAbashkin has joined #openstack-powervm19:14
*** AlexeyAbashkin has quit IRC19:18
efriedesberglu: See mriedem's question in -nova?20:20
*** edmondsw has quit IRC20:21
*** edmondsw has joined #openstack-powervm20:47
*** edmondsw has quit IRC21:05
*** edmondsw has joined #openstack-powervm21:08
*** edmondsw has quit IRC21:26
*** tjakobs has quit IRC22:00
*** esberglu has quit IRC22:04
*** esberglu has joined #openstack-powervm22:04
*** esberglu has quit IRC22:09
*** AlexeyAbashkin has joined #openstack-powervm22:12
*** AlexeyAbashkin has quit IRC22:16
tonybesberglu, edmondsw, efried: are any of y'all around?22:55
efriedtonyb: I'm here22:55
efriedthe others are gone22:55
tonybefried: 1 is all I need ;P22:56
efriedNot if it's the wrong one...22:56
tonybefried: ;p22:56
efriedLike, if you're going to ask me about RHEL packaging, yer scrood22:56
tonybefried: https://review.openstack.org/#/c/554977/ ... do you know if esberglu picked 3.3.? for a technical reason or was it just "it's the latest"22:56
tonybefried: clearly esberglu would be best to answer that but there are good reasons to pick 3.2.17 and I don't wnat to break things WRT 55497722:58
efriedtonyb: Are any of the things explicitly mentioned in the commit message missing in 3.2.17?22:58
efriedarm64/ppc64?22:58
tonyblet me check I know ppc64le is supported in 3.2 I don't knwo about ppc64(be)22:59
tonybefried: I have to admit I just assumed that was a typo22:59
efriedtonyb: I can be *nearly* certain he just picked the latest.  But yeah, you'll have to ask him to be sure.23:00
efriedassumed what was a typo?23:00
tonybefried: So from an architecture POV 3.2 and 3.3 support the same list (based on a 5sec read of the release notes)23:01
tonyband neither support ppc64(be) it's le all the way ;P23:01
tonybefried: "arm64 and ppc64"  ppc64 vs ppc64le23:01
tonybefried: from esberglu's commit message23:02
efriedOh.  I wasn't aware of any big-endian that we cared about, so I read ppc64 as ppc64le anyway.23:02
tonybhuh 3.217 ... skip a few 3.3.2 strange releases from etcd ;P23:02
efriedOkay.  So you'd like to -1 this patch with a comment to the effect that 3.2.17 would be preferred for <reasons>?  Based on the info you've provided above, that seems like a reasonable thing to do.23:03
tonybefried: Right yeah that was basically what I did23:03
efriedAs your alter ego ianw?23:03
tonybefried: Yeah infra are happy to fix it if we can settle on a version23:03
efriedcool cool.23:04
efriedtonyb: I dropped a link to this discussion in there FYI.23:05
efriedwell, if gerrit decides to get back to me.23:05
efriedthere we go.23:05
tonybefried: Cool. I pined esberglu when I poked infra ianw responded quicker than expected ;P23:06
*** AlexeyAbashkin has joined #openstack-powervm23:12
*** AlexeyAbashkin has quit IRC23:16

Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!