Monday, 2015-10-12

*** stevemar_ has joined #openstack-cinder00:00
*** EinstCrazy has quit IRC00:05
openstackgerritZhang Jinnan proposed openstack/cinder: Volume extend error does not catch exception  https://review.openstack.org/22797100:05
*** zhangjn has quit IRC00:17
*** dimsum__ has joined #openstack-cinder00:24
*** haomaiwang has joined #openstack-cinder00:31
*** dimsum__ has quit IRC00:31
*** haomaiwang has quit IRC00:35
*** chlong has joined #openstack-cinder00:51
*** diegows has quit IRC00:55
*** dimsum__ has joined #openstack-cinder00:57
*** mriedem is now known as mriedem_away00:59
*** dimsum__ has quit IRC01:00
*** EinstCrazy has joined #openstack-cinder01:03
*** zhangjn has joined #openstack-cinder01:05
*** gouthamr has quit IRC01:14
openstackgerritZhang Jinnan proposed openstack/cinder: Volume extend error does not catch exception  https://review.openstack.org/22797101:16
*** lixiaoy1 has joined #openstack-cinder01:17
*** dimsum__ has joined #openstack-cinder01:20
openstackgerritWilson Liu proposed openstack/cinder: Add hypermetro support for Huawei driver  https://review.openstack.org/20202301:22
*** zhangjn_ has joined #openstack-cinder01:25
*** dimsum__ has quit IRC01:27
*** zhangjn has quit IRC01:28
*** dimsum__ has joined #openstack-cinder01:31
*** Lee1092 has joined #openstack-cinder01:35
*** zhenguo has joined #openstack-cinder01:36
*** ozialien has quit IRC01:37
*** ozialien has joined #openstack-cinder01:37
*** akshai_ has quit IRC01:41
*** changbl has joined #openstack-cinder01:46
*** haomaiwang has joined #openstack-cinder01:50
*** davechen has joined #openstack-cinder01:51
*** davechen1 has joined #openstack-cinder01:56
*** davechen has quit IRC01:58
*** zhangjn has joined #openstack-cinder01:59
*** davechen has joined #openstack-cinder02:00
*** baojg has joined #openstack-cinder02:01
*** akshai has joined #openstack-cinder02:02
*** davechen1 has quit IRC02:02
*** zhangjn_ has quit IRC02:02
*** p0rtal has quit IRC02:03
*** davechen1 has joined #openstack-cinder02:07
*** pots has joined #openstack-cinder02:07
*** davechen has quit IRC02:09
*** zhangjn has quit IRC02:10
*** davechen has joined #openstack-cinder02:12
*** zhangjn has joined #openstack-cinder02:13
*** p0rtal has joined #openstack-cinder02:14
*** vincent_hou has joined #openstack-cinder02:14
*** zhangjn has quit IRC02:14
*** davechen1 has quit IRC02:15
*** p0rtal has quit IRC02:15
*** p0rtal has joined #openstack-cinder02:16
*** chlong has quit IRC02:18
*** zhangjn has joined #openstack-cinder02:20
*** pots has quit IRC02:21
*** akshai has quit IRC02:22
*** pots has joined #openstack-cinder02:24
*** pots has quit IRC02:25
*** david-ly_ has joined #openstack-cinder02:31
*** dimsum__ has quit IRC02:32
*** david-lyle has quit IRC02:33
*** vincent_hou has quit IRC02:35
*** zhangjn has quit IRC02:44
*** zhangjn has joined #openstack-cinder02:46
*** baojg has quit IRC02:48
*** zhangjn has quit IRC02:48
*** baojg has joined #openstack-cinder02:51
*** zhangjn has joined #openstack-cinder03:00
*** tobe has joined #openstack-cinder03:04
*** cvstealth has quit IRC03:04
*** cvstealth has joined #openstack-cinder03:04
*** DericHorn-HP has joined #openstack-cinder03:06
*** julim has joined #openstack-cinder03:18
*** zhangjn has quit IRC03:22
*** zhangjn has joined #openstack-cinder03:23
*** zhangjn has quit IRC03:26
*** DericHorn-HP has quit IRC03:29
*** zhangjn has joined #openstack-cinder03:30
*** zhangjn has quit IRC03:32
*** chlong has joined #openstack-cinder03:32
*** dimsum__ has joined #openstack-cinder03:32
*** david-lyle has joined #openstack-cinder03:37
*** dimsum__ has quit IRC03:38
*** david-ly_ has quit IRC03:40
*** dimsum__ has joined #openstack-cinder03:40
*** dave-mccowan has quit IRC03:40
*** baojg has quit IRC03:44
*** RaySun has joined #openstack-cinder03:46
*** baojg has joined #openstack-cinder03:47
*** dimsum__ has quit IRC03:50
*** sgotliv has joined #openstack-cinder03:59
*** akshai has joined #openstack-cinder04:03
*** akshai has quit IRC04:08
*** zhangjn has joined #openstack-cinder04:08
*** zhangjn has quit IRC04:09
*** zhangjn has joined #openstack-cinder04:09
*** julim has quit IRC04:16
*** vgridnev has joined #openstack-cinder04:21
*** lixiaoy1 has quit IRC04:31
*** yangyapeng has joined #openstack-cinder04:34
*** vgridnev has quit IRC04:35
*** vgridnev has joined #openstack-cinder04:37
*** subscope has joined #openstack-cinder04:43
*** chlong has quit IRC04:45
*** dimsum__ has joined #openstack-cinder04:51
*** dimsum__ has quit IRC04:54
*** chlong has joined #openstack-cinder04:57
*** RaySun has quit IRC05:04
*** RaySun has joined #openstack-cinder05:05
*** lixiaoy1 has joined #openstack-cinder05:05
*** vgridnev has quit IRC05:05
*** RaySun_ has joined #openstack-cinder05:06
*** vgridnev has joined #openstack-cinder05:06
openstackgerritAbhishek Shrivastava proposed openstack/cinder: Setup error check & minor bug fix in CloudByte  https://review.openstack.org/23006805:06
*** RaySun_ has quit IRC05:08
*** RaySun has quit IRC05:09
*** tsufiev_ has joined #openstack-cinder05:13
*** vgridnev has quit IRC05:13
*** vgridnev has joined #openstack-cinder05:17
*** vgridnev has quit IRC05:18
openstackgerrityogeshprasad proposed openstack/cinder: Retype support for CloudByte iSCSI cinder driver  https://review.openstack.org/21864505:20
*** nkrinner has joined #openstack-cinder05:34
*** stevemar_ has quit IRC05:34
*** p0rtal has quit IRC05:35
*** deepakcs has joined #openstack-cinder05:48
*** baojg has quit IRC05:54
*** dimsum__ has joined #openstack-cinder05:54
*** stevemar_ has joined #openstack-cinder05:54
*** subscope has quit IRC05:54
*** dimsum__ has quit IRC05:59
*** lixiaoy1 has quit IRC06:01
openstackgerritAbhishek Shrivastava proposed openstack/cinder: Setup error check & minor bug fix in CloudByte  https://review.openstack.org/23006806:03
*** BharatK has joined #openstack-cinder06:10
*** lixiaoy1 has joined #openstack-cinder06:11
*** shausy has joined #openstack-cinder06:14
*** kjelly has quit IRC06:14
*** kjelly has joined #openstack-cinder06:15
*** lixiaoy11 has joined #openstack-cinder06:20
*** lixiaoy1 has quit IRC06:22
*** ankit_ag has joined #openstack-cinder06:24
*** lixiaoy12 has joined #openstack-cinder06:27
*** lixiaoy11 has quit IRC06:27
*** stevemar_ has quit IRC06:27
*** vlaza has joined #openstack-cinder06:28
*** stevemar_ has joined #openstack-cinder06:28
*** subscope has joined #openstack-cinder06:29
*** stevemar_ has quit IRC06:33
*** lixiaoy1 has joined #openstack-cinder06:33
*** lixiaoy12 has quit IRC06:36
*** nikeshm has joined #openstack-cinder06:37
*** lixiaoy11 has joined #openstack-cinder06:38
*** subscope has quit IRC06:38
*** lixiaoy1 has quit IRC06:40
*** sgotliv has quit IRC06:42
*** chenying has joined #openstack-cinder06:51
*** dimsum__ has joined #openstack-cinder06:55
*** anshul has joined #openstack-cinder07:00
*** dimsum__ has quit IRC07:01
*** haypo has joined #openstack-cinder07:02
openstackgerritVictor Stinner proposed openstack/cinder: Port API types extra specs to Python 3  https://review.openstack.org/23221607:04
openstackgerritVictor Stinner proposed openstack/cinder: Port WSGI tests to Python 3  https://review.openstack.org/23221407:04
openstackgerritVictor Stinner proposed openstack/cinder: Port API to Python 3  https://review.openstack.org/23221507:04
openstackgerritVictor Stinner proposed openstack/cinder: Port API admin action tests to Python 3  https://review.openstack.org/23224207:04
*** anshul has quit IRC07:08
*** anshul has joined #openstack-cinder07:08
*** aix has joined #openstack-cinder07:10
*** ronis has joined #openstack-cinder07:21
*** dixiaoli has joined #openstack-cinder07:21
*** dixiaoli has quit IRC07:23
*** ronis has quit IRC07:29
*** ankit_ag has quit IRC07:29
*** ankit_ag has joined #openstack-cinder07:29
*** stevemar_ has joined #openstack-cinder07:29
*** stevemar_ has quit IRC07:34
*** chenying has quit IRC07:35
*** markus_z has joined #openstack-cinder07:37
*** ociuhandu has joined #openstack-cinder07:44
*** vgridnev has joined #openstack-cinder07:47
*** ndipanov has joined #openstack-cinder07:48
*** vincent_hou has joined #openstack-cinder07:48
vincent_hougeguileo: Ping.07:49
*** dimsum__ has joined #openstack-cinder07:57
*** markus_z has quit IRC07:58
*** vgridnev has quit IRC08:02
*** markus_z has joined #openstack-cinder08:02
*** dimsum__ has quit IRC08:02
*** vgridnev has joined #openstack-cinder08:03
*** wenjuan has joined #openstack-cinder08:06
wenjuanhello,If i want to post code to cinder,should i apply for the authority on groups of review.openstack.org08:12
*** vgridnev has quit IRC08:13
*** sgotliv has joined #openstack-cinder08:16
*** vgridnev has joined #openstack-cinder08:17
*** vgridnev has quit IRC08:19
dulekwenjuan: https://wiki.openstack.org/wiki/How_To_Contribute#If_you.27re_a_developer08:20
lixiaoy11wenjuan: https://wiki.openstack.org/wiki/How_To_Contribute08:20
*** jordanP has joined #openstack-cinder08:21
lixiaoy11dulek: :)08:21
duleklixiaoy11: ha, I was first ;)08:21
duleklixiaoy11: (or maybe not, is IRC consistent when calculating dates? ;))08:21
*** bluex-pl has joined #openstack-cinder08:22
*** bluex-pl has quit IRC08:23
lixiaoy11dulek: in my view, I was first08:23
*** bluex-pl has joined #openstack-cinder08:23
lixiaoy11(4:20:50 PM) lixiaoy1: wenjuan: https://wiki.openstack.org/wiki/How_To_Contribute08:23
lixiaoy11(4:20:50 PM) dulek: wenjuan: https://wiki.openstack.org/wiki/How_To_Contribute#If_you.27re_a_developer08:23
*** e0ne has joined #openstack-cinder08:24
lixiaoy11dulek: different views? :)08:24
*** lpetrut has joined #openstack-cinder08:27
haypooh :-( cinder.tests.unit.test_misc.ExceptionTestCase.test_exceptions_raise() failed with 'KeyError: 0' on a python34 check job08:31
*** ronis has joined #openstack-cinder08:31
haypook, test_misc now fails with WebOb 1.5 :-/08:34
duleklixiaoy11: Different, so non-consistent. ;)08:35
*** chlong has quit IRC08:35
openstackgerritVictor Stinner proposed openstack/cinder: Fix test_misc for WebOb 1.5  https://review.openstack.org/23352808:39
haypoplease review ^^ https://review.openstack.org/233528 : the WebOb 1.5 release broke all gates using Cinder!!08:40
*** shausy has quit IRC08:41
*** shausy has joined #openstack-cinder08:41
*** jistr has joined #openstack-cinder08:46
*** haomaiwang has quit IRC08:47
*** vgridnev has joined #openstack-cinder08:47
*** vgridnev has quit IRC08:47
*** haomaiwang has joined #openstack-cinder08:47
*** vgridnev has joined #openstack-cinder08:47
*** zhangjn has quit IRC08:51
*** zhangjn has joined #openstack-cinder08:52
*** jaypipes has joined #openstack-cinder08:52
*** vgridnev has quit IRC08:55
*** vgridnev has joined #openstack-cinder08:57
*** dimsum__ has joined #openstack-cinder08:58
*** aix has quit IRC08:58
*** BharatK has quit IRC08:58
*** haomaiwang has quit IRC09:01
*** haomaiwang has joined #openstack-cinder09:01
*** vincent_hou has quit IRC09:01
DuncanTAny core about? Looks like we need to land https://review.openstack.org/233528 to clear up our gate09:03
*** bluex-pl has quit IRC09:03
*** dimsum__ has quit IRC09:04
*** wenjuan has quit IRC09:04
*** bluex-pl has joined #openstack-cinder09:04
*** bluex-pl has quit IRC09:04
*** zhenguo has quit IRC09:06
*** bluex-pl has joined #openstack-cinder09:09
*** bluex-pl has quit IRC09:10
*** bluex-pl has joined #openstack-cinder09:11
*** bluex-pl has quit IRC09:11
*** bluex-pl has joined #openstack-cinder09:11
*** bluex-pl has quit IRC09:12
*** aix has joined #openstack-cinder09:12
*** bluex-pl has joined #openstack-cinder09:12
*** BharatK has joined #openstack-cinder09:13
haypoDuncanT: hi. why do you want me to open a bug to modify a single line?09:21
DuncanThaypo: We try to have bugs or blueprints to track all changes. It makes it far easier to be consistent in applying that than to argue about exceptions09:21
DuncanThaypo: A bug takes two minutes to file, the arguments have been known to go on for days09:22
*** vgridnev has quit IRC09:24
*** haypo has quit IRC09:25
*** haypo has joined #openstack-cinder09:26
haypoDuncanT: hi. why do you want me to open a bug to modify a single line? (oops, i loose my irc connection :-/)09:26
DuncanThaypo: We try to have bugs or blueprints to track all changes. It makes it far easier to be consistent in applying that than to argue about exceptions09:26
DuncanThaypo: A bug takes two minutes to file, the arguments have been known to go on for days09:26
e0neDuncanT: I'll +2 on it once CI passed09:27
*** wilson-1 has joined #openstack-cinder09:27
openstackgerritVictor Stinner proposed openstack/cinder: Fix test_misc for WebOb 1.5  https://review.openstack.org/23352809:30
*** wilson1 has quit IRC09:31
DuncanTe0ne: It's got my +2 on it now, you can push it through when you're happy09:33
DuncanThaypo: Thanks for the update09:33
haypoe0ne: you can test the patch locally. it's obviosu that test_misc fails without my change. at least on my PC, it pass with the change :)09:34
haypoDuncanT: why not only discussing a change in the change directly? what's the advantage of splitting the discussion between two tools (gerrit and launchpad)?09:34
e0nehaypo: I feel a bit uncomfortable to +A on patch w/o CI09:35
haypoe0ne: a patch cannot be merged if the CI fails09:35
e0nehaypo: Zuul's ETA is 15 minutes09:36
haypoe0ne: the CI must pass twice on a patch to merge the change, no?09:36
DuncanThaypo: At the moment, the only advantage is consistency with every other patch. If there are good reasons to change that, great, but right now we do things to way we do them. One direct answer to your question is that sometimes there is more than one way to fix a bug, so competing patches get posted - having a bug lets us track that09:37
DuncanThaypo: That doesn't stop duplicate bugs, but some people try to stay on top of that09:37
haypoDuncanT: hum ok09:37
DuncanThaypo: There's a Tokyo session for discussing beaurocracy in cinder, contributions and comments welcome09:38
haypoi'm not a fan of meeting about burocracy :)09:40
*** zhangjn has quit IRC09:40
*** zhangjn has joined #openstack-cinder09:41
DuncanThaypo: If you think there's something we can cut down on, comment on the etherpad if you don't want to attend - I'll ensure anything you add gets raised09:42
haypoDuncanT: the rule should be never open a bug, only open a bug when there are multiple changes for the same thing09:44
haypoi want to reduce the burocraty. i don't see how attending a meeting on burocraty would solve the issue09:44
DuncanThaypo: Attending the meeting helps because there are reasons why we have the processes we have, and so getting people together who know those reasons helps up reduce the processes *without* re-introducing the problems that the processes were designed to fix09:46
DuncanThaypo: For example, bugs are used to report a problem, since the person who found the problem very often doesn't have the knowledge to fix it09:46
DuncanThaypo: If we always open bugs then people who find problems (who outnumber, and are usually less technically adept then the bug fixers) only have one place to go09:47
haypoDuncanT: i'm not talking about opening a bug report when you hit a bug. i'm talking about the requirement to open a bug report to fix a bug. the commit message can be long enough to explain the bug, the fix, etc. and gerrit is a nice place for discussion09:47
DuncanThaypo: What happens to the other ten people who find the same problem? We end up with ten gerrit reviews that aren't linked together?09:48
DuncanThaypo: Our current record is four parallel submissions, I think09:48
haypoDuncanT: how does launchpad  prevent duplicates? maybe it's an issue in the gerrit tool :-p09:49
*** ociuhandu has quit IRC09:49
DuncanThaypo: And for the people who don't know to search gerrit (which is far from easy, or standard to search), they're stuck not knowing that this is a known issue being worked on09:49
*** haomaiwang has quit IRC09:50
haypoi don't think that it's so common to write a similar patch to fix the same bug09:50
*** chlong has joined #openstack-cinder09:50
DuncanThaypo: It has happened a good few times... search the abandoned patch list09:50
*** haomaiwang has joined #openstack-cinder09:50
haypook09:51
*** vgridnev has joined #openstack-cinder09:52
*** lixiaoy11 has quit IRC09:52
*** bluex-pl has quit IRC09:53
*** davechen has left #openstack-cinder09:54
haypoe0ne, DuncanT : FYI my fear is that all gates of all projects are broken by cinder, that's why i consider that my fix must be merged quickly09:58
DuncanThaypo: It will be merged now as soon as it passes CI09:58
DuncanThaypo: We can't go any faster than jenkins.09:58
*** marzif has joined #openstack-cinder09:58
haypoDuncanT: i'm replying to "e0ne> haypo: I feel a bit uncomfortable to +A on patch w/o CI" and "Duncan: Patch Set 1: -Code-Review. Can you file a bug for this please (...)"09:59
*** dimsum__ has joined #openstack-cinder10:00
haypowell, it doesn't matter so much10:00
DuncanThaypo: History has shown us that skipping process for perceived  urgency causes us pain10:00
*** haomaiwang has quit IRC10:01
*** zhangjn has quit IRC10:01
*** yangyapeng has quit IRC10:01
*** haomaiwang has joined #openstack-cinder10:01
*** EinstCrazy has quit IRC10:01
*** dimsum__ has quit IRC10:06
*** e0ne_ has joined #openstack-cinder10:06
*** e0ne has quit IRC10:09
*** aarefiev has quit IRC10:10
dulekhaypo: One good thing about using Launchpad is that you can get email notifications on bugs without all the Gerrit's noise (Jenkins, Third Party CIs, nitpicking comments).10:11
*** aarefiev has joined #openstack-cinder10:14
*** e0ne_ has quit IRC10:14
*** vgridnev has quit IRC10:15
*** BharatK has quit IRC10:17
*** e0ne has joined #openstack-cinder10:19
*** vgridnev has joined #openstack-cinder10:24
*** BharatK has joined #openstack-cinder10:30
*** takedakn has joined #openstack-cinder10:34
*** zerda has joined #openstack-cinder10:37
*** vgridnev has quit IRC10:39
*** vgridnev has joined #openstack-cinder10:40
*** haomaiwang has quit IRC10:46
*** haomaiwa_ has joined #openstack-cinder10:49
*** vgridnev has quit IRC10:55
*** IanGovett has joined #openstack-cinder10:56
*** ociuhandu has joined #openstack-cinder10:56
*** zhangjn has joined #openstack-cinder10:57
*** EinstCrazy has joined #openstack-cinder10:58
*** vgridnev has joined #openstack-cinder10:59
*** EinstCrazy has quit IRC10:59
*** EinstCrazy has joined #openstack-cinder11:00
*** bluex-pl has joined #openstack-cinder11:00
*** vgridnev has quit IRC11:00
*** vgridnev has joined #openstack-cinder11:00
*** haomaiwa_ has quit IRC11:01
*** haomaiwa_ has joined #openstack-cinder11:01
*** dimsum__ has joined #openstack-cinder11:01
*** tobe has quit IRC11:06
*** tobe has joined #openstack-cinder11:06
*** dimsum__ has quit IRC11:07
*** vgridnev has quit IRC11:09
*** vgridnev has joined #openstack-cinder11:14
*** tobe has quit IRC11:15
*** tobe has joined #openstack-cinder11:16
*** dimsum__ has joined #openstack-cinder11:22
*** haomaiwa_ has quit IRC11:28
*** haomaiwang has joined #openstack-cinder11:28
*** stevemar_ has joined #openstack-cinder11:31
*** e0ne has quit IRC11:31
*** stevemar_ has quit IRC11:35
openstackgerritZhang Jinnan proposed openstack/cinder: Volume extend error does not catch exception  https://review.openstack.org/22797111:37
*** dave-mccowan has joined #openstack-cinder11:40
*** haomaiwang has quit IRC11:47
*** haomaiwang has joined #openstack-cinder11:48
openstackgerritYuriy Nesenenko proposed openstack/cinder: Implement snapshots-related features for Block Device Driver  https://review.openstack.org/22229211:52
*** vgridnev has quit IRC11:56
*** julim has joined #openstack-cinder11:59
*** haomaiwang has quit IRC12:01
*** haomaiwang has joined #openstack-cinder12:01
*** rushil has joined #openstack-cinder12:04
*** e0ne has joined #openstack-cinder12:19
*** zerda has quit IRC12:19
*** vgridnev has joined #openstack-cinder12:20
*** haomaiwang has quit IRC12:24
*** markvoelker has joined #openstack-cinder12:26
*** vgridnev has quit IRC12:27
*** Yogi1 has joined #openstack-cinder12:28
e0neDuncanT: hi again. will you have few minutes to chact about brick-client (volume attachment w/o nova)?12:32
DuncanTe0ne: Sure12:33
DuncanTe0ne: Got a meeting in 30 minutes, that will last about 30 minutes. Other than that, any time12:33
nikeshmxyang: hi12:35
e0neDuncanT: I've got poc for iscsi and rbd attachement. we need to make it pluguble or just add "try-catch ImportError" statements fo attache volumes using different protocols12:36
*** vgridnev has joined #openstack-cinder12:36
e0neDuncanT: e.g. to attach ceph volume via RBD protocol, user need to have installed ceph-common package and enabled kernel module12:36
*** edmondsw has joined #openstack-cinder12:36
*** diablo_rojo has joined #openstack-cinder12:37
*** vgridnev has quit IRC12:38
DuncanTI'd add try-catch with appropriate errors for things that need to be installed12:38
DuncanTiSCSI needs the appropriate kernel and userspace too12:38
*** timcl has joined #openstack-cinder12:40
e0neDuncanT: so, will  we need to cover iSCSI stuff in try-catch too?12:41
nikeshmxyang: In liberty, for taking a backup of a attached volume, we are either creating a temporary snapshot or temporary volume. What is need of temporary snapshot or volume?12:41
DuncanTe0ne: I don't think there's any harm in it, and it puts RBD and iSCSI on an equal footing - nothing you don't need to operate needs to be installed12:42
nikeshmxyang: is taking backup from a temporary snapshot is application consistent?12:42
DuncanTnikeshm: It is to provide generic support, where the driver hasn't implemented attach_snapshot12:42
DuncanTnikeshm: A snap is needed for live backup for consistency, yes12:43
e0neDuncanT: agree. I still want to have minimum requirements list.12:43
*** deepakcs has quit IRC12:43
DuncanTe0ne: Whatever makes sense to you - we can tidy it later if needed. Setting a good tone from the beginning is useful though12:43
DuncanTnikeshm: Backing up a live, changing block device is never going to give you anything useful12:44
*** gouthamr has joined #openstack-cinder12:44
nikeshmDuncanT: i have a confusion in crash consistent and application consistent,12:44
e0neDuncanT: I'm worried how Ironic guys will use it. IMO, we need to tolk about it with them12:44
DuncanTnikeshm: cinder can only do crash consistent by itself12:44
DuncanTe0ne: We definitely need to talk to them, it's easier to do with a PoC though12:45
e0neDuncanT: I'll cleanup my PoC's code and will bring it to the IRC/ML later this week12:47
haypoooook, my fix for cinder gates has been merged, cool: https://review.openstack.org/#/c/233528/ "Fix test_misc for WebOb 1.5"12:47
DuncanTLet the rechecks commence12:48
nikeshmDuncanT: is it not possible to call nova apis from cinder which would do fsFreeze before taking a backup of a attached volume12:48
DuncanTe0ne: Sounds like a plan12:48
e0nethanks12:49
*** pots has joined #openstack-cinder12:49
e0neDuncanT: after getting some feedback, probably we need to have Cinder-Ironic liaisons.12:49
e0nesmcginnis: ^^12:50
DuncanTe0ne: I guess so. We should sort basic CI too12:52
*** ronis has quit IRC12:59
*** nkrinner is now known as nkrinner_afk13:00
*** cbader has joined #openstack-cinder13:00
*** lpabon has joined #openstack-cinder13:01
*** ronis has joined #openstack-cinder13:03
nikeshmDuncanT: any thoughts13:04
*** mc_nair has joined #openstack-cinder13:06
DuncanTnikeshm: Do those nova APIs exist?13:07
*** breitz has joined #openstack-cinder13:07
*** dustins has joined #openstack-cinder13:08
*** dustins has quit IRC13:08
*** porrua has joined #openstack-cinder13:08
*** xyang1 has joined #openstack-cinder13:09
johnthetubaguyDuncanT: nikeshm: e0ne: I think I saw a spec to add those APIs, although I am unsure how well exposing those would work in practice (due to timeouts in the underlying calls, etc)13:10
DuncanTjohnthetubaguy: Might be best to allow people to try to orchestrate it externally initially, see if there is actually any need for cinder integration13:11
*** martyturner has joined #openstack-cinder13:14
nikeshmlive vm snapshot in nova uses fsFreeze https://github.com/openstack/nova/blob/f2e2a5891d5f5ff9346e6dc8e4dd0e994485245c/nova/virt/libvirt/driver.py#L150513:15
*** mriedem has joined #openstack-cinder13:15
johnthetubaguynikeshm: yes, we use fsFreeze, but there is not REST API to call that directly13:15
johnthetubaguyDuncanT: yeah, that makes sense, I think its group of VMs that folks are the most worried about right now13:16
nikeshmjohnthetubaguy: you said about a spec, do you have link?13:17
*** mriedem_away has quit IRC13:17
*** annasort has joined #openstack-cinder13:17
johnthetubaguynikeshm: I looked in my list of specs, and I can't find it right now, sorry13:18
nikeshmjohnthetubaguy: ok ,  if you find please share13:19
nikeshm:)13:19
openstackgerritIvan Kolodyazhny proposed openstack/cinder: Fix Status-Line in HTTP response  https://review.openstack.org/23143813:19
*** martyturner has quit IRC13:20
*** martyturner has joined #openstack-cinder13:22
*** martyturner has quit IRC13:23
smcginnise0ne: Are you volunteering to be an ironic liason? :)13:24
smcginnisDuncanT: Weren't you doing a lot with ironic for a while there/13:24
smcginnis?13:24
*** martyturner has joined #openstack-cinder13:24
e0nesmcginnis: we need to discuss it. DuncanT and hemna are good candidates too13:25
*** lcurtis has joined #openstack-cinder13:25
smcginnise0ne: Good. Want to put something on the meeting agenda to make sure we cover it?13:25
smcginnishttps://wiki.openstack.org/wiki/CinderMeetings13:25
smcginnisOr at least start discussing it.13:26
*** jungleboyj has joined #openstack-cinder13:26
*** dimsum__ is now known as dims13:27
*** dims is now known as Guest282113:27
*** ankit_ag has quit IRC13:28
*** merooney has joined #openstack-cinder13:29
DuncanTsmcginnis: I was for a while, moved on though13:30
smcginnisDuncanT: OK, cool.13:30
DuncanTsmcginnis: I think hemna is doing a fair bit right now. I might be again in a few months13:30
*** haomaiwang has joined #openstack-cinder13:31
*** stevemar_ has joined #openstack-cinder13:32
*** shausy has quit IRC13:34
*** jgregor has joined #openstack-cinder13:34
*** gouthamr has quit IRC13:35
*** Guest2821 is now known as dims__13:35
*** gouthamr has joined #openstack-cinder13:36
*** stevemar_ has quit IRC13:36
*** BharatK has quit IRC13:36
*** william has joined #openstack-cinder13:39
*** william is now known as Guest412313:40
*** juzuluag has joined #openstack-cinder13:42
*** eharney has joined #openstack-cinder13:48
*** superdan is now known as dansmith13:48
openstackgerritJohn Griffith proposed openstack/cinder: Update config format for replication_devices  https://review.openstack.org/23330713:49
*** BharatK has joined #openstack-cinder13:51
*** vgridnev has joined #openstack-cinder13:51
*** brad[] has joined #openstack-cinder13:53
*** diablo_rojo1 has joined #openstack-cinder13:56
*** diablo_rojo has quit IRC13:56
openstackgerritMatt Riedemann proposed openstack/cinder: windows: don't use LOG.exception if not logging an exception  https://review.openstack.org/23364413:57
*** lprice1 has quit IRC13:59
*** martyturner has quit IRC13:59
*** haomaiwang has quit IRC14:01
*** martyturner has joined #openstack-cinder14:01
*** haomaiwang has joined #openstack-cinder14:01
*** dims__ has quit IRC14:01
*** dims__ has joined #openstack-cinder14:02
*** jungleboyj has quit IRC14:04
*** vgridnev has quit IRC14:07
*** vgridnev has joined #openstack-cinder14:07
openstackgerritEric Harney proposed openstack/cinder: Move ssh_utils tests to test_ssh_utils  https://review.openstack.org/22994714:08
*** BharatK has quit IRC14:12
*** dustins has joined #openstack-cinder14:14
*** pots has quit IRC14:14
*** krotscheck has joined #openstack-cinder14:14
*** tobe has quit IRC14:16
*** tobe has joined #openstack-cinder14:19
*** nikeshm has quit IRC14:22
smcginnismriedem: ping14:22
smcginnismriedem: Is this a dupe of the new one you filed?14:23
smcginnismriedem: https://bugs.launchpad.net/cinder/+bug/150473514:23
openstackLaunchpad bug 1504735 in Cinder "There is no need to use LOG.exception when no exception handler is used" [Undecided,New] - Assigned to chenying (ying-chen)14:23
*** ntpttr has joined #openstack-cinder14:23
*** garthb has joined #openstack-cinder14:28
mriedemlooks the same, i didn't find any previous bugs before opening mine14:31
*** takedakn has quit IRC14:31
mriedemsmcginnis: different failure points though14:31
mriedemthis bug isn't in the windows vhdutils stuff14:31
smcginnismriedem: True14:32
smcginnisI think I'll do some grepping to see if there's anywhere else we are using LOG.exception we shouldn't be.14:32
*** haomaiwang has quit IRC14:35
*** vlaza has quit IRC14:35
*** haomaiwang has joined #openstack-cinder14:38
*** diablo_rojo1 has quit IRC14:39
*** jgregor has quit IRC14:40
*** lprice has joined #openstack-cinder14:42
e0neDuncanT, haypo:  are we going to backport webob fix to liberty? I've reproduced it locally on the stable/liberty brancj14:42
*** asselin_ has joined #openstack-cinder14:42
*** tpeoples has joined #openstack-cinder14:42
DuncanTe0ne: I think we need to, yes14:43
openstackgerritoliver-leahy-l proposed openstack/cinder: encryption_api_url requires a version  https://review.openstack.org/23003114:44
*** takedakn has joined #openstack-cinder14:44
smcginnisDuncanT, e0ne, haypo: That only affect unit tests, right?14:44
smcginnisNo need to try to quick cut a new RC...14:45
e0nesmcginnis: unit tests and almost each vendor CI14:45
*** pots has joined #openstack-cinder14:46
*** edtubill has joined #openstack-cinder14:47
*** takedakn has quit IRC14:47
*** nikeshm has joined #openstack-cinder14:48
smcginnise0ne: Thanks14:48
e0nesmcginnis: np14:49
*** edmondsw has quit IRC14:49
*** kurtmartin has joined #openstack-cinder14:52
*** edmondsw has joined #openstack-cinder14:53
*** mtanino has joined #openstack-cinder14:53
e0necherry-picked to Liberty https://review.openstack.org/#/c/233668/14:54
*** lpetrut has quit IRC14:56
smcginniszigo, eharney: Will this cause packaging issues? https://review.openstack.org/#/c/233668/14:56
*** changbl has quit IRC14:56
smcginniszigo, eharney: Only affects unit tests, but I know zigo said that's part of the packaging process.14:56
eharneysmcginnis: seems fine to me, just a regular test fix14:57
smcginniseharney: Cool, thanks.14:58
*** daneyon has joined #openstack-cinder14:58
*** haomaiwang has quit IRC15:01
openstackgerritEric Harney proposed openstack/cinder: Tox fast8: use pep8 env dir  https://review.openstack.org/23367315:01
*** salv-orlando has joined #openstack-cinder15:01
*** haomaiwang has joined #openstack-cinder15:01
*** daneyon_ has joined #openstack-cinder15:01
*** sgundur has joined #openstack-cinder15:03
*** HenryG_ is now known as HenryG15:03
*** daneyon has quit IRC15:04
*** anshul has quit IRC15:06
*** ronis has quit IRC15:06
*** thangp has joined #openstack-cinder15:09
*** aarefiev has quit IRC15:10
*** diablo_rojo has joined #openstack-cinder15:13
*** jungleboyj has joined #openstack-cinder15:14
*** bill_az has joined #openstack-cinder15:15
*** harlowja_at_home has joined #openstack-cinder15:19
*** rhagarty__ has joined #openstack-cinder15:20
*** jdurgin1 has joined #openstack-cinder15:21
*** rhagarty_ has quit IRC15:22
*** markus_z has quit IRC15:22
*** diogogmt has joined #openstack-cinder15:24
*** asselin_ has quit IRC15:26
*** mriedem is now known as mriedem_away15:26
hemnawho ordered a Monday ?15:26
*** asselin_ has joined #openstack-cinder15:26
diablo_rojohemna: Not me15:27
*** rushil has quit IRC15:34
*** nikeshm has quit IRC15:36
jgriffithDuncanT: curious, do you guys see similar race issues with Nova that you see with Cinder?15:39
jgriffithDuncanT: or do their mechanisms seem to work better15:40
*** tobe has quit IRC15:40
johnthetubaguyjgriffith: which are the race issues that are causing issues?15:40
DuncanTjgriffith: There were races in nova, not looked at them for, erm, a couple of years now I guess15:40
jgriffithjohnthetubaguy: quite the opposite :)15:40
jgriffithjohnthetubaguy: I'm asking if there "are" issues15:40
DuncanTjgriffith: I'll ask the nova team. It would certainly be interested to see how they fixed them15:41
jgriffithjohnthetubaguy: the reason I'm asking... is there's what's turning into a signficiant rewrite of all of the Cinder code to address reaces15:41
jgriffithjohnthetubaguy: I've been poking at Nova and it's use of the lock deocrator and instance state object15:41
jgriffithjohnthetubaguy: I'm wondering if that would be safer/more effective15:42
johnthetubaguyjgriffith: ah, OK, we got rid of most of them, there are few different strategies depending on the issue15:42
*** rushil has joined #openstack-cinder15:42
jgriffithjohnthetubaguy: I'm also wondering why folks on the Cinder side have stated that lock files can't be cleaned/removed15:42
jgriffithjohnthetubaguy: I'd be interested in learning more about your experiences15:43
jgriffithjohnthetubaguy: I pinged dansmith earlier but he's in meetings most of the morning.  Will probably bug him again later :)15:43
johnthetubaguynot sure we use lock files, I think they are greenlet ones by default, using the olso stuff, so I stopped worring how its done15:43
johnthetubaguyso there are lots of things we do in different cases really15:44
johnthetubaguystuff thats owned by a compute, we can do that local lock, its in memory I believe15:44
johnthetubaguyfor some DB stuff, we are moving torwards compare and swap updates with retries15:44
jgriffithjohnthetubaguy: ok, so that's the same direction Cinder is on right now15:45
jgriffithjohnthetubaguy: I was tracing through this: https://github.com/openstack/nova/blob/master/nova/compute/api.py#L190115:45
jgriffithjohnthetubaguy: in the outer API on through15:45
johnthetubaguythe scheduler and node stuff, its more retries right now, but cooking up some new ways15:46
jgriffithjohnthetubaguy: seem effective15:46
*** sgotliv has quit IRC15:46
jgriffithjohnthetubaguy: ahh... yeah, different issues like you mentioned15:46
johnthetubaguyjgriffith: it works, its not perfect, you can get issues with long running tasks getting paused15:46
jgriffithjohnthetubaguy: makes sense... fortunately those are a bit limited for us15:47
jgriffithjohnthetubaguy: backups and copying images/volumes15:47
johnthetubaguyyeah, we do have state based locking in the API too15:47
johnthetubaguylocking is an overly strong word15:48
jgriffithjohnthetubaguy: but if yall have the swap/compare approach in progress as well then perhaps I am not *as* concerned15:48
jgriffithjohnthetubaguy: weak-locks?15:48
johnthetubaguywell it just checks the current state to make sure its as expected in the DB15:48
johnthetubaguyjust a quick check, and then updates it15:48
jgriffithjohnthetubaguy: ahh... yeah, that's our current strategy on most things15:49
johnthetubaguylots of the instance.save() commands take an expected state, to do the same thing15:49
johnthetubaguyyeah, the pattern hasn't changed much15:49
jgriffithjohnthetubaguy: yeah, Nova seems to have some nicer helper/wrapper functions around it, but we have the same principal15:49
openstackgerritVictor Stinner proposed openstack/cinder: Port API types extra specs to Python 3  https://review.openstack.org/23221615:49
openstackgerritVictor Stinner proposed openstack/cinder: Port WSGI tests to Python 3  https://review.openstack.org/23221415:49
openstackgerritVictor Stinner proposed openstack/cinder: Port API to Python 3  https://review.openstack.org/23221515:49
openstackgerritVictor Stinner proposed openstack/cinder: Port API admin action tests to Python 3  https://review.openstack.org/23224215:49
jgriffithjohnthetubaguy: I think my problem with lockfiles in Cinder is mostly just that they're in the wrong place15:50
jgriffithjohnthetubaguy: they're in the manager.. ie on the other side of the RPC call which introduces latencies and more problems15:50
jgriffithjohnthetubaguy: although in most cases the db update checks seem "ok"15:51
jgriffithjohnthetubaguy: do you folks have somebody actively working on the compare/swap implementations?15:51
johnthetubaguyjgriffith: I think we use both15:52
johnthetubaguyjgriffith: I think jaypipes has the most context on compare and swap, I don't remember where we applied that now15:52
jgriffithjohnthetubaguy: yeah.... we use both the db state check and the locks15:53
jgriffithjohnthetubaguy: we do db state checks in the cinder/volume/api.py then do locks in a couple places in the manager15:53
jgriffithjohnthetubaguy: ahhh http://www.joinfu.com/2015/01/understanding-reservations-concurrency-locking-in-nova/15:54
jgriffithI'll read a bit :)15:54
ntpttrHey everyone, I'm running tox on a fresh clone of cinder in devstack, and every test is failing telling me "'str' object has no attribute 'DEALER'". Anyone else run into this problem?15:54
jgriffithjohnthetubaguy: thanks for the input!15:54
johnthetubaguyjgriffith: no worries, happy to help15:55
johnthetubaguyjgriffith: finding the race is the hard bit, usually :)15:55
jgriffithjohnthetubaguy: yah, not something I claim to be good at15:55
*** apoorvad has joined #openstack-cinder15:55
jgriffithjohnthetubaguy: my concern is we seem to be on a path now where we say "every/any" db status update is a race15:56
johnthetubaguyjgriffith: ah, yeah, gotcha15:56
jgriffithntpttr: werid15:57
jgriffithntpttr: let me try it in a clean env15:58
eharneyntpttr: i just saw that in some nova tests actually, it's related to oslo_messaging / zeromq imports15:58
ntpttreharney: Yeah, that what the traceback is showing me too15:58
* jgriffith now thinks maybe he shouldn't have updated his env :)15:58
eharneysome new library must have updated and broken something15:58
jgriffithpyinotify ?15:59
*** pots3 has joined #openstack-cinder15:59
*** haomaiwang has quit IRC16:01
*** haomaiwang has joined #openstack-cinder16:01
ntpttreharney, jgriffith: Here's the traceback from every test: http://paste.openstack.org/show/476035/16:01
*** zhangjn has quit IRC16:01
jgriffithntpttr: I can't help right now, I can even build an env with the addition of pyinotify :(16:02
*** pots has quit IRC16:03
openstackgerritNate Potter proposed openstack/cinder: Remove 'refresh' parameter from driver get_stats  https://review.openstack.org/23332816:05
*** haypo has left #openstack-cinder16:08
*** salv-orl_ has joined #openstack-cinder16:09
*** ronis has joined #openstack-cinder16:12
*** salv-orlando has quit IRC16:13
*** IanGovett has quit IRC16:13
DuncanTjgriffith: A good way to find races is to write client code that doesn't check the status of volumes before doing stuff on them, then add sleeps in random places in API, c-vol and your driver16:13
jgriffithDuncanT: sure16:14
*** leeantho has joined #openstack-cinder16:15
ntpttrLooks like the error is happening in Jenkins as well, its not just local16:16
*** timcl has quit IRC16:17
*** haomaiwang has quit IRC16:17
*** haomai___ has joined #openstack-cinder16:17
eharneyntpttr: can you write a launchpad bug for it?16:17
ntpttrSure16:17
*** sgundur has quit IRC16:18
jgriffithDuncanT: I keep going back to this though:  https://review.openstack.org/#/c/221441/5/cinder/volume/api.py16:18
jgriffithDuncanT: just doesn't "feel" right16:19
guitarzanthe "conditional_update" call16:19
guitarzan?16:19
*** jdurgin1 has quit IRC16:20
jgriffithguitarzan: well, the pattern of implementing a raise_error in every call etc16:20
*** p0rtal has joined #openstack-cinder16:20
guitarzanhmm, definitely clunky16:21
jgriffithguitarzan: it's just kind of a "code smell" thing to me16:21
guitarzancould it just be a generic "You lost a race condition, sorry try again" error?16:22
DuncanTjgriffith: I think you're right, we need a better code pattern for that sort of code, that's pretty unreadable16:22
jgriffithguitarzan: well, that's kind of what i've been wondering on all of this.. why that's so bad16:22
jgriffithguitarzan: or maybe an entry-lock in the actual API layer16:23
guitarzangiven the choice, I'd pick "try again" over lock, but that's just me16:23
jgriffithDuncanT: guitarzan my bigger concern is when this ends up duplicated in every API call16:23
scottdajgriffith: +1. It seems that the API checks have races, why not just use locks?16:23
jgriffithguitarzan: yeah, I'm not objecting to either16:24
jgriffithscottda: I honestly don't know one versus the other16:24
guitarzanlocks are probably easier16:24
DuncanTjgriffith: Be interesting to make a list of the API calls that can race.16:24
DuncanTguitarzan: 'try again' internally or passed back to the API caller?16:24
scottdaThe APi checks are a kinda lock, but they don't have to be respected by a given client, as DuncanT pointed out above.16:24
jgriffithscottda: I just know that this patch series is rather hard for me to follow and it does make me concerned as I stated before16:24
*** p0rtal has quit IRC16:25
jgriffithDuncanT: well I think geguileo has done that16:25
guitarzanDuncanT: good question, but I think bailing out completely makes the most sense16:25
DuncanTjgriffith: Where? I guess I missed that16:25
jgriffithDuncanT: perhaps a false assumption on my part16:25
jgriffithDuncanT: I thought that he mentioned that's what he was doing16:25
DuncanTjgriffith: Ah, I've lost track of what people are doing, I'm just reading the output at this point16:26
DuncanTguitarzan: Bailing out is an API change, and we have to support old clients :-(16:26
guitarzanDuncanT: sure, but a call just failing is fine16:26
guitarzanimo16:27
DuncanTguitarzan: Depends if it failed before16:27
guitarzanI think that's an argument that could be had16:27
jgriffithDuncanT: https://review.openstack.org/#/q/status:open+project:openstack/cinder+branch:master+topic:bug/1493476,n,z16:27
DuncanTguitarzan: Failing something that used to queue/block then succeed breaks clients16:27
jgriffithDuncanT: I don't know if there are "more" or if this is the list he has etc16:27
guitarzanDuncanT: true, but we've silently broken that stuff before :)16:27
guitarzanlike adding all of the locks in the first place16:28
*** porrua has quit IRC16:28
guitarzanqueue/blocking I mean16:28
DuncanTjgriffith: Ah, that isn't a very useable list... but I might be able to extract what I want from it. Thanks16:28
jgriffithguitarzan: yeah, but now that DuncanT pointed it out we're screwed :)16:28
guitarzanhaha16:28
jgriffith:)16:28
guitarzanI got bit by the source_volid lock thing16:28
DuncanTguitarzan: We've screwed up a lot of things before. At some point we should at least think carefully before screwing things up again16:28
guitarzanDuncanT: fair enough, no argument16:29
*** porrua has joined #openstack-cinder16:29
scottdaDo we expect clients to check state, and set to proper state (i.e. detaching) or are we OK with clients that don't bother?16:29
guitarzanpersonally I tend to think that fail early and often is a good strategy16:29
scottdaand if clients can do whatever they want, what's the sense is all this state management in the first place?16:29
guitarzanscottda: clients don't set state16:29
guitarzanclients perform actions16:29
scottdanova does16:30
guitarzanno it doesn't16:30
scottdaok, well, nova calls begin_detaching which sets the state.16:30
guitarzancorrect16:30
*** hemna is now known as hemnafk16:30
guitarzanif you're saying do clients have to use the api "correctly" then sure :)16:30
*** aix has quit IRC16:31
*** timcl has joined #openstack-cinder16:31
guitarzannova's a good example. it doesn't handle all api call failures correctly either :(16:33
guitarzanthere's no way to win, let's go shopping16:33
DuncanTscottda: We have to be resilient to the fact that clients can and will call random shit with no apparent sense at all. It's ok to not give them whatever the hell they thought they wanted, it isn't ok to get things stuck so that the admin needs to get involved. It's also not generally ok to cause a series of calls that worked in the last release to not work16:34
DuncanTnow16:34
DuncanTRight, I'm going home, it's getting late to be in the office. Time to raid the biscuit tin then go home16:34
jgriffithDuncanT: guitarzan intersting.... https://review.openstack.org/#/c/143837/9/nova/db/sqlalchemy/api.py16:34
scottdaSince the state is checked, i.e. in begin_detaching, and if we eliminate the races with an atomic compare-and-swap, there will be no failure where there used to be success.16:35
guitarzan@retrying.retry! :)16:35
jgriffithguitarzan: LOL16:36
scottdaAnd if clients can call random stuff and not honor the API, we should just implement locks in the API instead of checking state.16:36
jgriffithguitarzan: unfortunate naming of that module16:36
*** diogogmt has quit IRC16:36
guitarzanI don't know how I feel about that either16:36
guitarzanit seems like you wouldn't want that retrying to happen at that low of a level16:36
jgriffithguitarzan: at least it's readable and isolated :)16:36
guitarzansure16:36
jgriffithguitarzan: well, the loop in the api code is essentialy the same thing16:37
guitarzanI'm talking myself into the lock every action case I think16:37
*** wilson1 has joined #openstack-cinder16:37
jgriffithguitarzan: but it keeps issuing new db calls no?16:37
*** willsama has joined #openstack-cinder16:37
guitarzanjgriffith: yeah, I'm just thinking out loud16:38
*** angela-s has joined #openstack-cinder16:38
jgriffithguitarzan: careful, I have a trademark on that :)16:38
guitarzando you want an entire api call to be "atomic"?16:38
guitarzanhaha16:38
DuncanTjgriffith: I don't find retry decorators very readable, but I didn't find that earlier explict retry code readable either. Maybe I need to upgrade my brain16:38
DuncanTguitarzan: That'd mean I'm nuking Vegas every time I access our public cloud. I'm surprisingly ok with this.16:39
*** bluex-pl has quit IRC16:39
jgriffithLOL16:39
guitarzanhaha!16:39
*** wilson-1 has quit IRC16:40
*** Guest4123 has quit IRC16:40
*** jordanP has quit IRC16:41
*** jistr has quit IRC16:42
*** diogogmt has joined #openstack-cinder16:42
*** IanGovett has joined #openstack-cinder16:43
*** amit213 has quit IRC16:45
*** amit213 has joined #openstack-cinder16:46
*** ntpttr has quit IRC16:47
*** juzuluag has quit IRC16:47
*** harlowja_at_home has quit IRC16:47
*** ntpttr has joined #openstack-cinder16:51
*** ntpttr has quit IRC16:54
*** ntpttr has joined #openstack-cinder16:55
*** ozialien has quit IRC16:56
*** shausy has joined #openstack-cinder16:58
*** haomai___ has quit IRC17:01
*** haomaiwang has joined #openstack-cinder17:01
*** stevemar_ has joined #openstack-cinder17:02
*** p0rtal has joined #openstack-cinder17:03
*** hemnafk is now known as hemna17:03
*** ntpttr has quit IRC17:04
*** sghanekar_ has joined #openstack-cinder17:05
*** willsama has quit IRC17:06
*** stevemar_ has quit IRC17:07
*** p0rtal has quit IRC17:07
*** ociuhandu has quit IRC17:11
*** mriedem has joined #openstack-cinder17:14
*** mriedem_away has quit IRC17:16
*** daneyon has joined #openstack-cinder17:17
*** daneyon has quit IRC17:19
*** daneyon_ has quit IRC17:20
smcginnisthingee, jungleboyj, jgriffith: There are a few patches waiting for a second +2 on kilo.17:22
smcginnisthingee, jungleboyj, jgriffith: https://review.openstack.org/#/q/project:openstack/cinder+branch:stable/kilo+status:open,n,z17:23
smcginnisthingee, jungleboyj, jgriffith: Should we get some of those in before kilo goes to security only?17:23
jgriffithsmcginnis: indeed!17:23
*** IanGovett has quit IRC17:24
jungleboyjsmcginnis: Ok.  Will take a look.17:26
jgriffitheharney: ping17:27
tbarronsmcginnis: thingee: jungleboyj: jgriffith: kilo also needs backport of fix for  https://bugs.launchpad.net/cinder/+bug/150515317:28
openstackLaunchpad bug 1505153 in Manila "gates broken by WebOb 1.5 release" [Critical,In progress] - Assigned to Gaurang Tapase (gaurang-tapase)17:28
*** diogogmt_ has joined #openstack-cinder17:29
*** ronis has quit IRC17:29
tbarron^^ in cinder too17:29
*** diogogmt has quit IRC17:29
*** diogogmt_ is now known as diogogmt17:29
smcginnistbarron: Thanks. I did see you're blocked on that.17:29
tbarronsmcginnis: yeah, fixed a commit message and hit it :-)17:30
smcginnisDoh17:30
jgriffithjungleboyj: can you +2/A this one after it passes tests: https://review.openstack.org/#/c/233747/17:33
jgriffithjungleboyj: get the gate back to healthier state for us17:33
*** kevincarr1991 has joined #openstack-cinder17:34
kevincarr1991tbarron: Did you have a chance to try and test the nfs setup with cinder?17:35
tbarronkevincarr1991: a bit, did some experiments, need to do more.17:35
tbarronkevincarr1991: I can break the nova compute side by messing with permissions on the mount there.17:36
tbarronkevincarr1991: I want to test in a more production environment than devstack.  Are you using a distribution?17:36
*** rushil_ has joined #openstack-cinder17:39
*** rushil has quit IRC17:39
kevincarr1991tbarron: No i did a manual three node setup17:42
*** nkrinner_afk has quit IRC17:43
kevincarr1991tbarron: are you using a separate node for the cinder service?17:43
tbarronkevincarr1991: Not yet, looking for gear.17:44
aorourkewas there ever a launchpad bug filed for the error ntpttr brought up? "'str' object has no attribute 'DEALER'"17:44
eharneyaorourke: https://bugs.launchpad.net/cinder/+bug/150529517:44
openstackLaunchpad bug 1505295 in openstack-ansible "Tox tests failing with AttributeError" [High,In progress] - Assigned to Jesse Pretorius (jesse-pretorius)17:44
aorourkeeharney, thank you17:44
tbarronkevincarr1991: back to our earlier conversation, you wouldn't normally have an fstab entry for the nfs share17:44
kevincarr1991tbarron: ahh ok. and I will delete it out of the fstab file.17:45
tbarronkevincarr1991: your compute node should automatically do the mount, under a similar path as the cinder node.17:45
tbarronkevincarr1991: it will do the mount when you attach a cinder volume to a compute instance.17:46
kevincarr1991tbarron: OK, for me it will be the controller node since that is where cinder is running17:46
tbarronkevincarr1991: the controller node is effectively also the block storage node in your case.17:46
tbarronkevincarr1991: I am saying that when you do the attach, the compute node where the vm instance is running should do a similar mount.17:47
kevincarr1991tbarron: yes, so do i also need to install cinder on the compute nodes so they can attach?17:47
tbarronkevincarr1991: no17:47
kevincarr1991tbarron: Oh, ok thank you17:47
tbarronkevincarr1991: from your brief log snippet a few days ago, it looked like the mount succeeded there, but that17:47
tbarronkevincarr1991: some subsequent commands failed because the volume being attached wasn't readable.17:48
kevincarr1991tbarron: yes. I also noticed that the I am getting an error in the volume log that say "NFS driver not initialized"17:49
tbarronkevincarr1991: can you run 'ls -ld' and 'ls -la' on the mount from the cinder node, first, and then on the (similar) mount from the compute node right after attempting an attach?17:49
tbarronkevincarr1991: well, that is a more fundamental problem.17:49
tbarronkevincarr1991: I think you were past that the other day, but who knows.17:49
kevincarr1991tbarron: I was past that. that just started but I am not sure why. I have to get that fixed before I can run the commands you suggested.17:50
tbarronkevincarr1991: whenever you get 'X driver not initialized' you need to go to the cinder/block node (in your case, the controller)17:50
tbarronkevincarr1991: restart the service, and back up from the end of the volume log to the error initializing right after the service starts.17:51
kevincarr1991tbarron: I think specifying version 3 for the nfs might be causing the issue17:51
tbarronkevincarr1991: in this case, see if the mount is failing on the cinder node.17:51
tbarronkevincarr1991: nfs v 3 works, but only if the server is supporting that version.17:52
*** ronis has joined #openstack-cinder17:52
kevincarr1991tbarron: It does support that version17:52
tbarronkevincarr1991: then it *should* work, if the cinder node is set up right.  Check if the mount failed.17:53
kevincarr1991tbarron: restarting the service17:53
kevincarr1991tbarron: yes the mount failed when I restarted it17:54
tbarronkevincarr1991: so here is where you manually mount the share, just as an experiment, on /mnt or some such, then17:55
tbarronkevincarr1991: when that works, use the same nfs options (if any) in cinder.conf17:56
kevincarr1991tbarron: just tried that and the mount worked17:56
tbarronkevincarr1991: were you using version 3?17:56
kevincarr1991tbarron: yes i used the following mount -t nfs -o vers=3 ip:/exports17:57
*** martyturner has quit IRC17:58
*** martyturner has joined #openstack-cinder17:59
*** apoorvad_ has joined #openstack-cinder18:00
tbarronkevincarr1991: so what is the error in the volume log around the mount?18:00
*** haomaiwang has quit IRC18:01
kevincarr1991tbarron: Unable to update stats, NfsDriver -1.2.0  driver is uninitialized18:01
*** haomaiwang has joined #openstack-cinder18:01
tbarronkevincarr1991: that is a consequence of the driver being unitialized.  Go back to where the driver starts up and look18:03
tbarronkevincarr1991: for lines like: CMD "mount" returned: ...18:03
*** apoorvad has quit IRC18:03
*** ntpttr has joined #openstack-cinder18:08
*** ntpttr has quit IRC18:09
kevincarr1991tbarron: I see now i am getting permission issues but the share has a very open permissions18:09
*** haomaiwang has quit IRC18:17
*** vmtrooper has joined #openstack-cinder18:19
tbarronwe're taking this to a side-channel for now ...18:19
*** salv-orlando has joined #openstack-cinder18:25
*** salv-orl_ has quit IRC18:25
*** ntpttr has joined #openstack-cinder18:30
jgriffithsmcginnis: I have some concerns about this one: https://review.openstack.org/#/c/189588/18:33
jgriffithsmcginnis: I would have said the right thing to do is "fix the bug" of course18:33
jgriffithsmcginnis: but given all the discussion lately around compatible changes etc, I have to pause18:34
smcginnisjgriffith: True18:34
smcginnise0ne made a good point too. Can we backport with ApiImpact?18:34
* smcginnis sees that was addressed in the comments18:35
smcginnisSo it doesn't change what is documented for the API (which apparently was wrong) but it does change behavior.18:36
jgriffithsmcginnis: yeah18:37
mtaninosmcginnis: yes, I think so.18:37
e0nesmcginnis: some users cant use that "wrong" behavior18:37
jgriffithsmcginnis: if it were liberty I would have no concern18:37
e0nesmcginnis: e.g. like they did with AZ issue18:37
e0nejgriffith: +118:37
jgriffithbut Kilo... I don't know.  I don't want to break existing deployments, even if what theyr'e doing is technically *wrong*18:38
jgriffithe0ne: smcginnis my suggestion in the review was maybe make it configurable so we don't screw people up?18:38
smcginnisjgriffith: Probably just leave that one then. Good fix, but not right for this "old" branch.18:38
e0nejgriffith: it seams reasonable18:38
jgriffithsmcginnis: afraid that may be the case18:38
smcginnisjgriffith: Yeah, but then we're adding a new config option to an old branch.18:38
jgriffithsmcginnis: DOH18:39
jgriffithsmcginnis: yeah, that's not doable either :(18:39
smcginnisI think unfortunately we should probably leave it as is and move on. :\18:39
eharneyi like that fix, but with how long that was broken, just leaving it as-is in Kilo isn't really unreasonable18:39
jgriffithsmcginnis: yeah, sorry18:39
smcginnisOh well, worth reviewing.18:40
jgriffitheharney: yeah, I like the fix too.... it's a bummer18:40
smcginnisAnd now if someone wants it, there's a patch out there they can apply to change it.18:40
jgriffithsmcginnis: :)18:40
jgriffithsmcginnis: you've read some of my comments in backports :)18:40
smcginnisHah18:40
e0nesmcginnis: cd cinder && make && make install cinder:)18:40
jgriffithsmcginnis: even those that I know won't get accepted I like to post them and even -2 them myself18:40
smcginnise0ne: :)18:41
jgriffithso that deployers have an easy patch/reference if they want to assume the risk18:41
smcginnisjgriffith: Not a bad pattern to follow, IMO.18:41
jgriffithsmcginnis: I think people would probably rather a patch attached to the LP bug18:41
jgriffithsmcginnis: which I'll try and do instead going forward18:41
jgriffithanyway...18:41
smcginnisjungleboyj: Jenkin's +1'd on this now: https://review.openstack.org/#/c/233747/18:42
jgriffithsmcginnis: man... that took a while18:43
smcginnisToo many rechecks going on or something.18:43
hemnajenkins had been pooh'n out quite a bit over the weekend18:43
smcginnisI do wonder how much longer the way we do things with Jenkins will scale.18:43
jgriffithsmcginnis: haha18:44
jgriffithsmcginnis: people have been saying that for a LONNNG time18:44
*** nikeshm has joined #openstack-cinder18:44
smcginnisjgriffith: No doubt.18:44
jgriffithsmcginnis: every release though it gets better and better18:44
smcginnisI do remember a session in Atlanta from someone pitching moving away from Jenkins.18:44
jgriffithsmcginnis: the only downside is it's sort of like being on a treadmill :)18:45
smcginnisI don't think it's a Jenkins issue though.18:45
smcginnisGood analogy. :)18:45
jgriffithsmcginnis: nah... it's a dependency problem I think more than anything else18:45
*** kevincarr1991 has quit IRC18:45
smcginnisMore and more dependencies.18:45
jgriffithsmcginnis: volume gets high, then if you introduce a problem that causes the chain to break you have some aftermath18:45
jgriffithThe OpenStack infra is pretty amazing when you start pulling back the covers18:46
smcginnisLike the old credit card commercial where everything is humming along until someone tries to pay with cash.18:46
smcginnis+11118:46
jgriffithLOL18:46
smcginnisThey do awesome things.18:46
jgriffithYeah... just like that!18:46
smcginnisWasn't sure if anyone else would actually get that reference. :)18:46
jungleboyjsmcginnis: +A.18:47
smcginnisjungleboyj: Thanks!18:47
hemnawasn't there talk of replacing jenkins ?18:47
smcginnisIn Atlanta there was.18:47
smcginnisI don't think it really went over well.18:47
hemnaasselin,  ?18:49
* jungleboyj is looking at the other stable/kilo items.18:49
asselin_hemna, hi18:49
asselin_replacing jenkins, yes, it's in zuulv318:50
hemnais that happening this century ?18:50
hemna:P18:50
asselin_hemna, http://specs.openstack.org/openstack-infra/infra-specs/specs/zuulv3.html18:51
asselin_hemna, It was discussed in vancouver. not sure the status. You can ask jeblair in -infra18:51
*** jdandrea has joined #openstack-cinder18:53
*** martyturner has quit IRC18:53
hemnacool.  so yah my guess is not any time soon then18:53
hemnaseems like a big hill to climb18:53
*** martyturner has joined #openstack-cinder18:53
*** shausy has quit IRC18:53
jdandreaCan we always count on the scheduler filters to be queried in the order listed in cinder.conf or is that something we should *not* assume will always be the case?18:54
openstackgerritNate Potter proposed openstack/cinder: Block oslo.messaging version 2.6.0  https://review.openstack.org/23376918:56
ntpttr^^ That patch is a temporary fix for the errors I was talking about earlier18:57
ntpttrIt looks like oslo.messaging 2.6.0 is causing the problems18:57
jgriffithntpttr: see my comments19:00
jgriffithmtanino: we can't actually just update independently like that19:01
*** julim has quit IRC19:01
jgriffithoops19:01
mtaninoooo19:01
jgriffiths/mtanino/ntpttr/19:01
jgriffithmtanino: sorry about that19:01
mtaninoyup19:01
jgriffithntpttr: https://review.openstack.org/#/c/233724/19:01
jgriffithntpttr: once that merges we can get away with your patch, but not until then19:01
jgriffithntpttr: assuming it matches of course :)19:02
ntpttrjgriffith: All right, thanks wasn't sure how the requirements workflow worked :)19:02
jgriffithntpttr: so once that merges we can land it19:03
jgriffithntpttr: int he meantime if you could update the commit message to reference that oslo patch19:03
jgriffithntpttr: I'll +2/A it as soon as the other one lands19:03
jgriffithntpttr: make sense/19:03
jgriffith?19:03
ntpttrjgriffith: Okay, sounds good - referencing the oslo patch as in including the link to https://review.openstack.org/#/c/233724/?19:04
guitarzanoslo is like the openstack supervillain19:04
jgriffithntpttr: oops.. I said oslo.. meant requirements19:04
dims__guitarzan: apologies19:04
jgriffithntpttr: but *yes* you figured out what I meant :)19:04
dims__on behalf of oslo folks19:04
jgriffithpissh19:04
jgriffiththat's nothing!19:04
guitarzandims__: haha, no worries, feel free to continue taking over the world19:05
*** gouthamr has quit IRC19:05
dims__guitarzan: :)19:06
dims__guitarzan: 23 versions today (http://lists.openstack.org/pipermail/openstack-announce/2015-October/thread.html) found 2 problems and trying to fix 'em19:07
guitarzanthat's crazy19:07
*** gouthamr has joined #openstack-cinder19:07
*** ociuhandu has joined #openstack-cinder19:08
openstackgerritNate Potter proposed openstack/cinder: Block oslo.messaging version 2.6.0  https://review.openstack.org/23376919:09
hemnadoh19:09
jgriffithntpttr: Excellent!19:10
jgriffithntpttr: thanks!19:10
ntpttrjgriffith: np! thanks for the advice19:10
*** daneyon has joined #openstack-cinder19:10
*** daneyon_ has joined #openstack-cinder19:11
jgriffithntpttr: oops19:12
jgriffithntpttr: you need to match what's in the other patch :)19:12
jgriffithntpttr: oslo.messaging>=1.16.0,!=1.17.0,!=1.17.1,!=2.6.0 # Apache-2.019:12
jgriffithntpttr: even if the logic is the same :)19:13
jgriffithntpttr: I know it's extremely picky of me19:13
ntpttrjgriffith: Oops sorry I thought I had because I saw that they just put 2.6.0 at the end! I'll fix that up19:14
eharneyi think the reqs job will fail it if doesn't match exactly anyway?19:15
ntpttreharney, jgriffith: It looks like the cinder one didn't even match before, 1.16.0 wan't at the front19:15
*** daneyon has quit IRC19:15
jgriffithntpttr: weird, as eharney pointed out we shouldn't be able to get oos like that19:16
*** DericHorn-HP has joined #openstack-cinder19:16
eharneyyeah i don't know how that would happen19:16
*** timcl has quit IRC19:18
openstackgerritNate Potter proposed openstack/cinder: Block oslo.messaging version 2.6.0  https://review.openstack.org/23376919:18
*** asselin_ has quit IRC19:22
*** eharney has quit IRC19:24
jungleboyjsmcginnis: jgriffith I have put my vote in on all the patches in Stable/kilo that have passed jenkins.19:27
jgriffithjungleboyj: thanks!19:27
*** asselin_ has joined #openstack-cinder19:28
jgriffithjungleboyj: BTW, note that some of those not passing jenkins are waiting for ntpttr 's requirements update19:28
*** rushil_ has quit IRC19:31
*** lpabon has quit IRC19:32
*** changbl has joined #openstack-cinder19:33
patrickeastjungleboyj: did you see this one https://review.openstack.org/#/c/232847/ ?19:33
*** rushil has joined #openstack-cinder19:34
*** gouthamr has quit IRC19:35
*** rushil has quit IRC19:36
jungleboyjpatrickeast: Oops.  Hold on.19:37
jungleboyjpatrickeast: Done.19:41
jungleboyjAny other requests?19:41
patrickeastjungleboyj: sweet thanks, i think the only one left in my batch of iscsi junk was https://review.openstack.org/#/c/232846/ which seems to be getting some hate from jenkins19:42
patrickeastwas passing, might be the issue jgriffith was talking about (i'm not caught up on the details...)19:42
jungleboyjpatrickeast: Ok, let me know if you get it figured out.19:43
patrickeastjungleboyj: will do19:43
patrickeastjungleboyj: thanks19:43
*** harlowja has quit IRC19:44
*** apoorvad_ has quit IRC19:45
ntpttrcd19:45
ntpttrhah oops this is not my terminal19:46
*** Yogi11 has joined #openstack-cinder19:49
*** jgregor has joined #openstack-cinder19:50
*** yrabl has quit IRC19:51
*** eharney has joined #openstack-cinder19:52
*** Yogi1 has quit IRC19:53
*** stevemar_ has joined #openstack-cinder19:56
*** stevemar_ has quit IRC19:59
jgriffithaorourke: ping19:59
jgriffithpatrickeast: yes, it's the requirements issue20:00
jgriffithpatrickeast: I'll +2/A it after the fix lands20:00
patrickeastjgriffith: ok cool, thanks!20:00
aorourkejgriffith, hey20:00
jgriffithaorourke: howdy20:01
jgriffithaorourke: hey... I actually wanted to get your input on that (https://review.openstack.org/#/c/233307/3/doc/source/devref/replication.rst)20:01
*** kurtmartin has quit IRC20:01
*** martyturner has quit IRC20:01
jgriffithaorourke: I'm open to ideas, but I wanted to ping you and patrickeast and anybody else to pick something universal and that we all agree on20:01
aorourkejgriffith, I looked over that earlier. I was wondering what the difference would be with volume_backend and device_target_id?20:02
jgriffithvolume_backend_name seemed good because in the managed case we'll need/want that20:02
jgriffithaorourke: nothing, it's just a name/label :)20:02
aorourkejgriffith, so does this replace device_target_id?20:02
jgriffithaorourke: it just becomes a question of what makes more "sense" and what we want to live with going forward20:02
jgriffithaorourke: yes20:02
aorourkeas the new unique id?20:02
aorourkeok20:02
jgriffithaorourke: that way it's clear with the managed case at least to me ;)20:03
*** ronis has quit IRC20:03
jgriffithaorourke: so in the case of managed we have to have that volume_backend_name so it just sort of "made sense" to me20:03
aorourkejgriffith, you have it listed as backend_name at first but then volume_backend_name after in the NOTE section20:03
jgriffithaorourke: yeah... so that's confusing becasue20:03
jgriffithaorourke: I need to fix that20:03
jgriffithaorourke: but wanted to ping you and others before doing anything20:04
jgriffithaorourke: have all of us agree :)20:04
*** Lee1092 has quit IRC20:04
jgriffithaorourke: does that mean you have no preference? :)20:05
aorourkejgriffith, the volume_backend_name might be different than the array identifier is my concern20:05
*** sgotliv has joined #openstack-cinder20:05
jgriffithaorourke: sure, but it's just a label20:05
jgriffithIt will most certainly be different, agreed20:05
aorourkejgriffith, I guess i am a little confused, does volume_backend_name represent the *actual* volume_backend_name of the managed device?20:06
*** Yogi11 has quit IRC20:06
jgriffithIn the case of managed yes20:06
jgriffithin the case of unmanaged it could be *whatever*20:07
jgriffithSo...20:07
aorourkejgriffith, ok, but even with managed the volume_backend_name could still be different than the array id20:07
aorourkeit more than likely will20:07
jgriffithmanaged:  volume_backend_name=hostname@backend_name#pool20:07
jgriffithunmanaged: volume_backend_name=my-vendor-required-name-or-id20:07
jgriffithaorourke: That's kinda the point.. in the case of managed we *NEED* the cinder host name (or volume_backend_name)20:08
aorourkejgriffith, so the goal here is to standardize on an ID that will be passed into failover basically?20:08
jgriffithNo, standardize on a key20:08
jgriffithWe've already standardized on the value in the case of managed20:09
aorourkean identifier key20:09
jgriffithit IS the host20:09
jgriffithof a configured backend20:09
aorourkeright20:10
jgriffithaorourke: do you have a suggestion?20:11
jgriffithaorourke: two different labels?20:11
jgriffithaorourke: something completely different?20:11
aorourkejgriffith, i think that might be needed20:11
jgriffithaorourke: can you expand please?20:12
* jgriffith feels he's pulling teeth20:12
aorourkejgriffith, device_target_id should be used as a way to identify the backend array20:12
jgriffithaorourke: in which case?20:13
aorourkejgriffith, even if it is managed, i feel there needs to be a way to 'name' the array20:13
jgriffithaorourke: both?20:13
aorourketo id it20:13
jgriffithsigh...20:13
jgriffithbut you're missing the point20:13
jgriffithI think20:13
jgriffithmaybe not... what I'm asking you is:  what key would you like to use to specify the target hostname (Cinder name)20:14
openstackgerritVictor Stinner proposed openstack/cinder: Port API types extra specs to Python 3  https://review.openstack.org/23221620:14
openstackgerritVictor Stinner proposed openstack/cinder: Port WSGI tests to Python 3  https://review.openstack.org/23221420:14
openstackgerritVictor Stinner proposed openstack/cinder: Port API to Python 3  https://review.openstack.org/23221520:14
openstackgerritVictor Stinner proposed openstack/cinder: Port API admin action tests to Python 3  https://review.openstack.org/23224220:14
jgriffithaorourke: OR, would you rather we modified the "managed_target_device" to NOT be a bool20:14
jgriffithbut to be the backend name or None?20:14
jgriffithso if it's None that indicates unmanaged20:15
jgriffithif it's set we assume it's a properly formed backend/host name?20:15
aorourkejgriffith, "managed_target_device" is meant for the primary configuration though20:15
aorourkejgriffith, not the replication_devices20:15
jgriffithUmmm... what?20:15
aorourkemanaged_replication_target ... True|False20:16
jgriffithaorourke: yes... so change that20:16
jgriffithmanaged_replication_target = <host>@<backend-name>#<pool> | None20:17
*** Yogi1 has joined #openstack-cinder20:17
aorourkejgriffith, then you are forcing every secondary array to that same host20:18
jgriffithaorourke: how?20:18
jgriffithIf I have hosts: sleepy, dopey, goofy20:18
jgriffithI can do:  goofy@lvm#lvm20:18
jgriffithor20:18
jgriffithdopey@lvm#lvm20:18
jgriffithor20:18
jgriffithsleepy@lvm#lvm20:18
jgriffithI can make it whatever I want20:19
aorourkemanaged_replication_target = <host>@<backend-name>#<pool> and replication_device = backend_name:biz,unique_key:val are meant for the main configuration correct? or am i missing something?20:19
jgriffithaorourke: they're meant for the cinder.conf file.20:19
aorourkeyes20:19
aorourkeof the primary array20:19
jgriffithaorourke: so... if you read the doc info:20:19
jgriffithaorourke: you have a backend named "driver-foo" right?20:20
jgriffithaorourke: see the config section for 'driver-foo'20:20
jgriffith?20:20
aorourkeyes looking at it20:20
aorourkethat is the primary right?20:20
jgriffithaorourke: In this case yes20:20
aorourkeok20:20
jgriffithaorourke: so if I want to enable replication to one or more of the other confgured backends...20:21
jgriffithaorourke: I would do:  managed_replication_target=drirver-biz,driver-baz20:21
aorourkeyep20:21
jgriffithaorourke: that would instruct driver-foo to set up pairing and do it's thing on init to those backends20:22
jgriffithaorourke: so they're now valid/available replication target devices20:22
jgriffithaorourke: I could also make entries for driver-biz to pair with driver-foo etc etc20:22
jgriffithaorourke: does that make sense?20:23
aorourkeright, it does make sense20:23
aorourkewhat i am saying, in this case, if you set managed_replication_target = <host>@<backend-name>#<pool> in driver-foo, all the replication targets off of it will use that entry20:23
jgriffithaorourke: well yeah20:23
jgriffithif you don't want to do that then don't set that in your config20:23
jgriffithwhat is it that you want?20:24
*** harlowja has joined #openstack-cinder20:24
aorourkejgriffith, to be able to set different hosts for different targets off of the same primary20:24
*** apoorvad has joined #openstack-cinder20:24
jgriffithaorourke: so add more entries20:24
jgriffithaorourke: it's a list20:24
jgriffithas I said earlier:  managed_replication_target = driver-biz,driver-baz....20:24
aorourkeyes so then managed_replication_target is a list as well?20:25
jgriffithaorourke: correct20:25
aorourkeand they have to be concurrent then. so managed_replication_target[0] goes to replication_devices[0]20:25
aorourkeok20:25
jgriffithaorourke: well, that's up to you and your driver20:26
jgriffithaorourke: some backends can have multiple targets, they may want all of them... but thats the level of detail that IMO can/should go in the type info20:26
jgriffithaorourke: and is going to be vendor-specific20:27
jgriffithand shouldn't be considered in Cinder's core code20:27
aorourkejgriffith, i like the idea of backend_name or volume_backend_name being configurable on the targets, like you have in this patch. but if you think it makes sense another way..20:27
jgriffithaorourke: just so long as they have the tools/mechanisms to do what they want or need20:27
jgriffithaorourke: Ohhh20:28
jgriffithI see what you were getting at20:28
jgriffithhehe.. sorry20:28
jgriffithyou were talking about how to align the managed_replication_target list and the replication_device entries?20:28
aorourkejgriffith, yeah20:28
jgriffithso yeah... that doesn't work :)20:28
aorourkejgriffith, i think it should be kept in each target as it is now20:29
jgriffithYeah, I think you're right... I think it has to be20:29
jgriffithI think that managed flag is actually useless TBH20:29
jgriffithaorourke: so how about this... there are two required keys in the replication_device entry:20:30
aorourkewith this new patch managed and unmanaged is very similar now20:30
aorourkewhat i was saying earlier, though, is there still should be a key that allows you to ID the array.  whether managed or unmanaged, vendors would probably want to name it consistently20:30
aorourkenot based off of a host if managed, otherwise something else20:30
aorourkeshould be consistent20:30
aorourkeand backend_name is a host if you are managed20:31
hemnaand we still need a key that is consistent for the client  list replication targets20:31
jgriffithaorourke: read line 82 :)20:31
hemnaso everyone has the same copy/paste column for failover20:31
aorourkehemna, yes, which should remain device_target_id20:31
aorourkejgriffith, yes, but like hemna is saying there needs to be a standardized identifier regardless of if the target is managed or unmanaged20:32
aorourkefor list_replication_target20:32
hemnayes20:32
aorourkeand to pass it to replication_failover20:32
jgriffithhemna: aorourke I think we're rat holing a bit...  yeah, sure20:32
aorourkeso each vendor does not have a different key to pass20:32
jgriffithhemna: aorourke but I'm saying that the more I look at this we could put all of that in one entry20:32
jgriffithhemna: aorourke let me propose it and see what you guys think20:33
hemnacool20:33
aorourkejgriffith, ok20:33
ntpttrWhen any cores have time would you mind giving this patch from last week a quick look? I think I've ironed out the suggestions I've been given on it https://review.openstack.org/#/c/228646/ :)20:36
*** dustins has quit IRC20:42
*** sghanekar_ has quit IRC20:43
*** e0ne has quit IRC20:48
*** edtubill has quit IRC20:48
*** ntpttr has quit IRC20:50
*** vgridnev has quit IRC20:51
mc_nairhemna, leeantho - I'm looking into Live Migration support for some of the IBM drivers to make sure everything cleaning up nicely (based on https://etherpad.openstack.org/p/live-migration-results).  I was wondering if you guys used scripts for running the different test scenarios 10+ times?20:53
*** pots3 has quit IRC20:53
jdandreaCan we always count on scheduler filters to be polled in the order listed in cinder.conf or should I *not* assume that will always be true? (Want to ask jecarey but he is not on. Can anyone give insight?)20:54
*** abhi has quit IRC20:54
*** porrua has quit IRC20:54
*** abhi has joined #openstack-cinder20:55
hemnamc_nair, yah leeantho had a script that  he ran against an existing multi-node setup20:56
*** mriedem has quit IRC20:58
*** edtubill has joined #openstack-cinder20:59
mc_nairhemna ah, shweet - thanks. Got the a multinode setup for live migration (the instructions you had were great) and tried a few out by hand, but was getting old quickly.20:59
hemnayah it's a pain21:00
*** sghanekar_ has joined #openstack-cinder21:00
hemnaleeantho, do you have the etherpad url we had for our live migration setup/testing/scripts ?21:00
openstackgerritJohn Griffith proposed openstack/cinder: Update config format for replication_devices  https://review.openstack.org/23330721:00
jgriffithaorourke: hemna see if that makes sense or not ^^21:01
*** edmondsw has quit IRC21:01
hemnajgriffith, ok thanks...we are off to a beating21:02
*** hemna is now known as hemnafk21:02
*** mriedem has joined #openstack-cinder21:02
openstackgerritOpenStack Proposal Bot proposed openstack/cinder: Updated from global requirements  https://review.openstack.org/23286821:04
*** stevemar_ has joined #openstack-cinder21:04
openstackgerritAlon Marx proposed openstack/cinder: Implement changes in the consistency_group handling in the xiv/ds8k driver.  https://review.openstack.org/23328021:04
openstackgerritAngela Smith proposed openstack/cinder: Adds friendly zone name support  https://review.openstack.org/18051821:07
openstackgerritSean McGinnis proposed openstack/cinder: Only use LOG.exception in exception handler  https://review.openstack.org/23382821:09
mc_nairjgriffith: quick question about https://review.openstack.org/#/c/233307 - are "device_target_id" and "managed_backend_name" meant to be used mutually exlusively?  I.e. 'device_target_id' is only used for unmanaged, and 'mamanged_backend_name' only used for managed by Cinder?21:15
openstackgerritOpenStack Proposal Bot proposed openstack/python-cinderclient: Updated from global requirements  https://review.openstack.org/23288921:15
*** ntpttr has joined #openstack-cinder21:17
*** ntpttr has quit IRC21:19
*** salv-orlando has quit IRC21:20
*** zhiyan has quit IRC21:20
*** salv-orlando has joined #openstack-cinder21:20
*** serverascode has quit IRC21:21
*** briancurtin has quit IRC21:22
*** ctracey has quit IRC21:22
*** lprice has quit IRC21:24
*** rhefner has quit IRC21:25
*** scottda has quit IRC21:26
*** ameade has quit IRC21:26
mriedemanyone know if there is a fix up for this yet? https://bugs.launchpad.net/cinder/+bug/1505394 - if not i've got one on the way21:28
openstackLaunchpad bug 1505394 in OpenStack Compute (nova) "nova.tests.unit.test_exceptions.test_exceptions_raise fails with webob 1.5.0" [Critical,In progress] - Assigned to Matt Riedemann (mriedem)21:28
openstackgerritMatt Riedemann proposed openstack/cinder: windows: don't use LOG.exception if not logging an exception  https://review.openstack.org/23364421:28
mriedemlifeless: ^ i see you on the python issue thread related to that so you might want to peek21:28
jgriffithmc_nair: nope, the idea is that you need/want both of them21:30
jgriffithmc_nair: the only key being that if the target is NOT managed then you would set managed_backend_name = None21:31
jgriffithmc_nair: even in the case of a managed rep target, your primary drivers is still going to need some sort of identifying info21:31
jgriffithmc_nair: and we don't have a good way that I can figure out to do things like "read config from XYZ"21:32
lifelessmriedem: huh? thats 3.5+ only, totally unrelated21:36
mriedemlifeless: regressed in 3.5?21:37
mriedemb/c that also fails/shows up in the py34 jobs21:37
lifelessmriedem: no, it was effature work21:38
lifelessbah21:38
lifelessfeature work21:38
lifelessso you probably want to look at the neutron patch21:38
lifelesssec while I dig it up21:38
mc_nairjgriffith: thanks for the clarification.  So unmanaged doesn't care about the "managed_backend_name" (makes sense because there's no Cinder name to give there).  I still don't follow what the "device_target" id will need to get used for in the managed case, but I'm not very familiar with how repl is handled in the drivers so I'll dig into that on my own.21:39
lifelessmriedem: I456b7846b8a53e4d3f8c91583685e0e1eaa8471921:39
lifelessmriedem: and I58e7e01ed152028ad43bb3ada87d719caa2ab08d21:39
jgriffithmc_nair: so in my case for example.. in order to pair clusters, I need to have some info like "cluster name"21:39
jgriffithmc_nair: which is an internal identifier just for me21:40
jgriffithmc_nair: so I would set that as the identifier in that key21:40
jgriffithmc_nair: for others it may be a UUID21:40
jgriffithmc_nair: or something completely different21:40
*** merooney has quit IRC21:41
mriedemlifeless: ok my change is basically the same21:43
mriedemuse LOG.error instead of LOG.exception21:43
lifelessmriedem: yup21:43
mc_nairjgriffith: ok cool, that helps a bit. And you're confident that each driver can use just a single field for a unique target id?  The only reason I'm asking is if not it'd be a bit odd if we have this one required field we designate to be vendor specific but we also acknowledge there can be other keys which will be vendor specific21:43
lifelessmriedem: but 17911 has nothing to do with this21:43
lifelessmriedem: how did you find that number ?21:43
mriedemlifeless: ok, i got that from the heat patch that fixed the same issues in heat21:44
jgriffithmc_nair: so the thing is they can add as many keys as the like21:44
jgriffithmc_nair: but that "one" is required21:44
lifelessmriedem: so heat are fundamentally confused21:44
jgriffithmc_nair: because 3Par folks asked for it :)21:44
lifelessmriedem: it was a bug in Python 3.x < 3.521:44
jgriffithmc_nair: that's what they want to return in the list_targets call21:44
lifelessmriedem: 17911was a feature request for asyncio for 3.5+21:44
jgriffithmc_nair: which makes sense kinda21:44
jgriffithhave at least *something* consistent21:45
lifelessmriedem: it *may* be that 3.5 is fixed because of my 17911 patch ?21:45
lifelessmriedem: that I could believe, but its totally incidental :)21:45
mc_nairjgriffith: ah got it - that was the missing piece.  I get that there can be other vendor specific ones but was wondering why we required a key that was still going to be used in sort of vendor specific ways.21:45
mriedemlifeless: ok, yeah, i was having a hard time making the connection between what was failing in the py34 jobs and that 17911 patch21:46
mc_nairmakes sense now though with trying to have at least one consistent-ish thing to queue off of for things like generating target list21:46
lifelessso I think I fixed a regression in my feature work21:46
lifelesswhere traceback.print_exception() would fail if sys.exc_info() was none21:47
lifelessbut we didn't identify it as such21:47
*** jaypipes has quit IRC21:47
lifelessso, saying heat was confused is perhaps unfair21:47
lifeless*I* was confused21:47
lifelessand I think anyone looking at that bug will be to :)21:47
*** vmtrooper has quit IRC21:48
lifelessmriedem: I've suggested a different spelling of the fix that will also work on all Pythons21:48
lifelessmriedem: (and will give the same behaviour that the author had previously)21:49
lifelessmriedem: your one adds a traceback when no exception is present on 3.x21:49
mc_nairjgriffith: thanks for clearing that up.  Your reward is one more question :) any reason in the docs for the unmanaged case that you set "managed_backend_name: None" instead of just leaving out that key?  You just feel like it's better to be explicit on that one?21:50
jgriffithmc_nair: LOL21:50
jgriffithmc_nair: yeah :)  So I want to just grab that key in my driver to know what to init21:50
jgriffithmc_nair: and sure, I could just say "if it's not there" but why be so simple :)21:50
jgriffithmc_nair: honestly it could be either way, but my experience is that if you have too many things "optional" then people forget to enter it21:51
jgriffithmc_nair: bb in a few... gotta run for now21:51
*** edtubill has quit IRC21:52
mc_nairjgriffith: and dictionary.get('nonexistent') defaults to None anyway so in this case it seems like it could be simpler to just leave it out21:52
jgriffithmc_nair: yeah, it might be :(21:52
jgriffithI just hate changing it again :)21:53
jgriffithbut I'm certainly fine with it....21:53
mc_nairjgriffith: not a big deal either way though.  Your reward for answering that one is some spelling nit comments in that changeset - then I'm out of "rewards" for the day21:53
jgriffithI'll let everybody else decide21:53
jgriffithlol21:53
jgriffithdarn21:53
mc_nairhaha yea - I'm sure you'll be ignoring my questions in no time21:54
jgriffithmc_nair: nahh... they're good questions21:56
jgriffithOk, really going now... going to be late if I don't mozie21:56
*** daneyon_ has quit IRC21:58
*** thangp has quit IRC21:58
openstackgerritPatrick East proposed openstack/cinder: Add retries for Cisco FCZM client CLI _cfg_save  https://review.openstack.org/23384621:58
*** earlephilhower has quit IRC21:58
*** jgregor has quit IRC21:59
mc_nairsure thing - sorry to hold ya up22:00
*** Yogi1 has quit IRC22:00
*** mc_nair has quit IRC22:00
*** jgregor has joined #openstack-cinder22:01
*** lprice has joined #openstack-cinder22:02
mriedemlifeless: yeah isn't that what stack_info is for though?22:03
mriedemon py >= 3.222:03
*** dims_ has joined #openstack-cinder22:09
*** salv-orl_ has joined #openstack-cinder22:10
*** 32NAAJR1K has joined #openstack-cinder22:10
*** vmtrooper has joined #openstack-cinder22:10
*** jgregor has quit IRC22:11
*** dims__ has quit IRC22:11
*** ctracey has joined #openstack-cinder22:13
*** salv-orlando has quit IRC22:13
*** jungleboyj has quit IRC22:16
openstackgerritMatt Riedemann proposed openstack/cinder: windows: don't use LOG.exception if not logging an exception  https://review.openstack.org/23364422:16
patrickeastuhh ok i'm confused, i just got a merge conflict error from jenkins on https://review.openstack.org/#/c/232845/ but there doesn't appear to be any errors, or any newly merged changes in stable/kilo for that matter22:17
patrickeastanyone know what might have happened?22:17
*** asselin__ has joined #openstack-cinder22:17
*** jgregor has joined #openstack-cinder22:18
*** asselin_ has quit IRC22:18
*** serverascode has joined #openstack-cinder22:18
jgriffithpatrickeast: not sure, but try rebasing22:19
jgriffithpatrickeast: could be related to the req update22:20
patrickeastjgriffith: i did, there aren't any missing changes :(22:20
jgriffithOh.. hmm22:20
patrickeastlast change on stable/kilo was 10 days ago afaik22:20
patrickeastor as far as https://git.openstack.org/cgit/openstack/cinder/?h=stable%2Fkilo  knows about22:20
patrickeastjgriffith: looks like others are complaining about this kind of thing over in -infra22:21
patrickeastmight be a more general zuul/jenkins breakage22:21
*** ameade has joined #openstack-cinder22:21
*** p0rtal has joined #openstack-cinder22:21
*** stevemar_ has quit IRC22:23
*** daneyon has joined #openstack-cinder22:24
*** zhiyan has joined #openstack-cinder22:25
*** dave-mccowan has quit IRC22:26
*** vmtrooper has quit IRC22:27
*** stevemar_ has joined #openstack-cinder22:27
*** daneyon has quit IRC22:28
*** vmtrooper has joined #openstack-cinder22:28
*** IlyaG has joined #openstack-cinder22:29
*** daneyon has joined #openstack-cinder22:30
*** xyang1 has quit IRC22:33
*** IanGovett has joined #openstack-cinder22:34
*** IanGovett has quit IRC22:38
*** hemnafk is now known as hemna22:40
*** IlyaG has quit IRC22:41
*** briancurtin has joined #openstack-cinder22:42
openstackgerritWalter A. Boring IV (hemna) proposed openstack/os-brick: Add new Connector APIs for path validation  https://review.openstack.org/19976422:43
*** stevemar_ has quit IRC22:47
hemnapatrickeast, I just had the same issue on my patch22:47
*** stevemar_ has joined #openstack-cinder22:47
hemnaI was confused when I rebased locally and didn't see a conflict.  so I just hit the rebase button in gerrit22:47
patrickeasthemna: did that fix it?22:50
hemnayah it seems so22:51
patrickeasthmm i don't seem to even have a rebase button available for this one22:51
patrickeastits not always there... right? or am i blind?22:52
hemnalogged in ?22:52
hemnaI think it's only there if another patch has landed, and the current patch is behind ?22:53
*** rhefner has joined #openstack-cinder22:53
*** IlyaG has joined #openstack-cinder22:54
*** scottda has joined #openstack-cinder22:55
*** IlyaG has quit IRC23:00
*** lpabon has joined #openstack-cinder23:01
*** david-ly_ has joined #openstack-cinder23:01
*** david-lyle has quit IRC23:02
*** daneyon has quit IRC23:03
*** david-lyle has joined #openstack-cinder23:04
*** david-ly_ has quit IRC23:04
*** lpabon has quit IRC23:09
*** diogogmt has quit IRC23:13
thingeesmcginnis: ack wrt kilo23:14
*** diogogmt has joined #openstack-cinder23:15
*** zhangjn has joined #openstack-cinder23:15
*** DericHorn-HP has quit IRC23:17
*** dave-mccowan has joined #openstack-cinder23:23
*** IlyaG has joined #openstack-cinder23:23
*** lprice1 has joined #openstack-cinder23:24
*** lprice has quit IRC23:26
*** zhangjn has quit IRC23:26
*** dave-mccowan has quit IRC23:27
*** gouthamr has joined #openstack-cinder23:28
openstackgerritJohn Griffith proposed openstack/cinder: Update config format for replication_devices  https://review.openstack.org/23330723:29
*** gouthamr_ has joined #openstack-cinder23:29
jgriffithpatrickeast: which patch was it?23:32
*** vilobhmm11 has joined #openstack-cinder23:32
*** ntpttr has joined #openstack-cinder23:32
patrickeastjgriffith: https://review.openstack.org/#/c/232845/23:32
vilobhmm11smcginnis : ping23:32
*** dave-mccowan has joined #openstack-cinder23:32
*** gouthamr has quit IRC23:32
*** stevemar_ has quit IRC23:33
vilobhmm11smcginnis, jgriffith : is there a limit on the number of volumes that can be attached to a nova instance (VM)23:33
patrickeastjgriffith: oh wait, you mean the one that needed the requirements change?23:33
patrickeastjgriffith: https://review.openstack.org/#/c/232846/23:33
jgriffithpatrickeast: https://review.openstack.org/#/c/232846/23:34
jgriffithpatrickeast: that's going to cause you problems I believe23:34
patrickeastjgriffith: wouldn't it just need a rebase?23:35
patrickeastjgriffith: once the requirements one lands*23:35
jgriffithpatrickeast: well, the problem is that the changes haven't landed yet, and your needed-by there is failing23:36
jgriffithpatrickeast: I'm not sure about linking deps in stable... I try not to do that :)23:36
patrickeasthaha yea in retrospect maybe not the best idea23:36
jgriffithpatrickeast: so FWIW, the use of depends on etc is causing all sorts of havoc for me :(23:38
jgriffithpatrickeast: I think if we can get the oslo patches to merge somehow then try again we might be good23:38
jgriffithpatrickeast: I wouldn't bother rechecking for now though23:38
jgriffithpatrickeast: although I'm not entirely clear on what the "conflict" is in this case23:39
patrickeastjgriffith: afaik the conflict error on the first one in the batch was from zuul breaking, in theory it should go away now that they restarted the troublesome zuul node23:40
jgriffithahh23:40
patrickeastjgriffith: what i'm not sure on though is how exactly to recheck a merge conflict23:40
jgriffithwonder why eharney 's patch is puking....  looks23:41
openstackgerritAngela Smith proposed openstack/cinder: Adds friendly zone name support  https://review.openstack.org/18051823:41
jgriffithOH>.. DERP23:41
jgriffithThe zmq issue23:41
jgriffithSo something that would be helpful if everyone focused on helping to get the requirements updates landed :)23:42
jgriffiththen come back to these23:42
*** angela-s has quit IRC23:42
jgriffithwe don't want anything else going in to verify until those land23:42
jgriffithor it just gums up the works again23:42
patrickeastmakes sense23:43
*** IlyaG has quit IRC23:43
jgriffithpatrickeast: granted I'm the one who +2/A'd that patch but it was like 4 hours ago before I really knew we had the issue :)23:43
patrickeastlol23:43
dims_jgriffith: lol :)23:44
jgriffith:)23:44
patrickeastjgriffith: looks like https://review.openstack.org/#/c/233747/ probably got hit by the merge failure stuff too23:45
jgriffithpatrickeast: well.. that's expected :)23:45
jgriffithpatrickeast: it's parent hasn't merged23:45
jgriffithpatrickeast: so now things are all messed up there23:45
jgriffithpatrickeast: if you click on the cherry picked link you can see what I'm talking about23:46
patrickeastjgriffith: its parent? i don't see any dependency on it23:46
jgriffithpatrickeast: it's a cherry pick from https://review.openstack.org/#/c/233528/, which hasn't merged23:46
jgriffith:(23:46
jgriffithand it appears that mriedem pointed out that maybe that should be changed anyway23:47
patrickeastoh what, cherry-pick makes it wait until the first one merges?23:47
jgriffithpatrickeast: it has to23:47
patrickeasti thought it was just a documentation thing23:47
patrickeastwhy? they are on separate branches23:47
jgriffithpatrickeast: if you cherry pick and it doesn't align with master then the world bursts into a huge atomic fireball23:47
patrickeastlol23:48
*** vmtrooper has quit IRC23:48
jgriffithpatrickeast: so if you think about it... the way we manage stable is backporting fixes that land in master right?23:48
patrickeastyea23:48
jgriffithpatrickeast: so we don't want to backport something that hasn't landed... because, well who knows.  Maybe that change will never land, maybe it's borked... maybe it needs to be changed from a 400 to a 500 :)23:49
patrickeastbut there isn't (afaik) anything that forces it to be in master first other than convention23:49
jgriffithpatrickeast: and then your backport is wrong  and you introduced a new bug to stable :(23:49
patrickeastyea totally on board there23:49
jgriffithpatrickeast: gerrit forces it as you can see by the conflict :)23:49
jgriffithpatrickeast: or something we run in the gate at any rate23:49
jgriffithpatrickeast: because it's going to try and pull that change id from master, but it's not there so it barfs23:50
patrickeastjgriffith: im not sure of that actually... i think we might have just gotten lucky with zuul breaking23:50
jgriffithpatrickeast: see what I mean?23:50
patrickeastjgriffith: yea it would make sense23:50
*** zhangjn has joined #openstack-cinder23:50
jgriffithpatrickeast: pretty sure that's how it works... because if you look at the merging process it's pulling commit ID's from master23:50
jgriffithpatrickeast: NOT pulling reviews from gerrit (I think that would end badly)23:51
patrickeastjgriffith: how would that work with conflicts requiring changes to port stuff?23:51
patrickeastjgriffith: it seems like it would have to pull the patch up for review and merge it23:51
*** vilobhmm11 has left #openstack-cinder23:51
jgriffithpatrickeast: not following?23:51
patrickeastnot automate the cherry-pick23:51
jgriffithahhh23:51
jgriffithpatrickeast: it doesn't automate that stuff anyway23:52
jgriffithpatrickeast: so it pulls your patch, and tries to apply it to master23:52
jgriffithpatrickeast: if the stuff you need to make it work isn't in master it's not going to work23:52
jgriffithpatrickeast: see what I mean?23:52
jgriffithpatrickeast: err.. not master23:52
jgriffithpatrickeast: now look what you've done23:52
jgriffithpatrickeast: you've got me all confused with words :)23:53
patrickeasthaha23:53
jgriffithpatrickeast: so how about this... I'll be you a beer in Tokyo; that if you wait for those things to all land correctly then reverify your patch in stable/kilo it'll land :)23:53
patrickeastjgriffith: so i think we're on the same page, it merges whatever is in review onto the target branch, right?23:53
patrickeastjgriffith: hah deal23:53
jgriffithpatrickeast: I'll leave it as an exercise for you to dig into the depths of our systems to figure out how/why :)23:54
*** aorourke is now known as aorourke_afk23:54
jgriffithsighh23:55
jgriffithbut we're never going to get that silly patch to land anyway so none of this matters :(23:55
*** stevemar_ has joined #openstack-cinder23:56
jgriffithpatrickeast: https://jenkins07.openstack.org/job/gate-cinder-python34/1421/console23:56
patrickeastis there anything we can do to help it along?23:56
jgriffith:(23:56
*** smoriya has joined #openstack-cinder23:57
*** diogogmt has quit IRC23:57
jgriffithpatrickeast: wait and recheck... or find/fix this:  https://bugs.launchpad.net/cinder/+bug/150183823:58
openstackLaunchpad bug 1501838 in Cinder "Tests: lazy load operation of attribute 'snapshot_metadata' cannot proceed" [Undecided,New]23:58
*** diogogmt has joined #openstack-cinder23:58

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