Monday, 2014-12-15

openstackgerritMonty Taylor proposed openstack-dev/pbr: Write and read more complex git sha info  https://review.openstack.org/14166600:02
mordredclarkb: there is the patch ported on to master00:03
fungimordred: would that also be useful returned as an attribute of the pbr.version.VersionInfo object?00:05
fungiperhaps there's a better option for software which wants to be able to return the git sha along with the human-readable version somewhere which doesn't involve a runtime dependency on pbr maybe00:07
fungii guess the cli tool provides a good example of how to go about that00:09
*** ZZelle_ has quit IRC00:11
*** sabari is now known as zz_sabari00:20
*** ivar-lazzaro has quit IRC00:22
*** ivar-lazzaro has joined #openstack-infra00:23
*** zz_avozza is now known as avozza00:23
*** fandi has joined #openstack-infra00:31
*** zz_sabari is now known as sabari00:32
*** avozza is now known as zz_avozza00:33
*** dpaterson has quit IRC00:34
*** Masahiro has joined #openstack-infra00:37
mordredfungi: I do not understand the chaos that a runtime dep on pbr causes in some people's brains00:37
mordredfungi: it's a python library00:38
mordredopenstack already has >200 python libraries00:38
*** otter768 has joined #openstack-infra00:38
*** Masahiro has quit IRC00:42
*** ryanpetrello has joined #openstack-infra00:43
*** dimsum__ has joined #openstack-infra00:46
*** oomichi_ has joined #openstack-infra00:46
*** penguinRaider has quit IRC00:47
*** teran has quit IRC00:53
*** unicell has joined #openstack-infra00:54
*** tylerdurden has quit IRC00:54
*** shakamunyi has joined #openstack-infra00:55
*** Masahiro has joined #openstack-infra00:55
*** ivar-lazzaro has quit IRC00:57
*** sabari is now known as zz_sabari00:58
*** ryanpetrello has quit IRC00:59
*** ryanpetrello has joined #openstack-infra01:01
*** zz_sabari is now known as sabari01:08
*** yaguang has joined #openstack-infra01:08
*** ryanpetrello has quit IRC01:12
*** boris-42 has quit IRC01:13
*** wuhg has joined #openstack-infra01:19
*** yaguang has quit IRC01:20
*** yaguang has joined #openstack-infra01:20
*** stevemar has joined #openstack-infra01:20
*** mriedem has joined #openstack-infra01:21
*** ddieterly has joined #openstack-infra01:24
*** zz_avozza is now known as avozza01:27
*** jaypipes has joined #openstack-infra01:28
*** mriedem has quit IRC01:31
*** zhiwei has joined #openstack-infra01:34
*** otter768 has quit IRC01:35
*** liusheng has quit IRC01:37
*** liusheng has joined #openstack-infra01:37
*** hdd has joined #openstack-infra01:41
*** ivar-lazzaro has joined #openstack-infra01:42
openstackgerritJoshua Hesketh proposed openstack-infra/zuul: Refactor sources out of triggers  https://review.openstack.org/11899301:42
openstackgerritJoshua Hesketh proposed openstack-infra/zuul: Fix pep8 issues  https://review.openstack.org/11518701:42
openstackgerritJoshua Hesketh proposed openstack-infra/zuul: Add gerrit reviews into patchset approvals  https://review.openstack.org/9739001:42
openstackgerritJoshua Hesketh proposed openstack-infra/zuul: Add support for negative requirements  https://review.openstack.org/10272601:42
openstackgerritJoshua Hesketh proposed openstack-infra/zuul: Configure triggers dynamically  https://review.openstack.org/11953401:43
openstackgerritJoshua Hesketh proposed openstack-infra/zuul: Add support for 'connection' concept  https://review.openstack.org/12152801:43
openstackgerritJoshua Hesketh proposed openstack-infra/zuul: Call driver methods more dynamically  https://review.openstack.org/11953301:43
openstackgerritJoshua Hesketh proposed openstack-infra/zuul: Add base class for triggers  https://review.openstack.org/11953201:43
openstackgerritJoshua Hesketh proposed openstack-infra/zuul: Add base class for sources  https://review.openstack.org/11953101:43
openstackgerritJoshua Hesketh proposed openstack-infra/zuul: Add base class for reporters  https://review.openstack.org/11953001:43
*** ivar-lazzaro has quit IRC01:44
*** yaguang has quit IRC01:51
*** hdd has quit IRC01:57
*** talluri has joined #openstack-infra02:00
*** talluri has quit IRC02:05
*** pcrews has joined #openstack-infra02:18
*** fandi has quit IRC02:20
*** fandi has joined #openstack-infra02:22
*** pcrews has quit IRC02:27
*** yaguang has joined #openstack-infra02:29
*** talluri has joined #openstack-infra02:47
*** KanagarajM has joined #openstack-infra02:49
*** ddieterly has quit IRC02:52
*** jerryz has joined #openstack-infra02:54
*** zz_dimtruck is now known as dimtruck03:10
*** dpaterson has joined #openstack-infra03:19
*** koolhead17 has joined #openstack-infra03:23
*** ddieterly has joined #openstack-infra03:25
*** ddieterly has quit IRC03:27
*** ddieterl_ has joined #openstack-infra03:27
*** Masahiro has quit IRC03:27
*** baoli has quit IRC03:29
*** baoli has joined #openstack-infra03:29
*** dkranz has joined #openstack-infra03:30
*** ddieterl_ has quit IRC03:31
*** otter768 has joined #openstack-infra03:36
*** teran has joined #openstack-infra03:38
*** otter768 has quit IRC03:40
*** teran has quit IRC03:42
*** teran has joined #openstack-infra03:45
*** dpaterson has quit IRC03:48
*** oomichi_ has quit IRC03:50
*** mestery has quit IRC03:52
*** ayoung has quit IRC03:52
*** amitgandhinz has joined #openstack-infra03:54
*** shashankhegde has joined #openstack-infra03:55
*** cody-somerville has joined #openstack-infra03:56
*** mestery has joined #openstack-infra04:00
*** yamamoto_ has joined #openstack-infra04:04
*** Masahiro has joined #openstack-infra04:04
*** yfried|afk is now known as yfried04:22
*** amitgandhinz has quit IRC04:23
*** nuritv has quit IRC04:24
*** dimsum__ has quit IRC04:25
*** baoli has quit IRC04:26
*** ddieterly has joined #openstack-infra04:26
*** talluri has quit IRC04:28
*** shashankhegde has quit IRC04:30
*** kingia has joined #openstack-infra04:30
*** kingia is now known as dhp04:30
*** ddieterly has quit IRC04:31
*** nuritv has joined #openstack-infra04:32
*** talluri has joined #openstack-infra04:36
*** talluri has quit IRC04:37
*** talluri has joined #openstack-infra04:37
*** talluri has quit IRC04:38
*** talluri has joined #openstack-infra04:39
*** talluri has quit IRC04:40
*** talluri has joined #openstack-infra04:40
*** otter768 has joined #openstack-infra04:41
*** talluri has quit IRC04:44
*** achanda has joined #openstack-infra04:47
*** otter768 has quit IRC04:51
*** talluri has joined #openstack-infra04:52
*** mrmartin has joined #openstack-infra04:53
*** liusheng has quit IRC04:54
*** liusheng has joined #openstack-infra04:54
*** miqui has quit IRC04:56
*** koolhead17 has quit IRC04:58
*** koolhead17 has joined #openstack-infra04:58
*** koolhead17 has joined #openstack-infra04:58
*** boris-42 has joined #openstack-infra05:01
*** dhp_ has joined #openstack-infra05:01
*** dhp_ is now known as iain-king05:01
*** dhp has quit IRC05:01
*** iain-king is now known as dhp05:02
*** avozza is now known as zz_avozza05:03
*** ddieterly has joined #openstack-infra05:08
*** achanda has quit IRC05:08
*** koolhead_ has joined #openstack-infra05:08
*** achanda has joined #openstack-infra05:09
*** hdd has joined #openstack-infra05:10
*** achanda has quit IRC05:11
*** koolhead17 has quit IRC05:11
*** achanda has joined #openstack-infra05:12
*** ddieterly has quit IRC05:13
*** vigneshvar has joined #openstack-infra05:15
*** stevemar has quit IRC05:16
*** achanda has quit IRC05:16
*** achanda has joined #openstack-infra05:16
*** nuritv has quit IRC05:17
*** dimtruck is now known as zz_dimtruck05:18
*** achanda has quit IRC05:18
*** nuritv has joined #openstack-infra05:19
*** ddieterly has joined #openstack-infra05:26
*** nuritv has quit IRC05:28
*** nikil has joined #openstack-infra05:30
*** ddieterly has quit IRC05:31
*** jyuso has quit IRC05:33
*** jyuso has joined #openstack-infra05:33
*** yaguang has quit IRC05:34
nikilhi i see that the project/branch/ref are taking from zuul and it written into env $workspace/test-evn.sh. Is there any way in devstack-gate to use specify branch/URL for only one particular project like neutron. That is it should fetch all projects from standard repo and only the neutron should fetch from our inernal repo for the CI05:36
*** nuritv has joined #openstack-infra05:37
*** nuritv has quit IRC05:38
*** yaguang has joined #openstack-infra05:43
*** yfried has quit IRC05:43
*** nuritv has joined #openstack-infra05:47
*** nuritv has quit IRC05:48
*** koolhead_ has quit IRC05:49
*** dannywilson has joined #openstack-infra05:49
*** nuritv has joined #openstack-infra05:51
*** nuritv has quit IRC05:52
*** penguinRaider has joined #openstack-infra05:53
*** nuritv has joined #openstack-infra05:55
*** hdd has quit IRC05:56
*** nuritv has quit IRC05:57
*** KanagarajM has quit IRC06:02
*** nuritv has joined #openstack-infra06:02
*** nuritv has quit IRC06:04
*** nuritv has joined #openstack-infra06:05
*** nuritv has quit IRC06:07
*** nuritv has joined #openstack-infra06:12
*** nuritv has quit IRC06:13
*** nuritv has joined #openstack-infra06:16
*** nuritv has quit IRC06:18
*** nuritv has joined #openstack-infra06:20
*** nuritv has quit IRC06:21
*** ddieterly has joined #openstack-infra06:26
*** Masahiro_ has joined #openstack-infra06:26
*** simonmcc has quit IRC06:26
*** jraim has quit IRC06:26
*** simonmcc_ has joined #openstack-infra06:26
*** jraim_ has joined #openstack-infra06:26
*** nuritv has joined #openstack-infra06:27
*** Masahiro has quit IRC06:28
*** jamespage has quit IRC06:28
*** nuritv has quit IRC06:29
*** ddieterly has quit IRC06:31
*** nuritv has joined #openstack-infra06:35
*** nuritv has quit IRC06:37
openstackgerritColleen Murphy proposed openstack-infra/project-config: Run acceptance tests without rake  https://review.openstack.org/14172806:38
*** nuritv has joined #openstack-infra06:40
crinklenibalizer: ^06:41
*** nuritv has quit IRC06:42
*** imcsk8 has quit IRC06:42
*** imcsk8 has joined #openstack-infra06:43
*** nuritv has joined #openstack-infra06:44
*** nuritv has quit IRC06:45
* nibalizer looks06:46
*** nuritv has joined #openstack-infra06:48
*** nuritv has quit IRC06:49
*** koolhead17 has joined #openstack-infra06:51
*** otter768 has joined #openstack-infra06:52
*** ddieterly has joined #openstack-infra06:53
*** nuritv has joined #openstack-infra06:54
*** penguinRaider has quit IRC06:55
*** Longgeek has joined #openstack-infra06:56
*** mrunge has joined #openstack-infra06:56
*** nuritv has quit IRC06:56
nikilhi can some one explain me when pre_test_hook, post_test_hook and gate_hook function executes ?06:57
*** otter768 has quit IRC06:57
*** ddieterly has quit IRC06:57
*** nuritv has joined #openstack-infra06:58
*** nuritv has quit IRC07:00
*** vigneshvar has quit IRC07:01
*** yfried has joined #openstack-infra07:04
zhiyanhi folks, i'm interested in what's the cause of this kind of wired issue http://logs.openstack.org/22/141722/1/check//gate-glance-python27/feece60/console.html#_2014-12-15_06_12_51_737 ... the version rang is not wrong but ..07:04
*** nuritv has joined #openstack-infra07:05
*** nuritv has quit IRC07:06
*** nuritv has joined #openstack-infra07:13
*** nuritv has quit IRC07:15
*** teran has quit IRC07:15
*** nuritv has joined #openstack-infra07:18
*** vigneshvar has joined #openstack-infra07:20
*** nuritv has quit IRC07:21
wuhghi ,all,  how can i get build history of https://jenkins.openstack.org/view/All/job/gate-horizon-dsvm-integration/07:21
*** penguinRaider has joined #openstack-infra07:23
*** dannywilson has quit IRC07:23
*** nuritv has joined #openstack-infra07:24
*** nuritv has quit IRC07:26
*** Longgeek has quit IRC07:26
*** skraynev has joined #openstack-infra07:26
*** nuritv has joined #openstack-infra07:27
*** _nadya_ has joined #openstack-infra07:27
*** nuritv has quit IRC07:28
*** nuritv has joined #openstack-infra07:34
*** Longgeek has joined #openstack-infra07:34
*** nuritv has quit IRC07:35
*** skraynev has quit IRC07:36
*** zhiwei has left #openstack-infra07:37
*** skraynev has joined #openstack-infra07:38
*** _nadya_ has quit IRC07:38
*** skraynev_ has joined #openstack-infra07:38
*** skraynev_ has quit IRC07:38
*** unicell has quit IRC07:39
*** nuritv has joined #openstack-infra07:39
*** nuritv has quit IRC07:41
*** Longgeek has quit IRC07:41
*** nuritv has joined #openstack-infra07:42
*** Longgeek has joined #openstack-infra07:42
*** jgallard_ has joined #openstack-infra07:43
*** nuritv has quit IRC07:44
*** unicell has joined #openstack-infra07:45
*** nuritv has joined #openstack-infra07:48
*** ala_ has joined #openstack-infra07:49
*** nuritv has quit IRC07:50
*** Longgeek has quit IRC07:50
*** Longgeek has joined #openstack-infra07:52
*** nuritv has joined #openstack-infra07:52
*** teran has joined #openstack-infra07:53
*** nuritv has quit IRC07:54
*** jamespage has joined #openstack-infra07:55
*** jamespage has joined #openstack-infra07:55
*** nuritv has joined #openstack-infra07:55
*** nuritv has quit IRC07:57
*** dhp has quit IRC08:00
*** nuritv has joined #openstack-infra08:01
*** nuritv has quit IRC08:03
*** jpich has joined #openstack-infra08:04
*** HeOS has quit IRC08:05
*** nuritv has joined #openstack-infra08:07
*** dhp has joined #openstack-infra08:07
*** willroberts_ has quit IRC08:07
*** nuritv has quit IRC08:08
*** willroberts_ has joined #openstack-infra08:09
*** nuritv has joined #openstack-infra08:11
*** jpich has quit IRC08:11
*** che-arne has joined #openstack-infra08:11
*** che-arn4 has joined #openstack-infra08:11
*** nuritv has quit IRC08:12
*** che-arn4 has quit IRC08:12
*** jpich has joined #openstack-infra08:13
*** nuritv has joined #openstack-infra08:13
*** mrunge has quit IRC08:14
*** dhp has quit IRC08:15
*** nuritv has quit IRC08:15
*** markus_z has joined #openstack-infra08:15
*** salv-orlando has joined #openstack-infra08:16
*** markus_z has quit IRC08:16
*** sabari is now known as zz_sabari08:17
*** nuritv has joined #openstack-infra08:19
*** nuritv has quit IRC08:20
*** miqui_ has quit IRC08:22
*** ivar-lazzaro has joined #openstack-infra08:22
*** nuritv has joined #openstack-infra08:22
*** zz_sabari is now known as sabari08:23
*** kashyap` is now known as kashyap08:24
*** nuritv has quit IRC08:24
*** k4n0 has joined #openstack-infra08:25
*** doude has joined #openstack-infra08:26
*** rlandy has joined #openstack-infra08:26
*** mpaolino has joined #openstack-infra08:26
*** ivar-lazzaro has quit IRC08:27
*** nuritv has joined #openstack-infra08:27
*** vigneshvar_ has joined #openstack-infra08:29
*** achuprin_ has quit IRC08:29
*** nuritv has quit IRC08:29
*** jcoufal has joined #openstack-infra08:31
*** nuritv has joined #openstack-infra08:32
*** SumitNaiksatam has quit IRC08:32
*** vigneshvar has quit IRC08:32
*** SumitNaiksatam has joined #openstack-infra08:33
*** nuritv has quit IRC08:34
*** mpaolino has quit IRC08:35
*** nuritv has joined #openstack-infra08:37
*** mpaolino has joined #openstack-infra08:38
*** nuritv has quit IRC08:39
*** jlibosva has joined #openstack-infra08:40
*** nuritv has joined #openstack-infra08:41
*** achuprin_ has joined #openstack-infra08:42
*** nuritv has quit IRC08:43
*** zz_avozza is now known as avozza08:44
*** skraynev has left #openstack-infra08:45
*** nuritv has joined #openstack-infra08:47
*** salv-orlando has quit IRC08:48
*** nuritv has quit IRC08:49
*** luqas has quit IRC08:50
*** nuritv has joined #openstack-infra08:53
*** otter768 has joined #openstack-infra08:53
*** pblaho has joined #openstack-infra08:53
*** nuritv has quit IRC08:55
*** luqas has joined #openstack-infra08:56
*** sabari is now known as zz_sabari08:57
*** otter768 has quit IRC08:58
*** nuritv has joined #openstack-infra08:58
*** jlibosva has quit IRC08:58
*** nuritv has quit IRC09:00
*** jlibosva has joined #openstack-infra09:00
*** subscope has joined #openstack-infra09:00
*** e0ne has joined #openstack-infra09:01
*** nuritv has joined #openstack-infra09:02
*** nuritv has quit IRC09:03
*** e0ne has quit IRC09:07
*** skraynev has joined #openstack-infra09:07
*** skraynev has left #openstack-infra09:08
*** nuritv has joined #openstack-infra09:09
*** viktors|afk is now known as viktors09:10
*** BobBall_AWOL is now known as BobBall09:11
*** nuritv has quit IRC09:12
*** _nadya_ has joined #openstack-infra09:12
*** jlibosva has quit IRC09:12
*** andreykurilin has joined #openstack-infra09:13
*** jlibosva has joined #openstack-infra09:13
*** nuritv has joined #openstack-infra09:13
*** nuritv has quit IRC09:15
*** hashar has joined #openstack-infra09:15
*** derekh has joined #openstack-infra09:17
*** Guest60167 has joined #openstack-infra09:19
*** jedimike has joined #openstack-infra09:19
*** nuritv has joined #openstack-infra09:19
*** AJaeger has joined #openstack-infra09:20
*** AJaeger has quit IRC09:20
*** AJaeger has joined #openstack-infra09:20
*** MaxV has joined #openstack-infra09:20
*** nuritv has quit IRC09:21
*** nuritv has joined #openstack-infra09:23
*** nuritv has quit IRC09:25
*** HeOS has joined #openstack-infra09:26
*** nuritv has joined #openstack-infra09:27
*** doude has quit IRC09:28
*** doude has joined #openstack-infra09:29
*** dimsum__ has joined #openstack-infra09:29
*** nuritv has quit IRC09:29
*** ildikov has quit IRC09:30
*** jp_at_hp has joined #openstack-infra09:31
*** arxcruz has joined #openstack-infra09:32
*** yamamoto_ has quit IRC09:32
*** nuritv has joined #openstack-infra09:33
*** koolhead17 has quit IRC09:34
*** markvan has quit IRC09:34
*** dimsum__ has quit IRC09:34
*** markvan has joined #openstack-infra09:35
*** nuritv has quit IRC09:35
*** _nadya_ has quit IRC09:35
*** nuritv has joined #openstack-infra09:37
*** nuritv has quit IRC09:39
*** nuritv has joined #openstack-infra09:42
*** ildikov has joined #openstack-infra09:43
*** nuritv has quit IRC09:44
*** ildikov has quit IRC09:44
*** pblaho has quit IRC09:44
openstackgerrityolanda.robla proposed openstack-infra/infra-specs: Add nodepool disk image builder testing spec.  https://review.openstack.org/13959809:47
*** nuritv has joined #openstack-infra09:49
*** pelix has joined #openstack-infra09:50
*** e0ne has joined #openstack-infra09:51
*** nuritv has quit IRC09:52
*** yfried has quit IRC09:53
*** yfried has joined #openstack-infra09:53
*** yaguang has quit IRC09:54
*** nuritv has joined #openstack-infra09:54
*** andreykurilin has quit IRC09:55
*** nuritv has quit IRC09:56
*** Guest60167 has quit IRC09:57
*** nuritv has joined #openstack-infra09:58
*** yamamoto has joined #openstack-infra09:58
*** nuritv has quit IRC09:59
openstackgerrityolanda.robla proposed openstack-infra/infra-specs: Add nodepool image testing spec.  https://review.openstack.org/13959810:00
*** yolanda has joined #openstack-infra10:00
*** nuritv has joined #openstack-infra10:03
*** ildikov has joined #openstack-infra10:03
*** yamamoto has quit IRC10:04
*** nuritv has quit IRC10:05
*** belmoreira has joined #openstack-infra10:06
*** che-arne has quit IRC10:06
*** nuritv has joined #openstack-infra10:07
*** andreaf has joined #openstack-infra10:07
*** asettle has quit IRC10:08
*** Guest60167 has joined #openstack-infra10:09
*** nuritv has quit IRC10:09
*** nuritv has joined #openstack-infra10:15
*** avozza is now known as zz_avozza10:15
*** zz_avozza is now known as avozza10:16
*** nuritv has quit IRC10:16
*** avozza is now known as zz_avozza10:17
*** nuritv has joined #openstack-infra10:18
*** nuritv has quit IRC10:19
*** ihrachyshka has joined #openstack-infra10:20
*** nuritv has joined #openstack-infra10:22
*** nuritv has quit IRC10:24
*** mrunge has joined #openstack-infra10:24
*** asettle has joined #openstack-infra10:25
*** nuritv has joined #openstack-infra10:27
*** nuritv has quit IRC10:29
*** nuritv has joined #openstack-infra10:31
*** skolekonov has joined #openstack-infra10:32
*** skolekonov has quit IRC10:33
*** nuritv has quit IRC10:33
*** salv-orlando has joined #openstack-infra10:33
*** salv-orl_ has joined #openstack-infra10:34
*** salv-orlando has quit IRC10:34
*** yfried is now known as yfried|afk10:34
*** nuritv has joined #openstack-infra10:35
*** nuritv has quit IRC10:37
*** gema has quit IRC10:37
*** belmoreira has quit IRC10:39
*** skolekonov has joined #openstack-infra10:40
*** nuritv has joined #openstack-infra10:40
*** nuritv has quit IRC10:41
*** jp_at_hp has quit IRC10:43
*** nuritv has joined #openstack-infra10:45
*** Adri2000 has quit IRC10:45
*** nuritv has quit IRC10:46
*** jp_at_hp has joined #openstack-infra10:48
*** nuritv has joined #openstack-infra10:49
*** Adri2000 has joined #openstack-infra10:49
*** nuritv has quit IRC10:51
openstackgerritMike Heald proposed openstack-infra/infra-specs: Result set management and paging specification  https://review.openstack.org/13963810:53
*** nuritv has joined #openstack-infra10:54
*** unicell has quit IRC10:54
*** yfried|afk is now known as yfried10:54
*** otter768 has joined #openstack-infra10:54
*** nuritv has quit IRC10:56
*** liusheng has quit IRC10:56
*** liusheng has joined #openstack-infra10:57
*** nuritv has joined #openstack-infra10:58
*** ZZelle has quit IRC10:58
*** ZZelle has joined #openstack-infra10:58
*** jgallard_ has quit IRC10:58
*** otter768 has quit IRC10:59
*** nuritv has quit IRC11:00
*** nuritv has joined #openstack-infra11:01
*** aysyd has joined #openstack-infra11:02
*** nuritv has quit IRC11:03
openstackgerritThierry Carrez proposed openstack-infra/project-config: Introduce Oslo-specific stable-maint team  https://review.openstack.org/14176911:04
*** yamamoto has joined #openstack-infra11:05
*** nuritv has joined #openstack-infra11:07
*** nuritv has quit IRC11:08
*** asettle has quit IRC11:08
*** yamamoto has quit IRC11:10
*** pblaho has joined #openstack-infra11:10
*** nuritv has joined #openstack-infra11:11
*** jp_at_hp has quit IRC11:11
*** nuritv has quit IRC11:13
*** amuller has joined #openstack-infra11:13
*** nuritv has joined #openstack-infra11:15
*** nuritv has quit IRC11:17
*** zz_avozza is now known as avozza11:17
*** Guest60167 has quit IRC11:17
*** Masahiro_ has quit IRC11:17
*** _nadya_ has joined #openstack-infra11:18
*** nuritv has joined #openstack-infra11:20
*** mfink__ has quit IRC11:20
*** asettle has joined #openstack-infra11:21
*** nuritv has quit IRC11:22
*** jp_at_hp has joined #openstack-infra11:23
*** nuritv has joined #openstack-infra11:25
*** avozza is now known as zz_avozza11:27
*** nuritv has quit IRC11:27
*** nuritv has joined #openstack-infra11:30
*** fandi has quit IRC11:30
*** nuritv has quit IRC11:31
*** pc_m has joined #openstack-infra11:33
*** nuritv has joined #openstack-infra11:34
*** mpaolino has quit IRC11:35
*** nuritv has quit IRC11:36
*** mpaolino has joined #openstack-infra11:38
*** nuritv has joined #openstack-infra11:39
*** nuritv has quit IRC11:40
openstackgerrityolanda.robla proposed openstack-infra/storyboard: Return task count by status for a story dynamically  https://review.openstack.org/13910011:43
*** nuritv has joined #openstack-infra11:43
*** nuritv has quit IRC11:45
openstackgerrityolanda.robla proposed openstack-infra/storyboard: Return task count by status for a story dynamically  https://review.openstack.org/13910011:46
*** nuritv has joined #openstack-infra11:47
*** zz_avozza is now known as avozza11:48
*** nuritv has quit IRC11:49
*** nuritv has joined #openstack-infra11:51
openstackgerrityolanda.robla proposed openstack-infra/storyboard: Return task count by status for a story dynamically  https://review.openstack.org/13910011:52
*** nuritv has quit IRC11:52
*** nuritv has joined #openstack-infra11:53
rediskinhiyo! this already have +2, could someone please give +A to this very simple patch https://review.openstack.org/#/c/140296/11:54
*** nuritv has quit IRC11:55
*** adalbas has joined #openstack-infra11:57
*** _nadya_ has quit IRC11:58
*** gema has joined #openstack-infra11:58
*** nuritv has joined #openstack-infra11:59
*** avozza is now known as zz_avozza12:00
*** nuritv has quit IRC12:01
*** nuritv has joined #openstack-infra12:04
*** nuritv has quit IRC12:05
*** arxcruz has quit IRC12:06
*** nuritv has joined #openstack-infra12:08
*** nuritv has quit IRC12:10
*** penguinRaider has quit IRC12:11
*** nuritv has joined #openstack-infra12:12
*** _nadya_ has joined #openstack-infra12:14
*** nuritv has quit IRC12:14
*** arxcruz has joined #openstack-infra12:17
*** nuritv has joined #openstack-infra12:17
*** Masahiro has joined #openstack-infra12:18
*** nuritv has quit IRC12:19
*** nuritv has joined #openstack-infra12:21
*** Masahiro has quit IRC12:23
*** liusheng has quit IRC12:23
*** nuritv has quit IRC12:24
*** liusheng has joined #openstack-infra12:24
*** talluri has quit IRC12:26
*** nuritv has joined #openstack-infra12:27
*** nuritv has quit IRC12:28
*** jpich has quit IRC12:30
*** dimsum__ has joined #openstack-infra12:32
*** nuritv has joined #openstack-infra12:32
*** jpich has joined #openstack-infra12:33
*** hashar has quit IRC12:33
*** acruz_ has joined #openstack-infra12:33
*** acruz__ has joined #openstack-infra12:34
*** nuritv has quit IRC12:34
*** nuritv has joined #openstack-infra12:36
*** dimsum__ has quit IRC12:37
*** EmilienM is now known as EmilienM|afk12:37
*** mpaolino has quit IRC12:38
*** nuritv has quit IRC12:38
*** nuritv has joined #openstack-infra12:43
*** dpaterson has joined #openstack-infra12:43
*** nuritv has quit IRC12:44
*** jgallard_ has joined #openstack-infra12:45
*** nuritv has joined #openstack-infra12:46
*** zz_avozza is now known as avozza12:47
*** baoli has joined #openstack-infra12:48
*** nuritv has quit IRC12:48
*** baoli_ has joined #openstack-infra12:48
*** nuritv has joined #openstack-infra12:49
*** nuritv has quit IRC12:51
*** penguinRaider has joined #openstack-infra12:52
*** baoli has quit IRC12:52
*** baoli__ has joined #openstack-infra12:52
*** dimsum__ has joined #openstack-infra12:52
*** baoli_ has quit IRC12:53
*** nuritv has joined #openstack-infra12:54
*** baoli__ has quit IRC12:54
*** baoli has joined #openstack-infra12:55
*** otter768 has joined #openstack-infra12:55
*** nuritv has quit IRC12:56
*** yolanda has quit IRC12:56
*** e0ne has quit IRC12:57
*** e0ne has joined #openstack-infra12:57
*** mfink has joined #openstack-infra12:57
*** nuritv has joined #openstack-infra12:58
*** nuritv has quit IRC13:00
*** otter768 has quit IRC13:00
*** erlon has joined #openstack-infra13:01
*** nuritv has joined #openstack-infra13:01
*** andreaf has quit IRC13:02
*** nuritv has quit IRC13:03
*** salv-orl_ has quit IRC13:04
*** jcoufal_ has joined #openstack-infra13:05
*** tnovacik has joined #openstack-infra13:06
*** kgiusti has joined #openstack-infra13:06
*** dprince has joined #openstack-infra13:08
*** jcoufal has quit IRC13:08
*** mbacchi has joined #openstack-infra13:09
*** nuritv has joined #openstack-infra13:10
*** Hal has joined #openstack-infra13:11
*** Hal is now known as Guest4300713:11
*** Guest43007 has quit IRC13:12
*** Hal_ has joined #openstack-infra13:12
*** nuritv has quit IRC13:12
*** weshay has joined #openstack-infra13:13
*** nuritv has joined #openstack-infra13:14
*** nuritv has quit IRC13:16
*** EmilienM|afk is now known as EmilienM13:17
*** nuritv has joined #openstack-infra13:18
*** Masahiro has joined #openstack-infra13:19
*** nuritv has quit IRC13:20
*** yamamoto has joined #openstack-infra13:21
*** nuritv has joined #openstack-infra13:22
*** jp_at_hp has quit IRC13:22
*** ddieterly has joined #openstack-infra13:22
*** acruz__ has quit IRC13:23
*** mpaolino has joined #openstack-infra13:23
*** nuritv has quit IRC13:24
*** acruz_ has quit IRC13:24
*** Masahiro has quit IRC13:24
*** acruz_ has joined #openstack-infra13:24
*** koolhead17 has joined #openstack-infra13:24
*** bswartz has quit IRC13:25
*** acruz_ has quit IRC13:25
*** arxcruz has quit IRC13:25
*** nuritv has joined #openstack-infra13:26
*** arxcruz has joined #openstack-infra13:27
*** nuritv has quit IRC13:28
*** jistr has joined #openstack-infra13:28
*** arxcruz has quit IRC13:31
*** arxcruz has joined #openstack-infra13:31
*** mfink has quit IRC13:32
*** mfink has joined #openstack-infra13:33
*** nuritv has joined #openstack-infra13:34
*** jp_at_hp has joined #openstack-infra13:34
*** hashar has joined #openstack-infra13:35
*** nuritv has quit IRC13:35
*** jistr has quit IRC13:36
*** nuritv has joined #openstack-infra13:38
*** nuritv has quit IRC13:39
*** salv-orlando has joined #openstack-infra13:40
*** yamamoto has quit IRC13:40
*** yamamoto has joined #openstack-infra13:41
*** avozza is now known as zz_avozza13:41
*** nuritv has joined #openstack-infra13:41
*** andreaf has joined #openstack-infra13:42
*** nuritv has quit IRC13:43
*** _nadya_ has quit IRC13:44
*** nuritv has joined #openstack-infra13:47
*** nuritv has quit IRC13:48
*** dkranz has quit IRC13:48
*** dkranz has joined #openstack-infra13:49
*** unicell has joined #openstack-infra13:50
*** nuritv has joined #openstack-infra13:51
*** nuritv has quit IRC13:53
*** dizquierdo has joined #openstack-infra13:54
*** mugsie_ is now known as mugsie13:55
*** nuritv has joined #openstack-infra13:56
andreafhi - I'm seeing a weird dependency issue when running devstack - http://paste.openstack.org/show/151187/ - it seems that the version from novaclient (installed from git) cannot be matched against the version expected by openstackclient (also installed from git). Has anyone seen this before?13:56
*** nuritv has quit IRC13:57
sdagueandreaf: what run is this in?13:59
*** nuritv has joined #openstack-infra14:00
*** sabeen1 has joined #openstack-infra14:01
*** mattfarina has joined #openstack-infra14:01
*** pblaho has quit IRC14:01
*** pblaho has joined #openstack-infra14:01
*** nuritv has quit IRC14:02
*** yaguang has joined #openstack-infra14:02
*** dimsum__ is now known as dims14:02
*** bswartz has joined #openstack-infra14:03
*** lttrl has joined #openstack-infra14:04
AJaegerandreaf, that's a known issue with setuptools 8.0 that clarkb, dstufft and fungi worked on over the weekend.14:04
*** marcusvrn has quit IRC14:05
AJaegerandreaf, please recheck, I expect it's worked around now. If it still occurs, please tell us again.14:05
*** nuritv has joined #openstack-infra14:06
*** marcusvrn has joined #openstack-infra14:06
odyssey4memight it be this issue? https://bugs.launchpad.net/python-openstackclient/+bug/140267914:06
uvirtbotLaunchpad bug 1402679 in python-openstackclient "setuptools 8 breaks python-openstackclient" [Undecided,New]14:07
openstackgerrityolanda.robla proposed openstack-infra/storyboard: Return task count by status for a story dynamically  https://review.openstack.org/13910014:07
*** nuritv has quit IRC14:08
*** fandi has joined #openstack-infra14:10
*** _nadya_ has joined #openstack-infra14:10
*** mjturek has joined #openstack-infra14:10
*** nuritv has joined #openstack-infra14:11
*** mpaolino has quit IRC14:11
openstackgerritDmitry Teselkin proposed openstack-infra/zuul: Process event multiple times.  https://review.openstack.org/13602714:11
AJaegerodyssey4me, yeah, same problem. Read the discussion on this channel from Saturday especially.14:12
*** nuritv has quit IRC14:12
*** yolanda has joined #openstack-infra14:13
*** erikmwilson has joined #openstack-infra14:13
*** doug-fish has joined #openstack-infra14:13
AJaegerodyssey4me, There's a new version of pbr out since yesterday that will handle this.14:13
*** nuritv has joined #openstack-infra14:14
AJaegerandreaf, sdague, odyssey4me: pep440 changes, basically the get versions like python-glanceclient 0.14.2.2.gb126351 are not pep440 compliant.14:14
*** dkliban has joined #openstack-infra14:14
AJaegerand thus setuptools 8 will have this version tuple: (-1, 0, 14, 2,2,...) for it - and thus 0.14.2.2.gb12... is less than 0.0 ;(14:15
odyssey4meAJaeger: thanks for the pointer - will check on that.14:15
AJaegerUsing "0.14.2.2+gb..." fixes this14:15
AJaegerand pbr 0.10.2 contains a fix.14:15
*** nuritv has quit IRC14:16
AJaeger.. to use "+" instead "." in that place14:16
*** erikmwilson has joined #openstack-infra14:16
*** dizquierdo has quit IRC14:16
fungiAJaeger: odyssey4me: actually it doesn't. we emergency released that as 0.10.1 but then reverted it immediately and released 0.10.2 without it, because it turns out that setuptools is unable to parse requirement file entries containing a +14:17
odyssey4meAJaeger: I just tested using pbr 0.10.2 and setuptools 8.0.2 and it doesn't work14:17
fungiright now we have setuptools pinned <8 in our tests14:17
fungiandreaf: sdague: ^14:18
odyssey4methanks fungi - we'll do the same for now until a fix is identified14:19
fungithere's another proposed workaround to get rid of the git sha in pbr version strings entirely and move them into egg info metadata14:19
sdaguefungi: so that does mean however that all deployed users that get a setuptools upgrade are broken, right?14:19
*** julim has joined #openstack-infra14:19
fungisdague: yes, setuptools 8 is currently operating in a non-backward-compatible fashion14:20
*** nuritv has joined #openstack-infra14:20
fungiand also there was some talk of loosening the pep 440 normalization in another setuptools point release to allow arbitrary alphanumeric string subcomponents14:20
fungiwhich would be another way out of this14:20
*** nuritv has quit IRC14:21
fungisdague: keep in mind this specific issue should only surface when trying to pip-install from non-released source and then require newer than the released version in your dependencies14:22
fungiwhich unfortunately we do in our test infrastructure14:22
fungithe setuptools pin was to allow us more time to figure out a way forward between pbr and setuptools/pip developers14:23
*** aysyd has quit IRC14:23
clarkbalso oslo.db14:24
openstackgerritMike Heald proposed openstack-infra/infra-specs: Proposal for a 'fail-fast' option on jobs  https://review.openstack.org/12925514:24
clarkbwe should fix the sqlalchemy requirement there asap14:24
fungioh, has that not merged yet?14:24
fungicrap14:24
*** nuritv has joined #openstack-infra14:24
clarkbmaster needs a release14:24
sdaguefungi: actually, I thought it was the opposite14:24
clarkbjuno needs merging14:24
sdagueclarkb: which repo?14:25
clarkboslo.db14:25
*** sdake has quit IRC14:25
sdagueah14:25
fungiahh, that's why i was confused. forgot about the backport14:25
jd__can someone validate https://review.openstack.org/#/c/140343/ because I think it's blocking the tooz gate for over a week :(14:25
AJaegerfungi, ah, I didn't read all of the history. Thanks for the explanation!14:25
*** zz_avozza is now known as avozza14:25
*** vigneshvar_ has quit IRC14:25
fungiAJaeger: yeah, it was a lot of stabbing in the dark for a good chunk of the weekend to figure out a way forward14:26
clarkboslo.db as released uses a version requirement string that new setuptools explodes on14:26
clarkbso need to release new versions that dont14:26
*** nuritv has quit IRC14:26
fungii take it that was the only project we found still using that multi-range pattern?14:26
AJaegerfungi, clarkb: Could either of you write a summary mail to openstack-dev before more people ask, please?14:27
clarkbno a lot do but most have it overridden14:27
fungii think we had been doing something similar for hacking transitions for a while, which well need to stop doing14:27
*** aysyd has joined #openstack-infra14:27
*** dkliban has quit IRC14:27
sdaguehey, question14:27
clarkbso are less important in the fix now category. but with a pin it may not matter anyway14:27
sdaguewhere is az3.clouds.archive.ubuntu.com coming from?14:27
sdaguein devstack runs14:27
*** dustins has joined #openstack-infra14:27
*** dkliban has joined #openstack-infra14:27
sdagueis that a mirror we set explicitly?14:27
clarkbsdague no thats hpcloud base image14:28
* fungi loves that hpcloud gets packages from amazon's cloud14:28
*** dizquierdo has joined #openstack-infra14:28
AJaegerrol14:28
sdagueso all the failures on apt fetch failures seem to be to that host14:28
fungii'll start drafting a setuptools redux/sotu in etherpad and others can jump in and correct any misstatements14:29
AJaegersdague, could you review ACL normalization patch - just "cosmetics", please: https://review.openstack.org/#/c/140822/14:29
*** nuritv has joined #openstack-infra14:29
clarkbAJaeger while a summary should be written that wont stop the asking :)14:29
fungidraft will be in https://etherpad.openstack.org/p/hFwpOHmMWX shortly14:29
AJaegerclarkb, yeah but it will avoid that I give wrong answers ;(14:30
sdagueare we should that's actually an amazon server?14:30
*** nuritv has quit IRC14:31
AJaegerthanks, sdague !14:31
sdagueclarkb: do you know which file it's in? I'd like to try changing the mirror location and see if it helps14:31
clarkb/etc/apt/sources.list?14:32
fungisdague: actually i guess it's not necessarily in amazon. seems to just be a dns round-robin between a bunch of canonical's ip addresses14:32
sdaguefungi: yeh14:32
sdagueclarkb: it might be there, or they might have put it in a .d/ file14:33
sdaguemostly I wanted a live example to know14:33
Guest91362have any of you looked into translating the infra manual?14:33
Guest91362erg14:33
*** Guest91362 is now known as annegentle14:33
openstackgerritNikita Konovalov proposed openstack-infra/python-storyboardclient: Setting up base classes  https://review.openstack.org/13809214:33
annegentleI just noticed that there's a translated version of GerritWorkflow14:34
sdaguebecause on every run which failed against az3, the rax mirrors actually seemed to work correctly14:34
*** nuritv has joined #openstack-infra14:34
clarkbthey are different mirrors14:36
sdagueclarkb: right, I know14:36
openstackgerritDmitry Teselkin proposed openstack-infra/zuul: Process event multiple times.  https://review.openstack.org/13602714:36
sdaguebut the point being, we actually have a mirror check bit in d-g14:36
sdaguewhich checks connectivity to rax mirrors on each run14:36
*** nuritv has quit IRC14:36
openstackgerritMerged openstack-infra/devstack-gate: Give a more specific error message when giving up in git_remote_update  https://review.openstack.org/13565614:36
*** dizquierdo has quit IRC14:36
openstackgerritMerged openstack-infra/project-config: Normalize Gerrit ACLs  https://review.openstack.org/14082214:36
sdaguewhich is passing when az3 connections fail14:37
andreafAJaeger, fungi, sdague: thanks ^^^14:39
*** nuritv has joined #openstack-infra14:39
*** alaski_ is now known as alaski14:39
*** mriedem has joined #openstack-infra14:39
*** eharney has joined #openstack-infra14:41
*** eharney has quit IRC14:41
*** eharney has joined #openstack-infra14:41
*** nuritv has quit IRC14:41
*** sdake has joined #openstack-infra14:41
fungisdague: it's hit and miss though. a few months back the rackspace package mirrors were regularly unusable14:42
fungithey seem to trade places as to who's broken when14:42
*** achanda has joined #openstack-infra14:42
*** nuritv has joined #openstack-infra14:43
fungiclarkb: do we have any open lp bugs or sb tasks for any of the setuptools 8 stuff? mostly looking for good examples of the two classes of related failures14:43
*** nikil has quit IRC14:43
*** nuritv has quit IRC14:44
clarkbfungi for the first its the sqlalchemy issue second is pbr gitsha114:44
*** _nadya_ has quit IRC14:45
AJaegerfungi, odyssey4me mentioned https://bugs.launchpad.net/python-openstackclient/+bug/140267914:45
uvirtbotLaunchpad bug 1402679 in python-openstackclient "setuptools 8 breaks python-openstackclient" [Undecided,New]14:45
fungiclarkb: right, i was looking for the error messages and tracebacks we were getting, but maybe that level of detail is unnecessary14:45
clarkband there is that bug on openstackclient. I was going to file a bug on setuptools then realized this was intentional14:45
sdaguefungi: sure14:46
clarkbfungi ya ruhe had links on saturday14:46
*** bnemec has joined #openstack-infra14:46
fungion second thought, i'll just wave hands vigorously and omit examples for now14:46
ttxclarkb, fungi: Blocked on Swift 2.2.1.rc1 release due to the issue I posted on the -infra ML14:47
clarkbpart of the issue is thia manifests not just in setuptools errorz eg ^14:47
clarkband heat template thing breaking and glance image uploads failing14:48
clarkbttx yes known issue with setuptools release14:48
*** dizquierdo has joined #openstack-infra14:48
clarkbyou are likely not going to want to use 'rc' anymore14:48
openstackgerritDavanum Srinivas (dims) proposed openstack-infra/project-config: move oslo.version to attic  https://review.openstack.org/14181214:48
*** sdake has quit IRC14:49
ttxclarkb: ok, cool (or not)14:49
fungittx: pep 440 is the future, and the future is now14:49
clarkbttx we can make an sdist with older setuptools for this release though14:49
clarkbmaybe14:49
*** nuritv has joined #openstack-infra14:49
annegentlettx: one other idea on the cross-project current states, is to add it to the cross-project meeting?14:49
ttxclarkb: that would be cool. I only need one14:49
annegentlettx: I could do a short report this week on docs14:50
ttxannegentle: that would work for me, but the agenda is already a bit heavy for this week14:50
annegentlettx: really I just want to find out more from everyone14:50
ttxannegentle: we can try to squeeze it14:50
*** signed8bit has joined #openstack-infra14:50
*** wenlock has joined #openstack-infra14:50
annegentlettx: yeah I'm looking at the agenda now, the types of things I'm asking about are going to play into the "reform spec" line14:50
annegentlettx: so I don't want to overload14:50
*** spzala has joined #openstack-infra14:51
*** nuritv has quit IRC14:51
annegentlettx: and this is informal, also, sort of a "commiseration" session14:51
ttxclarkb: I need a swift rc1 today, next time I need some RC tag should be end of January, so gives us time to discuss what the future is14:51
clarkbttx and you just need an sdist?14:51
ttxclarkb: yes, a swift-tarball job14:52
clarkbproblem is we should be careful whereever possible to be compat with new setuptools14:52
ttxclarkb: so sdist + upload14:52
ttx(to tarballs.o.o/swift)14:52
clarkbso I dont just want to do a thing and have it not work sincs we already had enough of that tjis weekend14:52
clarkbbut rc should be normalized14:53
ttxclarkb: alternative is to delete tag and push one that would be PEP440 futureproof instead14:53
clarkboh I bet it spat out a normalized sdist name14:53
ttxI just need tag to match tarball14:53
*** nuritv has joined #openstack-infra14:54
clarkbwhich failed to upload because the name was wrong14:54
ttxit spit out a 2.2.1c114:54
clarkbya14:54
clarkbwoo14:54
clarkbso normalization is more aggressive than I hoped14:55
ttxit was uploaded alright, I just don't want to have a tag that says 2.2.1.rc1 and a tarball that says 2.2.1c114:55
clarkbyup14:55
*** rkukura has quit IRC14:55
*** nuritv has quit IRC14:55
* ttx goes to read that crazy spec that can't handle rcs14:55
clarkbI think in that case it is ok to rebuild with old setuptools14:56
*** otter768 has joined #openstack-infra14:56
*** stevemar has joined #openstack-infra14:56
clarkbfungi ^ make sense ?14:56
ttxclarkb: yes, final should be 2.2.1 and all happy14:56
fungiwow14:57
*** ddieterly has quit IRC14:57
clarkbalso ^ breaks our ability to use dstuffts suggestion for trailing alphas14:57
clarkbso that is a nonstarter imo14:57
*** nuritv has joined #openstack-infra14:57
fungiso setuptools normalization is causing pbr to rewrite the version numbers generated when building an sdist14:57
ttxhmm, looks like c1 is the way of the future. I have seen the future, and it's ugly and not-self-explaniing.14:57
clarkbfungi well pbr says X and setuptools says X'14:58
fungif(x)14:58
* fungi nods14:58
ttxweeird... the spec is pretty accepting of 'rc' as an equivalent of 'c'14:59
fungiyeah i think regenerating the sdist with setuptools 7.x should be okay for now14:59
*** nuritv has quit IRC14:59
*** Sincler has joined #openstack-infra14:59
clarkbhrm sdist build is in a tox venv though how did swift use ltest setuptools?14:59
fungittx: it accepts it in a version match, but doesn't emit it and i think pbr is letting setuptools decide what the version number should be when making the sdist15:00
fungimordred: ^ new wrinkle15:00
clarkbrc is normalized to c15:00
ttxfungi: yeah. That's why we get the nice warning, followed by a quick kick in the nuts15:00
clarkbI think setuptools does that normalization whenever it does its thing15:00
clarkbtldr welcome to the new world order15:00
*** otter768 has quit IRC15:00
clarkbbefore we rebuild though we should figure out how sdist building used latest setuptools in the first place15:01
fungiso anyway, i'm guessing either that tag was pushed before we had setuptools pinning in place, or the pin isn't working for tarball jobs15:01
*** rkukura has joined #openstack-infra15:01
ttxclarkb: if retriggering swift-tarball to get a rc1 tarball is too awkward, we can probably push 2.2.1c1 instead... I'd just need you to delete the 2.2.1.rc1 tag from swift git repo15:02
*** avozza is now known as zz_avozza15:02
*** nuritv has joined #openstack-infra15:02
clarkbttx well it used tox to build which should use old setuptools15:02
clarkbso I dont understand how this failed yet. and need to if a rebuild is going to work15:03
*** sdake has joined #openstack-infra15:03
clarkbfungi except its tox15:03
clarkbso should be unrelated to pinning15:03
clarkbunless15:03
clarkbdoes swift allow site packages?15:03
*** nuritv has quit IRC15:04
ttxsounds like a rhetorical question15:04
clarkbI dont think they do. so how did this fail?15:05
fungiclarkb: any chance something was installed into the virtualenv with -U and there was a gratuitous dependency on setuptools somewhere?15:05
clarkboh maybe there is a -U15:05
*** dmsimard_away is now known as dmsimard15:06
clarkbso a rebuild likely wont fix :/15:06
clarkbit will just update and get back on the pep440 party train15:06
*** sdake has quit IRC15:07
*** nelsnelson has joined #openstack-infra15:07
*** sdake has joined #openstack-infra15:07
openstackgerritomri marcovitch proposed openstack-infra/system-config: Add Third Party FAQ paragraph  https://review.openstack.org/14181715:08
*** dangers_away has quit IRC15:09
*** ihrachyshka has quit IRC15:09
*** nuritv has joined #openstack-infra15:09
openstackgerritomri marcovitch proposed openstack-infra/system-config: Add Third Party FAQ paragraph  https://review.openstack.org/14181715:10
*** dangers_away has joined #openstack-infra15:10
*** superdan is now known as dansmith15:10
*** nuritv has quit IRC15:11
*** bknudson has quit IRC15:11
*** ihrachyshka has joined #openstack-infra15:12
*** esker has joined #openstack-infra15:14
*** nuritv has joined #openstack-infra15:14
fungiclarkb: sdague: okay, rough stab at a message to the dev ml at https://etherpad.openstack.org/p/hFwpOHmMWX15:15
fungiplease hack that up as necessary15:15
*** nuritv has quit IRC15:16
clarkblgtm15:17
openstackgerritMerged openstack-infra/devstack-gate: Add tooz in project list  https://review.openstack.org/14034315:17
*** bknudson has joined #openstack-infra15:18
clarkbwow that was fast15:18
clarkbfungi so for the swift thing you think new tag too?15:18
*** nuritv has joined #openstack-infra15:19
fungiclarkb: did you determine if there was an install -U happening in there?15:19
* fungi finds the log15:20
clarkbthere is a -U in the tox.ini install command. I did not confidm if that is forcing setuptools to update (it is still really early here)15:20
clarkbfungi ttx put a link in his email15:20
fungioh, i haven't gotten to e-mail yet15:20
fungiirc seemed to be on fire15:20
*** nuritv has quit IRC15:20
ttxfungi: -infra ml15:22
*** nuritv has joined #openstack-infra15:23
*** zz_dimtruck is now known as dimtruck15:23
*** salv-orlando has quit IRC15:23
*** nuritv has quit IRC15:24
*** nuritv has joined #openstack-infra15:26
*** liusheng has quit IRC15:26
*** _nadya_ has joined #openstack-infra15:26
*** liusheng has joined #openstack-infra15:27
*** wenlock has quit IRC15:27
*** nuritv has quit IRC15:27
fungiwe should probably start archiving the tox logs from things like tarball jobs too15:30
fungier, tox's pip logs15:30
*** timcline has joined #openstack-infra15:30
*** annegent_ has joined #openstack-infra15:31
*** timcline has quit IRC15:31
*** timcline has joined #openstack-infra15:31
*** nuritv has joined #openstack-infra15:32
openstackgerritomri marcovitch proposed openstack-infra/system-config: Add Third Party FAQ paragraph  https://review.openstack.org/14181715:32
*** teran has quit IRC15:32
openstackgerritMerged openstack-infra/project-config: Introduce Oslo-specific stable-maint team  https://review.openstack.org/14176915:33
*** viktors has left #openstack-infra15:33
fungii'll get the group for that ^ fixed up shortly15:33
*** teran has joined #openstack-infra15:33
*** nuritv has quit IRC15:34
*** teran_ has joined #openstack-infra15:34
clarkbI guess I can ru  that locally and checj tox log15:35
fungiyeah, the console log is silent about virtualenv setup15:36
*** erikmwilson has quit IRC15:37
*** jerryz has quit IRC15:37
*** nuritv has joined #openstack-infra15:37
anteayathere is a patch up to add more logs to swift: https://review.openstack.org/#/c/141668/ what is the feedback so far on logs in swift?15:37
anteayamore is good?15:37
*** erikmwilson has joined #openstack-infra15:38
openstackgerritJulien Danjou proposed openstack/requirements: pymemcache and sysv_ipc for tooz  https://review.openstack.org/14092015:38
clarkbanteaya yes wanted to test it on devstack volume of logs and those jobs shoild only run on dg changes15:38
*** achuprin_ has quit IRC15:38
anteayaokay so +A would make us happy then15:38
*** nuritv has quit IRC15:38
*** teran has quit IRC15:38
anteayajust wanted to confirm15:38
*** liusheng has quit IRC15:38
*** liusheng has joined #openstack-infra15:39
anteayaboo, I have a nit about the name15:40
clarkbanteaya: name?15:40
anteayaunderscores and a hyphen in the new name :(15:40
anteayazuul_swift_devstack-logs15:40
*** cdent has joined #openstack-infra15:41
openstackgerritDavanum Srinivas (dims) proposed openstack-infra/project-config: move oslo.version to attic  https://review.openstack.org/14181215:42
clarkbok I reproduced locally. Now to read logs15:42
fungiif nobody else has any additional corrections/suggestions/detail for https://etherpad.openstack.org/p/hFwpOHmMWX i'll send it to the dev ml in about 15 minutes15:43
clarkbfungi: confirmed that tox is installing 8.0.2 into the venv so a rebuild won't help unless we hobble its env a bit more15:44
anteayafungi: I have read it, I have nothing to add15:44
*** nuritv has joined #openstack-infra15:44
clarkbsend it15:44
clarkbfungi: ttx: I think that means simplest thing is a new tag15:44
*** amitgandhinz has joined #openstack-infra15:44
*** e0ne_ has joined #openstack-infra15:44
fungire-tag 1.2.3.rc1 as 1.2.3c1?15:45
clarkbfungi: ya, then the tag version and sdist version will match each other15:45
*** erikwilson has joined #openstack-infra15:45
*** erikmwilson has quit IRC15:45
clarkbwhich seems to be ttx's biggest concern15:46
*** nuritv has quit IRC15:46
*** erikwilson is now known as erikmwilson15:46
ttxclarkb: well, I have to patch all my scripts too but I can survive that15:46
*** wenlock has joined #openstack-infra15:47
*** e0ne has quit IRC15:47
ttxif you guys remove the 2.2.1.rc1 tag I can retag 2.2.1c115:47
fungittx: any reason not to just have both tags on that commit?15:47
* anteaya wonders if this is a case for y'all?15:47
*** nuritv has joined #openstack-infra15:48
ttxfungi: none except noise and potential confusion15:48
*** tonytan4ever has joined #openstack-infra15:48
fungii can push a null string to the old tag if you really want, though people/systems which have updated their remotes likely will have that old tag indefinitely cached15:48
clarkbdhellmann: before I go wanted ot make sure you saw that oslo.db could use a new release to help alleviate some of the new setuptools issues. Short story is the requirement on sqlalchemy in the current release is not parsed properly by setuptools15:48
fungisince tag removals don't convey on remote update15:48
fungi(though it will propagate to our replicas)15:48
*** mjturek has quit IRC15:48
clarkbdhellmann: the issue has been fixed on master but we consume it via releases in much of the testing now so a release would be awesome (similar thing likely needs to be done forthe stable/juno branch)15:49
dhellmannclarkb: I've had that reported. I am about to go into the oslo team meeting, and haven't had time to look carefully at what we'd be releasing, but we'll be addressing it after the meeting15:49
clarkbdhellmann: perfect. thank you15:49
*** nuritv has quit IRC15:49
ttxfungi: will existing http://tarballs.openstack.org/swift/swift-2.2.1c1.* be overwritten ? Should be a straight scp so ok, right ?15:49
dhellmannI know glance is blocked, but I don't want to break things worse by rushing out a relase15:50
fungittx: yes, it will get overwritten15:50
clarkbdhellmann: well at least as an upstream we should be fine with our pinning of setuptools15:50
ttxfungi: I guess I can already push the c1 tag15:50
dhellmannclarkb: so this problem was triggered by the setuptools release?15:50
clarkbdhellmann: so glance should be able to do things. HOwever anyone that hasn't pinned setuptools will need it and eventually we would like to remove the setuptools pin15:50
dhellmannsure, of course15:50
clarkbdhellmann: yes setuptools 8.0 broke the world in about 3 different ways15:51
*** radez_g0n3 is now known as radez15:51
clarkbdhellmann: the sqlalchemy thing is one of them :)15:51
fungittx: yep, and we can retrigger jobs for that new pep 440 normalized tag name if we find other subsequent issues15:51
*** nuritv has joined #openstack-infra15:51
openstackgerritMerged stackforge/python-jenkins: Fix it so build_job triggers a build  https://review.openstack.org/12246215:51
dhellmannclarkb: Are we talking to them about helping with testing or anything?15:52
*** bnemec has quit IRC15:52
clarkbdhellmann: we have spoken with dstufft at lenght. Basically pep440 got approved and is now implemented for better or worse15:52
*** salv-orlando has joined #openstack-infra15:52
* dhellmann adds pep440 to his reading list15:52
*** nuritv has quit IRC15:53
clarkbmordred has a change to pbr too that will be helpful (it drops git sha info from versions and puts it in egg info metadata)15:53
*** dizquierdo has quit IRC15:53
dhellmannok, I'll keep an eye out for that, too15:53
ttxfungi: so you'd rather keep the rc1 tag in the tree for everyone to sync ?15:53
clarkbI should write a quick patch to our pre release acceptance regex to reject all the stuff that gets normalized too15:53
ttx2.2.1c1 pushed15:53
*** che-arne has joined #openstack-infra15:55
fungittx: well, it's not so much that i'd rather keep it around or not. i can see an argument that having both tag names on that same commit makes it more obvious we changed the tag naming pattern at that point15:55
mriedemdevstack/tempest vm's are 8GB RAM / 8 VCPU, but how much disk is allocated to those VMs?15:55
*** wenlock has left #openstack-infra15:55
clarkbmriedem: it depends on cloud provider. its something like 80GB on rax and 200GB on hpcloud iirc15:55
ttxalrighty then15:55
ttxwelcome to the future15:55
*** bnemec has joined #openstack-infra15:55
mriedemclarkb: wow, that seems huge15:55
fungittx: but i'm happy to delete it if you want it gone for cleanliness, just be aware that it will still be indefinitely cached in some places15:55
openstackgerritJan Klare proposed openstack-infra/project-config: Added gate-{name}-chef-rake job-template  https://review.openstack.org/13713415:55
ttxfungi: I'll let notmyname decide15:56
fungisounds like a good plan15:56
*** nuritv has joined #openstack-infra15:56
mriedemclarkb: i guess it probably has to be big for grenade and the large cinder volumes created by devstack?15:56
*** wenlock has joined #openstack-infra15:56
clarkbmriedem: ya I think we give at least 24GB to cinder alone15:56
mriedemclarkb: ok. we were still doing 10GB cinder volume in our internal CI, but we're not running the same number of tests (or grenade for that matter)15:57
*** nuritv has quit IRC15:58
mtreinishmriedem: grenade doesn't use as much volume storage (less tests) the 24GB is probably overkill TBH, we should be able to get away with less15:58
mriedembut 200GB, wow15:58
mriedemper VM15:58
mriedemwith up to max ~800 VMs?15:58
mtreinishmriedem: that's just because the hp flavor is big15:58
*** amotoki has joined #openstack-infra15:58
mtreinishit also has like 30GB of ram iirc15:58
mriedemmtreinish: oh i thought they were 8GB RAM/8 VCPU pretty standard15:59
mriedemor is that just min?15:59
mtreinishmriedem: it's 8GB because of a kernel param15:59
*** bnemec has quit IRC15:59
*** mjturek has joined #openstack-infra15:59
mtreinishthat flavor was the only hp one with 8 vcpus to match rax nodes15:59
clarkbmtreinish: yup 30GB of ram artificially limited to 8GB15:59
clarkbmtreinish: well more importantly it was the smallest flavor that had us doing reasonable tempest run times16:00
*** bnemec has joined #openstack-infra16:00
*** nuritv has joined #openstack-infra16:00
*** mjturek has quit IRC16:00
*** mjturek has joined #openstack-infra16:01
fungiright, any smaller than that and hpcloud instances were way slower than rackspace, so it was an effort to get their test durations into the same ballpark16:01
anteayaomrim: collecting more information is what the third party meetings are for16:01
*** nuritv has quit IRC16:02
openstackgerritClark Boylan proposed openstack-infra/project-config: Make prerelease and release pipelines match pep440  https://review.openstack.org/14183116:02
clarkbfungi: ttx ^16:02
krotscheckStoryboard meeting in #openstack-meeting-316:03
clarkbI used the normalized form grammar to base that on16:03
omrimanteaya: Sure, I just thought that it will be helpful to collect as more as we can frequent questions for the page...16:03
mtreinishclarkb: my regex sucks, so I'll just ask, is the tempest integer tagging effected by that?16:03
mriedemmtreinish: the volumes created by tempest are 1GB aren't they?16:03
anteayaomrim: it will be, and the meetings are your first stop16:03
*** nuritv has joined #openstack-infra16:04
clarkbmtreinish: no you have always been compliant (yay for simple versions)16:04
mtreinishmriedem: yes, they should all be 1GB16:04
anteayaomrim: this group doesn't tend to make good use of email space, so discussing it at the meeting is a good way to learn how to maximize email real estate16:04
anteayaomrim: otherwise you just make noise that other people ignore16:04
mtreinishmriedem: and I don't think we have 24 going at one time in the gate which is why I think we can drop that number16:04
mtreinishclarkb: ok cool16:05
mtreinishmriedem: to be fair IIRC there is a tempest config flag for default volume size if you wanted to make larger ones16:05
*** ayoung has joined #openstack-infra16:05
*** nuritv has quit IRC16:05
krtayloromrim, are you talking about a FAQ?16:06
omrimkrtaylor: Yes16:06
mriedemmtreinish: right, that's what i was thinking, with 8 VCPU you are just running 4 workers concurrently with testr right?16:06
mriedemso you could be creating 4 1GB volumes at once16:06
fungiclarkb: that looks right to me16:06
mriedemi guess the 24GB is buffer for volumes that were not cleaned up properly16:06
mtreinishmriedem: well it might be more than that, depending on how many volumes are created during a test class16:07
mriedemsure16:07
gilliardWhich repo holds the sources for the nova API documentation?16:07
mriedemi don't think i've ever seen a test run more than 3 volumes though16:07
mriedemor 3 instances for that matter16:07
clarkbfungi: was your email sent yet? I may just be blind16:07
fungiclarkb: i'm sending it now--just amended it with a link to your zuul config change16:08
clarkbfungi: cool16:08
mtreinishmriedem: but you're right, the 24g is the is just a safety buffer. Before we did some cleanups on the volume creations we consistently jumped above 15GB which was the previous size iiirc16:08
krtayloromrim, that would be a big help, maybe a section in th new third-party docs?16:08
*** nuritv has joined #openstack-infra16:08
anteayakrtaylor: do you read the logs of the other third party meetings?16:08
*** bdpayne has joined #openstack-infra16:08
krtayloranteaya, yes16:08
dteselkinHi, I have question about pip, again :)16:09
dteselkinIs it worth to implement https support on pypi node?16:09
omrimkrtaylor: I already add a patch thank you..16:09
anteayathen you would know what conversation took place already between omrim and myself16:09
krtayloromrim, great! can you add that to the etherpad?16:09
krtayloranteaya, yes, thats why I guessed FAQ16:09
dteselkinI made that in our infra lab, but don't know should I send a patch.16:09
mtreinishmriedem: https://review.openstack.org/#/c/35129/16:09
*** nuritv has quit IRC16:10
clarkbdteselkin: we have avoided it because we have region specific mirrors and would either need to manage valid certs or have a CA of some sort16:10
clarkbdteselkin: I think if you pushed a patch that at least made it optional that would be great16:10
mriedemmtreinish: thanks16:10
clarkbdteselkin: then if/when we move to https it will be easy for us to do so16:10
*** pcrews has joined #openstack-infra16:10
krtayloromrim, there is a Reviews section to the etherpad16:10
mtreinishI guess it was never 15G... :)16:11
dteselkinclarkb, ok, then I'll do it. Thanks!16:11
mtreinishmriedem: if you want to push a patch to try and drop it, I think I'd get behind that16:11
clarkbdteselkin: thank you16:11
krtayloromrim, I was going to discuss it at todays meeting, but the current thought is to have a virtual sprint in the new year16:11
mriedemmtreinish: with 80GB-200GB of disk on the VMs, it's probably not necessary16:11
anteayakrtaylor: what is the link to this etherpad?16:11
krtayloranteaya, in the email, let me get it one sec16:12
*** dannywilson has joined #openstack-infra16:12
anteayayes posting it helps people discover it16:12
omrimkrtaylor: If FAQ will be helpfull there I will be glad to add it..Anyway I am not familier with Etherpad16:12
anteayaif you want them to add to it16:12
krtayloranteaya, it is also in the agenda for today's meeting16:12
krtaylorhttps://etherpad.openstack.org/p/third-party-ci-documentation16:12
krtayloranteaya,  it has been there for a couple of weeks, in addition to the email16:13
krtaylorasselin has signed up, and others have expressed interest16:13
anteayagood, thank you for posting it16:14
krtaylorsure, np16:14
anteayaand I hope it happens16:14
krtayloryeah, it will, just tough this time of the year16:14
*** nuritv has joined #openstack-infra16:15
*** yfried has quit IRC16:15
*** vigneshvar_ has joined #openstack-infra16:15
omrimanteaya: Can we also discuss about it at tomorrow meeting? (8:00UTC)16:16
*** ala_ has quit IRC16:16
*** nuritv has quit IRC16:16
anteayaomrim: of course16:17
anteayathat is the point of the meetings16:18
*** nuritv has joined #openstack-infra16:18
fungiand so it begins... https://mail.python.org/pipermail/distutils-sig/2014-December/025371.html16:18
omrimanteaya: Thanks!16:18
*** mjturek has left #openstack-infra16:19
*** mjturek has joined #openstack-infra16:20
anteayafungi: glad the soaps don't fail to deliver16:20
*** nuritv has quit IRC16:20
*** jpich has quit IRC16:20
*** yamamoto has quit IRC16:20
*** skolekonov has quit IRC16:22
adam_gclarkb, im here now, did ninjas sort everything out?16:22
clarkbadam_g: yes the mtreinsh ninja had you covered16:23
*** nuritv has joined #openstack-infra16:23
adam_gmtreinish, thanks for that16:23
*** yamamoto has joined #openstack-infra16:23
*** nuritv has quit IRC16:24
*** nuritv has joined #openstack-infra16:27
clarkblooks like nova is broken too in other ways16:27
*** nuritv has quit IRC16:29
*** markmcclain has joined #openstack-infra16:30
*** ddieterly has joined #openstack-infra16:31
*** packet has joined #openstack-infra16:31
*** ddieterly has quit IRC16:31
*** ddieterly has joined #openstack-infra16:32
fungioh neat16:32
*** annegent_ has quit IRC16:33
*** nuritv has joined #openstack-infra16:33
*** annegent_ has joined #openstack-infra16:33
*** david-lyle_afk is now known as david-lyle16:34
clarkbadam_g reports that 8.0.2 should fix nova16:34
clarkbso likely an out of date mirror16:34
*** yamamoto has quit IRC16:34
fungichecking now16:34
adam_gaccording to https://review.openstack.org/#/c/141654/ at least16:35
*** atiwari has joined #openstack-infra16:35
*** nuritv has quit IRC16:35
fungiyeah, i see mirrors have only 8.0.116:35
fungino 8.0.2 yet16:35
fungilooking into why16:36
*** liusheng has quit IRC16:36
fungioh, dfw and ord are missing it but iad has it. fun!16:36
*** liusheng has joined #openstack-infra16:37
*** dimtruck is now known as zz_dimtruck16:37
fungialso region-b.geo-1 has 8.0.216:37
fungitime to look at logs16:37
*** achanda has quit IRC16:37
*** nuritv has joined #openstack-infra16:38
*** achanda has joined #openstack-infra16:38
*** yamamoto has joined #openstack-infra16:38
*** reed has joined #openstack-infra16:39
*** nuritv has quit IRC16:39
fungilooks like maybe the refresh on dfw and ord got prematurely aborted and now the cron job is trying to complete it but falling prey to the 30-minute timeout16:40
fungii'll get those sync'd up16:40
openstackgerritMatt Riedemann proposed openstack-infra/elastic-recheck: Add query for setuptools 8/glance bug 1402747  https://review.openstack.org/14183516:40
uvirtbotLaunchpad bug 1402747 in glance "setuptools 8 breaks multi-range version checks" [Undecided,New] https://launchpad.net/bugs/140274716:40
*** nuritv has joined #openstack-infra16:40
jeblairfungi: (not that it's soon enough to help here, but i made some progress on bandersnatch + afs friday)16:41
fungiexcellent!16:41
*** achanda has quit IRC16:42
*** nuritv has quit IRC16:42
*** achanda has joined #openstack-infra16:42
*** liusheng has quit IRC16:43
*** mugsie has quit IRC16:43
*** liusheng has joined #openstack-infra16:43
*** KanagarajM has joined #openstack-infra16:44
*** yfried has joined #openstack-infra16:46
*** yaguang has quit IRC16:46
*** yamamoto has quit IRC16:47
openstackgerritMerged openstack-infra/elastic-recheck: Add query for setuptools 8/glance bug 1402747  https://review.openstack.org/14183516:47
uvirtbotLaunchpad bug 1402747 in glance "setuptools 8 breaks multi-range version checks" [Undecided,New] https://launchpad.net/bugs/140274716:47
openstackgerritMatt Riedemann proposed openstack-infra/elastic-recheck: Add query for nova setuptools 8 bug 1402751  https://review.openstack.org/14184016:48
uvirtbotLaunchpad bug 1402751 in nova "gate-nova-python27 fails with "TypeError: 'SetuptoolsVersion' object does not support indexing" after setuptools 8" [Undecided,New] https://launchpad.net/bugs/140275116:48
*** yamamoto has joined #openstack-infra16:49
pleia2good morning16:50
*** mugsie has joined #openstack-infra16:50
*** _sweston is now known as sweston16:51
bookwarhow do you version JJB templates? let's say there was a job for icehouse made from template, then there is a new job for Juno made from the same template, and then you need to make certain change in this Juno job, which is incompatible with icehouse. Do you "freeze" icehouse jobs after release somehow?16:51
*** dtantsur is now known as dtantsur|afk16:53
fungibookwar: we take extra effort to make sure that job templates are applicable across multiple branches, and implement conditional switches in them where needed to perform branch-specific steps16:53
*** armax has joined #openstack-infra16:53
fungibookwar: since the branch is passed into the job through an environment variable, you can match on that to identify which commands should be run16:53
bookwarfungi: i see, thanks16:54
dstufftfungi: was the bandersnatch thing a bandersnatch problem?16:54
dstufftor something else16:54
dimsdstufft: thanks for the quick response on the Version/index problem over the weekend16:54
*** yamamoto has quit IRC16:54
*** nuritv has joined #openstack-infra16:55
dstufftdims: no problem, Jason made the release I just wrote the patch :)16:55
dims:)16:55
dstufftone benefit to releasing over the weekend is that less people means less people yelling at us while we fix any issues :D16:55
dimshehe16:55
fungidstufft: i think the bandersnatch thing was possibly me leaving the sync running under a timeout (at least i haven't ruled out the possibility)16:56
*** arxcruz has quit IRC16:56
openstackgerritMerged openstack-infra/elastic-recheck: Add query for nova setuptools 8 bug 1402751  https://review.openstack.org/14184016:56
uvirtbotLaunchpad bug 1402751 in nova "gate-nova-python27 fails with "TypeError: 'SetuptoolsVersion' object does not support indexing" after setuptools 8" [Critical,Confirmed] https://launchpad.net/bugs/140275116:56
*** KanagarajM has quit IRC16:56
*** Masahiro has joined #openstack-infra16:56
*** nuritv has quit IRC16:57
dstufftfungi: ok16:57
*** otter768 has joined #openstack-infra16:57
*** pblaho has quit IRC16:57
dstufftfungi: just wanted to make sure we didn't break something else :)16:57
fungidstufft: i don't think so16:58
* ttx blames dstufft for the world being on fire and hits him with a trout16:58
fungia fire extinguishing trout!16:59
*** k4n0 has quit IRC16:59
*** sarob has joined #openstack-infra16:59
*** barra204_ has quit IRC16:59
*** nuritv has joined #openstack-infra16:59
dstuffthttps://www.youtube.com/watch?v=n9D6GNzpmkM17:00
*** MaxV has quit IRC17:00
*** MaxV has joined #openstack-infra17:01
*** nuritv has quit IRC17:01
*** Masahiro has quit IRC17:01
*** zz_dimtruck is now known as dimtruck17:01
*** otter768 has quit IRC17:01
*** nuritv has joined #openstack-infra17:03
*** shakamunyi has quit IRC17:03
*** kmartin has joined #openstack-infra17:04
anteayamorning pleia217:04
*** nuritv has quit IRC17:05
*** MaxV has quit IRC17:05
*** gyee has joined #openstack-infra17:06
*** kmartin has quit IRC17:08
*** nuritv has joined #openstack-infra17:08
*** annegent_ has quit IRC17:09
openstackgerritMatt Riedemann proposed openstack-infra/elastic-recheck: Add query for pbr bug 1402759  https://review.openstack.org/14184817:09
uvirtbotLaunchpad bug 1402759 in pbr "gate-neutron-python27 fails with "ValueError: ("Expected ',' or end-of-list in", u'neutron==2015.1"" [Critical,Fix released] https://launchpad.net/bugs/140275917:09
*** zz_avozza is now known as avozza17:09
*** jgallard_ has quit IRC17:10
*** nuritv has quit IRC17:10
*** mmaglana has joined #openstack-infra17:11
notmynamettx: just got in and catching up. what's the current state of things?17:11
anteayadstufft: I'm reading https://caremad.io/2013/07/setup-vs-requirement/ is it still accurate?17:12
*** ihrachyshka has quit IRC17:13
ttxnotmyname: that email I sent one hour ago is pretty accurate17:13
notmynamettx: ok, thanks. just getting to email now (IRC first!)17:13
*** hdd has joined #openstack-infra17:13
ttxabout to leave, so let me know if that email is unclear. Or I can parrot it now :)17:13
*** nuritv has joined #openstack-infra17:14
notmynamettx: just read it. the question is what to do with the rc tag17:14
dstufftanteaya: it's accurate as to how pip treats the two different files yes, and my thinking on the matter17:14
notmynamettx: meh. leave it. no harm done with it there17:14
dstufftanteaya: obviously openstack doesn't agree with me/us since it parses the requirements.txt files ;)17:15
notmynamettx: also, I'll send out an announce shortly to -dev17:15
ttxnotmyname: alright!17:15
notmynamettx: thanks for chasing that17:15
ttxnotmyname: welcome to the c1 new world order!17:15
notmynamettx: fungi: final question is if "rc" is done for all python things or just openstack things17:16
*** nuritv has quit IRC17:16
clarkbanything that uses setuptools17:16
notmynameclarkb: ok17:16
dstufftsetuptools normalizes17:16
ttxnotmyname: yes, it's PEP44017:17
clarkbdstufft yes thats the issue17:17
clarkbdstufft we tag one thibg setuptools spits out another17:17
dstufftclarkb: sorry I'm running on a few hours of asleep and I'm tired so I'm a little slow today17:17
clarkbso in an effort to reduce confusion we use c117:17
funginotmyname: setuptools 8 and anything else implementing pep 440 no longer sees "rc" as normalized17:17
notmynameok17:17
*** penguinRaider has quit IRC17:17
clarkbdsufft we want ag version to match sdist version. just requires us to use c17:18
clarkb*tag version17:18
fungidstufft: right, the new issue we identified is that since we rely on setuptools parsing to determine sdist tarball and wheel names, we need to use already-normalized versions in tags17:18
jd__tooz is still failing for an unknown reason, hint appreciated http://logs.openstack.org/14/141314/3/check//gate-tempest-dsvm-neutron-src-tooz/5c3aee9/ :(17:19
jd__cc dhellmann who might have a clue17:19
*** armax has quit IRC17:19
*** kmartin has joined #openstack-infra17:20
*** amotoki has quit IRC17:20
dstufftfungi: clarkb ah ok, sorry about that17:20
fungijd__: "'pymemcache' is not in global-requirements.txt" http://logs.openstack.org/14/141314/3/check/gate-tempest-dsvm-neutron-src-tooz/5c3aee9/logs/devstacklog.txt.gz#_2014-12-15_16_18_14_29817:20
*** sputnik13 has joined #openstack-infra17:20
*** armax has joined #openstack-infra17:20
jd__fungi: -_-17:20
*** armax has quit IRC17:21
jd__that will teach me not checking the log before pasting an error17:21
anteayadstufft: very good, thank you17:21
jd__we used to have a different error but I guess we ended up fixing it with the devstack-gate patch and I thought it will solve everything, it turns out that no, we still miss a patch17:21
jd__:)17:21
dstufftanteaya: for the record, I think openstack should just add the requirements to setup.cfg to match what they're already doing... but I don't have the time to argue for or make that change myself so :)17:22
*** AJaeger has quit IRC17:22
*** nuritv has joined #openstack-infra17:22
*** armax has joined #openstack-infra17:22
openstackgerritMatt Riedemann proposed openstack-infra/elastic-recheck: Update query for bug 1402747  https://review.openstack.org/14185217:22
uvirtbotLaunchpad bug 1402747 in glance "setuptools 8 breaks multi-range version checks" [High,Confirmed] https://launchpad.net/bugs/140274717:23
*** markmcclain has quit IRC17:23
*** markmcclain has joined #openstack-infra17:23
anteayadstufft: yes, the reason I ask is go get my head around requirements myself, it is a bit of work indeed17:23
fungidstufft: can we do multiple sections that way for situation-specific dependencies? (test-only requirements, interpreter-version-specific requirements, et cetera)?17:24
*** cnesa2 has quit IRC17:24
*** nuritv has quit IRC17:25
swestonanteaya: Good morning!  I am looking over the latest iteration of comments on the third-party dashboard, and could really use your input. https://review.openstack.org/#/c/13517017:25
*** armax has quit IRC17:25
*** hashar has quit IRC17:25
*** SumitNaiksatam has quit IRC17:26
dstufftfungi: well pbr would be the one translating it into setup.py key arguments like you're doing now, so you can do it however you want17:26
zaromorning17:26
*** ZZelle is now known as ZZelle__17:26
anteayamorning zaro17:26
*** armax has joined #openstack-infra17:26
*** markvan has quit IRC17:26
*** nuritv has joined #openstack-infra17:27
*** asselin has joined #openstack-infra17:27
fungidstufft: good point. so in theory yes we could enumerate multiple requirements scenarios in one setup.cfg and drop the requirements files17:27
*** Ryan_Lane has joined #openstack-infra17:27
*** markvan has joined #openstack-infra17:27
dstufftfungi: you'd of course be limited to whatever setuptools supports, but you're limited to that right onw anyways17:27
anteayasweston: I've rechecked for a fresh set of draft docs17:27
*** markmcclain has quit IRC17:27
*** nuritv has quit IRC17:28
*** avozza is now known as zz_avozza17:28
*** zz_avozza is now known as avozza17:29
zaropelix: i think you might be interested in this to speeed up jjb: https://review.openstack.org/#/c/138886/7/jenkins/__init__.py17:29
swestonanteaya: ok.  where are the docs produced?17:29
anteayathere is a link in the returned jenkins results17:29
*** tonytan4ever has quit IRC17:30
anteayabut they only last a certain period of time (7 days? 10 days? I don't know)17:30
dstufftfungi: when setuptools 8 is working in openstack and you're unpinned, it'd be useful I think to test pip dev branch against openstack before we release pip to see if there's anything in there that's going to break the world for y'all before it gets released17:30
anteayaso running recheck gets a fresh set of them17:30
*** nuritv has joined #openstack-infra17:30
openstackgerritMatthew Treinish proposed openstack-infra/infra-specs: Update the test-metrics-db spec to reflect recent changes  https://review.openstack.org/14185517:31
swestonI see.  clicking on the link right now produces a not found.  does it take some time to produce them?17:31
fungidstufft: "test pip dev branch" is i think still not something we entirely understand how to accomplish without building an entirely parallel duplicate of our infrastructure17:31
dstufftfungi: ok17:31
openstackgerritMerged openstack-infra/elastic-recheck: Add query for pbr bug 1402759  https://review.openstack.org/14184817:31
uvirtbotLaunchpad bug 1402759 in pbr "gate-neutron-python27 fails with "ValueError: ("Expected ',' or end-of-list in", u'neutron==2015.1"" [Critical,Fix released] https://launchpad.net/bugs/140275917:31
clarkbwe can monkey patch it with devstack easily enough17:31
clarkbjust have devstack grab prerelease pip17:31
fungidstufft: there are probably some things we can test against it, but its large and interdependent nature means we won't be able to thoroughly confirm it everywhere17:32
*** e0ne_ is now known as e0ne17:32
*** nuritv has quit IRC17:32
anteayasweston: yes, jenkins jobs need to finish running on the recheck17:32
anteayasweston: http://status.openstack.org/zuul/ filter on 13517017:33
*** jkraj has joined #openstack-infra17:33
anteayasweston: you will see the progress of the jenkins jobs17:34
swestonanteaya: thank you17:34
anteayawelcome17:34
dstufftfungi: yea well, it's packaging tooling, the only real test is to release it i've found :D but yea throwing it at devstack would at least give an indication I hope17:34
anteayado share that information please17:34
anteayasweston: I didn't know you didn't know that17:34
anteayait is helpful information to have17:34
mattfarinacan someone point me to what happened to pypi.openstack.org?17:34
fungimattfarina: we stopped using it and took it down, why?17:35
*** AJaeger has joined #openstack-infra17:35
swestonit certainly is! is this information in the docs anywhere?17:35
*** AJaeger has quit IRC17:35
*** AJaeger has joined #openstack-infra17:35
mattfarinafungi i just found a couple referenes to it and i was curious what happened. that's all. thanks17:35
*** dkranz has quit IRC17:35
fungimattfarina: we run separate pypi mirrors local to each provider/region where we run jobs now17:35
*** nuritv has joined #openstack-infra17:35
*** dkranz has joined #openstack-infra17:36
*** markmcclain has joined #openstack-infra17:36
anteayasweston: if not it should be, I smell an opportunity for you to write a patch :D17:36
*** Ryan_Lane has quit IRC17:37
dstufftfungi: clarkb one thing that I know will affect you, is pip 6 deprecates (but doesn't remove!) accessing non HTTPS indexes without passing a flag (techincally non secure origins as defined by Chrome), it won't be removed until pip 7 or 8 and there's a flag (and env var, and config file) you can set to allow it17:37
*** shashankhegde has joined #openstack-infra17:37
swestonanteaya: hehe, yes 😃 I will look into it today.17:38
fungidstufft: is there a good way to add trusted snakeoil server certs pip will accept?17:38
*** nuritv has quit IRC17:38
fungidstufft: server cert pinning basically?17:38
dstufftfungi: every version of pip that verifies TLS has a config option for an alternate CA bundle, so as most pip options goes there is a config file, env var, cli flag17:39
swestonanteaya: what do you think of having the third party systems check into the dashboard, as jhesketh suggests in the review?17:39
dstufftfungi: pip 6+ also now will default to using the system CA bundle if it can find one and only falls back to it's bundled one if it can't, so adding it to the system should work too on pip 6+17:39
fungidstufft: does that work okay for self-signed certs?17:39
dstufftfungi: yes17:39
dstufftthere's nothing special about CA signed certs except they are in the default CA bundle17:39
*** signed8bit has quit IRC17:40
dstufftfungi: oh yea, pip 6+ also adds a system wide config file in /etc/, and a virtualenv specific config file17:40
dstufftnot sur eif that's useful for y'all17:40
krtaylorsweston, duncant, mriedem and asselin would be good for input on the dashboard also17:41
anteayasweston: let me get to that place in the review and then either comment or get back to you17:41
swestonanteaya: ok.17:41
swestonkrtaylor: thank you17:42
fungidstufft: thanks--i'll see about getting snakeoil https going on our mirrors in preparation17:42
dstufftfungi: pip 6+ also adds a flag that just lets you disable TLS verification too17:42
dstufftthough maybe that should be wrapped into the flag that lets you specify a certain host doesn't need TLS17:42
swestonpleia2: ^ might have some comments as well17:43
*** jcoufal_ has quit IRC17:43
*** sputnik13 has quit IRC17:43
*** _nadya_ has quit IRC17:44
*** wenlock1 has joined #openstack-infra17:44
*** nuritv has joined #openstack-infra17:44
*** _nadya_ has joined #openstack-infra17:44
krtaylorsweston, I can add them as reviewers if you wish17:44
*** jp_at_hp has quit IRC17:45
*** harlowja_at_home has joined #openstack-infra17:45
*** achanda has quit IRC17:45
swestonkrtaylor: yes, please17:45
*** rkukura_ has joined #openstack-infra17:45
clarkbwill pip6 accept + ?17:45
*** achanda has joined #openstack-infra17:45
openstackgerritMerged openstack-infra/elastic-recheck: Update query for bug 1402747  https://review.openstack.org/14185217:45
uvirtbotLaunchpad bug 1402747 in glance "setuptools 8 breaks multi-range version checks" [High,Confirmed] https://launchpad.net/bugs/140274717:45
*** nuritv has quit IRC17:46
dstufftclarkb: in a version?17:46
*** achanda has quit IRC17:47
*** achanda has joined #openstack-infra17:47
*** rkukura has quit IRC17:47
*** rkukura_ is now known as rkukura17:47
*** _nadya_ has quit IRC17:49
*** sputnik13 has joined #openstack-infra17:49
*** _nadya_ has joined #openstack-infra17:50
*** sputnik13 has quit IRC17:50
clarkbya17:50
*** bhunter71 has joined #openstack-infra17:50
clarkbsince current doesnt via vendored setuptools aiui17:50
pelixzaro: speed up jjb? looks like https://review.openstack.org/#/c/138886/7 is about correct encoding for spaces in job names?17:51
*** wenlock1 has quit IRC17:51
zaropelix: take a look at the comment/suggestion by kevin.17:51
dstufftclarkb: yea, whatever the latest setuptools is when 6.0 is released is what will be bundled into pip17:51
dstufftclarkb: which means 8.0.2 right now, so + should be supported17:52
openstackgerritAndreas Jaeger proposed openstack-infra/project-config: Normalize ACLs  https://review.openstack.org/14186017:52
*** hdd has quit IRC17:52
dstufftclarkb: if for whatever reason something in PEP 440 isn't supported in pip we'd probably fix it and issue a new release asap17:52
*** harlowja_at_home has quit IRC17:53
openstackgerritKhai Do proposed openstack-infra/jenkins-job-builder: deprecate postbuildscript onsuccess and onfailure parameter names  https://review.openstack.org/13925717:53
*** sweston is now known as _sweston17:54
pelixzaro: what he needs is for us to get https://review.openstack.org/#/c/75514/ sorted and landed17:54
*** nuritv has joined #openstack-infra17:55
pelixzaro: or https://review.openstack.org/#/c/45371/ either should do the job17:55
*** yamamoto has joined #openstack-infra17:55
pleia2_sweston: thanks for the ping, I held off on further review of that patch after jhesketh's comment because I'm really not sure17:56
*** sputnik13 has joined #openstack-infra17:56
*** yfried is now known as yfried|afk17:57
pleia2anteaya: can you look at https://review.openstack.org/#/c/141817/ when you have a chance? the patch needs a lot of work, but I'm not sure what to suggest re: formatting (and if a FAQ is appropriate at all), it seems something a lot of operators struggle with, so it's probably useful in some form17:57
*** nuritv has quit IRC17:57
*** e0ne has quit IRC17:58
zaropelix: so parrallel would be nice but might not be needed if python-jenkins library was faster?17:58
*** sputnik13 has quit IRC17:58
*** nuritv has joined #openstack-infra17:59
*** fandi has quit IRC17:59
pelixzaro: unlikely, the main delay is latency of requests17:59
zaropelix: it seems we should make the fix to the underlying library first to see how much fater it will work?17:59
*** yamamoto has quit IRC18:00
zaropelix: so kevin's suggestion will reduce the number of requests by what looks like quite a bit.18:00
*** nuritv has quit IRC18:01
pelixit'll help, but not much once you have lots of jobs think +200018:01
*** _sweston is now known as sweston18:01
*** shashankhegde has quit IRC18:01
pelixhis only helps for the rename, one of the biggest delays is the attempt to retrieve the XML from the server if the job exists18:01
*** signed8bit has joined #openstack-infra18:02
dstufftfungi: so far one thread on distutils-sig about setuptools 8 with only two people other than me. MAybe popcorn won't be needed *knocks on wood*18:02
*** _nadya_ has quit IRC18:02
pelixthink both of the parallel approaches discard this with the realization that if the cache is empty, simply uploading the job and letting jenkins work out if the job is the same or not is much quicker18:03
anteayapleia2: sure that came out of last tuesdays third party meeting if you wanted to skim the logs for context, I'll review after I finish reviewing sweston's patch18:03
swestonpleia2: ok, I am responding to it today.  am providing an update in the third party meeting soon if you want to discuss it further.18:03
fungidstufft: very promising! i think it's gone surprisingly smoothly, really18:03
pelixzaro: difference between 2hrs+ and 3-4 minutes to upload 2000 jobs18:03
fungidstufft: thanks in no small part to your assistance all weekend. thanks again18:04
*** derekh has quit IRC18:04
pleia2sweston: thanks18:04
dstufftfungi: considering we changes some very old and very core code to setuptools that a lot of people had cause to apply some sort of work around over the years, I'm pretty happy with how it's gone so far18:04
*** cnesa has joined #openstack-infra18:04
stevemaris there a bug that is tracking the setuptools<0.8 work?18:04
dstufftfungi: thanks :) least I could do heh after breaking things ;)18:04
clarkbmriedem has a few now for specific behaviors18:05
clarkbstevemar ^18:05
fungistevemar: it's really lots of different issues, just all exposed by a common event, but being worked more or less separately in parallel18:06
*** whayutin_ has joined #openstack-infra18:06
*** weshay has quit IRC18:06
*** nuritv has joined #openstack-infra18:06
*** subscope has quit IRC18:07
*** annegent_ has joined #openstack-infra18:07
clarkbat this point we should try to get the pbr change in that drops git shas from versions, release pbr, then propose revert of setuptools pin18:07
clarkbas oslo.db is released now iirc18:07
dstufftyea I saw dhellmann say that on the ML18:07
*** sputnik13 has joined #openstack-infra18:08
clarkbthe revert of the pin should self test18:08
*** nuritv has quit IRC18:08
clarkbI would help but need to afk for much of the day now. fwiw I think mordreds pbr change looked good just was unable to review and test properly18:08
anteayaomrim: so Signed-off-by is used in the commit message for https://review.openstack.org/#/c/141817/ yet you are the owner18:09
dstufftthen we'll quick release pip 6.0 and break it all over again! (just kidding, I don't suspect anything in there is going to break anything further thans etuptools pep 440ization did)18:09
anteayaomrim: what is meant by your use of Signed-off-by?18:09
*** rustlebee is now known as russellb18:09
*** sputnik13 has quit IRC18:09
clarkbwell we need to get https dealt with but that sounds straightforward18:09
clarkbanteaya so that the info is in git not gerrit18:10
*** patrickeast has joined #openstack-infra18:10
*** hdd has joined #openstack-infra18:10
dstufftclarkb: that's not changed in 6 other than 6 warns that in the future it'll break18:10
dstufftso you have time for that18:10
*** tjones1 has joined #openstack-infra18:11
clarkbah I misread I thought behavior changed with toggle to go back18:11
*** nuritv has joined #openstack-infra18:11
clarkbthats even better18:11
fungiclarkb: the bandersnatch mirror syncs i have going in dfw and ord need to complete before we see full coverage from the oslo.db release18:11
*** sputnik13 has joined #openstack-infra18:11
zaropelix: i see your point about latency on retreiving the job xml but the check for existing jobs seems to on every operation so i think it would affect more than just renaming of jobs.18:11
clarkbfungi will need that for the pbr release too18:12
dstufftclarkb: yea, the toggle exists in 6.0, but all it does it shut up the warning since currently there is only a warning18:12
clarkbgotcha18:12
anteayaclarkb: I read the words but I still am lacking context I'll read the gerrit commit message wikipage18:12
dstufftthings that the end user needs to change is way easier to deprecate than thing that package author needs to change :(18:12
anteayapleia2: I agree with all your points, nice review18:13
*** nuritv has quit IRC18:13
*** sputnik13 has quit IRC18:13
clarkbanteaya basically signed off by has nothing to do with gerrit as we use it18:13
clarkblooks like pbr change needs pep8 fixes18:14
clarkbmordred are you aroynd to do that?18:14
anteayafound it it has to do with the dco: https://wiki.openstack.org/wiki/OpenStackAndItsCLA#The_Developer_Certificate_of_Origin18:15
anteayawhich to the best of my knowledge we are not using18:15
anteayaperhaps he is just planning ahead18:15
anteayaso no harm to leave it in the commit message then I guess18:15
*** marcusvrn has quit IRC18:15
*** sputnik13 has joined #openstack-infra18:15
openstackgerritMatthew Treinish proposed openstack-infra/infra-specs: Update the test-metrics-db spec to reflect recent changes  https://review.openstack.org/14185518:17
*** yfried|afk is now known as yfried18:17
*** tjones1 has left #openstack-infra18:18
*** marcusvrn has joined #openstack-infra18:18
*** nuritv has joined #openstack-infra18:18
fungianteaya: some contributors who also contribute to dco-using projects likely have git commit hooks already installed to add that header automatically18:19
zaropelix: also i think that jjb creating lots of non-existing jobs is the slowness and since python-jenkins will check whether the job already exists before creating a job that's 2 request for every job instead of just 1.18:19
*** melwitt has joined #openstack-infra18:19
*** nuritv has quit IRC18:20
anteayafungi: ah cool18:21
pelixzaro: I'm guessing we might get a 33% increase in throughput by avoiding that extra round trip, though it might be better to have the jenkins object store the list of jobs internally and for assert_job_exists to retrieve the information from this by default unless passed 'refresh=True'?18:22
*** Hal_ has quit IRC18:22
*** nuritv has joined #openstack-infra18:22
*** HeOS has quit IRC18:22
*** Ryan_Lane has joined #openstack-infra18:23
anteayasweston: I suggest you talk to emagama in neutron, DuncanT and junglejoyj in cinder, morgainfainberg in keystone and jogo in nova about your third party dashboard spec18:23
*** BobBall is now known as BobBall_AWOL18:23
* morganfainberg 's ears perk up.18:23
anteayasweston: if you hope to get buy in from the various programs to use it, you will need to talk to them about it18:24
anteayamorganfainberg: hello18:24
morganfainberganteaya, Hiya!18:24
anteayasweston: oh and also in ironic, though I don't have a contact name yet18:24
*** nuritv has quit IRC18:24
swestonanteaya: ok, that is excellent advice.18:24
anteayasweston: you have a nice start18:24
anteayait will take some revisions and a lot of conversations18:25
anteayabut it would nice to see it happen18:25
anteayamorganfainberg meet sweston18:25
anteayasweston, morganfainberg18:25
morganfainbergsweston, hi there!18:25
swestonanteaya: thank you.  what is the best way to start these discussions?18:25
anteayaattend their meetings18:25
swestonmorganfainberg: hello18:25
morganfainbergsweston, yep attend the meetings!18:25
morganfainbergbest way to get all the project cores eyes / input on your ideas18:26
anteayainvite them to any third party meeting you plan on attending (don't be surprised if they don't show up)18:26
anteayayou will have better luck if you go to them18:26
swestonmorganfainberg: ok18:26
morganfainbergsweston, our meeting (keystone) is tomorrow...18:26
jrollanteaya: what contact do you need from ironic?18:26
swestonshould I update the agenda items for this?18:26
anteayajroll: ah yes18:26
morganfainbergsweston, https://wiki.openstack.org/wiki/Meetings/KeystoneMeeting18:27
clarkbone line docstring needs punctuation?18:27
*** prad has joined #openstack-infra18:27
fungipossibly also getting it onto an upcoming cross-project weekly meeting agenda could help too if this is something which needs cross-project input18:27
anteayajroll: which ironic core reviewer wants to be point person for third party matters?18:27
morganfainbergsweston, you can put something on the agenda /me checks to make sure it's accurate18:27
clarkbif H402 isnt dead yet it should go on the list18:27
anteayafungi: good idea18:27
swestonmorganfainberg: ok, will do18:27
morganfainbergthat agenda might be out-dated18:27
*** nuritv has joined #openstack-infra18:27
morganfainbergwe skipped last week's meeting18:27
anteayasweston: so consider the cross-project meeting as well18:27
zaropelix: is that a suggestion for have a python-jenkins cache?18:27
jrollanteaya: great question, does it have to be a core? adam_g is our usual testing guru but not core. what are the responsibilities?18:27
swestonfungi: ok, yes thanks18:27
mriedemclarkb: stevemar: bug 1402751 - bug 1402747 - bug 140275918:27
uvirtbotLaunchpad bug 1402751 in nova "gate-nova-python27 fails with "TypeError: 'SetuptoolsVersion' object does not support indexing" after setuptools 8" [Critical,Confirmed] https://launchpad.net/bugs/140275118:27
uvirtbotLaunchpad bug 1402747 in glance "setuptools 8 breaks multi-range version checks" [High,Confirmed] https://launchpad.net/bugs/140274718:27
morganfainberghm18:27
uvirtbotLaunchpad bug 1402759 in pbr "gate-neutron-python27 fails with "ValueError: ("Expected ',' or end-of-list in", u'neutron==2015.1"" [Critical,Fix released] https://launchpad.net/bugs/140275918:27
anteayajroll: the responsibilites is to be responsible18:27
swestonI will attend cross-project as well18:27
zaropelix: would make sense to me.18:28
morganfainberglooks like it's mostly up to date18:28
pelixzaro: I believe JJB gets the full list of jobs on the server to switch between update versus create calls to python-jenkins18:28
jrollha18:28
anteayajroll: doesn't have to be core, if the other cores will listen and back them up18:28
morganfainbergso feel free to add to the end18:28
morganfainbergsweston,^18:28
anteayaif adam_g wants it, I think other people will listen to him in ironic18:28
swestonmorganfainberg: ok, thank you!18:28
jrolladam_g: can I throw you under anteaya's bus? :)18:28
jrollyeah, agree18:28
anteayajroll: now you are getting the picture18:28
adam_gjroll, sure! :)18:28
anteayaadam_g: congratulations and my condolences18:28
jrollperfect18:29
jrollthanks y'all18:29
anteayasweston: talk to adam_g about ironic's input on the spec18:29
adam_ganteaya, is there a wiki describing  the role i just signed up for? :)18:29
*** nuritv has quit IRC18:29
anteayanot really18:29
*** _nadya_ has joined #openstack-infra18:29
pelixzaro: exactly just the first initialization to retrieve the list of jobs from the server using the 'get_jobs()' method and have assert_job_exists go through that by default unless we need to explicitly refresh. Which should only be true for rename and copy18:30
anteayasince I wanted to use peer pressure and the soft sell18:30
clarkbI will update mordreds patch shortly then afk for real18:30
anteayaadam_g: a wiki will just scare folks away :)18:30
swestonanteaya: neutron meeting is today, should we get some input from mestery as well?18:30
*** ivar-lazzaro has joined #openstack-infra18:30
anteayasweston: my suggestion is talk to edgar first18:30
pelixzaro: that leaves the ability to error early in place and only adds extra round trips where needed18:30
anteayahe will give you the obvious suggestions and relay to kyle18:30
*** e0ne has joined #openstack-infra18:31
swestonanteaya: ok, will do18:31
*** ihrachyshka has joined #openstack-infra18:31
anteayakyle is busy and edgar can let him know once the spec suits edgar's needs18:31
anteayaso yes having kyle's input is valuable18:31
swestonanteaya: gotcha18:31
adam_gsweston, whats URL for the spec?18:31
anteayagetting it the right way is suggested18:31
*** dimtruck is now known as zz_dimtruck18:31
*** _nadya_ has quit IRC18:31
swestonadam_g: https://review.openstack.org/#/c/135170/18:31
adam_gsweston, thanks18:32
*** doug-fish has quit IRC18:32
swestonadam_g: you bet!18:32
*** shashankhegde has joined #openstack-infra18:32
*** markmcclain has quit IRC18:32
*** lttrl has quit IRC18:32
swestonanteaya: agreed.18:32
*** koolhead17 has quit IRC18:32
*** harlowja has joined #openstack-infra18:33
*** nuritv has joined #openstack-infra18:33
*** marun has joined #openstack-infra18:33
*** markmcclain has joined #openstack-infra18:33
swestonthe more eyes we can get on this from the beginning, the better18:33
*** sdake has quit IRC18:33
*** sarob has quit IRC18:33
*** dpaterson has quit IRC18:34
swestonanteaya: regarding the stackforge repo, I have sent an email to mikal but so far no response18:34
*** nuritv has quit IRC18:34
anteayasweston: hmmmmm18:35
*** _nadya_ has joined #openstack-infra18:35
anteayasweston: okay I can follow up with jhesketh18:35
anteayahopefully he will be at the tuesday 0800 utc meeting18:35
anteayathanks for letting me know18:35
*** sdake has joined #openstack-infra18:36
*** sdake has quit IRC18:36
*** sdake has joined #openstack-infra18:36
*** armax has quit IRC18:36
swestonanteaya: okay, that would be helpful, thank you.  I'll be at the point this week at which I will be ready to start integrating some of the repo, but most of it will have to be reworked18:36
*** armax has joined #openstack-infra18:36
anteayaunderstood18:36
anteayalet's see if we can get the radar repo opened up for you to contribute to18:37
*** _nadya_ has quit IRC18:37
anteayaI'll do my best18:37
clarkbfungi: dhellmann dstufft mordred jeblair SergeyLukjanov jhesketh https://review.openstack.org/#/c/141667/ that should be ready now18:37
zaropelix: yeah, makes sense.  would you like to make that suggestion on the review?18:37
swestonanteaya: ok, sounds good.18:38
clarkband with that I need to run18:38
*** nuritv has joined #openstack-infra18:39
*** Ryan_Lane has quit IRC18:41
*** nuritv has quit IRC18:41
anteayaenjoy your run18:41
anteayaI think I am going to go for a walk18:41
*** liusheng has quit IRC18:42
*** gyee_ has joined #openstack-infra18:42
*** liusheng has joined #openstack-infra18:42
*** gyee_ has quit IRC18:43
*** andreykurilin_ has joined #openstack-infra18:43
*** nuritv has joined #openstack-infra18:43
*** nuritv has quit IRC18:45
fungiclarkb: all our mirrors have setuptools 8.0.3 now18:45
fungiand presumably new oslo.db as well18:45
*** Masahiro has joined #openstack-infra18:45
*** ayoung has quit IRC18:46
jeblair2014-12-15 18:46:28,713 INFO: Downloading: https://pypi.python.org/packages/3.4/s/setuptools/setuptools-8.0.3-py2.py3-none-any.whl18:46
jeblairfungi: 8.0.3 was just released, right?18:47
*** nuritv has joined #openstack-infra18:47
*** groknix has joined #openstack-infra18:48
fungijeblair: yep18:48
fungilike, minutes ago18:49
fungiso everything seems to be back in sync now18:49
jeblairthought so -- just saw that scroll by in my mirror testing18:49
fungiand running with the bandersnatch version released over the weekend18:49
*** nuritv has quit IRC18:49
fungijeblair: note new bandersnatch release yesterday with another fix for raciness, in case you missed it18:49
*** Masahiro has quit IRC18:50
jeblairfungi: ah, thanks.  i'm working from master from like friday, so i probably don't have that, but close.18:51
*** lttrl has joined #openstack-infra18:51
fungiheh18:51
jeblairi'll be sure to update as soon as i figure out how to do that with hg18:51
fungihg clone uhdfuhiklzdfvuuhikuhiscrew it i'm importing this into git18:51
dstufftimport all the things into git18:52
*** Ryan_Lane has joined #openstack-infra18:52
*** nuritv has joined #openstack-infra18:52
*** wuhg has quit IRC18:53
*** nuritv has quit IRC18:54
*** zz_dimtruck is now known as dimtruck18:56
dhellmannclarkb, mordred : I think I'm going to have to start asking for more comments in the pbr code that runs these git commands. _gert_version_from_git() o_O18:56
lifelessclarkb: hows the setuptools thing going?18:57
*** dprince has quit IRC18:57
fungilifeless: mostly wrangled now. see http://lists.openstack.org/pipermail/openstack-dev/2014-December/052985.html18:57
*** doug-fish has joined #openstack-infra18:57
*** otter768 has joined #openstack-infra18:58
*** nuritv has joined #openstack-infra18:58
*** cnesa2 has joined #openstack-infra18:58
*** cnesa has quit IRC18:58
mesterysweston: neutron meeting is tomorrow18:58
mesterysweston: https://wiki.openstack.org/wiki/Network/Meetings18:58
*** groknix has quit IRC18:59
*** nuritv has quit IRC18:59
*** rockyg has joined #openstack-infra18:59
lifelessfungi: so we're going to sit pinned for a while, and then 8.0.2 will fix us?18:59
*** ayoung has joined #openstack-infra19:00
clarkblifeless: lolno19:00
*** whayutin_ has quit IRC19:00
lifelessdhellmann: I may be able to shed light - I had to internalise the whole thing when I was doing changes there19:00
clarkblifeless: we are going to drop git shas from versions and include them in egg info metadata instead19:00
lifelessdhellmann: what in particular are you looking at?19:00
dhellmannlifeless: https://review.openstack.org/#/c/141667/19:00
lifelessclarkb: do we log that during test jobs?19:00
fungilifeless: we can start19:01
clarkblifeless: yes (via zuul)19:01
clarkbfungi: lifeless we always have19:01
fungioh, right that part19:01
lifelessclarkb: the egg metadata? cool. I never saw that.19:01
clarkblifeless: no19:02
fungilifeless: but also mordred mentioned there that we should start running 'pbr freeze' in the jobs too so we have a record of the git shas for the versions being used19:02
clarkbwe log it differently in the tests19:02
clarkbbut we will also have pbr freeze which we can use too19:02
swestonmestery: yes, apologies .. need to update my calendar :-)19:02
clarkbso I think we have the use case pretty well covered19:02
*** dustins_ has joined #openstack-infra19:02
*** andreykurilin_ has quit IRC19:02
*** andreykurilin_ has joined #openstack-infra19:03
*** otter768 has quit IRC19:03
lifelesswe'll still put the git versions in the debian package versions etc?19:03
lifelessactually what I'm asking is this - has this been considered with the same amount of input from operators that the semver changes got in the first place?19:04
clarkblifeless: I think we can, I haven't looked at the change atop master19:04
*** nuritv has joined #openstack-infra19:04
clarkblifeless: honestly no because it doesn't matter if setuptools doesn't work19:04
lifelessclarkb: well dstufft seemed to think we had a way to do it and work with setuptools, no ?19:05
clarkbyou can't install anything properly without versions it groks19:05
clarkblifeless: he was wrong19:05
*** dustins has quit IRC19:05
lifelessclarkb: hahahahahahahahah19:05
lifelessdstufft: why can't we have nice things?19:05
dstufftwait a moment, what did I say?19:06
clarkbdstufft: the +g thing19:06
*** pblaho has joined #openstack-infra19:06
*** nuritv has quit IRC19:06
clarkbit didn't work because old setuptools explodes on the +19:06
clarkbso we can't sanely have the gitsha in a version and expect it to work with 8.0 and 7.019:06
fungilifeless: in this case it's somewhat complicated by the fact that pbr relying on setuptools emitting version details means we need to use already-pep-440-normalized versions strings in tarball/wheel names and egg-info19:06
*** ociuhandu has joined #openstack-infra19:07
clarkbthat broke the +g thing then ^ broke the idea of supporting trailing alpha things19:07
*** _nadya_ has joined #openstack-infra19:07
clarkbbecause we would essentially be requiring everyong to have setuptool>=8.019:07
dstufftclarkb: right, and I was going to see about adjusting the spec so it allowed a trailing alpha numeric, and mordred said the pbr change will handle it instead19:08
dstufftso I didn't bother to run the numbers to see about that19:08
clarkbdstufft: ya its fine, it wouldn't have worked anyways19:08
clarkbso I htink mordreds approach is the best one19:08
fungiwell, at least wouldn't have worked without a more significant overhaul of how we're doing things19:09
annegent_hey reed, around?19:09
dstufftclarkb: I can possibly add a thing that'll tell setuptools _not_ to emit normalized versions19:09
dstufftlike a flag19:09
reedannegent_, one ear yes19:10
lifelessclarkb: fungi: I think I have captured this correctly in the distutils sig thread19:10
openstackgerritRamy Asselin proposed openstack-infra/project-config: Prepare project-config for puppet module split #1  https://review.openstack.org/14052319:10
openstackgerritRamy Asselin proposed openstack-infra/project-config: Prepare project-config for puppet module split #2  https://review.openstack.org/14054819:10
*** sarob has joined #openstack-infra19:10
* fungi catches up19:10
*** pblaho has quit IRC19:11
fungihonestly, i think getting rid of the non-monotonic revision control noise in dev version strings is a cleaner way forward anyway19:11
*** nuritv has joined #openstack-infra19:12
*** tonytan4ever has joined #openstack-infra19:12
clarkbfungi: I disagree :)19:12
clarkbfungi: its particularly important for the CD crowd19:12
clarkbof which lifeless is a participant19:12
clarkbbut that use case is relatively well dealt with using mordreds latest pbr changes so I think we will survive19:12
openstackgerritRamy Asselin proposed openstack-infra/project-config: Prepare project-config for puppet module split #2  https://review.openstack.org/14054819:12
dstufftwouldn't they be getting a different devN if they are running off master anyways for each commit?19:13
*** whayutin_ has joined #openstack-infra19:13
dstufftor running off the same branch anyways19:13
lifelessfungi: +1 on non-monotonic; CD wants monotonic, but we *can't* avoid non-monotonic with a DVCS19:13
*** nuritv has quit IRC19:13
fungii don't disagree that having the git sha mapping easily obtained from the software/package is good, just that it doesn't necessarily belong embedded in version numbers19:13
dstufftthe git hash is only useful if you're mixing branches afaik19:13
clarkbdstufft: no that is not true, because git19:13
lifelessfungi: so -1 on removing the signal: if version A==version B, the contents of A must == the contents of B.19:13
lifelessthe more I think about this, the worse it is19:13
clarkbdstufft: no no the way gerrit works nova has hundreds of commits with the same devN19:14
dstufftclarkb: but different branches19:14
clarkbdstufft: because everything is run and tested against master19:14
*** teran_ has quit IRC19:14
clarkbdstufft: no19:14
openstackgerritRamy Asselin proposed openstack-infra/project-config: Prepare project-config for puppet module split #1  https://review.openstack.org/14052319:14
clarkbdstufft: everything is differnt applied to master19:14
lifelessclarkb: they are branches in the DAG19:14
fungidstufft: ephemeral commits which never merge. so in theory different branches yes (thousands of ephemeral branches)19:14
clarkblifeless: yes but that isn't reflected in the version data either19:14
lifelessclarkb: it is via the git sha19:14
clarkblifeless: here "branch" is is the last tag different19:15
dstufftclarkb: and the CI people are applying random builds from gerrit instead of tracking master?19:15
clarkblifeless: which we are dropping19:15
lifelessclarkb: and which I've just -1'd.19:15
*** sarob has quit IRC19:15
*** nuritv has joined #openstack-infra19:15
clarkblifeless: sure its a fair thing to -1 just understand there is no other way to fix it given the state of the world right now19:15
*** jkraj has quit IRC19:15
lifelessdstufft: no, they are building their own branch because of local fixes etc19:15
clarkblifeless: and your email seems to capture that relatively well19:16
lifelessclarkb: setuptools reverting would fix it19:16
*** _nadya_ has quit IRC19:16
dstufftsetuptools reverting only fixes it until we re-land PEP 44019:16
jeblairnote that while it is helpful to know that version 1.0+abc != 1.0+def, i have still taken to the habit of uninstalling installed versions of software with those hashes because of the sorting problem (i never know whether a different 1.0+hash will sort > or < the installed version)19:17
*** dims has quit IRC19:17
fungiit seems like setuptools sees this as ripping off a bandage, pain expected, hopefully short-lived as the python package community solves all the issues around it19:17
jeblairso while it is a useful signal that some package is not the same as what's installed, the only thing i can do with that signal is "go clean up the mess"19:17
*** nuritv has quit IRC19:17
clarkbjeblair: right, which is why I think mordreds change is a good one19:17
*** dims has joined #openstack-infra19:17
mmedvedeasselin: there is a typo in the topic of your recent patches19:17
clarkband as was pointed out it puts the sha1 in every version regardless of whether or not it is a tag19:18
clarkbwhich is also handy19:18
asselinmmedvede, thanks. I'll check and fix19:18
clarkbthat said the commit hash is part of the version and it would be nice if we could have that info there19:18
clarkbif we can't then oh well19:18
clarkbanothe rthought I had was the convert the hash to base 10 and put that in the version19:18
fungidstufft: and some ci systems (such as ours) _are_ installing random commits from gerrit because they need to test whether or not they function19:18
clarkbsince that would be valid under pep44019:18
lifelessjeblair: the rule used to be that they sorted ==19:18
clarkbbut that would make sorting even more confusing19:19
sdagueif it's not there we're going to need to do a bunch more dump of things19:19
*** smcginnis has joined #openstack-infra19:19
lifelessjeblair: e.g. installing X+g1 over X+g0 would replace it rather than going 'oh, installed already'19:19
sdaguebecause pip-freeze having that is extremely important in understanding what's coming from where19:19
clarkbsdague: mordred's change comes with a pbr freeze19:19
clarkbsdague: we would just use that19:19
sdagueok19:19
*** sputnik13 has quit IRC19:19
fungisdague: which will have the added benefit that you get the shas associated with the tagged version numbers too19:20
lifelessclarkb: which then we're telling operators to do as well19:20
*** MaxV has joined #openstack-infra19:20
asselinmmedvede, done19:20
dstufftSo like I offered over the weekend, I can check on the feasibility of adding a normalization rule to PEP 440 so that a single trailing .alphanumeric gets converted to a +alphanumeric19:20
clarkblifeless: yes if deploying from pbr I think that would be the expectation19:20
dstufftI just didn't bother to do that because mordred told me not to19:21
mmedvedeasselin: thx19:21
clarkbdstufft: keep in mind that would require changing the emit behavior too19:21
fungidstufft: however, to take advantage of that, we'd need to stop relying on normalized versions from setuptools in naming our sdists/wheels19:21
*** MaxV has quit IRC19:21
fungier, what clarkb just said19:21
*** dims has quit IRC19:21
dstufftdo you check against that tag somewhere? I thought that was jsut in released versions19:22
clarkbhumans do. Its a sanity thing19:22
clarkbthere should be a 1:1 relationship between those strings that doens't include normalization rules19:22
clarkbespecially since if we don't change emit behavior that means the version on pypi will have a +19:23
fungidstufft: also that's where the continuous deployment crowd gets bitten. they're installing non-release versions, so likely need to be able to generate tarballs/wheels19:23
dstufftPyPI won't allow anything with a + in it to be uploaded19:23
*** sputnik13 has joined #openstack-infra19:23
*** nuritv has joined #openstack-infra19:23
clarkbdstufft: sorry let me rephrase19:23
clarkbdstufft: local pypi type things like mirrors or devpi could have + in them19:23
clarkbsince that is again how CDers deploy their stuff19:24
dstufftyes19:24
clarkband if you have old setuptools that breaks ou19:24
*** markmcclain has quit IRC19:24
clarkbso we could just require new setuptools and use the +19:24
clarkbinstead of adding new normalization rules that will in practice not add any benefit19:24
*** sputnik13 has quit IRC19:25
*** nuritv has quit IRC19:25
clarkbanyways I really really need to go now or will be late for things19:25
dstufftwell it'd only require new setuptools if you're installing a dev version from some sort of index, not in general. Presumably since PyPI won't allow uploads like that someone doing that is doing it internally and has some semblance of control over what version of setuptools they are using. Alternatively I can probably add a flag to disable the "emit normalized" behavior19:26
lifelessclarkb: what happens with trunk pbr? it already has + - and worked on setuptools 7, so what breaks if we just release trunk ?19:26
*** sputnik13 has joined #openstack-infra19:26
clarkblifeless old setup tools explodes on +19:26
lifelesshow old?19:27
lifelessah, no- trunk is .g19:27
*** Swanson has joined #openstack-infra19:27
*** nuritv has joined #openstack-infra19:27
lifelessit does +g for debian serialisation19:27
clarkbrelease before 8.019:27
dstufftit explodes on + depending on at what place you input the version into setuptools, because setuptools (apparently) has multiple places it parses versions19:27
fungiright, we tried (briefly) running with a pbr which used +g instead of .g and it went badly19:28
dstufftwith multiple different things it allows depending on what place you're sticking a version19:28
*** whayutin_ has quit IRC19:28
*** sputnik13 has quit IRC19:28
lifelesstrunk will be no different there19:28
*** smcginnis has left #openstack-infra19:28
lifelessbut FWIW the patch is a one liner19:28
lifeless(release_string) - to output it19:28
*** nuritv has quit IRC19:29
*** markmcclain has joined #openstack-infra19:30
openstackgerritRamy Asselin proposed openstack-infra/project-config: Add puppet-recheckwatch as split out module  https://review.openstack.org/14043019:32
dhellmannclarkb: I'm looking into a 1.2.1 release of oslo.db for stable/juno -- is the requirements spec for sqlalchemy in the stable/juno branch of the requirements list correct?19:34
*** sputnik13 has joined #openstack-infra19:34
dstufftdhellmann: it is similar in scope to the old one19:34
dstufftallows the same versions19:34
fungidhellmann: since https://review.openstack.org/141584 merged, yes19:34
dhellmanndstufft: ok19:34
dstufftcould theortically allow some extra ones if SQLAlchemy went backwards and released them19:35
dstufftbut it shouldn't _not_ allow something that the old one did19:35
*** sputnik13 has quit IRC19:36
dhellmannhrm19:36
dhellmannthe 1.0.x series is stable/juno, but we don't want to set a cap lower than we have to19:36
dstufft(by that I mean, it does like !=0.9.3, if SQLA released a 0.9.3.1 or something it'd allow that)19:36
dhellmannI suppose I could create a 1.2.0 branch and release 1.2.1 from there19:36
*** nuritv has joined #openstack-infra19:37
*** sputnik13 has joined #openstack-infra19:37
dhellmannwhy did we pull sqlalchemy 0.8.x out of the allowed range in master?19:37
dstufftdhellmann: someone suggested to me that we should19:37
fungidhellmann: you'll want to name it either stable/juno or feature/1.2 depending on how you plan to go about it19:37
dstufftI forget who it was19:37
dhellmanndstufft: I think we can convince zzzeek not to do that19:37
dstufftsomeone in here19:37
dstufftsot hat's what I did19:37
*** dims has joined #openstack-infra19:37
dstufftI think it was like a19:37
dhellmannfungi: we already have a stable/juno branch started from 1.0.0, which is why this is confusing19:37
fungidhellmann: ahh19:38
dstufft"well we can probably drop 0.8 in master" sort of thing19:38
dstufftif i remember correctly19:38
*** sputnik13 has quit IRC19:39
dhellmannok, I'm sure the oslo.db team will be happy to be able to drop some of the compat code they're maintaining19:39
*** david-lyle is now known as david-lyle_lunch19:39
*** nuritv has quit IRC19:39
dstufftSo if you want the sha in the version tag I see five ways forward -> A) Use + and mandate that everyone moves to setuptools 8+ B) Use . and mandate that everyone stays on setuptools < 8 C) I check to see if we can normalize .alphanum to +alphanum and CD operators need to be on setuptools >= 8 D) I check to see if we can normalize .alphanum to +alphanum and make it so pbr can turn off emiting normalized E) Use + and see about releasing19:40
dstufft patched copies of the older setuptools that won't explode19:40
*** sputnik13 has joined #openstack-infra19:40
*** nuritv has joined #openstack-infra19:40
sdaguedhellmann: while you have a stable juno branch, because it's not capped in requirements, stable/* are totally allowed to use latest oslo.db (that's what their requirements say)19:40
dhellmannsdague: right, I'm just trying to figure out where to put a change to the sqlalchemy version used by oslo.db for stable/juno, and what version to tag it as19:41
sdaguedhellmann: ah, gotcha19:41
dhellmannif we're going to make a 1.2.1 and cap juno to that, then I need a new branch19:41
dhellmannbut it's not clear that's the right fix, either19:41
sdagueso, previously stable/juno was < 1.219:41
dhellmannyeah, I guess we want stable/juno to be <=1.2.1 and kilo to be >=1.2.119:42
sdaguesure19:42
*** nuritv has quit IRC19:42
sdagueyeh, that would be a transitional bridge19:42
*** whayutin_ has joined #openstack-infra19:42
dhellmannright now master is >=1.1.0, but with the sqlalchemy change that's no longer correct I think19:42
dhellmannso now what do we call this branch? "feature/1.2" seems wrong19:44
fungidhellmann: i'm unconvinced we should >=1.2.1 in master. openstack still works with earlier versions, just recent setuptools causes a problem19:44
dhellmannfungi: ok, fair point19:44
dhellmannso just the cap to <=1.2.1 in stable/juno then19:45
fungiwe won't be able to run tests in master for older oslo.db with newer setuptools, but we'd be testing with the latest version allowed by the requirements list regardless19:45
*** rwsu has joined #openstack-infra19:45
lifelessdstufft: C D and E all make a lot of sense to me19:45
dhellmannyeah, I think it's safe to assume if you end up with something older installed it came from a package somewhere anyway19:45
*** Ryan_Lane has quit IRC19:46
lifelessdstufft: B isn't long term tenanble19:46
lifelessdstufft: and A seems likely to be disruptive19:46
dhellmannfungi: what name should we give this branch? "feature/1.2" feels odd because it's not really a feature, but is "stable/1.2" going to cause trouble with some of our automation tools?19:46
*** armax has quit IRC19:46
dstufftlifeless: I don't believe so either, I was jsut being exhaustive as to what I could think of :)19:46
lifeless:)19:47
fungidhellmann: stable/1.2 will fail because of the devstack feature matrix regarding it as an invalid stable branch name (i got to go through this exercise with pbr on saturday)19:47
lifelesswhat TZ is mordred in at the moment?19:47
dstufftand of course there's the other option of not including the sha sums in the version number which mordred's pbr change does (though I think the change in general is a good one even if you keep the sha sums in the version numbers, it'd nice to know what git hash a released version came from too)19:47
dhellmannfungi: ok, I'll take the benefit of your experience then -- would you please make me a feature/1.2 branch for oslo.db from changeset 4ad43a40611ef8cba715aa4d392dda40c079894a19:47
fungidhellmann: we settled on feature/0.10 for the pbr backport releases, but the plan was to delete that branch as soon as it got tagged19:47
harlowjahmm, qq, i assume the juno gate stuff is being adjusted due to this setuptools stuffs, i'm seeing 'pkg_resources.VersionConflict: SQLAlchemy 0.8.4 is installed but SQLAlchemy>=0.9.7,<=0.9.99 is required by ['oslo.db']'19:47
dstufftI'm happy to do whatever I need to do on my side for whatever option seems best19:47
harlowja* http://logs.openstack.org/80/121280/67/check//gate-tempest-dsvm-neutron-src-taskflow-juno/4b4ed02/logs/devstacklog.txt.gz19:47
*** nuritv has joined #openstack-infra19:48
lifelessdstufft: yes, I support putting the git info in the metadata files; separate from removing it in dev builds :)19:48
dhellmannfungi: we'll need to keep this branch in case we have to make more 1.2 backports19:48
dhellmannharlowja: yeah, we're working out the fix right now19:48
harlowjathx dhellmann19:48
lifelessdstufft: I can't speak for mordred, but I'd be super happy if you investigate the C/D/E options19:48
fungidhellmann: well, we can always re-branch from the 1.2.1 tag, but sure it can just be left there too19:48
*** annegent_ has quit IRC19:49
dstufftlifeless: okies19:49
*** nuritv has quit IRC19:49
dhellmannfungi: yeah, this is going to mess with how we backport oslo.db fixes to juno, too -- I wonder if we should move the stable/juno branch instead of making a new one19:50
dhellmannthat feels dangerous though19:50
fungidhellmann: okay, now an openstack/oslo.db feature/1.2 branch exists, starting from the 1.2.0 tag (commit a73d499)19:50
lifelessargh19:50
lifelesshttps://www.python.org/dev/peps/pep-0440/#changing-the-version-scheme19:50
lifelessis going to bite us separately19:50
*** nuritv has joined #openstack-infra19:50
*** spzala has quit IRC19:51
fungidhellmann: that's certainly an option... fast-forwarding it to the 1.2.0 commit should be fine assuming there are no other changes in that branch deviating from master19:51
lifelessclarkb: fungi: ^ this *also* means that the current pbr trunk versions are as correct as we can make them, modulo the +.19:51
*** spzala has joined #openstack-infra19:51
dhellmannfungi: we have some cherry picks for existing backports19:52
*** nuritv has quit IRC19:52
fungidhellmann: you may need a merge from the 1.2.0 tag then to keep the branch ff-only compatible19:52
dstufftlifeless: what's going to bite you about that?19:52
*** david-lyle_lunch is now known as david-lyle19:53
lifelessdstufft: CD deployers deploying off of master19:53
*** sputnik13 has quit IRC19:53
*** HeOS has joined #openstack-infra19:53
dstufftlifeless: not sure I understand19:53
lifelessdstufft: we start with a release19:53
lifelessversion 1.019:53
lifelesswe do one commit19:53
dhellmannfungi: I've never done that through gerrit before, how does that work? create a merge commit and then review it?19:53
lifelessversion 1.0.dev119:53
lifelesswe do a second commit19:53
*** david-lyle is now known as david-lyle_t19:53
lifeless1.0.dev219:53
lifelesswe tag that19:53
*** david-lyle_t is now known as david-lyle19:53
lifeless1.0a119:53
lifelesswhich has the same content as 1.0.dev219:54
dstufftok?19:54
fungidhellmann: i'm thinking through potential gotchas there. for starters the acl isn't going to allow that with a stable-named branch, but there are other linearity issues to think about too19:54
lifelesswe wanted to then do19:54
lifelesswe do another commit19:54
lifelesswe wanted to make that be 1.0.a1.dev119:54
lifelessbut 1.0.dev2 will sort before it.19:54
lifelessSo it will never install.19:55
fungidhellmann: the acl thing is tractible, but i'm slightly worried about branching from a 1.2.0 which isn't actually 1.2.0 (because it involves a merge)19:55
fungiclarkb: ideas there? ^19:55
*** sputnik13 has joined #openstack-infra19:55
*** zz_sabari is now known as zz_zz_sabari19:55
dhellmannfungi: yeah, and I think dragging the 1.2.0 requirements back into stable/juno is going to open another can of worms19:55
lifelessso19:55
*** rockyg has quit IRC19:55
dstufftlifeless: sort before means "less than"19:55
dstufft1.0.dev2 is < 1.0.a119:56
lifelessoh19:56
*** jseiler has joined #openstack-infra19:56
lifelessok so this is the reason we can't release pbr trunk19:56
dhellmannfungi: I'll go with the feature/1.2 branch for now, release a 1.2.1, and write this up for the mailing list so the oslo.db team knows about handling backports differently19:56
lifelessbut we can fix I think19:56
lifelessdstufft: so 'ahead of' means 'lower than' ?19:56
dstufftlifeless: it's kind of confusing I guess, the PEP sort order talks in terms of sort order in an ascending fashion, though often times people think descending when they think versions19:56
dstufftessentially the PEP means what order does sorted() put it in if they are in a list19:57
dstufftsorted([1, 2, 3, 4]) => [1, 2, 3, 4]19:57
dstufft1 sorts ahead of 219:57
dstufft2 sorts lower than 319:57
*** yamamoto has joined #openstack-infra19:57
dstufftthe _old_ PEP, PEP 386 had the behavior you were talking about19:57
lifelesswould you accept a patch to make it use lesser and greater consistently ?19:57
nelsnelsonGreetings, channel.  Could I please request another review of this submission?  https://review.openstack.org/#/c/134348/  Thanks for your attention.19:57
dstufft.dev was _higher_ than an alpha and beta and rc and was sorted between rc and the release19:58
lifelessdstufft: ok so this means we *have* to do 1.0a1.dev219:58
lifelessor dev3 will never be installed19:58
lifelessdstufft: that will work, right ?19:58
dstufftthe change sin PEP 440 started out as me arguing that made no sense and it was a brea kin compat in the order that setuptools put them in19:58
dstufftlifeless: and yes we accept clarification patches always19:59
*** doug-fish1 has joined #openstack-infra19:59
*** esp has joined #openstack-infra19:59
dstufftlifeless: 1.0.dev0, 1.0.dev1, 1.0.a1, 1.0.a1.dev0, 1.0.a1.dev1, 1.019:59
dstufftterms of "oldest" to "newest"20:00
dstufft(maybe older and newer is better terminology than lower/higher)20:00
dstuffter20:00
*** whayutin_ has quit IRC20:00
dstufftsorry that's wrong20:00
dstufft1.0.dev0, 1.0.dev1, 1.0.a1.dev0, 1.0.a1.dev1, 1.0.a1, 1.020:00
dstufftthat's right20:00
lifelessso thats a problem20:00
*** sputnik13 has quit IRC20:01
*** yolanda has quit IRC20:01
lifelessdstufft: whats the next version number after 1.0.a1 ?20:01
lifeless1.0.a2.dev120:01
lifelesssorted20:01
lifelessI need to wake up :)20:01
*** yamamoto has quit IRC20:01
lifelessthis is why the semver code has the stuff in it it has ;)20:02
lifelessrighto, time to go - later folk20:02
*** doug-fish has quit IRC20:02
dstufft(just double checked my answer, and that sort order is for pre 8 and post 8 setuptools)20:02
dstufftlifeless: a2 is after a1, or .postN20:02
dstuffta2 is probably what you want though20:02
dstuffta2.devN20:02
*** tkelsey has joined #openstack-infra20:03
*** doug-fish1 has quit IRC20:04
*** annegent_ has joined #openstack-infra20:04
*** subscope has joined #openstack-infra20:05
*** stpierre has joined #openstack-infra20:05
stpierrecan anyone help me figure out what's happening with tempest here? http://logs.openstack.org/51/120451/3/check//check-grenade-dsvm/ef5f14f/logs/grenade.sh.txt.gz (or, failing that, help me find the correct IRC channel in which to ask?) thanks.20:05
fungijust tested out mordred's 141666 for pbr master with tip of gertty master, and here's the (sorted) diff in output between pip freeze and pbr freeze: http://paste.openstack.org/show/151391/20:06
*** doug-fish has joined #openstack-infra20:06
fungii like that it includes python interpreter version, pip and setuptools too (sor of like pip list)20:06
*** bitblt has joined #openstack-infra20:07
jeblairi have made a commit; now i need to figure out how to push that to bitbucket...20:07
*** bitblt has left #openstack-infra20:07
*** kevinbenton has joined #openstack-infra20:07
dhellmannfungi: https://review.openstack.org/141893 https://review.openstack.org/14189420:07
dhellmannharlowja: ^^20:07
harlowjacools20:08
harlowjadurn setuptools20:08
jeblairfungi: oh that's a git sha in the comment?20:08
anteayahi asselin I had gone for a walk20:08
fungijeblair: yep20:08
anteayaasselin: on the mailing list I stated what I am doing20:08
dstufftmight make sense to make that like20:08
dstufftgit: <hash>20:08
dstuffter, # git: <hash>20:08
dhellmannfungi: oh, interesting, those patches don't seem to have triggered zuul20:08
anteayaasselin: and the times I am available to answer questions during third party meetings20:08
fungijeblair: that's the proposed alternative to making it a subcomponent of the version string itself20:08
jeblairfungi: *nod*20:09
harlowjasomeone just needs to implement a parser for that version that follows how people think it should be; some simple DSL :-P20:09
anteayaasselin: anyone is welcome to join me to ask questions and share ideas during those times I have stated I will be available20:09
lifelessclarkb: fungi: - I have to go - my opinion is on https://review.openstack.org/#/c/141667/ now20:09
*** jedimike has quit IRC20:09
*** subscope has quit IRC20:09
fungiharlowja: all the versioning standards are broken in some way. what we need is a new standard to replace them... http://xkcd.com/927/20:10
lifelessIf I had the time to commit to being around to discuss it, I would -2 this20:10
lifelessBut I'm on leave and life is short.20:10
harlowjafungi exactly!20:10
fungilifeless: thanks for checking back in on your travels20:10
harlowjai was just thinking; u know something like the following DSL "(<=0.84) or (>=0.99)"20:10
harlowjasomething simple with just 'or' 'and '20:11
harlowjaand be done with it, ha20:11
dstufftharlowja: my plan for the future is to do just that20:11
*** Ryan_Lane has joined #openstack-infra20:11
harlowjawoot20:11
dstufftalthough it'll sit alongside this, so the , will just be an alias for AND20:11
harlowjathat will match what a SAT solver needs also20:12
harlowjaso that will help making a good dependency solver20:12
harlowjasomeday20:12
dstufftyea, that's a future task for me too, first pip needs more refactorings to make the code base sane so we can add one at all20:12
dstufftpip is very spaghetti20:12
*** whayutin_ has joined #openstack-infra20:13
fungidhellmann: zuul may just be busy handling its events/results queues. i'm looking into it20:13
dstufftpart of what I'm doing here is taking features from setuptools and pip, standardizing, and putting them into https://github.com/pypa/packaging which then gets used instead inside of pip/setuptools20:13
harlowjacool20:13
dhellmannfungi: ok, I wasn't sure if the branch name had anything to do with it20:13
*** dprince has joined #openstack-infra20:13
fungidhellmann: i think you caught it right as a gate reset or two happened20:14
dhellmannfungi: ok20:14
*** amuller has quit IRC20:14
dstufftPEP 440 is probably the most painful one of those :/ though we tried to make it less painful overall20:14
*** ociuhandu has quit IRC20:14
fungidhellmann: yep, they're in check now20:17
dhellmannfungi: I'm spoiled; usually zuul shows the patch immediately :-)20:17
*** shashankhegde has quit IRC20:18
*** ihrachyshka has quit IRC20:20
*** prad has quit IRC20:21
dhellmannfungi, dstufft, sdague: https://review.openstack.org/#/c/141896/ caps oslo.db in juno20:22
*** annegen__ has joined #openstack-infra20:22
*** viglesias has quit IRC20:22
*** annegent_ has quit IRC20:22
*** prad has joined #openstack-infra20:22
*** ihrachyshka has joined #openstack-infra20:22
*** baoli has quit IRC20:23
*** vhoward has left #openstack-infra20:23
*** viglesias has joined #openstack-infra20:25
anteayaEmilienM: okay so the puppet-beaker-rspec job runs on puppet-storyboard for instance: http://git.openstack.org/cgit/openstack-infra/puppet-storyboard/tree/20:26
anteayawhich does have a Rakefile, yay off to a good start20:27
*** avozza is now known as zz_avozza20:27
anteayahowever the commit message states "For modules that have unit tests in the spec/ directory"20:27
anteayaI don't see that puppet-storyboard has a spec/ directory20:28
anteayaEmilienM: what am I not understanding?20:28
nibalizeranteaya: those tests run on the stackforge/puppet-* projects as well20:28
*** zz_avozza is now known as avozza20:28
anteayanibalizer: okay20:28
nibalizerand those projects do have unit tests20:28
nibalizerso it worked great in the case of storyboard because it did not have unit tests, but against a more mature module it fell short20:29
anteayaso if we are changing a job, I need to see how the functionality will affect the projects running that job20:29
anteayaand puppet-storyboard runs that job and doesn't have a spec/ directory20:29
anteayaso perhaps I don't yet understand the commit message20:29
*** eharney has quit IRC20:30
*** nithyag_ has quit IRC20:30
*** hamzy_vacation has quit IRC20:30
*** redrobot has quit IRC20:30
*** jcooley has quit IRC20:30
*** spiffxp has quit IRC20:30
*** leifmadsen has quit IRC20:30
*** timfreund has quit IRC20:30
*** sdague has quit IRC20:30
*** crinkle has quit IRC20:30
*** cinerama has quit IRC20:30
*** jogo has quit IRC20:30
*** grantbow has quit IRC20:30
*** Guest20522 has quit IRC20:30
*** niedbalski has quit IRC20:30
*** avozza is now known as zz_avozza20:30
anteayabecause after reading it I was expecting the job being edited to run on repos with spec/ directories only20:30
anteayawhich according to the first repo I found, is not the case20:30
*** tonytan4ever has quit IRC20:30
anteayaI'm willing to say that I don't understand20:30
anteayawhich is probably the case20:30
anteayabut I would like to20:30
*** zz_avozza is now known as avozza20:31
*** prad has quit IRC20:31
*** eharney has joined #openstack-infra20:31
*** nithyag_ has joined #openstack-infra20:31
*** hamzy_vacation has joined #openstack-infra20:31
*** redrobot has joined #openstack-infra20:31
*** jcooley has joined #openstack-infra20:31
*** spiffxp has joined #openstack-infra20:31
*** leifmadsen has joined #openstack-infra20:31
*** timfreund has joined #openstack-infra20:31
*** sdague has joined #openstack-infra20:31
*** crinkle has joined #openstack-infra20:31
*** cinerama has joined #openstack-infra20:31
*** jogo has joined #openstack-infra20:31
*** grantbow has joined #openstack-infra20:31
*** Guest20522 has joined #openstack-infra20:31
*** niedbalski has joined #openstack-infra20:31
nibalizerokay let me try to explain20:32
* anteaya listens20:33
*** _nadya_ has joined #openstack-infra20:33
nibalizerthe end state we want all modules to be in is they have beaker tests and rspec-puppet tests, those are sometimes called acceptance tests and unit tests, respectively20:33
nibalizernow i made that job so that i could run and develop acceptance tests for storyboard (and other modules, but i started on storyboard)20:33
anteayaI support the end state20:34
nibalizerand storyboard doesn't have unit tests because i haven't gotten there yet20:34
nibalizerso i iterated until it worked20:34
anteayauntil what worked?20:34
nibalizerpuppet storyboard + acceptance tests + beaker testing20:34
*** Masahiro has joined #openstack-infra20:34
anteayahaving beaker run and not fall over?20:34
nibalizerya20:34
nibalizerand everything was good until someone tried to use that test on a module that had unit tests as well20:35
anteayaokay20:35
anteayawhere are the acceptance tests for puppet-storyboard?20:35
nibalizerturns out the syntax i was using in that test was wrong, and it was kindof a fluke that it worked at all20:35
*** sarob has joined #openstack-infra20:35
anteayaI couldn't find them20:35
sdaguedhellmann: actually, you want to make it < 1.3 ?20:35
nibalizerin a review that hasn't landed yet20:35
anteayaurl?20:35
sdaguebecause that allows for possible future fixes without updating the world20:35
dhellmannsdague: oh, good point20:35
nibalizeranteaya: https://review.openstack.org/#/c/126086/20:36
anteayanibalizer: while I look this over, can we add this and its significance to the commit message for https://review.openstack.org/#/c/141728/120:36
*** sarob has quit IRC20:36
dhellmannsdague: updated20:37
sdaguedhellmann: +220:37
anteayanibalizer: because so far I am feeling that 141728 depends on 12608620:37
dhellmannsdague: I'll let the tests pass and then push that through20:37
*** Masahiro has quit IRC20:39
nibalizeranteaya: no if anything 126086 depends on 14172820:39
openstackgerritJeremy Stanley proposed openstack-infra/elastic-recheck: Bugs _in_ this project go in StoryBoard now  https://review.openstack.org/13912020:39
nibalizer141728 is about improving the testing infra and 126086 just takes adavantage of those improvements20:40
anteayanibalizer: okay can we track that relationship then in the commit message?20:40
*** amcrn has joined #openstack-infra20:41
anteayaI'm lost on how we improve the testing structure that requires a directory of tests in order to run that don't yet exist in the repo20:41
* anteaya goes back to listening20:41
openstackgerritJeremy Stanley proposed openstack-infra/system-config: Elastic recheck has two kinds of bugs  https://review.openstack.org/13913920:42
nibalizerso the puppet-storyboard stuff all works fine under the current state of project-config20:42
nibalizerwhat doesn't work fine is the stackforge modules20:42
nibalizerhttps://review.openstack.org/#/c/140844/ is an example20:42
openstackgerritJeremy Stanley proposed openstack-infra/system-config: Elastic recheck bug tracking is now in storyboard  https://review.openstack.org/13913920:43
anteayaDon't know how to build task 'spec/acceptance'20:43
anteayaso rake is upset and you want to use rspec20:44
nibalizerya, basically20:44
anteayaso can you show me a paste of output of what rspec does on puppet-storyboard in its current state?20:45
nibalizercalling 'rake spec' should cause the unit tests to be run, the fact that 'rake spec spec/acceptance' did the beaker tests is wild20:45
anteayawell especially since there were no spec/acceptance tests in the first place20:45
*** MarkAtwood has joined #openstack-infra20:46
anteayabtw I have never worked with beaker20:46
*** baoli has joined #openstack-infra20:46
*** sputnik13 has joined #openstack-infra20:46
nibalizerwell this is kindof what you asked for http://paste.ubuntu.com/9532723/20:47
nibalizerthese acceptance tests haven't been merged yet20:47
*** ihrachyshka has quit IRC20:47
nibalizerand there are some lingering issues around rabbitmq20:47
*** baoli has quit IRC20:47
*** shashankhegde has joined #openstack-infra20:47
nibalizerbut yea if you use the syntax that colleen suggested you do get beaker tests out the other end20:47
*** baoli has joined #openstack-infra20:47
anteayahere is my problem: Failed examples:20:48
anteayarspec ./spec/acceptance/class_spec.rb:7 # storyboard class default parameters should work with no errors20:48
anteayathe repo you are testing has a file in spec/acceptance20:48
anteayaso the job ran but the test failed, fine20:48
anteayapuppet-storyboard has no spec/ directory20:48
openstackgerritColleen Murphy proposed openstack-infra/project-config: Run acceptance tests without rake  https://review.openstack.org/14172820:49
anteayacan you show me an example of what happens if you run the rspec command on a repo with no spec/ directory?20:49
crinkleanteaya: I've attempted to make the commit message more descriptive20:49
nibalizermy change adds the spec directory20:49
anteayacrinkle: thanks20:49
*** teran has joined #openstack-infra20:49
anteaya141728 adds a spec directory?20:50
* anteaya looks again20:50
crinkle141728 corrects the command20:50
nibalizerhttp://paste.ubuntu.com/9532745/20:50
crinklerunning rspec spec/acceptance without that directory will fail, but this is a nonvoting job and that is expected20:51
nibalizerit fails, but the test is nonvoting so thats not a big deal20:51
anteayaah ha20:51
anteayathat was the missing piece20:51
crinklewe intend to keep it nonvoting until we can update the modules to have acceptance tests, but we need the infrastructure in place first20:51
anteayaplease state in the commit message that the expected outcome of this patch is that the job will fail20:52
crinkleokay20:52
anteayaand btw I'm adverse to merging jobs that will fail20:52
anteayaso now you have to convince me why I should merge a patch that will cause a job to fail20:52
*** vigneshvar_ has quit IRC20:52
*** teran_ has joined #openstack-infra20:52
anteayaor sorry, +2 a patch20:53
nibalizerwell the job alraedy fails?20:53
crinklethis was causing jobs to fail anyway, see https://review.openstack.org/#/c/140194/20:53
anteayacrinkle says running rspec spec/acceptance without a spec directory will cause the job to fail20:53
anteayawhich was my suspicion20:53
crinkleit was failing with rake spec spec/acceptance too20:53
*** erikwilson has joined #openstack-infra20:54
nibalizerare you saying you would like some logic to be added so that it 'passes' the test if there are no test files to run?20:54
crinklethe purpose of 141728 is so that when the acceptance tests are in place, the correct tests will be run20:54
crinkleotherwise the tests won't get run at all20:54
anteayawell that would be my utopia20:54
crinklewe don't really want acceptance tests to pass if there are no acceptance tests20:55
*** teran has quit IRC20:55
anteayafair point20:55
*** dprince has quit IRC20:55
anteayaany way of adding a message to the failure stating that the reason it failed is due to absence of the expected directory of tests?20:55
crinklein nibalizer's paste it says "cannot load such file"20:56
crinklewhich seems clear to me20:56
anteayaand that loaderror comes from rspec?20:57
*** mtanino has joined #openstack-infra20:57
crinkleyes20:57
*** sputnik13 has quit IRC20:57
anteayaokay thanks20:57
jogofungi: there is something wrong with status.openstack.org/elastic-recheck/ it hasn't been updating20:57
jogoI am running some of the scripts locally to see if anything is broke on that side20:58
*** kgiusti has quit IRC20:58
openstackgerritWeidong Shao proposed openstack-infra/project-config: Grant push tag privilege to compass-core group  https://review.openstack.org/14190320:58
jogobut haven't found anything yet (just finished running the unclassified tool)20:58
jogois it possible to get a copy of the logs20:58
fungijogo: takign a look now20:58
jogofungi: thanks20:58
*** prad has joined #openstack-infra20:58
*** otter768 has joined #openstack-infra20:59
*** doug-fish has quit IRC20:59
fungijogo: hrm... 102 processes stretching back 6 hours or more21:00
fungijogo: i think the flock isn't right21:00
openstackgerritColleen Murphy proposed openstack-infra/project-config: Run acceptance tests without rake  https://review.openstack.org/14172821:00
jogoflock?21:00
*** Ng has quit IRC21:00
*** david-ly_ has joined #openstack-infra21:00
fungijogo: the update is run under a flock on /var/lib/elastic-recheck/er_safe_run.lock21:01
fungifile lock21:01
*** dmellado has quit IRC21:01
*** ddieterl_ has joined #openstack-infra21:01
*** baoli has quit IRC21:01
*** dangers_away has quit IRC21:01
*** marcusvrn has quit IRC21:02
*** esker has quit IRC21:02
*** adalbas has quit IRC21:02
*** Swanson has quit IRC21:02
*** grue_pm_ has quit IRC21:02
*** lifeless has quit IRC21:02
*** gingerjiang has quit IRC21:02
*** vipul has quit IRC21:02
*** ekarlso- has quit IRC21:02
fungijogo: the mail spool is full of tracebacks about timeouts querying logstash too21:02
*** ddieterly has quit IRC21:02
*** david-lyle has quit IRC21:02
*** ctlaugh has quit IRC21:02
*** yjiang5 has joined #openstack-infra21:02
anteayanibalizer crinkle what would happen if you merged the patch that creates the spec/ directory first?21:02
*** tkelsey has quit IRC21:03
jogofungi: ahh maybe we need some sort of timeout for that job?21:03
*** ctlaugh has joined #openstack-infra21:03
*** dangers_away has joined #openstack-infra21:03
jogosay an hour?21:03
openstackgerritWayne Warren proposed openstack-infra/jenkins-job-builder: Add plugins_info to module registry object.  https://review.openstack.org/13292721:03
openstackgerritWayne Warren proposed openstack-infra/jenkins-job-builder: Update 'timeout' wrapper module  https://review.openstack.org/12946721:03
*** baoli has joined #openstack-infra21:03
fungijogo: well, not sure yet. i'm going to clean up the process pileup first and then see what's actually broken21:03
*** otter768 has quit IRC21:03
*** Longgeek has quit IRC21:03
*** erikmwilson has quit IRC21:03
dhellmannfungi: looks like picking a different branch name introduced an issue with the requirements check: https://jenkins06.openstack.org/job/gate-oslo.db-requirements/45/console21:03
crinkleanteaya: well we wouldn't be able to verify that the test works, since it would be running a different test between when we merge that and when we merge the -config patch21:04
*** grue_pm has joined #openstack-infra21:04
*** lifeless has joined #openstack-infra21:04
crinklebut that's not my patch so nibalizer ^21:04
jogofungi: cool, local tests didn't find anything failing21:04
anteayacrinkle: okay I wondered if that was the case, but thought I'd ask21:05
anteayathanks21:05
*** erikwilson has quit IRC21:06
dhellmannfungi: I don't think we want a feature/1.2 branch on the global requirements list; I wonder if we should go back to the idea of bringing stable/juno up to date to 1.2.021:07
fungidhellmann: oh, that's a good point about the requirements check jobs21:08
dhellmannhow did you get around this over the weekend?21:08
fungiclarkb: do you have any thoughts on how we could safely update oslo.db's stab;e/juno branch from 1.0 plus backported patches to 1.2.0?21:09
clarkbmerge 1.2.0 into it21:09
nibalizeranteaya: hrm?21:09
fungidhellmann: the fixes i was trying to backport in pbr were not reqs changes, and i was only rewinding to the most recent release tag21:09
clarkblike a feature branch21:09
fungiclarkb: yeah, that's what i figured we'd need to do to retain ff-only safeness21:09
*** vipul has joined #openstack-infra21:10
asselinmmedvede, when do you think this will merge? https://review.openstack.org/#/c/137156/21:10
fungiclarkb: however, that means that we then release a 1.2.1 which is based on a 1.2.0-like history with a merge commit21:10
anteayareviewed and commented21:10
fungiclarkb: so not entirely sold on whether that's a clean process to follow, but maybe so21:10
anteayanibalizer: crinkle answered me21:10
clarkbfungi I think the merge commit is required for fast forwarding21:11
nibalizerokay21:11
*** sputnik13 has joined #openstack-infra21:11
fungiclarkb: the other question is, if this is likely to crop up for other libraries in the future, how do we accommodate it repeatably?21:11
jeblairclarkb, fungi: https://bitbucket.org/pypa/bandersnatch/pull-request/12/add-option-to-dir-hash-index-files/diff21:11
*** erikmwilson has joined #openstack-infra21:11
mattoliverauMorning21:12
clarkbfungi I think we dont stable/juno instead we stable/x21:12
dhellmannfungi, clarkb : the only conflicts I get when I merge are in the requirements lists. Do I need to make this a special kind of merge, or can i just "git merge 1.2.0" make the fixes, then commit?21:12
clarkbmaybe but that is hard for other reasons21:12
fungijeblair: is that the proposed solution to the afs node count limit?21:12
*** erikmwilson has quit IRC21:12
*** adalbas has joined #openstack-infra21:12
jeblairfungi: yep.  ran that on afstest and 'vos release', so what's there is the output21:13
dhellmannclarkb: like stable/1.2? I like the idea of that21:13
*** amcrn has quit IRC21:13
dhellmannwe could call it something other than stable, too, if we need to do that21:13
clarkbdhellmann ya I need to think about that more but I think thats better21:13
fungiclarkb: stable/foo with foo not in icehouse,juno right now breaks the devstack branch matrix, yeah?21:13
clarkbfungi yes so would need some work21:13
fungik21:13
*** dpaterson has joined #openstack-infra21:13
fungiwas pretty sure the feature matrix barfed when i tried that with pbr over the weekend21:14
clarkbyup21:14
*** erikwilson has joined #openstack-infra21:14
*** erikwilson is now known as erikmwilson21:15
dhellmannwe still have the problem with the requirements compat job though if we don't call the branch stable/juno -- because the job assumes the branch of the lib and the branch of the requirements list are the same21:15
*** ekarlso- has joined #openstack-infra21:15
dhellmannfungi, clarkb : the only conflicts I get when I merge are in the requirements lists. Do I need to make this a special kind of merge, or can i just "git merge 1.2.0" make the fixes, then commit?21:15
dhellmannI haven't pushed a merge commit to gerrit before21:15
clarkbdhellmann I think making fixes then committing is what you want21:15
*** Swanson has joined #openstack-infra21:16
mmedvedeasselin: the https://review.openstack.org/#/c/137156/ is ready to go in whenever. jeblair, are you still willing to shepherd the elasticsearch module split? It has a couple of +2's now.21:16
anteayamattoliverau: morning21:16
*** esker has joined #openstack-infra21:16
*** Sukhdev has joined #openstack-infra21:17
*** marcusvrn has joined #openstack-infra21:17
asselinmmedvede, yes, lgtm. I'll rebase my changes on top of that.21:18
*** Ng has joined #openstack-infra21:19
jeblairmmedvede: yep, aprvd21:19
*** baoli has quit IRC21:20
mmedvedejeblair: thank you. I have rechecked, the seed repository is in sync with system-config21:21
openstackgerritJoe Gordon proposed openstack-infra/devstack-gate: DO NOT MERGE: testing aiopcpu with tempest full  https://review.openstack.org/13650421:24
openstackgerritJoe Gordon proposed openstack-infra/devstack-gate: Set custom cpu_model for live_migrate  https://review.openstack.org/14153021:24
jeblairfungi, clarkb, dhellmann: i believe we always intended to create stable/version-number branches for library projects with no stable/releasename branches21:24
jeblairfungi, clarkb, dhellmann: in the case that we needed them to do a point release21:25
jesusaurusim have some trouble with my nodepool service, it doesn't seem to be getting the events that jenkins is using a node (the node never leaves the "ready" state despite tests being run). how can i best troubleshoot this pipeline?21:25
jeblairfungi, clarkb, dhellmann: we may have forgotten about that when reviewing the feature matrix change21:25
dhellmannjeblair: we've been using stable/name branches for that so far21:25
dhellmannin this case, we need to jump several releases up, though21:26
jeblairdhellmann: yeah, i meant for projects with no stable/releasename branch...21:26
jeblairdhellmann: for projects with one -- why do you need a 1.2 branch that is not juno?21:26
dhellmannjeblair: ok. The requirements job breaks on those because there's no feature/1.2 branch in the requirements project21:26
dhellmannthe juno version of oslo.db was 1.0 and we have had a couple of point releases21:27
dhellmannwe need a version of the lib with the requirements for stable/juno's version of sqlalchemy21:27
dhellmannsince master and stable/juno don't agree on those requirments, it needs to be a version < 1.3.021:27
dhellmann1.2.0 was the last release that worked with juno, so...21:28
*** sarob has joined #openstack-infra21:28
jeblairso master of oslo.db is 1.3, juno is 1.0, however, juno versions of projects are actually using 1.2?21:29
dhellmannjeblair: 1.2 does work with juno versions of project (we just released 1.3 today)21:29
fungijeblair: the "stable/juno" branch was used to backport fixes to 1.0 which was the most recent version at the time of the juno release21:29
dhellmannright21:29
*** atiwari has quit IRC21:29
fungibut apparently there is a desire for the stable/juno branch to track master until master ceases to work with stable/juno21:30
fungiexcept that we also want to backport patches to it that we haven't released from master yet?21:30
dhellmannfungi, clarkb : git review says "remote rejected] HEAD -> refs/publish/stable/juno/bug/1394298 (you are not allowed to upload merges)"21:30
fungithat's the part i've been unable to reconcile with the use case21:30
fungidhellmann: right, that will need an acl adjustment21:31
jeblairis this another situation that would suggest that we cap or freeze dependencies in stable branches when they are cut?21:31
dhellmannfungi: I'm not sure what you mean about backporting unreleased fixes?21:31
dhellmannjeblair: we did try that, and that prevents grenade from upgrading a deployment so we undid it21:31
*** jedimike has joined #openstack-infra21:31
fungidhellmann: you said you backported fixes (from somewhere) to the stable/juno branch of oslo.db, but that oslo.db should work with master (up until it didn't as of 1.3.0)21:32
dhellmannjeblair: now, we could have tried a higher cap, but neither sdague nor I had the time to work out what those numbers should be21:32
*** ihrachyshka has joined #openstack-infra21:32
fungier, juno should work with oslo.db master up until 1.3.0 i mean21:32
jeblairbecause the straightforward resolution would seem to me to be to release 1.0.X to fix juno, but that is complicated by the fact that juno is really using 1.2, though unspecified.21:32
dhellmannfungi: we follow the usual backport process, though, so those changes have to be in oslo.db master before they go into a branch21:32
jedimikeclarkb, hi, we're having a problem with jenkins and the zmq publisher. Jenkins is running, jobs are running and passing/failing, but it's not opening port 8888 for nodepool to connect to. Any ideas where we should start looking?21:33
dhellmannjeblair: right, and master is now >=1.1 and so we can't have a cap in juno lower than that21:33
fungidhellmann: right, i think the multiple use cases being expressed may be irreconcilible. still trying to think through the interactions there21:33
dhellmannk21:33
jeblairjedimike, jesusaurus: we might have seen the zmq plugin in jenkins fail; try disable/re-enable zmq publishing in jenkins, and if that doesn't work, restart jenkins21:34
jeblairjedimike, jesusaurus: we don't really have any data on whether or how often this happens because it is hard to debug21:34
jedimikejeblair, ok we'll try enable/disable, we've just restarted and the publisher didn't come back up21:34
jesusaurusjeblair: thanks21:34
jeblairjedimike, jesusaurus: also try "zmq-stream" in nodepool/tools to help debug21:35
fungidhellmann: i think what we want is to be able to branch from any release of a library to backport fixes. having a rolling branch to aggregate those is going to get messy21:35
dhellmannI tried to summarize things in http://lists.openstack.org/pipermail/openstack-dev/2014-December/053021.html21:35
anteayadhellmann: so just so this doesn't get lost, this is dougwig's script for splitting out advanced services from neutron last week, based on your script for oslo: https://github.com/dougwig/split-repo/blob/master/service-split.sh21:35
dhellmannfungi: I agree21:35
fungidhellmann: however, that means that we can no longer di strict branch name mapping in requirements checks21:35
dhellmannfungi: right - and interestingly we need oslo.db 1.2 to be compatible with the requirements of juno, but it might not be :-/21:36
fungiand i'm not immediately seeing how we can continue doing global-requirements enforcement on changes to requirements files in libraries21:36
dhellmannoh, wait, I guess it has to be so far because it has been working -- forget that21:37
fungiunless we somehow embed additional metadata in the release about what version of openstack it should be tested against21:37
dhellmannyeah, for a 1.2 branch, do we check against juno or kilo?21:37
fungier, in the branch from which we're going to release the backport point versions21:37
*** dkliban is now known as dkliban_bbr21:37
*** dkliban_bbr is now known as dkliban_brb21:38
*** doug-fish has joined #openstack-infra21:38
dhellmannyeah, we could easily put a file in the branch and have the job read it -- but what would the file say in this case?21:38
*** teran has joined #openstack-infra21:38
fungisomething like "stable/juno" i think21:38
dhellmannso that means we would have to change all of the requirements of 1.2 to match the requirements of stable/juno to get the job to pass21:38
jedimikejeblair, thanks, we're doing the disable/enable thing now21:38
dhellmannbecause for 1.2 we have already bumped several requirements21:38
fungiwe would presumably want to treat the stable/1.2 branch like part of juno for testing purposes21:38
dhellmannyeah21:39
fungiwhich we can't retroactively solve at this point, right21:39
jeblairit seems like 1.2 is part of juno...21:39
dhellmannsemver would tell us that release number should be 1.3, since it has requirements changes :-|21:39
jeblairbecause juno says >1.0 and 1.2 matches.21:39
fungijeblair: except it sounds like 1.2 has requirements which are newer than the stable/juno requirements list21:39
jeblairsorry >=1.021:39
dhellmannwell, 1.3 is > 1.0 but 1.3 doesn't work21:40
dhellmann1.2 does have newer requirements -- I don't know if the older ones would work, I only updated sqlalchemy21:40
fungiif we'd already had this "should work with juno" flag in place somewhere that we could match on, that would allow us to force it to be tested against the juno reqs list21:40
*** _nadya_ has quit IRC21:41
fungiand refuse addition of post-juno requirements until the developers had decided to move on to a breaking version21:41
* dhellmann wonders how different the 1.1 requirements are from juno21:41
*** teran_ has quit IRC21:41
fungibut this of course means that we need to plan in advance when we will start developing things which won't work with the last release, which i suspect we've been slack about before now21:41
jeblairdhellmann: how does putting a version cap on the old side prevent an upgrade?21:41
jogofungi: thanks for fixing http://status.openstack.org/elastic-recheck21:42
*** baoli has joined #openstack-infra21:42
dhellmannjeblair: grenade fails, but I forget the exact scenario21:42
fungijeblair: it breaks upgrading _if_ the new side also declares a minimum version greater than the maximum version supported by the previous release21:42
dhellmannyeah, I don't know if grenade is trying to update the libraries first and then the apps, or one app at a time, or what21:43
openstackgerritMerged openstack-infra/project-config: Add puppet-elasticsearch as split out module  https://review.openstack.org/13715621:43
jeblairfungi: that's confusing.  :(21:43
fungijogo: all i did was kill a bunch of copies of e-r query update processes on status.o.o and let cron start new ones21:43
jeblairdhellmann: but yeah, i could see how that approach would break21:43
dhellmannjeblair: yeah, I was disappointed since I thought we had worked this out at the summit :-(21:44
jogofungi: do you think it makes sense to add a timeout to those jobs? if so how would I go about adding it?21:44
fungijeblair: the upgrade problem arises if your consecutive server releases have incompatible requirements, since you would potentially have to upgrade multiple services at the same time21:44
dhellmannjeblair: it has something to do with the way we test rolling upgrades by only upgrading part of the stack and then trying to do things with services21:44
*** dmellado has joined #openstack-infra21:44
dhellmannit looks like oslo.db 1.1 has some requirements bumps, too21:45
jeblairi sort of doubt that is going to work unless we split services into venvs21:45
fungijogo: https://git.openstack.org/cgit/openstack-infra/system-config/tree/modules/openstack_project/manifests/pypi_mirror.pp#n6421:46
dhellmannjeblair: yeah, that's what we did at Dreamhost because we didn't want to fight this fight21:46
jeblair(which i think strong requirements enforcement lets us consider doing since we can guarantee installability with one set of packages with that instead of the side effect of a devstack install)21:47
*** atiwari has joined #openstack-infra21:47
jheskethMorning21:47
*** armax has joined #openstack-infra21:47
anteayamorning jhesketh21:48
jogofungi: thanks21:48
fungijogo: i would recommend moving the flock out of the wrapper script and just call it directly from cron like i did for bandersnatch21:48
*** ryanpetrello has joined #openstack-infra21:48
jeblairdhellmann: something i'm still not groking though -- why not release 1.0.X and cap stable/juno to that?21:49
dhellmannjeblair: master needs >=1.1 at this point21:50
dhellmannthat means there would be no overlapping compatible requirement, so grenade fails to upgrade us21:50
openstackgerritMatthew Treinish proposed openstack-infra/elastic-recheck: Add another failure pattern for 1402747  https://review.openstack.org/14191221:50
*** openstackgerrit has quit IRC21:50
*** openstackgerrit has joined #openstack-infra21:50
dhellmannbecause when we created stable/juno we didn't foresee needing to release a new version with a change in requirements, only a bug fiix21:50
*** dhp has joined #openstack-infra21:50
dhellmannjeblair: can we cap setuptools in the stable/juno test environment?21:51
openstackgerritMatthew Treinish proposed openstack-infra/elastic-recheck: Add another failure pattern for bug 1402747  https://review.openstack.org/14191221:51
uvirtbotLaunchpad bug 1402747 in glance "setuptools 8 breaks multi-range version checks" [High,Confirmed] https://launchpad.net/bugs/140274721:51
dstufftit doesn't generally work to cap the version of the installer you want to be installed with21:52
*** jlibosva has quit IRC21:52
dstufftbecause if someone has setuptools 8 installed, and you add a cap on setuptools < 8, they'll install everything with setuptools 8 and as part of that downgrade their setuptools21:52
jeblairdhellmann, fungi: i'm kind of stuck on "how does grenade ever work if it assumes that there will be compatible overlapping versions of all python libraries"21:53
fungidhellmann: we explicitly don't have a requirement on setuptools because there's a chicken-and-egg problem with declaring you need an older version than you're running21:53
dhellmannjeblair: I don't know. sdague may21:54
jeblairthat just seems like a requirement that i would expect to be impossible to satisfy21:54
fungidhellmann: when we "pinned" it on our workers, we did so by changing the version we preinstall21:54
openstackgerritRamy Asselin proposed openstack-infra/project-config: Prepare project-config for puppet module split #2  https://review.openstack.org/14054821:54
dhellmannfungi: and I guess we use the same workers for juno and master?21:54
fungidhellmann: yes21:54
*** emagana has joined #openstack-infra21:55
jogofungi: ack21:56
fungidhellmann: also it's only feasible for the moment because we're running with virtualenv/pip which haven't updated to embed newer versions of setuptools yet21:56
jeblairsdague: what am i missing regarding grenade ^ ?21:56
sdaguejeblair: until recently we had compatible overlaps21:57
sdaguebecause we kept all of stable unpinned21:57
openstackgerritMatthew Treinish proposed openstack-infra/elastic-recheck: Add another failure pattern for 1402747  https://review.openstack.org/14191221:58
jeblairsdague: but doesn't that assume that we will never have a third-party dependency that breaks backwards compat between a release we use in juno and a release we use in master?21:58
*** jlibosva has joined #openstack-infra21:58
fungisdague: which as it turns out is misleading, because we test changes to the libraries with requirements master but expect stable release branches which don't follow the same global requirements set to continue working with them21:58
dhellmannjeblair, fungi, sdague: would it help us to revert dstufft's patch changing the version of sqlalchemy we use in master to match what we use in juno? http://git.openstack.org/cgit/openstack/requirements/commit/?id=f02eb22ad8a5a18835f5755c619a25fbf24a245321:58
dhellmannbecause then I could release a version of 1.2 that tests against master requirements21:59
sdaguejeblair: possibly, but that's the system we had. I will in no way say it's the best system, but it caught a bunch of bugs in OpenStack21:59
jeblairsdague: it seems like a normal grenade job should be able to upgrade from capped stable requirements to uncapped master requirements no matter the leap.  and perhaps the rolling-upgrade jobs need to do something different22:01
sdaguejeblair: so... sorry, rebuilding context22:01
jeblairsdague: like install into a virtualenv so that they can similarly make the leap, but on a service-by-service basis22:01
sdaguea normal grenade can do that22:01
sdagueexcept....22:01
*** yamamoto has joined #openstack-infra22:01
cody-somervillezaro: ping22:01
sdaguethings like ceilometer install into other packages paste pipelines22:02
sdagueso our normal offline upgrade model breaks, because we assumed that we could shut everything down22:02
sdagueupgrade and start services in a reasonable order22:02
*** mrunge has quit IRC22:02
jeblairwould a process of 'shut all down; upgrade all; start all' address that?22:03
sdaguebut when one software package installs into the execution space of another, then there is a coupling that wasn't known until recently (there is an ML thread on this)22:03
sdagueyep22:03
openstackgerritMatthew Treinish proposed openstack-infra/elastic-recheck: Expand failure pattern for bug 1402747  https://review.openstack.org/14191222:03
uvirtbotLaunchpad bug 1402747 in glance "setuptools 8 breaks multi-range version checks" [High,Confirmed] https://launchpad.net/bugs/140274722:03
*** mattfarina has quit IRC22:03
sdagueexcept, that's a whole bunch of rework22:03
jeblairsdague: is that path agreed upon?22:04
*** dkliban_brb is now known as dkliban22:04
*** ildikov has quit IRC22:04
sdagueI don't know that there is any agreed on path here22:04
sdaguealso, got to end my day, call of the family22:05
sdaguetalk to folks later22:05
fungiit seems like this is partly an atrifact of our previous limitation of needing to be able to test upgrades on an all-in-one server environment, and what we really want to be able to test is that different versions of the software can work together successfully. so the need for coinstallability of versions from different releases is more of a symptom of our testing design?22:05
dhellmannthat sounds right22:06
*** sarob has quit IRC22:06
jeblairfungi: well, that's what i was getting at earlier, but the ceilometer case still makes it different22:06
dhellmannceilometer case?22:06
*** mrmartin has quit IRC22:06
jeblairwhat sdague just described -- ceilometer installing itself into other projects execution space22:06
dhellmannoh, I missed that22:06
dhellmannyeah, that makes sense22:06
fungirather than interacting through well-defined interfaces22:06
*** bswartz has quit IRC22:07
dhellmannwell, swift's interface for emitting notification was "add something to the wsgi pipeline"22:07
dhellmannbecause they won't add it directly to swift22:07
jeblairat any rate, it seems like the described method of altering grenade would solve the problem22:07
*** ZZelle has joined #openstack-infra22:07
jeblairi'm sort of sad that we don't know if anyone is working on it22:07
dhellmannat least, that's my understanding22:07
*** stpierre has quit IRC22:07
dhellmannall of that sounds like a long term fix, so here's a short term idea:22:08
jeblairbecause this seems like a pretty big design flaw that is certain to make things very unecessarily difficult22:08
*** pelix has quit IRC22:08
jeblairwe're just "lucky" that it broke on libraries that we manage first22:08
openstackgerritWayne Warren proposed openstack-infra/jenkins-job-builder: Update 'timeout' wrapper module  https://review.openstack.org/12946722:09
zarocody-somerville: yo!22:09
*** emagana has quit IRC22:09
dhellmannchange the requirements check job to look at a file in the repo being tested to find the branch of the requirements repo to use; set up the feature/1.2 branch of oslo.db to refer to master in that file; change the master requirements for sqlalchemy to match stable/juno22:09
dhellmann(in the global list); then change feature/1.2 requirements to that same string; release 1.2.1 from that22:10
dhellmannjeblair: yes, indeed22:10
jeblairdtroyer: do you know if there are plans to rework grenade to stop all/upgrade all/start all ?22:10
fungito put the current paradox in concrete terms, we're saying we expect stable/juno servers to work reliably with oslo.db 1.1.0 and 1.2.0 but we didn't actually test those oslo.db releases with the stable/juno requirements list (and instead declare moving-target requirements from master in those oslo.db releases)22:11
*** david-ly_ is now known as david-lyle22:11
dhellmannfungi, jeblair : let me know what you think of that short-term fix, and if you like it I'll work on patches in the morning22:11
*** sputnik1_ has joined #openstack-infra22:11
jeblairdtroyer: ^ see conversation with sdague above for more context22:12
*** sputnik13 has quit IRC22:12
*** kmartin has quit IRC22:12
jeblairdhellmann: is all of that in service of being able to land changes to feature/1.2 of oslo.db?22:12
*** emagana has joined #openstack-infra22:12
fungidhellmann: if you change the requirements enforcement so that the relevant branch can be declared from a file in the project being tested, we'll probably also want to adjust the requirements sync in devstack to use that too22:12
*** asselin has quit IRC22:12
*** kmartin has joined #openstack-infra22:13
*** mfink has quit IRC22:13
*** asselin has joined #openstack-infra22:13
dhellmannjeblair: well, yes, so that we can have a 1.2.x that has requirements that allows it to be installed for juno tests so that we have a version of oslo.db that works with both juno and master so we can do grenade updates22:13
dhellmannjeblair: oh, I left out the cap oslo.db in juno to < 1.322:13
jogofungi: man flock doesn't explain what "-k" does22:13
jogooh thats because its the command timeout ...22:14
dhellmannfungi: oh, wow, yeah, probably22:14
fungidhellmann: since down the road you'll want to be able to set oslo.db's stable/1.3 branch to test as if it were stable/kilo (so that new non-kilo-compatible requirements don't get added)22:14
*** jlibosva has quit IRC22:14
jeblairdhellmann: yeah, i'm just trying to figure out why you want to change the requirements check job -- what is it blocking?22:14
*** ddieterl_ has quit IRC22:14
dhellmannjeblair: http://logs.openstack.org/94/141894/1/check//gate-oslo.db-requirements/0a860bb/console.html22:14
dhellmann"warning: Could not find remote branch feature/1.2 to clone"22:15
dtroyerjeblair: no long term plans, but that is close to how it was orignally written…start all, stop all, upgrade one at a time and restart.  some of that may have changed recently with the sideways jobs and whatnot22:15
*** ryanpetrello has quit IRC22:15
jeblairdhellmann: right, so it's blocking changes to the feature/1.2 branch of oslo.db22:15
*** ryanpetrello_ has joined #openstack-infra22:16
dhellmannjeblair: to any branch of any project that does not have a similar branch in openstack/requirements22:16
dhellmannbut yeah, immediately it's to oslo.db22:16
*** dustins_ has quit IRC22:16
*** ddieterly has joined #openstack-infra22:16
*** ryanpetrello_ is now known as ryanpetrello22:16
dhellmannit means I couldn't have a feature branch that changed requirements, though22:16
*** ihrachyshka has quit IRC22:17
jeblairdhellmann: feature branches should probably fall back on master requirements22:17
dhellmannI don't know. Short term I'd be happy to cap oslo.db<1.1 in stable/juno but I don't think that's a long term fix.22:17
dhellmannok, we could make the script that smart I guess22:17
*** yfried is now known as yfried|afk22:17
dhellmannrather than specifying it in a file, if the branch isn't found and the name starts with "feature" use master?22:17
*** doug-fish has quit IRC22:18
openstackgerritMatthew Treinish proposed openstack-infra/elastic-recheck: Expand failure pattern for bug 1402747  https://review.openstack.org/14191222:18
uvirtbotLaunchpad bug 1402747 in glance "setuptools 8 breaks multi-range version checks" [High,Confirmed] https://launchpad.net/bugs/140274722:18
jeblairdhellmann: yeah, in devstack-gate for instance we fall back on cross-testing with master22:18
*** annegen__ has quit IRC22:18
*** sputnik1_ is now known as sputnik1322:19
jeblairdtroyer: so i think the fact that we have to have compatible versions of dependencies across major openstack versions is a harmful artificial restriction22:19
dhellmannok, that would be a simpler change22:19
jeblairdtroyer: i don't think it was or should be the intended effect of grenade, but it seems like it is in the status quo22:19
dtroyerit is an artifact of the case of running with mixed releases of things, specifically n-cpu on a separate upgrad path introduced that22:20
jeblairdtroyer: if that's the only hangup, then i think we need to go back to the drawing board on how that test is implemented22:20
*** ddieterl_ has joined #openstack-infra22:20
dtroyerSo it sounds like it is time to start planning son-of-devstack-and-grenade to split the tasks up more clearly, and get as much into venvs from the start as possible22:20
*** ddieterly has quit IRC22:20
*** ildikov has joined #openstack-infra22:21
*** ddieterl_ has quit IRC22:21
jeblairdtroyer: yeah, i think if we want to have isolated environment upgrades, we'll have to do something like that.  that way each environment can do any upgrade it needs (including jumping major incompatible versions)22:21
*** teran_ has joined #openstack-infra22:22
*** ddieterly has joined #openstack-infra22:22
jeblairdtroyer: i think that the requirements jobs leave us in a position where we can still say that at the end of the day, the projcets will all converge on the same set of dependencies at the end of the upgrade22:22
*** ddieterly has joined #openstack-infra22:22
jeblairdhellmann: also, removing the requirements check job from the feature/1.2 branch of oslo.db is an option22:23
*** Masahiro has joined #openstack-infra22:23
openstackgerritMatthew Treinish proposed openstack-infra/elastic-recheck: Expand failure pattern for bug 1402747  https://review.openstack.org/14191222:23
uvirtbotLaunchpad bug 1402747 in glance "setuptools 8 breaks multi-range version checks" [High,Confirmed] https://launchpad.net/bugs/140274722:23
jeblairdhellmann: basically, i don't want to make the rube-goldberg requirements machinery any more complex than it already is; i feel like in the long run, if oslo.db has a stable/juno branch, that's where we ought to be able to make these kinds of fixes, so i'd like the long-term solutions to involve making that happen22:24
dhellmannjeblair, dtroyer : mordred did pitch the idea of a single job that installed everything and ran some basic tests, which would ensure that those requirements sort of work together22:24
jeblairie, fixing grenade so that we can do that.22:24
jeblairdhellmann: ++22:24
*** teran has quit IRC22:25
jeblairdhellmann: (though i do still believe that feature branches should fall back to master in requirements check jobs anyway)22:25
jeblair(regardless of _this_ problem)22:25
dhellmannjeblair: yeah, unfortunately our stable/juno branch is pretty far out of date by now. We did discuss merging 1.2 back into stable/juno, but that opens another can of worms with requirements changes like this because then I have to have 1.2.1 use different requirements from 1.2.0, which is not only a semver violation but also confusing22:25
dhellmannyeah, falling back to master totally makes sense22:25
*** dkranz has quit IRC22:26
dhellmannturning off the check job for that branch is ok with me22:26
dhellmannit means I need to think harder about what requirements update to make, though22:26
openstackgerritJoe Gordon proposed openstack-infra/system-config: Improve er_safe_run  https://review.openstack.org/14192322:26
jogofungi: ^22:26
*** ChuckC has quit IRC22:26
dhellmannjeblair: I think we want 1.2.1 to have the same requirements as master22:26
dhellmannjeblair: but what I have up for review now is the same requirements as juno, so I need to spend more time with a fresh brain on that22:27
jogofungi: I left the script in because I don't think that was the issue. I think you saw a bunch of them due to flock blocking by default22:27
jeblairso my thought process is: fixing grenade lets us cap stable branches which would make stable/juno branches of libraries useful and thus avoid this problem.22:27
*** jedimike has quit IRC22:27
jeblair(for the long term fix)22:27
*** Masahiro has quit IRC22:28
dhellmannyes22:28
* dhellmann looks around for someone with time to rewrite grenade22:28
*** bhunter71 has quit IRC22:29
jeblairi'm hoping that jogo will work with dtroyer on that since jogo did a lot of the n-cpu upgrade work22:29
mtreinishjeblair: heh, good luck with that :)22:29
*** erlon has quit IRC22:29
jeblairdhellmann: so if you want the reqs check job to run to continue to provide safety for your 1.2 work, then maybe doing the feature fallback to master is the way to go22:30
jeblairmtreinish: why?22:30
anteayajeblair: I do believe capping stable branches is something ttx wants, inasmuch as I have agreed to work on a spec for it22:30
* jogo reads backlog22:30
jeblairjogo: would you be willing to help out with thatL22:30
anteayare-writing grenade will have to be part of the spec?22:30
dhellmannjeblair: well, what I really need is to know that devstack-gate works with those requirements, so we can turn off the requirements job22:30
mtreinishjeblair: take a look at the grenade git logs, commits are far and few between22:31
anteayasweston: do check your email for a response from mikal about radar22:31
jogojeblair: help out with what?22:31
jeblairmtreinish: yeah, but what we have is grenade being used in a way it was note designed for, and the unintended side effect is that we are going to _seriously_ shoot ourselves in the foot with that.22:31
jeblairmtreinish: we _might_ be able to dig ourselves out of it this time because we control all the parts involved.  we may not be as lucky next time22:32
jogojeblair: and it sounds like I should say yes to whatever it is22:33
mtreinishjeblair: I'm not disagreeing, I'm just saying that people with grenade knowledge are often busy with 10 other things, so someone spending the time to do a rewrite like that is going to be a long way off22:33
mtreinishhopefully I'm wrong though22:33
* anteaya notes jogo just said yes22:33
jeblairjogo: so grenade currently requires that there be a version of every dependency that can work with both the old and new sides of the upgrade22:33
jogojeblair: right, we don't re-install deps in grenade22:34
jeblairjogo: so that means deps can never change, which is clearly not what we desire22:34
dhellmannjogo: yeah, with the new setuptools and subsequent changes to the sqlalchemy requirements specification, that's now causing a problem for things that use oslo.db22:34
*** yfried|afk is now known as yfried22:35
mtreinishjeblair: they can just in N+1 intervals. You just have to have overlap between releases. So you slowly ratchet up the min version22:35
jogojeblair: agreed, I think its reasonable to tell people to upgrade python deps at the same time as upgrading an openstack service22:35
dhellmannjeblair: hrm, what if we make master sqlalchemy the same as juno, and then release oslo.db 1.4 that uses those settings, then update juno to force it to skip 1.1, 1.2, and 1.3?22:36
*** dizquierdo has joined #openstack-infra22:36
dhellmannjeblair: because oslo.db will work with those versions of sqlalchemy; I don't know why we changed the settings over the weekend22:36
jogojeblair: so  what is the new desired grenade behavior? install new version deps during the pull up phase of grenade22:36
dhellmannjogo: if the point of grenade is to test that individual services can be updated separately, those services could be installed into isolated virtualenvs to allow the dependencies to be updated, too22:37
jogodhellmann: well originally the point of grenade was upgrades AFAIK we didn't clearly specify individual services22:38
jogodhellmann: venvs may be an issue for distros22:38
jeblairmtreinish: problem is that an N+1 interval might be completely incomptabile.  it's completely reasonable to say that juno openstack works with foo<1.0 and kilo openstack works with bar>=1.0.  if the maintainer of foo releases something like that, we have to be able to handle it.22:39
dhellmannjogo: do we upgrade all services at once in grenade?22:39
dhellmannjogo: or do we update one, test, update next, test, etc.22:39
mtreinishjogo: well devstack is probably going to move towards per service venvs eventually, we can discuss doing that in grenade once that's done22:39
jogodhellmann: all at once (but in partial n-cpu, we do all but n-cpu)22:39
*** mfink has joined #openstack-infra22:39
dhellmannjogo: ok. I guess we don't update the dependencies to simulate being able to update the apps separately22:40
jogomtreinish: while I am a big fan of going to per service venvs I think there will be distro backlash (which I am ok wit)22:40
mtreinishjogo: why would they care? devstack/grenade don't use packaged python things (or at least they shouldn't)22:41
*** cnesa2 has quit IRC22:41
dhellmannjogo: we would still be testing that everything can be installed together, but this changes the upgrade test from "one service at a time" to "one container at a time"22:41
jogodhellmann: as long as we test both I think distros will be happy22:42
dhellmannright, we'd need to keep both scenarios22:42
jogodhellmann: so your proposing we migrate grenade to do service venvs?22:42
dhellmannwhatever sort of container makes you happy, but venvs are easy22:42
jogodhellmann: and leave the default config for devstack to not use them?22:42
dhellmannyeah, I think that makes sense22:42
jogodhellmann: makes sense to me too22:42
dhellmannand also have grenade update dependencies22:43
*** atiwari has quit IRC22:43
jogodhellmann: per $container22:43
dhellmannjogo: right22:43
jogodhellmann: would making grenade update dependencies without service $containers be sufficient?22:44
*** doug-fish has joined #openstack-infra22:44
dhellmannjogo: it would fix my problem, but it would no longer tell us if we could update systems without "forklifting" the whole thing22:44
dhellmannso I don't think that's what we really want, long term22:44
jeblairyeah, that would break the ncpu test right?22:44
jogojeblair: well I was thinking for ncpu, we could just restart n-cpu with new deps22:45
mtreinishit could if there were incompatible reqs between releases on n-cpu22:45
jeblairdhellmann: re 1.4: will juno work with oslo.db 1.4?  i thought an incompatability had been introduced?  or is that incompatibility just the sqla version you're talking about changing?22:45
jogomtreinish: exactly22:45
dhellmannjogo: that won't work if the dependencies don't overlap, because you won't be able to start the other services then22:46
*** ociuhandu has joined #openstack-infra22:46
dhellmannjeblair: the incompatibility is the sqla version setting22:46
jeblairmtreinish, jogo: yeah, i think that's just another time bomb of the same variety, and we will need venvs (or equiv) to avoid that22:46
jogodhellmann: and that is something we want t explicitly support right?22:46
dhellmannjogo: so I've been told22:46
adam_gper-service venvs would be useful in the regular devstack run for isolating tempest from the rest of the deployment22:46
jogojeblair dhellmann: if you right a qa-spec about how you want the grenade job to do venvs (which I assume means add venv support to grenade) I would be happy to work on it22:47
jeblairadam_g: i think we already do that by running with tox22:47
mtreinishjeblair: well to an extent, site-packages is enabled in the tempest tox.ini22:47
jeblairjogo: i can't push this, sorry.22:48
jeblairi'm really hoping someone else can take ownership of it22:48
mtreinishjogo: it would have to be added to devstack first, then we could use it in grenade22:49
jogojeblair: ack was hoping dhellmann could define the reqs and you review22:49
openstackgerritDoug Hellmann proposed openstack/requirements: Make SQLAlchemy settings compatible with Juno  https://review.openstack.org/14192722:49
jogomtreinish: right22:50
dhellmannjogo: I don't think I have time to do that, either. :-/22:50
*** sarob has joined #openstack-infra22:51
jogodhellmann:  :/ mtreinish would you be able to help?22:51
mmedvedejeblair: the second part of elasticsearch split is now ready https://review.openstack.org/#/c/137155/22:51
mtreinishjogo: maybe on the review side, but I've got too many plates spinning to write a spec for this. (I'm also not sure I understand all the reqs)22:52
*** yfried is now known as yfried|afk22:52
mmedvedejeblair: thanks22:52
*** kumartin has joined #openstack-infra22:53
jeblairjhesketh, clarkb, fungi, mordred, SergeyLukjanov: i single-core approved https://review.openstack.org/#/c/137155/ due to time constraints22:53
jogomtreinish dhellmann: I don't understand all the reqs either I think22:54
jeblairjogo: you set up the original ncpu partial job, right?  can you drive it?  i think you'll have a lot of help reviewing22:54
jogojeblair: I can  drive it yeah, then ask you folks for reviews to make sure I am not missing anything22:54
jeblairjogo: thanks.  yeah, none of us is going to think of everything.  :)22:55
jogojeblair: but  first want to get some of my aiopcpu stuff landed22:55
openstackgerritWayne Warren proposed openstack-infra/jenkins-job-builder: Update 'timeout' wrapper module  https://review.openstack.org/12946722:56
jogolive migration is blocked on some big devstack-gate changes that hopefully dtroyer will do, but can get tempest-full without live migrate working22:56
jeblairjogo: *nod*.  i think this is a time bomb, and if it goes off again before we fix grenade, we may have to disable some grenade jobs to dig ourselves out.22:57
jogojeblair: agreed, which is why I am diving into this now22:57
jeblairwoot22:57
adam_gjogo, i'd be down to help out with service venvs. i'm in jury duty today and tomorrow, though, with bad courthouse wifi22:58
jeblairjogo: i will pitch in by bumping the d-g changes to the top of my review queue22:58
*** dims has quit IRC22:58
*** packet has quit IRC22:59
jogojeblair: thanks, rebasing my patch series to make it clear what is ready to land22:59
openstackgerritJoe Gordon proposed openstack-infra/devstack-gate: DO NOT MERGE: testing aiopcpu with tempest full  https://review.openstack.org/13650422:59
openstackgerritJoe Gordon proposed openstack-infra/devstack-gate: Set up ssh_known_host based on hostname  https://review.openstack.org/13659622:59
openstackgerritJoe Gordon proposed openstack-infra/devstack-gate: Set custom cpu_model for live_migrate  https://review.openstack.org/14153022:59
*** ChuckC has joined #openstack-infra22:59
openstackgerritJoe Gordon proposed openstack-infra/devstack-gate: Setup /etc/hosts for aiopcpu  https://review.openstack.org/13615822:59
openstackgerritJoe Gordon proposed openstack-infra/devstack-gate: Allow root user to ssh in as stack  https://review.openstack.org/13717622:59
openstackgerritJoe Gordon proposed openstack-infra/devstack-gate: Enable live block migration  https://review.openstack.org/13576822:59
jogoas no reason to land the live migrate patches yet22:59
dhellmannjogo: thanks, I'll help with reviews as well22:59
dhellmannin the mean time, I'm going ahead with the oslo.db 1.4 plan, unless someone can point out a reason that won't work23:00
jeblairdhellmann: i can not think of such a reason, which means nothing.  :)23:00
dougwighi infra, openstack/requirements question.  I'm trying to add the neutron-*aas repos to the project list, but...  they reference neutron as a library in master as "-e git+https://git.openstack.org/openstack/neutron#egg=neutron", which fails in the requirements jenkins jobs.  How should this case be handled?23:01
dhellmannjeblair: yes, I can't either, which means less and may give me the false confidence to deal with it tomorrow :-)23:01
fungisorry, got pulled away for a few minutes--catching up on conversation now23:03
*** andreaf has quit IRC23:03
jeblairdougwig: we have agreed that is undesirable and you need to reference either a specific version or a branch tarball.  note that in devstack jobs, if you add it to the project list in devstack-gate, it will be installed from git.  then the requirements should generally only be used in unit test jobs.23:03
*** dims has joined #openstack-infra23:03
*** achanda has quit IRC23:04
jogojeblair: ok everything under https://review.openstack.org/#/c/136504/ should be ready (and if all goes well that patch will pass tempest-full for aiopcpu, but maybe not neutron)23:04
*** achanda has joined #openstack-infra23:04
dougwigjeblair: so, move it to test-requirements.txt and trust the packager's to get the dependencies right?  (i'm fine with that.)  then we add specific requirements entries on the stable branches, maybe?23:05
*** rkukura_ has joined #openstack-infra23:05
*** sandywalsh_ has joined #openstack-infra23:05
* jogo starts writing the qa-spec23:05
jogofungi: looks like http://status.openstack.org/elastic-recheck/data/uncategorized.html is hung again :(23:06
mtreinishjogo: I didn't think neutron was enabled on aiopcpu (we really should rename that eventually)23:06
*** charz has quit IRC23:06
*** esker has quit IRC23:06
jogomtreinish: it is in the job with neutron and aiopcpu in the name23:06
mtreinishjogo: oh, I didn't think there was one like that23:07
*** esker has joined #openstack-infra23:07
mtreinishbut I see it's there now, I must have just missed it before23:07
*** rkukura has quit IRC23:08
*** rkukura_ is now known as rkukura23:08
*** sandywalsh has quit IRC23:08
jogowow https://jogo.github.io/gate/23:08
*** esker has quit IRC23:09
*** achanda has quit IRC23:09
*** esker has joined #openstack-infra23:09
*** charz has joined #openstack-infra23:09
jeblairjogo: i see a blank page23:12
*** sputnik13 has quit IRC23:12
mtreinishjogo: yeah, nothing is loading for me either23:12
*** yfried|afk is now known as yfried23:12
jrollit works without ssl http://jogo.github.io/gate/23:13
jrollalso, wow.23:13
jogooh right the ssl23:14
*** sputnik13 has joined #openstack-infra23:14
*** esker has quit IRC23:15
fungidougwig: any reason you need a python requirements entry to install neutron for you? that's not going to work out well outside of our ci anyway. we probably just need the relevant jobs to install neutron explicitly23:16
mtreinishjogo: heh, your rolling average is showing :)23:16
jogomtreinish: what should the BP be for the non overlapping dependency upgrades23:16
jogomtreinish: exactly, its sorta neat to see it in action23:16
mtreinishprobably grenade although we don't have bps setup for grenade23:16
fungidougwig: we shouldn't be putting things in requirements or test requirements lists which aren't released to pypi23:16
jogomtreinish: well some of the change is to devstack23:16
dougwigfungi: just an attempt at completeness and naivete because the sub-repos import neutron.23:17
*** Sukhdev has quit IRC23:17
fungidhellmann: i think the sqlalchemy requirement difference in oslo.db 1.3.0 was merely because the logistics around releasing a version for stable weren't forseen23:17
fungidhellmann: so that plan sounds as sane as i could hope for at least23:17
mtreinishjogo: push it up as a devstack bp then, I think that's fine23:17
jogomtreinish: cool23:18
fungijogo: i don't see any lingering/hung processes nor cron e-mail to the recheck account23:19
*** timcline_ has joined #openstack-infra23:19
jogofungi: hrmm23:20
*** teran has joined #openstack-infra23:20
*** emagana has quit IRC23:20
fungijogo: do those log anywhere? the recheckwatch irc bot is logging some tracebacks but i don't see where the update queries would log other than to stdout/stderr23:20
*** rlandy has quit IRC23:20
jogooh wait, its up to date, my bad23:20
fungiexcellent23:21
jogotimestamp is not UTC its local time23:21
fungilocal time of what/where?23:21
jogoData Last Updated: Mon Dec 15 2014 15:00:01 GMT-0800 (PST)23:21
jogoon http://status.openstack.org/elastic-recheck/23:21
fungiData Last Updated: Mon Dec 15 2014 23:00:01 GMT+0000 (UTC)23:21
fungilgtm, yeah23:21
fungiLast Elastic Search Index Update: Mon Dec 15 2014 22:59:32 GMT+0000 (UTC)23:21
fungiokay, i'm going to go grab some dinner then see if i can salvage what's left of the day23:22
fungibbiaw23:22
jogomtreinish: how does  non-overlapping-dependency-upgrades sound?23:22
jogofor bp name23:22
*** yfried is now known as yfried|afk23:23
*** teran_ has quit IRC23:23
*** timcline has quit IRC23:23
*** timcline_ has quit IRC23:24
*** unicell has quit IRC23:24
*** signed8bit has quit IRC23:24
dhellmannfungi: that's what I thought; thank you for the confirmation23:25
*** MarkAtwood has quit IRC23:25
mtreinishjogo: I guess that's fine23:25
*** dims has quit IRC23:25
*** kumartin has quit IRC23:26
*** amitgandhinz has quit IRC23:26
dhellmannanteaya: thanks for the link to https://github.com/dougwig/split-repo/blob/master/service-split.sh (sorry for the delayed response)23:26
dougwigdhellmann: it's a delayed response kind of day.23:27
*** armax has quit IRC23:27
*** andreykurilin_ has quit IRC23:27
dhellmanndougwig: seriously, I'm still catching up :-)23:27
anteayadhellmann: you ahve been busy23:27
openstackgerritMerged openstack-infra/gear: Use non-blocking IO in server  https://review.openstack.org/12875423:27
openstackgerritMerged openstack-infra/system-config: Split out elasticsearch module  https://review.openstack.org/13715523:28
dhellmannthe script looks good; I have plans to refactor ours into a separate script for making a repo containing specific contents only and then the oslo-specific parts23:28
*** annegent_ has joined #openstack-infra23:29
openstackgerritMerged openstack-infra/elastic-recheck: Expand failure pattern for bug 1402747  https://review.openstack.org/14191223:29
uvirtbotLaunchpad bug 1402747 in glance "setuptools 8 breaks multi-range version checks" [High,Confirmed] https://launchpad.net/bugs/140274723:29
*** fandi has joined #openstack-infra23:31
openstackgerritMerged openstack-infra/zuul: Set gearman timeout to 300  https://review.openstack.org/14146023:31
anteayadhellmann: the instructions in the script about getting branches and tags into the seed repo were important points during dougwig's process23:31
*** yamamoto has quit IRC23:33
*** teran has quit IRC23:33
*** emagana has joined #openstack-infra23:35
mordredhey all - sorry for the absence - my day exploded23:37
*** e0ne has quit IRC23:38
openstackgerritAnita Kuno proposed openstack-infra/infra-manual: Adds a link for new developers to use sandbox  https://review.openstack.org/10495123:38
mordredit's gonna take a while to digest scrollback, if there are any things that anyone needs/wants me to attention sooner rather than later - poke me23:38
*** spzala has quit IRC23:38
*** fandi has quit IRC23:39
anteayaexploding days, sounds familiar23:39
swestonanteaya: awesome, thank you :-).  Do you know what the process is to acquire push rights to the repo?23:39
anteayasweston: well it is a stackforge repo23:39
dougwigsweston: put your repo somewhere public and ask infra really, _really_, nicely.23:40
clarkbmordred see lifeless' comment on 14167723:40
anteayaso clone it, create a patch use git review, it will end up on gerrit23:40
clarkbmordred then we should decide if we want to drop the shas from versions23:40
swestondougwig: :-)23:40
anteayasweston: you mean core reviewer rights on it? ask mikal to add you23:40
jheskethanteaya: when you get a chance I've responded to your comment on https://review.openstack.org/#/c/141668/23:41
swestonanteaya: correct, otherwise it won't be very useful ;-)23:41
*** doug-fish has left #openstack-infra23:41
*** dmsimard is now known as dmsimard_away23:41
*** bswartz has joined #openstack-infra23:41
*** dizquierdo has quit IRC23:41
*** gondoi is now known as zz_gondoi23:42
swestonanteaya: thank you23:42
anteayasweston: welcome, go forth and create lovely things23:42
anteayajhesketh: I'm all for either hyphens or underscores23:42
*** BadCub02 has joined #openstack-infra23:43
swestonping mikal ^^23:43
* dstufft comes back and tries to figure out if people are more or less angry at him now23:43
anteayajhesketh: how many jobs would need to be edited if we go all hyphens in the swift jobs?23:43
mordredclarkb: okie23:43
anteayajhesketh: I would even write the patch if you are okay with it23:43
* mordred hands dstufft an apple pie23:43
anteayaor review it in a positive way, your call23:43
jheskethanteaya: I can neaten them up, it'd only be a small handful23:44
swestonanteaya: that is always my objective23:44
* anteaya lines up for pie23:44
jheskethgive me s a second23:44
anteayasweston: awesome23:44
openstackgerritJoshua Hesketh proposed openstack-infra/project-config: Add extra detail to swift indexes  https://review.openstack.org/14128623:44
anteayajhesketh: thank you23:44
dstufftmordred: :D23:44
*** dimtruck is now known as zz_dimtruck23:44
*** jaypipes has quit IRC23:44
anteayajhesketh: I will grep for <ha> in your scripts henceforth23:45
mordredclarkb, dstufft: how about we break 141667 into two patches - one that populates the git hash json file and provides the tool to inspect it23:45
mordredthat's generally useful, as dstufft points out23:45
dstufftlifeless said he was +1 on that extra functionality too23:45
mordredthen the question of "should we continue to have git sha directly in version number" can be considered23:46
dstuffthe was just -1 on removing from the version number23:46
clarkbsure. I think the contwntious thing is removinf it from the versions23:46
clarkbwhich honestly I am no longer expecting to avoid23:46
*** zz_zz_sabari is now known as zz_zz_zz_sabari23:46
dstufftI'm poking at if setuptools/PEP 440 can provide an answer to that23:46
*** mpaolino has joined #openstack-infra23:47
*** cdent has quit IRC23:47
jogodhellmann: trying to understand what went wrong23:47
jogodhellmann: and why we now want to support non overlapping dependencies (for the spec)23:47
jheskethanteaya: lol :P23:50
openstackgerritJoshua Hesketh proposed openstack-infra/project-config: Push dg-tempest-dsvm-full logs to swift  https://review.openstack.org/14166823:50
openstackgerritJoshua Hesketh proposed openstack-infra/project-config: Rename zuul-swift-upload jobs to use hypens  https://review.openstack.org/14194223:50
*** annegent_ has quit IRC23:50
jheskethanteaya: ^ there you go23:50
*** emagana has quit IRC23:50
*** mpaolino has quit IRC23:51
*** aysyd has quit IRC23:51
openstackgerritDean Troyer proposed openstack-infra/devstack-gate: Switch to use local.conf for DevStack runs  https://review.openstack.org/14194323:52
mordredclarkb: I think I'm aligned with you on that23:52
jogojeblair: ^ what is the problem statement for why we need non overlapping dependency upgrades?23:53
clarkbI must return to not being here today. I am +2ish to the change as it exists byt was unable to test properly so didnt actually +223:53
clarkbjogo doing upgrades one service at a time23:54
jogoclarkb: we can do that today if we assume overlapping dependency sets23:54
anteayajhesketh: thank you, I shall eat toast and then review23:54
jheskethsounds good, I'm going to go cafehack :-)23:55
clarkbjogo yes so I thibk saying non overlapping means we dont do that23:55
clarkbjogo maybe I dont understand your question23:55
*** dizquierdo has joined #openstack-infra23:55
notmynameremember when I was asking about getting shortlinks for gerrit dashboards? I made an upstream feature request and have been told "you just need to be made a project owner". since I don't know much about the details of our gerrit deploy, I don't really know how to repond https://code.google.com/p/gerrit/issues/detail?id=305723:55
jogoclarkb: the question is why do we want to allow juno to have require foo<1.0 and kilo require foo>1.123:56
*** annegent_ has joined #openstack-infra23:56
*** asettle has quit IRC23:57
jeblairjogo: juno require foo <1.0 and kilo require foo >= 1.023:57
*** alex7376 has joined #openstack-infra23:57
jeblairto reduce it to the simple case...23:57
*** annegent_ has quit IRC23:57
*** tnovacik has quit IRC23:57
*** alex7376 is now known as asettle23:57
clarkbwe want to do that?23:58
jeblairjogo: for two reasons: 1) because, particularly if we are not the authors of foo, there is no guarantee than foo 1.0 is in any way compatible with 0.9.  we should be able to handle that.23:59
*** avozza is now known as zz_avozza23:59
jeblair(in our current situation, it would be easier to switch from foo to bar in that case than to upgrade foo; that does not make sense to me)23:59

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