Saturday, 2014-12-13

*** bswartz has joined #openstack-infra00:00
*** jklare has joined #openstack-infra00:00
*** zz_sabari is now known as sabari00:01
*** xyang1 has joined #openstack-infra00:01
*** MarkAtwood has joined #openstack-infra00:03
*** bswartz has quit IRC00:04
*** bswartz has joined #openstack-infra00:05
armaxmtreinish: ping00:06
mtreinisharmax: pong00:08
armaxmtreinish: thanks for eyeballing patch https://review.openstack.org/#/c/140851/00:08
armaxmtreinish: quick question though00:08
armaxthe file http://logs.openstack.org/51/140851/23/check//check-neutron-dsvm-functional/168d32e/logs/subunit_log.txt.gz00:08
armaxlooks good to me, what’s going on? can you tell?00:08
mtreinishoh, sure if you download it the file it's either apache, or the http clients assume it's text encoded00:09
mtreinishbut it's really a binary so it'll screw things up00:10
mtreinishone sec, I'll find the d-g patch about it00:10
*** amitgandhinz has joined #openstack-infra00:10
armaxmtreinish: I see00:10
mtreinisharmax: http://git.openstack.org/cgit/openstack-infra/devstack-gate/commit/?id=f1838e89869c6e009c99253c2965132ea28ee30c00:11
armaxmtreinish: gotcha now00:11
armaxnow I am with you00:11
armaxmtreinish: thanks for bearing with me!00:11
armaxmtreinish: I can see that the file is all garbled00:12
armaxmtreinish: you told me yesteday too..but that slipped my mind! my bad00:12
mtreinishno worries00:12
*** amitgandhinz has quit IRC00:15
*** shakamunyi has quit IRC00:15
clarkbmtreinish: uh weshould've fixed that00:16
clarkbmtreinish: so if its still doing that we should figure out why00:16
*** salv-orlando has joined #openstack-infra00:16
mtreinishclarkb: armax has a patch adding it for the neutron functional jobs00:16
mtreinishit should be fixed for the tempest jobs00:17
clarkbmtreinish: it should be fixed for all jobs and that subunit log looks fine to me00:17
*** dannywilson has quit IRC00:17
mtreinishclarkb: it only becomes an issue when you download it00:17
clarkbmtreinish: thats what I did...00:18
clarkbwget00:18
mtreinishdid you try to parse it00:18
mtreinishwith one of the subunit tools?00:18
clarkbnot yet I can though00:18
mtreinishyeah, that's where it screwed up. Like the subunit gearman workers would fail before we did the rename00:18
clarkbworked fine for me00:19
clarkbRan 24 tests in 49.357s00:19
*** palar has joined #openstack-infra00:19
mtreinishhmm, weird. I know it used to fail with a .txt extension before00:19
clarkbfrom `testr load < filepath`00:19
fungiwe added mod_mime_magic or something right?00:20
*** barra204 has quit IRC00:20
clarkbfungi: ya basically says that mime type is not test/plain00:20
clarkband its binary data instead00:20
fungijust trying to remember how/where we fixed that on the logs vhost00:20
clarkb*text/plain00:20
*** Ryan_Lane has quit IRC00:21
*** thedodd has quit IRC00:21
mtreinishoh, it's a subunit v2 stream, before it was subunit v100:21
*** salv-orlando has quit IRC00:22
*** bswartz has quit IRC00:22
clarkbmtreinish: we did that because parsing v2 is faster than parsing v1 and v1 was really slow with neutrno00:22
clarkbmtreinish: and lifeless said v2 ould be default disk format in the near future00:22
*** wenlock has quit IRC00:24
fungiheh, neutrino00:24
fungishould totally be the new name for neutronclient00:25
*** ryanpetrello has quit IRC00:25
*** salv-orlando has joined #openstack-infra00:25
flashgordonclarkb: https://review.openstack.org/#/c/135768/6 can use a fresh review00:26
flashgordonas I fixed the commit message00:26
clarkbflashgordon: perfect much easier to grok now00:27
clarkb+200:27
*** andreykurilin_ has quit IRC00:28
lifelessclarkb: testr doesn't sort00:28
lifelessclarkb: it just prtitions00:28
flashgordonclarkb: thanks, I think another patch or two may have lost your +2 in the rebase00:28
clarkblifeless: I thought you made sort order deterministic00:28
*** salv-orlando has quit IRC00:29
clarkblifeless: because taking a subunit file from one host to another and running analze isoltion wouldn't work right otherwise00:29
lifelessin testtools.run yes within some limits00:29
lifelessno00:29
lifelessbackend issue today00:29
*** sweston_ has joined #openstack-infra00:29
*** sweston has quit IRC00:29
*** sweston_ is now known as sweston00:29
*** dims_ has joined #openstack-infra00:30
*** bswartz has joined #openstack-infra00:32
*** KurtMartin has joined #openstack-infra00:33
*** KurtMartin has quit IRC00:33
*** sweston_ has joined #openstack-infra00:33
*** ryanpetrello has joined #openstack-infra00:34
*** sweston has quit IRC00:35
*** sweston_ is now known as sweston00:35
*** salv-orlando has joined #openstack-infra00:36
*** Masahiro has joined #openstack-infra00:36
*** kmartin has quit IRC00:36
lifelessclarkb: testr doesn't control sort order within a backend is the issue00:38
clarkbgotcha00:38
clarkblifeless: basically backend says here is list and that may or may not be sorted in any particular order and testr won't change what it gets other than partitioning it00:39
*** dimtruck is now known as zz_dimtruck00:39
*** salv-orlando has quit IRC00:40
*** Masahiro has quit IRC00:40
*** patrickeast has quit IRC00:43
*** ryanpetrello has quit IRC00:43
*** MarkAtwood has quit IRC00:46
*** ryanpetrello has joined #openstack-infra00:46
mesteryfungi: Thanks! Cloning and testing now, you rock sir!00:50
*** mmaglana_ has quit IRC00:50
*** ChuckC has quit IRC00:51
*** david-lyle is now known as david-lyle_afk00:51
*** ryanpetrello has quit IRC00:51
openstackgerritMichael Krotscheck proposed openstack-infra/storyboard: Added cron plugin to clean old access tokens.  https://review.openstack.org/14053600:52
*** salv-orlando has joined #openstack-infra00:55
openstackgerritJoe Gordon proposed openstack-infra/devstack-gate: DO NOT MERGE: testing aiopcpu with tempest full  https://review.openstack.org/13650400:55
openstackgerritJoe Gordon proposed openstack-infra/devstack-gate: Set custom cpu_model for live_migrate  https://review.openstack.org/14153000:55
*** salv-orlando has quit IRC00:55
*** shashankhegde has quit IRC01:02
*** talluri has joined #openstack-infra01:03
*** talluri has quit IRC01:06
*** palar has quit IRC01:06
HenryGarmax: around?01:09
armaxHenryG: yes, I am01:09
HenryGarmax: Can vendor drivers for VPN/FW/LB also decompose?01:09
armaxHenryG: dougwig and I thought that this could happen at a later stage01:10
armaxHenryG: I think his spec captures this point, as in their community is still growing up and they may want to still be close together01:10
*** ChuckC has joined #openstack-infra01:11
armaxHenryG: it’s like a marriage, in the early years lots of love, in the late years everyone sleeps in his/her own room01:11
HenryGarmax: :)01:12
*** ryanpetrello has joined #openstack-infra01:12
*** Ryan_Lane has joined #openstack-infra01:14
*** salv-orl_ has joined #openstack-infra01:21
*** salv-orl_ has quit IRC01:22
*** salv-orl_ has joined #openstack-infra01:22
*** gyee has quit IRC01:23
*** ryanpetrello has quit IRC01:24
dougwigarmax: too much truth there.  :)01:27
armaxdougwig: oh well, it’s been a long week01:27
dougwigLol01:27
*** salv-orl_ has quit IRC01:35
*** salv-orlando has joined #openstack-infra01:36
*** sabari is now known as zz_sabari01:37
*** shakamunyi has joined #openstack-infra01:39
*** barra204 has joined #openstack-infra01:39
*** dims_ has quit IRC01:43
*** dimsum__ has joined #openstack-infra01:43
*** shakamunyi has quit IRC01:44
*** dimsum__ has quit IRC01:48
*** dimsum__ has joined #openstack-infra01:48
*** barra204 has quit IRC01:49
*** zhiwei has joined #openstack-infra02:01
*** ryanpetrello has joined #openstack-infra02:02
lifelessclarkb: nearly02:06
lifelessclarkb: testr says 'here is a list'02:06
lifelessclarkb: and backend runs in whatever order it wants02:06
lifelessclarkb: e.g. random, or sorted, or topologically sorted, or ...02:06
lifelessclarkb: testr needs to examine what comes back to determine isolation result validity and meaning02:07
*** palar has joined #openstack-infra02:09
*** zhiwei has quit IRC02:13
*** ryanpetrello has quit IRC02:15
*** zhiwei has joined #openstack-infra02:19
*** ivar-laz_ has joined #openstack-infra02:24
*** Masahiro has joined #openstack-infra02:25
*** ivar-laz_ has quit IRC02:25
*** ivar-laz_ has joined #openstack-infra02:25
*** ivar-lazzaro has quit IRC02:28
*** Masahiro has quit IRC02:29
*** ryanpetrello has joined #openstack-infra02:30
*** ZZelle_ has quit IRC02:31
*** rkukura_ has joined #openstack-infra02:31
*** lttrl has quit IRC02:31
*** rkukura has quit IRC02:32
*** rkukura_ is now known as rkukura02:32
*** zhiwei has quit IRC02:33
*** zhiwei has joined #openstack-infra02:36
*** zhiwei has quit IRC02:37
*** palar has quit IRC02:42
*** ryanpetrello has quit IRC02:47
*** adalbas has quit IRC02:50
*** mmaglana has joined #openstack-infra02:52
*** mmaglana has quit IRC02:52
*** zz_sabari is now known as sabari02:52
*** Ryan_Lane has quit IRC02:56
*** stevemar has quit IRC02:58
*** talluri has joined #openstack-infra02:59
*** pc_m has quit IRC03:06
*** sweston has quit IRC03:07
*** ivar-laz_ has quit IRC03:08
*** sweston has joined #openstack-infra03:09
*** Ryan_Lane has joined #openstack-infra03:18
*** Ryan_Lane has quit IRC03:19
*** Ryan_Lane has joined #openstack-infra03:26
*** liusheng has quit IRC03:27
*** liusheng has joined #openstack-infra03:28
*** Ryan_Lane has quit IRC03:29
*** ildikov has joined #openstack-infra03:30
*** Ryan_Lane has joined #openstack-infra03:36
*** xyang1 has quit IRC03:40
*** Masahiro has joined #openstack-infra03:41
*** Ryan_Lane has quit IRC03:42
*** Ryan_Lane has joined #openstack-infra03:43
*** Masahiro has quit IRC03:45
*** Ryan_Lane has quit IRC03:51
*** boris-42 has quit IRC03:53
*** dimsum__ has quit IRC03:59
*** dimsum__ has joined #openstack-infra04:00
*** thedodd has joined #openstack-infra04:00
*** erikmwilson has quit IRC04:01
*** thedodd has quit IRC04:01
*** dimsum__ has quit IRC04:04
*** MarkAtwood has joined #openstack-infra04:05
*** mfink has quit IRC04:17
*** mfink has joined #openstack-infra04:17
*** dpaterson has joined #openstack-infra04:19
*** eharney has quit IRC04:20
*** sabari is now known as zz_sabari04:32
*** eharney has joined #openstack-infra04:33
*** talluri has quit IRC04:34
*** harlowja is now known as harlowja_away04:34
*** SumitNaiksatam has joined #openstack-infra04:46
*** marun has quit IRC04:46
*** sweston_ has joined #openstack-infra04:53
*** sweston has quit IRC04:54
*** sweston_ is now known as sweston04:54
*** hdd has quit IRC04:56
*** dpaterson has quit IRC05:23
*** Masahiro has joined #openstack-infra05:29
*** tjones2 has quit IRC05:31
*** Masahiro has quit IRC05:34
*** liusheng has quit IRC05:39
*** liusheng has joined #openstack-infra05:40
*** MarkAtwood has quit IRC05:43
*** bhunter71 has quit IRC05:44
*** liusheng has quit IRC05:48
*** hdd has joined #openstack-infra06:01
*** MarkAtwood has joined #openstack-infra06:03
*** nelsnelson has quit IRC06:20
*** zz_sabari is now known as sabari06:24
*** sabari is now known as zz_sabari06:26
*** achanda has joined #openstack-infra06:28
*** rkukura_ has joined #openstack-infra06:36
*** rkukura has quit IRC06:36
*** rkukura_ is now known as rkukura06:36
*** achanda has quit IRC06:40
*** achanda has joined #openstack-infra06:40
*** otter768 has quit IRC06:41
*** achanda_ has joined #openstack-infra06:43
*** achanda has quit IRC06:45
*** reed has quit IRC06:56
*** hdd has quit IRC07:06
*** nikil22 has joined #openstack-infra07:07
nikil22hi in devstack gate is it possible to generate localrc file form particular checking. Because in CI system everything  works fine for me except its taking always the master branch and not the newly checked in code form gerrit system07:14
*** Masahiro has joined #openstack-infra07:15
*** Masahiro has quit IRC07:19
openstackgerritMatthew Treinish proposed openstack-infra/subunit2sql: Add --average option to sql2subunit cli  https://review.openstack.org/13211907:21
openstackgerritMatthew Treinish proposed openstack-infra/subunit2sql: Add new db api methods for getting test data from runs  https://review.openstack.org/14154707:21
openstackgerritMatthew Treinish proposed openstack-infra/subunit2sql: Refactor sql2subunit to use get_tests_run_dicts_from_run_id  https://review.openstack.org/14154807:21
*** enikanorov has joined #openstack-infra07:23
*** achanda_ has quit IRC07:24
*** enikanorov_ has quit IRC07:26
*** achanda has joined #openstack-infra07:28
*** melwitt has quit IRC07:29
*** nikil22 has quit IRC07:34
*** achanda has quit IRC07:36
*** nikil22 has joined #openstack-infra07:40
*** liusheng has joined #openstack-infra07:54
*** rkukura_ has joined #openstack-infra08:00
*** armax has quit IRC08:01
*** rkukura has quit IRC08:02
*** rkukura_ is now known as rkukura08:02
*** dimsum__ has joined #openstack-infra08:03
*** Longgeek has joined #openstack-infra08:04
nikil22hi in CI system it clone neutron repo exactly the checked in code. But in localrc file i don't see the repo url. So please let me know how to pull exactly the checked in code and run the tempest. ex: http://paste.openstack.org/show/150304/08:05
*** Longgeek has quit IRC08:07
*** Longgeek has joined #openstack-infra08:07
*** dimsum__ has quit IRC08:08
*** e0ne has joined #openstack-infra08:15
*** achanda has joined #openstack-infra08:20
*** mrmartin has joined #openstack-infra08:26
*** otter768 has joined #openstack-infra08:42
*** otter768 has quit IRC08:47
*** mrmartin has quit IRC08:57
*** rkukura_ has joined #openstack-infra09:03
*** MarkAtwood has quit IRC09:03
*** Masahiro has joined #openstack-infra09:04
*** rkukura has quit IRC09:06
*** rkukura_ is now known as rkukura09:06
*** e0ne has quit IRC09:07
*** HeOS has quit IRC09:08
*** zz_avozza is now known as avozza09:09
*** Masahiro has quit IRC09:09
*** koolhead17 has joined #openstack-infra09:09
*** koolhead17 has joined #openstack-infra09:09
*** liusheng has quit IRC09:11
*** liusheng has joined #openstack-infra09:12
*** MaxV has joined #openstack-infra09:24
*** Guest77493 has joined #openstack-infra09:25
*** liusheng has quit IRC09:29
*** liusheng has joined #openstack-infra09:30
*** mrmartin has joined #openstack-infra09:47
*** fandi has quit IRC09:48
*** liusheng has quit IRC09:49
*** liusheng has joined #openstack-infra09:49
*** hashar has joined #openstack-infra09:51
nikil22hi in devstack-gate how to specify the reop/branch/commit ID. I get this Information in jenkins but not sure how to make  job to pull the exact checked in version and run the devstack09:52
*** hashar has quit IRC10:03
*** achanda has quit IRC10:06
*** sweston has quit IRC10:06
*** tnovacik has joined #openstack-infra10:07
*** Guest77493 has quit IRC10:08
*** fandi has joined #openstack-infra10:14
*** MaxV has quit IRC10:23
*** mrmartin has quit IRC10:32
*** enikanorov has quit IRC10:36
*** zz_sabari is now known as sabari10:37
*** otter768 has joined #openstack-infra10:43
*** koolhead17 has quit IRC10:47
*** otter768 has quit IRC10:47
*** Masahiro has joined #openstack-infra10:53
*** Masahiro has quit IRC10:57
*** ZZelle has quit IRC10:57
*** ZZelle has joined #openstack-infra10:58
*** asselin has quit IRC11:16
*** tnovacik has quit IRC11:17
*** MaxV has joined #openstack-infra11:24
*** sabari is now known as zz_sabari11:41
*** salv-orlando has quit IRC11:44
*** avozza is now known as zz_avozza11:46
*** _nadya_ has joined #openstack-infra11:46
*** tnovacik has joined #openstack-infra11:48
*** boris-42 has joined #openstack-infra11:50
*** pblaho has joined #openstack-infra11:54
*** andreykurilin_ has joined #openstack-infra11:55
*** MaxV has quit IRC11:58
*** pblaho has quit IRC12:00
*** achanda has joined #openstack-infra12:01
*** amotoki has joined #openstack-infra12:01
*** salv-orlando has joined #openstack-infra12:02
*** MaxV has joined #openstack-infra12:02
*** dimsum__ has joined #openstack-infra12:06
*** smoser has quit IRC12:07
*** MaxV has quit IRC12:08
*** dimsum__ has quit IRC12:10
*** skata_ has quit IRC12:11
*** ociuhandu has quit IRC12:16
*** _nadya_ has quit IRC12:16
*** fandi_ has joined #openstack-infra12:18
*** fandi has quit IRC12:18
*** Longgeek has quit IRC12:21
*** Longgeek has joined #openstack-infra12:22
*** Longgeek_ has joined #openstack-infra12:25
*** lttrl has joined #openstack-infra12:25
*** Longgeek has quit IRC12:28
*** zz_avozza is now known as avozza12:36
*** amotoki has quit IRC12:37
*** Masahiro has joined #openstack-infra12:41
*** otter768 has joined #openstack-infra12:44
*** Masahiro has quit IRC12:46
*** rkukura has quit IRC12:47
*** otter768 has quit IRC12:49
*** rkukura has joined #openstack-infra12:49
*** amotoki has joined #openstack-infra13:02
*** lttrl has quit IRC13:06
*** mjturek has quit IRC13:12
*** e0ne has joined #openstack-infra13:19
*** Longgeek_ has quit IRC13:20
*** Longgeek has joined #openstack-infra13:21
*** ryanpetrello has joined #openstack-infra13:21
*** Longgeek_ has joined #openstack-infra13:22
*** ZZelle_ has joined #openstack-infra13:24
*** Longgeek has quit IRC13:25
*** ryanpetrello has quit IRC13:28
*** MaxV has joined #openstack-infra13:31
*** andreykurilin_ has quit IRC13:33
*** avozza is now known as zz_avozza13:35
*** lttrl has joined #openstack-infra13:52
*** salv-orlando has quit IRC14:02
*** boris-42 has quit IRC14:03
*** amotoki has quit IRC14:03
*** Longgeek_ has quit IRC14:05
*** MaxV has quit IRC14:05
*** Longgeek has joined #openstack-infra14:06
*** mrmartin has joined #openstack-infra14:06
*** MaxV has joined #openstack-infra14:07
*** mrmartin has quit IRC14:08
*** Longgeek_ has joined #openstack-infra14:10
*** achanda has quit IRC14:10
*** amotoki has joined #openstack-infra14:12
*** fandi_ has quit IRC14:13
*** lttrl has quit IRC14:13
*** achanda has joined #openstack-infra14:13
*** Longgeek has quit IRC14:13
*** fandi has joined #openstack-infra14:13
*** fandi has quit IRC14:14
*** fandi has joined #openstack-infra14:15
*** achanda has quit IRC14:15
*** achanda has joined #openstack-infra14:16
*** subscope has joined #openstack-infra14:19
*** achanda has quit IRC14:20
*** fandi has quit IRC14:21
*** fandi has joined #openstack-infra14:21
*** koolhead17 has joined #openstack-infra14:24
*** zz_avozza is now known as avozza14:26
*** Longgeek_ has quit IRC14:27
*** Masahiro has joined #openstack-infra14:30
*** salv-orlando has joined #openstack-infra14:32
*** Longgeek has joined #openstack-infra14:33
*** Longgeek has quit IRC14:34
*** Masahiro has quit IRC14:35
*** avozza is now known as zz_avozza14:36
*** salv-orlando has quit IRC14:38
*** _nadya_ has joined #openstack-infra14:39
*** HeOS has joined #openstack-infra14:40
*** Longgeek has joined #openstack-infra14:41
*** otter768 has joined #openstack-infra14:45
*** koolhead17 has quit IRC14:46
*** salv-orlando has joined #openstack-infra14:47
*** otter768 has quit IRC14:49
*** achanda has joined #openstack-infra14:50
*** marcusvrn has quit IRC14:52
*** marcusvrn has joined #openstack-infra14:54
*** marcusvrn has quit IRC14:58
*** marcusvrn has joined #openstack-infra15:00
*** dimsum__ has joined #openstack-infra15:08
*** liusheng has quit IRC15:10
*** dimsum__ has quit IRC15:13
*** liusheng has joined #openstack-infra15:14
*** koolhead17 has joined #openstack-infra15:22
*** zz_avozza is now known as avozza15:27
*** yfried_ has joined #openstack-infra15:28
*** _nadya_ has quit IRC15:36
*** pc_m has joined #openstack-infra15:46
*** sweston has joined #openstack-infra15:49
*** carl_baldwin has joined #openstack-infra15:52
*** subscope has quit IRC15:53
*** ChanServ has quit IRC15:55
*** sweston has left #openstack-infra15:55
*** salv-orlando has quit IRC15:56
*** nikil22 has quit IRC15:57
*** koolhead17 has quit IRC16:00
*** _nadya_ has joined #openstack-infra16:07
*** carl_baldwin has quit IRC16:09
*** MaxV has quit IRC16:11
*** _nadya_ has quit IRC16:15
*** Masahiro has joined #openstack-infra16:19
*** MaxV has joined #openstack-infra16:22
*** paul-- has quit IRC16:22
*** ChanServ has joined #openstack-infra16:23
*** sendak.freenode.net sets mode: +o ChanServ16:23
*** Masahiro has quit IRC16:23
*** andreykurilin_ has joined #openstack-infra16:24
*** paul-- has joined #openstack-infra16:27
*** marcusvrn has quit IRC16:33
*** marcusvrn has joined #openstack-infra16:33
*** yfried_ has quit IRC16:41
*** boris-42 has joined #openstack-infra16:42
*** harlowja_at_home has joined #openstack-infra16:42
*** marcusvrn has quit IRC16:44
*** e0ne has quit IRC16:45
*** otter768 has joined #openstack-infra16:45
*** marcusvrn has joined #openstack-infra16:46
*** MaxV has quit IRC16:49
*** otter768 has quit IRC16:50
*** yfried_ has joined #openstack-infra16:53
fungiugh... freenode's upgraded to an atheme release which drops dh-blowfish support for sasl, yet weechat is still on the fence about adding ecdsa-nist256p-challenge16:53
*** harlowja_at_home has quit IRC16:54
fungiso basically, the options are between plain auth and plain auth16:55
* fungi grumbles and goes back to having a saturday16:55
*** salv-orlando has joined #openstack-infra16:57
*** armax has joined #openstack-infra16:59
*** salv-orlando has quit IRC17:01
*** salv-orlando has joined #openstack-infra17:01
*** yfried_ has quit IRC17:14
*** HeOS has quit IRC17:15
*** yfried_ has joined #openstack-infra17:17
*** dimsum__ has joined #openstack-infra17:17
*** otter768 has joined #openstack-infra17:17
*** erlon has quit IRC17:19
*** achanda has quit IRC17:20
*** MaxV has joined #openstack-infra17:20
*** achanda has joined #openstack-infra17:21
*** amitgandhinz has joined #openstack-infra17:21
*** achanda has quit IRC17:23
*** achanda has joined #openstack-infra17:23
*** MaxV has quit IRC17:24
*** armax has quit IRC17:29
*** armax has joined #openstack-infra17:38
*** nikil22 has joined #openstack-infra17:41
nikil22Hi In CI system how to use the exact branch/commit ID in the JOB. i get these details as a variable in jenkins. But how can i use it in the devstack-gate so that it will clone that exact changes and run the test17:41
*** _nadya_ has joined #openstack-infra17:42
*** fifieldt_ has quit IRC17:44
*** fifieldt_ has joined #openstack-infra17:45
*** amitgandhinz has quit IRC17:46
*** shashankhegde has joined #openstack-infra17:46
*** amitgandhinz has joined #openstack-infra17:46
*** tjones1 has joined #openstack-infra17:49
funginikil22: we use zuul to calculate the git refs and supply them to jenkins via gearman17:50
funginikil22: but i think different people do it different ways17:51
nikil22fungi: same thing happens . Actually i get it via gearman. But how exactly in the job i should use it17:51
*** _nadya_ has quit IRC17:51
*** shakamunyi has joined #openstack-infra17:51
nikil22fungi: Because when the example job like dsvm-tempest-full will download only the master branch and run test in it.17:52
*** barra204 has joined #openstack-infra17:52
funginikil22: hopefully some of the people running third-party ci systems will speak up. i can explain how the openstack infrastructure ci integrates those pieces, but that may or may not be applicable to your use case17:52
fungier, well, i can explain later. at the moment i have to go run weekend errands17:52
funginikil22: devstack-gate determines the branches and refs to use based on what zuul determines from gerrit (the change proposed, the branch it's proposed against, whether that's a branch present on other projects being integrated, et cetera)17:53
* fungi will be back later17:53
*** tjones1 has quit IRC17:54
*** avozza is now known as zz_avozza17:55
nikil22fungi: thanks i will also look into more about the devstack-gate. Still now i dont see any variable to set the reference only branch and like neutron to enable or not i see. any way thanks i will dig more deeper .17:55
*** liusheng has quit IRC18:00
*** liusheng has joined #openstack-infra18:01
*** barra204 has quit IRC18:03
*** cody-somerville has quit IRC18:03
*** dimsum__ has quit IRC18:04
*** dimsum__ has joined #openstack-infra18:05
*** Masahiro has joined #openstack-infra18:08
*** dimsum__ has quit IRC18:09
*** dimsum__ has joined #openstack-infra18:09
*** Masahiro has quit IRC18:12
*** AJaeger has joined #openstack-infra18:13
AJaegerfungi, jeblair, anteaya: Could you have a look at https://review.openstack.org/#/c/141171/7/doc/source/devref/contribute.rst and tell me whether I'm overreacting, please?18:13
*** barra204 has joined #openstack-infra18:17
*** juris has joined #openstack-infra18:17
*** juris has left #openstack-infra18:18
*** melwitt has joined #openstack-infra18:24
*** e0ne has joined #openstack-infra18:25
*** armax has quit IRC18:27
*** andreykurilin_ has quit IRC18:39
openstackgerritClark Boylan proposed openstack-infra/system-config: Run an openstackweb dev site  https://review.openstack.org/14157118:42
*** amitgandhinz has quit IRC18:42
clarkbthat ^ has been WIP'd it is untested, but I figured we needed to start somewhere and I think that gives some initial shape to the thing18:44
clarkbif you grok php, silverstripe, openstackweb, apache, whatever please do push new patchsets. It will help a bunch18:45
ruhesomething's strange with devstack jobs. here is paste from devstacklog http://paste.openstack.org/raw/150391/18:46
ruhei see it in various reviews18:47
clarkbruhe: can you please link to specific job logs? we already host all of them18:47
clarkbno need to use paste for that18:47
*** achanda has quit IRC18:47
ruheclarkb: here is one of them http://logs.openstack.org/97/114997/2/check//check-tempest-dsvm-full/2c5826c/logs/18:47
ruhei don't even understand how can it fail with such error if swift doesn't have oslo.db and sqlalchemy in requirements.txt18:48
clarkbit is also odd that the version it complains about seems to match the allowed versions18:50
clarkbruhe: the error is hppening via paste. Is there not something in the paste config that does use oslo.db? (iirc it is ceilometer but would have to check)18:50
*** leakypipes has quit IRC18:50
clarkbya ceilometer is in the pipeline listed in proxy-server.conf18:52
*** zz_sabari has quit IRC18:52
AJaegerclarkb, ruhe: It says "SQLAlchemy<=0.8.99" - and 0.9.8 is isntalled18:55
clarkbits odd too that https://git.openstack.org/cgit/openstack/requirements/commit/?id=b52f1e8fd9a4ad5b6bb61ffbd59124159b55cd4e is what global requirements says18:55
clarkbAJaeger: ya but it also allows <=0.9.9918:55
AJaegerclarkb: who is the logic  for this? "<= 0.8.99 and <= 0.9.99"? So, that gives "<= 0.8.99", doesn't it?18:56
clarkbAJaeger: I don't think there is any logic...18:57
AJaeger;(18:57
clarkbAJaeger: my understanding is they want to say 0.8 or 0.9 are ok18:57
clarkbAJaeger: which should be >=0.8.4,<0.1018:58
*** salv-orlando has quit IRC18:58
AJaegeryeah...18:58
clarkbBUT old versions of pip will install betas and alphas if you do that hence the weirdness18:58
*** zz_avozza is now known as avozza18:58
AJaegerrequirement repo just has "SQLAlchemy>=0.9.7,<=0.9.99"18:58
clarkbAJaeger: ya thats a nw update from this week, but we test against release versions of oslo.db18:59
clarkbso oslo.db still has the old version. If that is a problem I would've expected tests to fail on global requirements chnage18:59
clarkbit should've failed at https://review.openstack.org/#/c/139880/ if that was a problem18:59
*** shashankhegde has quit IRC19:00
AJaegerunderstood, thanks19:00
*** zz_sabari has joined #openstack-infra19:01
*** _nadya_ has joined #openstack-infra19:02
clarkbI wonder19:03
*** otter768 has quit IRC19:03
clarkbno 0.9.8 was used according to pip freeze19:03
clarkber was used when the new version spec got in19:03
clarkband ceilometer was in the proxy-server pipeline then too19:04
*** otter768 has joined #openstack-infra19:04
clarkbdid we just do an oslo.db release?19:04
clarkbnope19:05
socialfungi: thanks a _lot_19:05
*** _nadya_ has quit IRC19:05
ruhei haven't found any new releases or related changes in these projects yet19:05
*** HeOS has joined #openstack-infra19:06
clarkbguess what released today?19:07
clarkbsetuptools!19:07
clarkbso pretty sure its newer setuptools (where pkg_resources comes from) braking us19:07
ruhe:)19:07
AJaegerreleases at weekends ;(19:07
dstufftit was released on a weekend because that's when the volunteer who maanges setuptools has time19:08
* clarkb looks up setuptools bug tracker19:08
clarkbdstufft: https://bitbucket.org/pypa/setuptools/issues that the one?19:09
dstufftyea19:09
dstufftthat old SQLAlchemy qualifer isn't valid in PEP 44019:09
*** cody-somerville has joined #openstack-infra19:09
clarkbdstufft: ya but I think over in -dev that one is valid19:09
AJaegerdstufft: yeah, understandable - it's just that I noticed too often breakage with release at weekends. Not sure whether it's my perception filter or whether there's a real corrolation19:10
dstufftclarkb: uh, let me look at that one19:10
clarkbdstufft: ERROR: openstackclient.shell Exception raised: python-neutronclient 2.3.9.40.g9ed73c0 is installed but python-neutronclient<3,>=2.3.6 is required by []19:10
dstufftclarkb: fwiw the specifiers are written by me19:10
clarkbdstufft: isn't that valid?19:10
dstufftclarkb: oh lol I know what the problem is19:10
clarkbdstufft: shoudl you file the bug then? because I have no idea19:10
clarkbI was just going to paste ^ and sa fix it :)19:10
dstufftit's because you're mixing a non PEP 440 version with a PEP 440 specifier19:11
clarkbI'm not sure I follow19:11
clarkbaren'tboth of those 440?19:11
*** otter768 has quit IRC19:11
dstufftso let me explain19:11
dstufftPEP 440 defines an order for versions that match PEP 440 right?19:11
dstuffta sort order19:11
dstuffthowever there are cases where people had versions that _didnt_ match PEP 440, so we needed to do something to make it possible to sort them19:12
dstufftso what we did is essentially sort all versions which are not PEP 440 compatible as "less than" any PEP 440 compat version19:12
dstufft(and within that, use the old setuptools algorithm)19:12
*** pcrews has quit IRC19:12
clarkbtl;dr all of python is going to be broken for a while19:13
dstufftso your specifier has >=2.3.6, but what that really is saying is >= (1, 2, 3, 6), but your version is (-1, 2, 3, 9, 40, "g9ed73c0")19:13
clarkbI thought 2.3.9.40.g9ed73c0 was 440 compliant19:14
*** e0ne has quit IRC19:14
dstufftno19:14
*** otter768 has joined #openstack-infra19:14
dstufftit's the .g9ed73c0 that makes it not19:14
dstufftthere's no sane way to sort that19:14
clarkbyes there is s/g9ed73c0//19:15
dstufftif you change that to 2.3.9.40+g9ed73c0 it'll work, because the+ signifiies a "local version" which has no semantics19:15
dstufftclarkb: we can't just ignore information19:15
AJaegerWhat fun ;(19:15
clarkbdstufft: apparently thats what the + does...19:15
clarkbanyways I am going to go be angry over there -> now19:15
dstufftclarkb: the + doesn't ignore it, it still has a defined sort order, it sorts by lower() and then string sorting, but it's special because things like PyPI won't allow you to upload it and stuff19:16
clarkbdstufft: so ignoring neutronclient thing19:16
clarkbdstufft: why is the sqlalchemy one not 440 compliant19:16
clarkbbest I can tell all of the sqlalchemy version stuff is compliant19:17
dstufftclarkb: I slightly mispoke, the problem isn't that it's not compatible (the SQLALchemy one), the problem is it relies on an inconsistent use of commas19:17
dstufftSQLAlchemy>=0.8.4,<=0.8.99,>=0.9.7,<=0.9.9919:18
dstufftif you treat the , as an AND, then it matches nothing, if you treat is as an OR, then it matches everything19:18
clarkbdstufft: so two changes in behavior then? are they both related to 400?19:18
clarkber 440?19:18
dstufftyou have to treat commas as both an OR and an AND in order for that specifier to make sense19:18
dstufftclarkb: yea19:18
clarkbyes I agree it makes no logical sense, but it worked in previous setuptools19:19
clarkbso how are you supposed to supply information about where a version comes from without making it sortable?19:19
dstufftclarkb: well lots of things worked in previous setuptools, part of the effort we're doing with packaging is standardizing and documenting, and as part of that we're also breaking behaviors that don't make sense19:19
clarkbsure19:20
clarkbexcept I think this just liteally broke the python world19:20
clarkbbceause evne if I fix my thing half of pypi will be broken19:20
dstufftno19:20
dstufftwe tested PEP 440 against PyPI19:20
clarkbbut apparently not setuptools 8.019:20
dstufftwe can successfully parse 98.12% as PEP 440 compliant versions19:20
clarkbotherwise oslo.db would've flagged an error19:20
dstufftI didn't say we achieved 100% compatible19:21
clarkbdstufft: I think you are saying the versions on pypi are compatible. what I am saying is the versions people use in their requirements lists may not be19:21
clarkbdstufft: or am I misunderstanding what you mean by testing 440 against pypi19:21
dstufftclarkb: sorry that was just the number I copy/pasted from the PEP19:22
dstufftwe did more testing than that19:22
dstufftin all cases we were within a few percent of 100%19:22
dstufftopenstack's requirement for SQLAlchemy is an outlier not a common case19:22
dstufftI've also been telling y'all it's gonna break in the future for months now :(19:23
clarkbdstufft: I don't recall that. I do recall being told to read pep 44019:24
clarkbwhich I did and I misunderstood our versions as being compatible19:24
clarkbin any case I need to go weekend now19:24
AJaegershould we cap setuptools for now? Or any other suggestion as next steop?19:25
clarkbAJaeger: that is probably the most direct immediate thing to do19:25
AJaegerto < 8.0?19:26
dstufftyou probably want to cap pip to < 619:26
dstufftas well19:26
dstufftbecause pip 6 includes PEP 44019:27
dstufftand will be coming out next week19:27
AJaegersetuptools is not in global-requirements ;(19:27
clarkbAJaeger: no beacuse it is expected to be there19:27
clarkbAJaeger: we have to pin it in our images19:27
clarkbsetuptools is special19:27
AJaegerclarkb: I see...19:27
AJaegernot sure what to change for that, so I let you or others do that and go back to my weekend as well ...19:29
clarkbreeading pbr version.py seems to indicate 440 was considered too19:35
clarkbso clearly we missed something reading 44019:35
*** otter768 has quit IRC19:38
clarkboh thats unreleased so that explains that (but the unreleased code would be broken too)19:39
*** Longgeek has quit IRC19:47
* mordred is unhappy19:50
*** shashankhegde has joined #openstack-infra19:52
*** Longgeek has joined #openstack-infra19:52
ruhesetting a cap on pip to < 6 seems complicated because of get-pip.py, while something like 'pip install -U "setuptools<8.0"' in install_puppet.sh should do the job19:52
mordredruhe: yeah - we're probably going to need to pin in devstack as well just to be sure19:53
dstufftyou can do ``pip install -U pip<6.0`` too, even after you do get-pip.py19:53
*** amitgandhinz has joined #openstack-infra19:53
mordreddstufft: the version fallback logic is insane19:53
mordredit's not what anyone is ever going to expect19:54
dstufftmordred: the alternative is an error19:54
mordredonly if you make an arbitrary set of rules that aren't logical and then stick to them with no regard to common sense19:55
mordredI get taht yuo can't sort g132423419:55
mordredbut making 2.3.9.gfoo < 2.3.6 is the least obvious failure mode possible19:55
mordredwhen CLEARLY the 9 is greated than the 619:55
*** mwagner_lap has quit IRC19:56
*** Longgeek has quit IRC19:56
*** Masahiro has joined #openstack-infra19:57
dstufftmordred: very few of the versions on PyPI had a pattern like that19:57
mordredsure - and we don't _release_ ours - but that doesn't mean that people with things not on pypi aren't going to be screwed19:57
mordredand I'd say all over the place19:57
mordredbecause lotgs of people who do not publish things to pypi also don't read things like PEP44019:57
mordredimagine the crazy pain this is going to cause for people with python-based corporate apps that all of a sudden arent' going to install because they weren't pure enough in their thinking brain19:58
mordredI'm just upset because not I'm going to spend the next however many hours or days scrambling to unbreak us19:59
mordredalso, do we have the field in the new metadata system to put the git sha information yet? beacuse I've been saying for forever that we'd be more than happy to move our extra info to that once it exists20:00
clarkbmordred: I think +g for local info20:00
mordredbut it seems that we've released the enforcement without having released the updates to metadata 2.020:00
clarkband still shove it into the version20:01
*** Masahiro has quit IRC20:01
mordredgreat.20:01
* mordred fumes more20:01
dstufftmordred: I've been asking people to help test this change for months, I've been telling people this might break things for month. I've used every avenue I've had at my disposal to try and get information from people that had things that wern't on PyPI20:01
dstufftIf some corporate app lives in a vacuum I can't really do a lot about that20:02
clarkbso I think wheer the disconnect was for me at least is that setuptools would enforce pep440. And do so without a WARNING THIS VERSION IS GOING TO BREAK LATER period20:02
mordredright20:02
mordredpip enforcing this makes perfect sense20:03
mordredand we were totally on board with that that meant20:03
mordredsetuptools enforcing it in this way is a complete and total surprise20:03
dstufftI'm not sure what breakage you think would not have happened if setuptools hadn't done it as well20:03
mordredwe install a version fromgit20:03
dstuffthow do you install it20:04
mordredthen we install a thing that depends on that thing which declares a thing20:04
mordredpip install -e .20:04
mordredin the git repo20:04
mordredTHEN20:04
mordredin a different git repo20:04
mordredwe install another thing that depends on the first thing which we've already installed20:04
mordredexcept that install breaks20:04
dstufftand how do you install that20:04
mordredbecause now the thing we installed sorts too low20:04
mordredpip install .20:04
dstufftso your install still would have broken20:04
mordredawesome20:04
dstufftif pip enforced it ands etuptools didn't20:04
clarkbno not quite20:04
mordredI'm so happy about the value this has brought me20:05
clarkbI mean it would still be funky20:05
clarkbbut pip would install a "newer" version instead20:05
dstufftpip would have uninstalled the git version and installed the latest version from PyPI it could find20:05
clarkbbecause pip would say you need X let me go get that20:05
dstufftwhich is probably not what you wanted20:05
clarkband things would still work20:05
*** melwitt has quit IRC20:06
clarkbbut that is where the THIS VERISON IS GOING TO BREAK warning comes from20:06
dstufftclarkb: the problem with that is, in our ability to determine, what PEP 440 did is for _most_ people, it made the versions and the specifiers they were using work more like what they thought it was going to work like20:07
dstufftso "this is going to break" isn't exactly correct20:08
dstufftbecause for most people it's "in the future this is going to be doing what you thought you were doing"20:08
clarkbwell except for the sort order being used20:08
clarkbyou could emit a warning any time you had to fall back on funky sort order20:08
*** amitgandhinz has quit IRC20:08
clarkbor would20:09
*** dimsum__ has quit IRC20:09
clarkbbecause parsefailure -> sort first is likely unexpected in all situations?20:09
*** salv-orlando has joined #openstack-infra20:09
dstufftif you think a warning about the funky sort order would make things better I can make a PR for that right now and see if jason can publish a quick 8.0.1 with it20:10
clarkbI think it would've at least made debugging easier. If you weren't in channel there is no way I would've figured that out20:10
clarkb(I think that warning should've come in a release before enforcement but I guess that ship has sailed)20:10
* dstufft tries to think how best to add a warning20:12
*** armax has joined #openstack-infra20:13
*** salv-orlando has quit IRC20:14
openstackgerritRuslan Kamaldinov proposed openstack-infra/system-config: Pin version of setuptools  https://review.openstack.org/14157720:15
fungii don't get why g1324234 is unsortable. isn't it just an alphanumeric string? posix has a well defined sort order for those since... well... posix?20:18
fungithough i am hoping people with "python-based corporate apps" not reading peps and following release notes also aren't automatically upgrading to most recent setuptools, et cetera20:19
*** ryanpetrello has joined #openstack-infra20:19
dstufftfungi: logically sortable, obviously any data can have a sort order defined for it, but like, is the version "dog" newer or older than the version "cat"20:20
ruhehttps://review.openstack.org/#/c/141577/ https://review.openstack.org/#/c/141578/ - is that enough to fix this problem for now? i'd like to continue my happy-hacking weekend :)20:21
dstufftobviously you _can_ define a sort order for those, but it's just arbitrary with no semblance of actually having a meaning attached to that order20:21
dstufftand in fact, we have a place for opaque strings that don't have meaning attached to them, in the local version20:21
clarkbdstufft: to be fair the parse fail sort first has all of the same problems as ^20:22
clarkbbut that was apparently ok20:22
clarkbdstufft: right so I now know why I am so confused20:22
*** dimsum__ has joined #openstack-infra20:22
clarkb440 was updated since I last read it completely removing the bits that we take advantage of20:22
clarkbso while we were 440 happy we are now not.20:22
clarkbwhich include source labels and rc versions20:23
dstufftclarkb: the difference is that the "parse fail sort first" isn't part of the PEP, we just added that in the packaging library, primarily for situations where someone _already_ has a version installed20:24
*** armax has quit IRC20:24
dstufftbecause we have to be able to sort the installed version and the candidate versions for techincal reasons20:24
clarkband lifeless' version.py changes were largely written before the updates to pep440 ok. I have unraveled this in my head20:26
openstackgerritMonty Taylor proposed openstack-dev/pbr: Revert all of the semver patches  https://review.openstack.org/14157920:26
openstackgerritMonty Taylor proposed openstack-dev/pbr: Prefix git suffixes with + instead of .  https://review.openstack.org/14158020:26
clarkbmordred: the problem with ^ is it won't pass due to the sqlalchemy thing20:26
mordredsure20:26
clarkbmordred: however we can likely test it off to the side while we deal with that20:26
mordredbut there's the code20:26
mordredyah20:27
mordredhttps://hg.python.org/peps/rev/59a0d31a1bc220:27
* morganfainberg came to look at SQLAlchemy thing and see people are aware20:27
AJaegermordred: please don't start rewriting OpenStack in Go! ;(20:27
clarkbmordred: but ya now I know why I was so confused. we wrote all of this stuff just prior to nick changing it all20:27
clarkbAJaeger: I am ready to rewrite it in php20:27
mordredthat change basically just pulled the rug out of all of our understand of what was going to be happening here20:27
morganfainbergmordred, hah @ the go comment.20:27
mordredalso - really? removing rc for c?20:27
*** social has quit IRC20:28
dstufftwe didn't remove rc20:28
mordredwho is the world thinks of c as meaning rc?20:28
mordredyeah you did20:28
clarkbdstufft: yes that change above removed it20:28
mordredhttps://hg.python.org/peps/rev/59a0d31a1bc220:28
dstufftno we did not20:28
mordred^^^^^20:28
dstufftit moved it to normalization20:28
dstufftPre-releases allow the additional spellings of alpha, beta, and rc for a, b, and c respectively.20:28
fungifwiw, other packaging systems do sort alphanumeric strings in .-separated components after pure numeric and then proceed in c sort order (so dog sorts after cat because ord('c') < ord('d') in that case)20:28
dstufftI know what I wrote20:29
clarkbdstufft: then why remove that from the grammar?20:29
mordredfine whatever20:29
mordredI'm done arguing about this20:29
dstufftclarkb: the grammar reflects the "normalized" form20:29
clarkbPublic version identifiers MUST comply with the following scheme: ...20:29
mordredI've indicated that I think it's crazy and nothing is going to change that. I will now continue working on unbreaking OpenStack20:30
dstufftIn order to maintain better compatibility with existing versions there are a number of "alternative" syntaxes that MUST be taken into account when parsing versions. These syntaxes MUST be considered when parsing a version, however they should be "normalized" to the standard syntax defined above.20:30
clarkbdstufft: maybe that MUST should be removed?20:30
* AJaeger remembers there was a similar change in rpm with sorting of version numbers that broke a few packages a couple of years ago ;(20:30
mordredruhe: yeah - I thnk that gets us past step one20:31
clarkbmordred: see comment on https://review.openstack.org/#/c/141580/20:31
dstufftclarkb: it's fine to clarify things in an already accepted PEP yea, we can reword it if the wording is confusing20:31
dstufft1.0rc1 is perfectly fine20:31
mordredclarkb: thanks20:32
dstufftit's not the normalized form, which tooling is supposed to prefer to emit normalized20:32
clarkbdstufft: that is what confused me. The statement basically says this is the only grammar accepted by public versions. Then later it says "we also accept these things"20:32
openstackgerritMonty Taylor proposed openstack-dev/pbr: Prefix git suffixes with + instead of .  https://review.openstack.org/14158020:32
dstufftclarkb: part of that is because the full grammar is not very meaningful looking20:32
dstuffthttps://github.com/pypa/packaging/blob/master/packaging/version.py#L162-L19820:32
mordredyah - I follow what's going on there now20:33
clarkbdstufft: so maybe say this is the canonical normalized grammar and refer to exceptions below instead of you must conform to this grammar?20:33
fungiso the ".dev123" version specifiers we were using for unreleased version numbers at one point... were those semver-derived or earlier-pep440-revision?20:33
dstufft.dev123 is valid20:33
clarkbfungi: they are still pep 44020:34
fungik20:34
*** amitgandhinz has joined #openstack-infra20:34
openstackgerritMerged openstack-infra/jenkins-job-builder: add support to git for changelog against branch  https://review.openstack.org/13401420:34
dstufftclarkb: I can make that update20:34
*** armax has joined #openstack-infra20:34
*** armax has quit IRC20:34
fungithough i suppose ideally pbr should start emitting only normalized pep440 version strings for better clarity20:35
mordredclarkb: so, I think we land the two patches from ruhe, then land and release pbr20:35
mordredfungi: right.20:35
* fungi is mostly caught up with scrollback now20:35
mordredfungi: https://review.openstack.org/141580 should fix pbr version emitting20:35
dstufftfungi: in an ideal PEP 440 centric viewpoint yes, and you can use the packaging library to do that if you want20:35
clarkbmordred: ya reviewing ruhe's changes now20:35
*** shashankhegde has quit IRC20:35
dstufftstr(packaging.version.Version("some string"))20:35
dstufftwil give you a normalized form20:35
fungidstufft: that's in stdlib now?20:35
mordredyeah, we can't use the packaging library unfortunately, because of setup_requires being evil20:35
*** ryanpetrello has quit IRC20:36
dstufftfungi: no, it's a third party lib that's designed to be easily bundled20:36
fungiahh, right20:36
clarkbmordred: except it must exist in setuptools right?20:36
openstackgerritMerged openstack-infra/jenkins-job-builder: Add Mercurial plugin feature to jenkins-job-builder  https://review.openstack.org/13913620:36
clarkbmordred: which we will have access to20:36
dstufftit's bundled in setuptools yes, though it's "private"20:36
mordreddstufft: is it vendorerd in setuptools?20:36
dstufftbut20:36
fungipbr can only rely on stdlib because we don't want pbr to bootstrap something else to bootstrap pbr20:36
fungithough i guess we do rely on setuptools20:36
dstufftsetuptools 8.0+ will return the version class from pkg_resources.parse_version20:36
clarkbfungi: no pbr depends on setuptools existing20:36
fungii suspect we have to have a sane fallback behavior in the face of older setuptools which lacks that method though20:37
clarkbfungi: yup20:37
*** pc_m has quit IRC20:37
dstufftyou can do parsed_version = pkg_resources.parse_version("some version"); if isinstance(parsed_version, tuple): fallback else: normalized = str(parsed_version)20:37
mordredwhat normalization do we need to do? the only thing we've got that's problematic at this point is the emission of .gXXXXXX20:38
clarkbruhe: mordred should we update ruhe's patches with pip install -U pip<6 too?20:38
clarkbmordred: I think this is thoughts on rewriting lifeless' stack20:38
mordredoh - meh20:38
clarkbmordred: since a lot of that is superceded by this20:38
dstufftmordred: https://www.python.org/dev/peps/pep-0440/#normalization20:38
clarkbwe can worry about it later20:38
dstufftthat's not mandatory stuff though for emiting20:38
dstufftit's mandatory for parsing20:38
clarkbmeh we can update pip install later if we need to20:39
mordredclarkb: ++20:39
mordreddo we have any devstack cores aroudn?20:39
clarkbnow hopefully tox doesn't release20:39
mordredsdague: you online?20:39
mordredclarkb: oh dear god20:39
*** armax has joined #openstack-infra20:39
openstackgerritMerged openstack-infra/jenkins-job-builder: Allow multiple comment-added events in gerrit trig.  https://review.openstack.org/12456820:40
clarkbwe also need to patch grenade20:40
clarkband I don't think that we can do this without force merging something because lol20:40
fungimordred: do you have the semver commit series handy and i'll repropose them?20:41
* dtroyer just caught up with this…20:41
clarkbI am looking at fixing grenade now20:41
fungi(or we can just let lifeless repropose them so gerrit still considers him the change owner)20:41
clarkboh hrm grenade doesn't setuptools directly it must rely on the devstack change except that grenade doesn't use proposed devstack?20:42
fungioh, i guess we can release on 141580 once it merges and then merge a revert of 14157920:42
dtroyergrenade tries to let the two devstack's manage their own environments20:43
clarkbdtroyer: oh I see, so its likely that we need stable/juno backport for grenade to work20:43
dtroyerprobably…20:44
clarkbso it is using proposed but only on the one branch which makes sense20:44
*** amitgandhinz has quit IRC20:44
mordredfungi: no, reset to 0.10.1, then cherry-picked all of the non-semver changes on top of it, then did a soft reset and committed that as the "revert"20:44
mordredfungi: so, I Think the easiest would be to just propose a revert of the revert patch20:44
clarkblet me propose backports of that change20:45
*** amitgandhinz has joined #openstack-infra20:45
openstackgerritMerged openstack-infra/system-config: Pin version of setuptools  https://review.openstack.org/14157720:45
openstackgerritMerged openstack-infra/jenkins-job-builder: Add support for Gerrit Trigger Comment Contains Expression  https://review.openstack.org/13660520:45
dstufftclarkb: : /Users/dstufft/projects/setuptools/pkg_resources.py:2314: RuntimeWarning: 'pip (6.0.dev1.wat)' is being parsed as a legacy, non PEP 440, version. You may find odd behavior and sort order. It is recommend to migrate to PEP 440 compatible versions.20:48
dstufftclarkb: would that warning be acceptable?20:48
openstackgerritMerged openstack-infra/jenkins-job-builder: URL in Maven deploy is an optional field  https://review.openstack.org/13858620:48
mordreddstufft: yeah, that would probably be helpful20:50
openstackgerritMerged openstack-infra/jenkins-job-builder: Reorganize tests/cmd  https://review.openstack.org/13405520:50
AJaegerdstufft: thanks! Would it make sense to add something like "It's sorted now as less than 0.0?"20:50
clarkbdstufft: +120:51
dstufftAJaeger: /Users/dstufft/projects/setuptools/pkg_resources.py:2315: RuntimeWarning: 'pip (6.0.dev1.wat)' is being parsed as a legacy, non PEP 440, version. You may find odd behavior and sort order. In particular it will be sorted as less than 0.0. It is recommend to migrate to PEP 440 compatible versions.20:51
dstufftbetter?20:51
*** nikil22 has quit IRC20:51
openstackgerritMerged openstack-infra/jenkins-job-builder: Add support for Config File Provider to Maven Project module  https://review.openstack.org/13622520:51
mordred++20:52
* AJaeger is happy, thanks dstufft20:52
clarkbhttps://review.openstack.org/#/c/141581/ https://review.openstack.org/#/c/141582/ are devstack backports20:53
clarkbstable-maint: note that 141582 Is NOT a backport and nor should it be. If I get -2's onthat  Iwill be very unhappy.20:53
dstuffthttps://github.com/jaraco/setuptools/pull/1520:55
ruheclarkb: re 141582. wouldn't unquoted <8.0 cause issues because of shell interpreting < as a redirect command?20:56
clarkbruhe: gah you are correct :)20:56
*** salv-orlando has joined #openstack-infra20:57
clarkbnote if we approve them in icehouse -> juno -> master order I don't think we need to force merge20:57
clarkbruhe: thanks20:57
*** AJaeger has quit IRC20:58
clarkbwho are devstack cores? dtroyer sdague mtreinish jeblair ianw ?20:58
mordredyah. dtroyer is online20:58
*** hdd has joined #openstack-infra20:58
* mordred thinks this is one of those where waiting for 2 cores may not be necssary20:58
clarkb+120:58
clarkband ya if the icehouse change works then we approve that one, then recheck juno, approve juno, recheck master, approve master20:59
dstufftclarkb: https://bpaste.net/show/8243ae9b860f better?21:01
*** salv-orlando has quit IRC21:01
clarkbdstufft: ya I think that will help me parse at least21:02
clarkbdstufft: also quick question about the sort order thing21:02
clarkbdstufft: you negate the versions right so say I have 2.3.9.g1231231 installed. That becomes -1.2.3.9.g123123121:02
clarkbassuming that is installed21:02
fungiclarkb: fwiw the stable-maint team no longer has jurisdiction over devstack21:03
*** armax has quit IRC21:03
ruheclarkb: is that change to stable/icehouse being tested by tempest from master? (just wondering)21:03
fungiclarkb: devstack cores should be able to approve as they see fit21:03
clarkbthe next version is 2.3.10.g1231231 which becomes -1.2.3.10.g123123121:03
clarkbdstufft: would the next version be treated as lower not higher?21:03
dtroyerI didn't know they ever did?21:03
dstufftclarkb: sort of, it's not actually the version string that gets negated21:03
dstufftwe compute a "sort key"21:03
dstufftwhich is a just a tuple21:04
clarkbfungi: oh thats good. I just had such a bad experience pushing fixes that were literally fixes to stable in the past and reviewers could not get over that it wasn't a backport21:04
dstufftand really it's just (-1, <previous sort key>) and (1, <pep 440 sort key>)21:04
dstufftand then we just rely on Python's tuple sorting21:04
clarkbdstufft: ok. But does that respect absolute values or ah ok21:04
*** avozza is now known as zz_avozza21:04
dstufftso 2.3.10.g1231231 will show as a newer version than 2.3.9.g123123121:04
fungiclarkb: there are now only 11 projects over which the legacy openstack-stable-maint team has control, and those will soon become project-specific stable-maint teams21:04
fungi(as of yesterday)21:05
*** amotoki has quit IRC21:05
dstufftclarkb: published the PEP update -> https://hg.python.org/peps/rev/047d121b118d21:05
dstufftit'll go live on the website at some point21:05
dstufftI think that cronjob is hourly21:05
*** zz_avozza is now known as avozza21:05
clarkbcool21:06
clarkboh you know what icehouse may just work becuase of pinning21:08
clarkbso we may be able to merge both backports at the same time21:08
dstufftFor whatever it's worth, we don't *like* breaking things, but we're in a situation where setuptools allows a lot of nonsense things like version numbers like "dog" and we're trying to standardize and exclude the "nonsense" things without breaking _too_ many things. We are testing our stuff against what's released on PyPI and we generally shoot for getting as close to 100% as possible.I didn't mean to sound as annoyed as I did at y'all,21:08
dstufft I have a headache and it's frustrating to get yelled at21:08
*** xyang1 has joined #openstack-infra21:10
clarkbya I think its frustrating for all involved. apologies for our crankyness too21:13
clarkbthe biggest miss here for me at least is we were 440 compliant and like 4 days after that code was written the pep changed without us knowing21:13
clarkbI think my next time feedback would be start with warnings in the code so that even people who think they are prepared get notified that they are not21:14
fungilikely we should have waited to implement pep 440 until it was approved21:14
clarkbfungi: except that we would've have been just as broken21:14
fungiand setuptools should have waited until long after pep 440 was approved to enforce it21:14
fungibut i get the eagerness to move on to new-shiny and not be stuck with a two-year deprecation cycle after the way forward is etched in stone21:15
dstufftI think setuptools is going to expand the "core contributors" to include me and I will probably start doing the setuptools releases at that point, which means they will likely start happening during the week21:15
dstufftI'm the only person who works on the packaging toolchain who gets work time to work on things, so that's why setuptools tends to get released on weekends21:16
fungii just can't wait to see the inevitable explosion which will be the package-sig ml come monday21:16
* fungi needs to make sure he is fully stocked on popcorn21:16
fungier, distutils-sig ml these days i mean21:18
clarkbmordred: also I propose we ditch the pbr semver stuff21:18
clarkbmordred: if pep440 is going to be enforced like this there is no sane way to have a not 1:1 set21:18
clarkber not 1:1 set of versioning21:19
mtreinishclarkb: do you have links? I'll fast approve the patches21:19
clarkbmtreinish: https://review.openstack.org/#/c/141582/ https://review.openstack.org/#/c/141581/ and https://review.openstack.org/#/c/141578/ note that last one can't merge until the second one merges21:19
dstufftfungi: I don't think it's going to be that bad honestly. Like I said, we did check PEP 440 against PyPI and we were really close compat wise. Openstack's two problems were the SQLAlchemy specifier which is a fairly complex specifier and isn't the common case (even looking at the global requirements for openstack, out of ~200 some specifiers only one was broken) and the git hash in the version which I think pbr is one of the few reasons21:19
dstufft someone would have something like that21:19
clarkbI think the first two can merge now21:19
fungidstufft: you checked that the version numbers registered on pypi were mostly pep-440-compliant, or that most packages on pypi use pep-440-compliant version specifiers for installing their dependencies?21:21
fungithose seem like very different scales of problems to identify21:21
fungianyway, water under the bridge now. hopefully whatever pain is encountered is short-lived and catalyzes the community into more standardized versioning going forward, on and off pypi21:23
clarkbonce the devstack changes merge next step is getting pbr merged and merging all updates to sqlalchemy that haven't merged then tagging things like oslo.do to use the valid sqlaclchemy version21:23
*** zz_dimtruck is now known as dimtruck21:23
mtreinishclarkb: ok, approved the stable branch versions21:23
dstufftfungi: the first one we checked everything by comparing all versions found on PyPI so we have exact numbers for that, the other one is harder and it was checked by going through github's code search looking for setup.py and requirements.txt files and I manually checked them21:23
clarkbmtreinish: thank you21:23
dstufftso the second one is a lot softer number21:23
fungidstufft: got it. i figured that was far from easy (seems almost intractable even)21:24
*** rkukura has quit IRC21:24
dstufftfungi: we also checked to see that the packaging lib sorted the available versions on PyPI the same as setuptools did previously21:24
dstufftboth with non PEP 440 versions included, and with them excluded21:24
clarkbmordred: you can tag a pbr release?21:24
clarkbI guess I might be able to too21:24
dstufft96.45% of projects sorted the same when we included the non PEP 440 versions21:25
dstufft99.88% sorted the same when we excluded them21:25
fungidstufft: yep, seems carefully thought out. i still expect a number of corner cases to come up on the ml over the next week or two21:25
mordredclarkb: I can21:26
fungiin our case, we have enough dependencies that the transitive tree is just about guaranteed to fall within that 0.12%21:26
dstufftfungi: yea I'm sure there will be corner cases21:26
clarkbmordred: trying to figure out the things that need to happen as early as posible since I will be out on monday21:26
mordredclarkb: I'll get the pbr release cut today21:26
clarkbfungi: thankfully we can test for that by reverting the setuptools pins21:26
*** avozza is now known as zz_avozza21:26
clarkbfungi: so at least we will be aware21:26
clarkb(it is larissa's birthday so not negotiating out of that to fix stuff :) )21:27
*** zz_sabari is now known as sabari21:27
fungigo celebrate21:27
clarkbfungi: I will on monday :)21:27
mordrednice part is - people have been wanting a pbr release for other features but we've been blocked on the lifeless patches21:27
clarkbsorry I meant monday is when I have to afk so I want to be helpful now21:27
mordredso this gets the pressure off of that work21:28
dstufftclarkb: mordred fungi FWIW we did not actually remove the source field from metadata 2.0, we just moved it from PEP 440 to PEP 426 because it's a metadata field not a version number part21:28
dstufftmetadata 2.0 isn't done yet, that's going to be the enxt big effort I think after warehouse21:28
mordrednod21:28
mordredhow's warehouse going?21:28
*** armax has joined #openstack-infra21:28
dstufftmordred: back burnered until pip 6 is done21:28
dstufftwhich i'm planning to release next week21:28
clarkb(which will also break us if we don't get this all fixed first. I think we can do it but depends on how bad transitive lib stuff is)21:29
fungidstufft: i think the main reason for having the git sha was to help us solve a potential corner case where you had sdists built from parallel branches descending from a common latest tag and the number of commits on each branch was the same. i'm still not convinced that's actually common enough to warrant the added complexity though21:29
dstufftyea I just merged PEP 440 support into pip 621:29
fungiand there is an open bug against pbr for an option flag to allow you to turn off appending the git sha anyway21:30
dstufftfungi: for the record, the source field in metadata 2.0 is entirely informational, it's used as a "this release came from this version", pip and co won't use that field in it's version resolution algorithm at all21:30
dstufftcame from this git hash*21:30
dstufftor whatever21:30
openstackgerritDarragh Bailey proposed openstack-infra/jenkins-job-builder: Reorder imports to match hacking guidelines  https://review.openstack.org/13346521:30
dstufftclarkb: I'm flexible on what day it gets released, or can push it off an extra week too if y'all want more time21:31
*** andreykurilin_ has joined #openstack-infra21:31
dstufftI'd like to release it next week fi possible though21:31
fungidstufft: right, which is why i think moving the git sha out of the version and into a metadata field doesn't really solve the problem i saw it being there to attempt to solve21:31
clarkbdstufft: would probably be good to see how far we get this weekend21:31
clarkbhttps://review.openstack.org/#/q/topic:openstack/requirements+status:open,n,z is basically the list of things that needs to merge21:31
fungibut i think it's an uncommon enough problem that i'm unconvinced it needs solving anyway21:31
clarkbthen we need to cut releases for anything that is consumed via releases21:31
clarkbactually there are quite a few not sqlalchemy updates so that list isn't that bad21:32
*** amitgandhinz has quit IRC21:32
clarkband devstack overriding requirements helps here21:32
*** amitgandhinz has joined #openstack-infra21:32
*** rkukura has joined #openstack-infra21:32
clarkbso we need it in anything consumed as a lib. python-*clients should not use sqlalchemy. I think that leaves the oslo projects21:32
dstufftfungi: yea, the + thing in versions isn't _techincally_ for that either, it's really designed for downstream people like ubuntu and co to mark when they patch an upstream thing or for people to fork an upstream project to mark they've forked it21:33
dstufftfungi: but it can be used in that context anyways since we just treat it as an opaque blob21:34
ruheclarkb: ceilometer and glance are still using old sqlalchemy version constraints. probably will need to update them too?21:34
clarkbruhe: ya, there are changes up for them. We don't need to focus on that though because global requirements overrides their requirements at install time21:34
clarkbruhe: so we should do that but its a lower priorityc21:35
ruheclarkb: i see. thanks for clarifying that21:35
fungiwell, it may impact their unit test jobs et cetera21:35
fungibut not devstack-gate based jobs21:35
clarkbfungi: only once tox updates but yes21:36
clarkba quick scan really shows oslo.db as the only one that I think we really need to worry about21:37
*** amitgandhinz has quit IRC21:37
clarkbits stable/juno requirements.txt need an update21:37
dstuffttox update shouldn't break anything until virtualenv is released21:38
dstufftthat'll happen next week when I do pip21:38
clarkbhttp://git.openstack.org/cgit/openstack/requirements/tree/global-requirements.txt?h=stable/juno#n13221:38
clarkbdstufft: do you want to propose your change ^ there too?21:38
fungiright, new tox vendoring new virtualenv vendoring new setuptools21:39
dstuffttox doesn't vendor virtualenv IIRC, it just depends on it21:39
*** sabari is now known as zz_sabari21:39
clarkbprobably to >=0.8.4 ?21:39
*** otter768 has joined #openstack-infra21:39
dstufftclarkb: I'm not sure how to do that on another branch21:39
dstufftI only ever do just ``git review``21:39
clarkbdstufft: its easy can walk you though it if you want21:39
dstufftok21:39
*** shakamunyi has quit IRC21:40
clarkbdstufft: basically `git remote update ; git checkout -b stable/juno origin/stable/juno ; git checkout -b fix-sqlalchemy ; make edits ; commit ; git review stable/juno`21:40
dstufftclarkb: do you want the more expressive form of the specifier that includes a bunch of != so that you get the same versions that allows?21:40
openstackgerritDarragh Bailey proposed openstack-infra/jenkins-job-builder: Support copyartifact build selector param  https://review.openstack.org/13377421:40
clarkbdstufft: if that is possible I think we should do that for juno since that is a stable branch21:41
clarkbdstufft: the change you made for kilo/master is fine because its the dev version but for the stable branch we should make it as 1:1 as possible21:41
dstufftget's the same versions assuming sqlalchemy doens't release a 0.9.1.1 or something21:41
dstufft*21:41
clarkbdstufft: ya I think we can live with that corner case21:41
*** otter768 has quit IRC21:43
*** barra204 has quit IRC21:45
clarkbdhellmann: for when you see IRC can we have a new release of oslo.db? we need it for updated sqlalchemy requirements. We will need the same for the juno branch too once we get the update on the juno branch21:45
*** Masahiro has joined #openstack-infra21:45
dstuffthttps://review.openstack.org/#/c/141584/21:46
*** jamespage_ has joined #openstack-infra21:46
clarkbthat will likely fail testing until the juno devstack change gets in21:47
clarkb(again because of libs consumed from releases)21:47
clarkbbut I can recheck it once the devstack change merges and I am +221:47
dstufftok21:49
dstuffti double checked it would do as it looks on both old pip and pip 6 with both old setuptools and new21:49
dtroyerdevstack stable/juno isn't happy with check-grenade-dsvm-ironic-sideways…21:49
*** Masahiro has quit IRC21:50
dtroyerlast successful run appears to be Dec 521:50
clarkbdstufft: perfect thank you21:50
clarkbdtroyer: hrm21:50
dstufftclarkb: for whatever it's worth, at some point in the future I want to see about adding grouping and OR operations to specifiers21:50
clarkbadam_g: devananda do you happen to be around?21:50
mtreinishdtroyer: oh, I know that, there's a tempest bug21:50
mtreinishI think the fix was in progress, let me fast approve it21:51
dtroyerthe IPv6 one?21:51
clarkbmtreinish: it cannot merge :)21:51
mtreinishyep21:51
dstufftbecause what you were trying to do with that specifier was something like (>=0.8.4 AND <=0.8.99) OR (>=0.9.7 AND <=0.9.99)21:51
clarkbso with juno we may have wedged ourselves21:51
clarkbdstufft: ya21:51
mtreinishclarkb: d'oh, yeah that's what it sounds like21:51
mtreinishdtroyer: https://review.openstack.org/#/c/141456/21:52
clarkbI think we can force merge the juno devstack change if the devstack cores are ok with it21:52
dstufftclarkb: setuptools 8 (and pip 6) includes some new specifiers too btw, like ~= and the ability to do ==1.* and such21:52
clarkbthen we can worry about fixing tempest for ironic sideways21:52
mtreinishclarkb: go ahead, I'm fine with that21:52
dtroyerclarkb: I'm good with that21:52
dstufft(can't use them until you're happy making those min versions tho)21:52
clarkbdstufft: ~= is basically match any "smaller" identifiers?21:53
dstufftnewer, it's the semver matcher basically21:53
clarkbrgr21:53
dstufft~=2.3 is >=2.3 AND < 321:53
dstufftmore or less21:53
clarkbfungi: mordred: any opposition to me merging https://review.openstack.org/#/c/141581/ ?21:53
clarkbI did propose it maybe one of you want to do that instead :)21:54
clarkbthough ruhe wrote it21:54
*** tnovacik has quit IRC21:56
mordredclarkb: I can do it21:56
mordredclarkb: oh - that's a force merge, right?21:56
mordredclarkb: I thought we thought that we didnt' need a force merge?21:57
clarkbmordred: yes, it needs a force merge because ironic sideways is failing which requires a tempest fix which can't merge until setuptools is pinned on juno21:57
clarkbmordred: we don't need it other than ironic sideways is failing21:57
clarkbmordred: also you can see that that change makes the other jobs pass21:57
clarkbso it works just not in that psecific case where tempest fails on ironic sideways21:58
mordredcool21:58
mordredI'll nija it21:58
mordredclarkb: done21:59
clarkbmordred: thank you I am rechecking the master change now21:59
clarkbmtreinish: now you can work on getting ironic fixed which we likely need as there will be many changes in the juno branch to update sqlalchemy requirement22:00
mtreinishclarkb: I already fast approved the ironic fix :)22:01
clarkbwoot22:01
mtreinishit was just a skip, because ironic doesn't support specifying network22:01
clarkbthat is easy22:01
clarkbI have rechecked dstufft's requirements juno change now too22:06
dstufftcool22:07
dstufft-> goes to get dinner22:07
mordreddstufft: heh. I'm still workingon morning coffee22:07
clarkbmordred: once devstack master change gets in (mtreinish can haz approval on that so it goes straight ot gate if tests pass?) its on to fixing pbr22:08
mtreinishclarkb: +A22:09
mordredclarkb: fixing pbr should just be rechecking the semver revert, then landing, then releasing, yeah?22:09
clarkbmordred: ya22:09
clarkbmordred: except then we need to go make everything use that version of pbr22:09
mordrednah - the version spec is wide open for pbr22:10
clarkbmordred: awesome22:10
mordredit's just <1.022:10
mordredso we're fine22:10
clarkbcool so other than updating requirements in all the things I think we are in really good shape22:11
mordredyah22:11
mordredthis is one of the easier break-the-world's we've had :)22:11
mordredeither that or we're just getting better at it22:11
clarkbdstufft: tl;dr I think there is a good chance we won't need you to delay pip release if you give us a bit of time22:11
clarkbmtreinish: oh crud tempest is branchless :)22:13
clarkbmtreinish: so we can't fix tempest until after devstack is updated22:13
clarkboh well that just means a recheck later today22:14
clarkbin ~1.5 hours22:14
openstackgerritMatthew Treinish proposed openstack-infra/subunit2sql: Add --average option to sql2subunit cli  https://review.openstack.org/13211922:14
openstackgerritMatthew Treinish proposed openstack-infra/subunit2sql: Correct writing of timestampes in write_test() for sql2subunit  https://review.openstack.org/14158522:14
mtreinishclarkb: oh, yeah forgot about that22:14
mtreinishI'll try to remember to do that later tonight22:14
clarkbme too o/22:14
clarkbso we were super duper extra wedged on that22:15
clarkbit was a triangle where devstack juno needed tempest master, tempest master needed devstack master, devstack master needed devstack juno22:16
clarkbmordred: ^ that is the mess that you untangled :)22:16
* mordred is helpful22:16
mtreinishooh, yeah that's a doozy22:16
*** zz_avozza is now known as avozza22:17
openstackgerritMatthew Treinish proposed openstack-infra/subunit2sql: Correct writing of timestampes in write_test() for sql2subunit  https://review.openstack.org/14158522:18
openstackgerritMatthew Treinish proposed openstack-infra/subunit2sql: Add --average option to sql2subunit cli  https://review.openstack.org/13211922:18
*** xyang1 has quit IRC22:20
clarkbmordred: how does this affect installs that are just shortsha1 versioned?22:23
clarkbI think it should break int he same way as before so likely not something to worry about22:23
*** avozza is now known as zz_avozza22:23
clarkbmordred: `git describe --always` on a repo with no tags reports short sha which is not valid under 440 either22:26
*** liusheng has quit IRC22:26
clarkbmordred: but maybe that is desireable22:27
*** liusheng has joined #openstack-infra22:27
clarkbhrm is 0+g1231231 < 0.0.1 ?22:27
clarkbif so maybe we do something like that22:27
mtreinishclarkb: I think it is22:29
mordredyeah - we've never really expected that short-sha would be compat - so actually the pep440 change I think does the right thing22:29
* mtreinish tries to remember the last time he fought the auto versioning in pbr22:29
clarkbwell in the case of no tag versions pbr gives you 123123122:29
clarkbwhich is going to be confusing making (and honestyl was in the past too)22:29
mordredk.I can make that change too22:30
clarkbbut if we make that version 0+g1231231 I wonder if that works22:30
mordred0+g123123 is fine22:30
mordredwe can test with packaging library22:30
clarkbmordred: ok as long as it will work22:30
clarkbhrm actually22:30
clarkb0.0.0.numcommitssincefirstcommit+g1231231 might be more pbrish22:31
clarkbin any case I Think we can worry about this particular scenario later22:31
Mithrandir0~$(date +%s)+g12345622:32
clarkbor even 0+numcommits.g123123122:32
Mithrandir0.0~$(date +%s)22:32
*** amitgandhinz has joined #openstack-infra22:33
mordred>>> v=version.Version('0+g123123')22:33
mordred>>> z=version.Version('0.1.1')22:33
mordred>>> v<z22:33
mordredTrue22:33
Mithrandir~ sorts as less than the empty string in deb and rpm world, + doesn't.22:33
clarkbMithrandir: I don't think ~ is accepted by pep 44022:33
clarkbsince it is an operator22:33
mordredright. ~ is out22:33
Mithrandiroperator?  How is ~ an operator in version strings?22:34
mordredversion strings will have to be translated from python to deb/rpm22:34
clarkbMithrandir: its an operator in requirements22:34
mordredthere is literally no string that works for all the systems22:34
Mithrandir:-/22:34
Mithrandirmordred: sadness.22:34
Mithrandirbut such is life.22:34
mordredMithrandir: yah22:34
* mordred stabs self in face22:34
clarkbmordred: I think we want num of commits in there so that if you add a second commit it will always be a higher version22:35
clarkbmordred: so terrible idea is 0+numcommitsg123123122:35
clarkbeg 0+10g123123122:35
mordredyah22:35
*** hdd has quit IRC22:35
MithrandirI'd recommend putting a timestamp in there, tbh.22:36
clarkbexcept that won't work22:36
clarkbbecause alpha sort22:36
*** fandi has quit IRC22:36
clarkbMithrandir: except timestamps don't really mean much in git22:36
mordredI think we need to do: if "." not in $(git describe --always): prepend 0.0.022:36
Mithrandirclarkb: oh, timestamp and the commit hash, sure.22:36
Mithrandirclarkb: but timestamps mean something to humans.22:36
clarkbMithrandir: but they don't mean things in git sorting22:36
clarkbwhich is really what we are trying to express onto pep 44022:37
*** stevemar has joined #openstack-infra22:37
Mithrandirmaybe I should read the pep and then tear my hair out so I understand where you're coming from at least.22:37
*** amitgandhinz has quit IRC22:37
clarkbso that if I have commits A <- B <- C that we also get version sorting A<B<C22:38
clarkband I don't think timestamps give that to us in a git world (because git preserves timestamps when you move stuff around22:38
openstackgerritMonty Taylor proposed openstack-dev/pbr: Make a PEP440-ish version for non-tagged repos  https://review.openstack.org/14158622:39
mordredclarkb: ^^ what about that?22:39
openstackgerritMatthew Treinish proposed openstack-infra/subunit2sql: Add new db api methods for getting test data from runs  https://review.openstack.org/14154722:39
Mithrandirclarkb: not the commit timestamp, I think?  Maybe the authorship timestamp.22:39
openstackgerritMatthew Treinish proposed openstack-infra/subunit2sql: Refactor sql2subunit to use get_tests_run_dicts_from_run_id  https://review.openstack.org/14154822:39
openstackgerritMatthew Treinish proposed openstack-infra/subunit2sql: Correct writing of timestampes in write_test() for sql2subunit  https://review.openstack.org/14158522:39
openstackgerritMatthew Treinish proposed openstack-infra/subunit2sql: Add --average option to sql2subunit cli  https://review.openstack.org/13211922:40
clarkbMithrandir: I don't think either will work22:40
clarkbMithrandir: especially with how we gerrit where stuff gets in at weird times22:40
clarkbmordred: I think that is a reasonable way to do it22:40
clarkbmordred: it won't work 100% of the time but it should work in a pbr world22:40
dstufftclarkb: 0+gwhatever is < 0.0.122:41
*** stevemar has quit IRC22:41
clarkbmordred: or maybe we devN?22:41
Mithrandir+ isn't allowed according to pep 44022:41
clarkbMithrandir: it is22:41
clarkbMithrandir: (don't worry I have lready been confused by this too :) )22:42
Mithrandiroh, I'm reading the local version thing.22:42
Mithrandirsorry.22:42
clarkbmordred: oh wait + does the right thing if you do it like this: 0+10.123abcd22:43
clarkbmordred: the 10 will be treated as an integer and they split on .'s22:43
clarkbmordred: so I think what we actually want is something like ^22:43
clarkb0+10.g123abcd22:44
clarkbwill always be less than 0+11.g012abc22:44
dstufftor 0.dev10+g123422:44
clarkbya or we could use dev22:44
* dstufft afks again22:44
clarkbif we go to devN we should update all cases to use devN22:46
clarkbwhich is maybe best decided by what is old setuptools vs new setuptools look like with the different setups22:47
Mithrandirhmm, ~ isn't an operator, ~= is, but yeah.22:49
* Mithrandir tears out hair.22:49
*** Longgeek has joined #openstack-infra22:52
*** shashankhegde has joined #openstack-infra22:53
*** jamielennox|away is now known as jamielennox22:55
*** esker has joined #openstack-infra22:55
clarkbok I am being called away to food. Will check back in later to see if tempest/pbr need rechecking22:56
*** Longgeek has quit IRC22:56
clarkbany thoughts on approving https://review.openstack.org/#/c/141584/1 too? I can do that when I get back if no one beats me to it22:57
*** dimtruck is now known as zz_dimtruck22:58
ZZelle_Hi everyone23:01
ZZelle_It seems there is a trouble during cirros image download by CI hosts23:01
dstufftMithrandir: We didn't use ~ because of compatability with Debian, because + sorts _after_23:03
fungiZZelle_: i hope not--we pre-cache the guest images devstack uses to keep it from downloading them from the internet at all23:03
dstufftlike 1.0+anything > 1.023:03
dstufftwe didn't use - because it's what setuptools used for post releases23:03
ZZelle_fungi, http://logs.openstack.org/57/141057/4/check//check-tempest-dsvm-neutron-pg/8bd823d/logs/screen-g-api.txt.gz23:03
dstufftwe were running out of characters23:03
Mithrandirdstufft: yes, so ~ should be have been required for prereleases.23:03
dstufftwe don't use ~ to demarcate pre-releases23:03
dstufftwe have names for them23:03
dstufft1.0a123:04
dstufft1.0b123:04
dstufft1.0c123:04
ZZelle_fungi, there is the same trouble with cinder/neutron tests using devstack23:04
dstufft1.0.dev023:04
fungiMithrandir: i believe in pep440 it's 1.2.3a4 to express something along the lines of debian 1.2.3~4 or 1.2.3~a423:04
dstufftetc23:04
MithrandirI think having "a", "b", "c" and the corresponding alpha/beta/rc magically in the middle of a string changing the sort order is insane.23:04
*** mwagner_lap has joined #openstack-infra23:04
fungisince 1.2.3a4 < 1.2.323:04
ZZelle_fungi, "2014-12-13 22:04:43.453 505 ERROR glance.registry.client.v1.client [8dbd043f-37d4-450e-acd3-dddab94c732c f369f106b34d4a1a9d9bdadb40bfc130 34fb041fb9c84a12ac635083ee9bce72 - - -] Registry client request GET /images/cirros-0.3.2-x86_64-uec-ramdisk raised NotFound"23:04
Mithrandirfungi: except much less expressive.23:04
dstufftMithrandir: *shrug*, basically zero people use anything but that in Python land23:04
dstufftor anywhere else I've seen tbh23:04
dstufftdebian is the only place that uses ~ that i've seen23:05
fungiMithrandir: i think that ship sailed 10+ years ago. pep440 is just trying to codify current usage and make as much sanity around it as can be found23:05
* dstufft goes to eat23:05
Mithrandirdstufft: it's supported in not-ancient RPM too.23:05
dstufftMithrandir: cool, two linux distros against 15 years of legacy behavior23:05
Mithrandirand well, 0~$(date +%s)+githash is pretty common for "this is a really new thing"23:05
fungiyeah, most of the distro packaging systems are copying the dpkg ~ usage now, but that's a pretty recent event23:05
Mithrandirwhere pretty recent is ten years old. :-P23:06
fungiyep23:06
Mithrandir(give or take, I didn't check when ~ was added to policy)23:06
fungiMithrandir: well, 10 years for debian. i mean only recently have non-debian-derived distros been following suit23:06
*** ChanServ has quit IRC23:07
clarkbZZelle_ thats the setuptools issue23:08
ZZelle_clarkb, ok23:08
clarkbit breaks swift which breaks glance23:08
*** jamielennox is now known as jamielennox|away23:08
*** shashankhegde has quit IRC23:08
*** ChanServ has joined #openstack-infra23:10
*** sendak.freenode.net sets mode: +o ChanServ23:10
Mithrandiras an aside, it also seems like pep440 is buggy in that it says that a component of 0 is the lowest value in the version ordering, then proceeds to talk about a0 being lower.23:10
Mithrandiror a1 or whatever.23:10
*** zz_dimtruck is now known as dimtruck23:11
fungiMithrandir: non-negative numbers less than 0. i just thought of a paper i want to submit to the journal of number theory23:12
Mithrandirfungi: sure, 0~1 is a non-negative version that's less than 0.23:12
Mithrandir(this broke imports in launchpad at some point there was something we tried to sync from debian with a version of 0~$(date)+sha1 or whatever.23:13
clarkbfungi does that go in with the 0 is (not) an Integer papers?23:13
Mithrandirand it went "huh", since it compared with 0.23:13
fungiclarkb: probably, yeah. now i want to go back to roman numerals23:14
clarkber sorry23:14
clarkbnatural number23:14
MithrandirI~V ? :-P23:14
MithrandirI'm not sure how that's improving things. :-P23:14
dstufftcan't make it worse23:14
Mithrandiryou can't express 0, I guess that might make it.. otherwise confusing.23:14
dstufftsetuptools 9 will enforce the new roman numerals based PEP23:14
fungitordinal numbers23:14
* fungi makes up terms23:15
dstufftMithrandir: that'll just make it easier to prevent people from keeping 0.X forever23:15
Mithrandirtrue dat.23:15
Mithrandirdid the romans have floating point, even?23:15
clarkbfractions23:15
fungiit was all fractions iirc23:16
dstufftthe romans were all about continous deplyoment23:16
clarkbIII/V23:16
Mithrandirok, then it's _really_ not improving things23:16
*** stevemar has joined #openstack-infra23:16
fungiiii/iv sorts after v/ix23:16
*** dimtruck is now known as zz_dimtruck23:17
*** ChanServ has quit IRC23:24
*** hdd has joined #openstack-infra23:24
*** zz_avozza is now known as avozza23:25
*** hdd has quit IRC23:25
*** esker has quit IRC23:26
clarkbdevstack master merged. time to recheck tempest and pbr23:27
*** ChanServ has joined #openstack-infra23:28
*** sendak.freenode.net sets mode: +o ChanServ23:28
clarkbwelcome back chanserv23:31
*** ChanServ has quit IRC23:31
fungiclearly they're still futzing around with their atheme server23:32
clarkbmordred pep8 fails on pbr changes23:32
clarkbthe reverts apparently undid some pep8 stuff23:33
lifelessmordred: reverting semver?23:34
clarkblifeless setuptools is enforcing pep440 now23:34
lifelessmordred: I think a single patch is needed to fix the version generation23:34
*** Masahiro has joined #openstack-infra23:34
lifelessmordred: reverting is really a poor idea IMO because it will allow the stable branch headache we had before to come back.23:34
lifelessmordred: so please don't do it that way23:35
clarkblifeless except we also need to relwase and it wasnt ready for other reasons iirc23:35
lifelessclarkb: no, it was just one patch pending23:35
clarkbso maybe release based on 0.10.0 and keep semver on master23:35
clarkbas an alternative23:35
lifelessclarkb: which was the one to change dev versions to be in the same timeline as pre-release versions23:36
*** ChanServ has joined #openstack-infra23:36
*** sendak.freenode.net sets mode: +o ChanServ23:36
lifelesse.g. 1.2.3.b1.0dev1 rather than 1.2.3.0dev523:36
lifelessclarkb: thats _all_23:36
clarkbwe also need to fix the source index things23:37
lifelesssource index?23:37
clarkb.g1231231 is invalid23:38
clarkbso we need to make it +g1231231 and parse that properly23:38
clarkbalso drop rc in your normalization as 'c' is normalized now23:38
*** Masahiro has quit IRC23:38
lifelessok, so do that, rather than reverting everything else23:39
lifelessmy concern is that I'll have more work to do than just doing these two minor changes now23:40
clarkbor its like a 3 line diff atop 0.10.0 to not be completely broken23:40
lifelessbut I have to leave in 90m to drive to dunedin, so I can't do it now23:40
*** otter768 has joined #openstack-infra23:40
clarkblifeless I think your changes can ve mostly dropped now23:40
clarkbbecause setuptools23:40
lifelessone 3 lines patch vs 2 3 line patches?23:40
lifelesswhat has setuptools done that helps us ?23:40
clarkbthey normalize and enforce versions now23:41
clarkbwhich is what breaks us23:41
clarkbbut is also what pbr wanted to do23:41
lifelesswhich is about 5% of the work thats being reverted23:41
clarkbit is?23:41
lifelessyeah23:41
clarkbI think semver is basically check setuptools increment done now23:42
lifelessI think you're wrong23:42
clarkbsince apparently they grok semver to anextenttoo23:42
clarkbvia ~=23:42
lifelessthe version normalisation bit, sure. Figure out what to increment from git - nope; offer the nice API for __version__ etc inside modules - no23:42
*** shakamunyi has joined #openstack-infra23:43
*** barra204 has joined #openstack-infra23:43
*** EmilienM|pto is now known as EmilienM23:43
clarkbanyways I looked at version.py and noped out because weekend23:44
clarkbits a lot more complicated conceptually than 0.10.023:44
lifelessfine, whatever. I don't have time to deal with this; if my work is reverted I'll do whatever is lowest cost engineering to get back to the current state - be that pester mordred to deal with the fallout his patch chain creates, or fork pbr or whatever, because annual leave.23:44
*** otter768 has quit IRC23:44
dstufftclarkb: for the record you won't be able to use ~= until you're happy mandating a min version on setuptools 8 and pip 623:44
lifelessclarkb: personally, setuptools broke things? setuptools should rever.23:45
lifelessclarkb: the migration plan for PEP-440 AIUI was always to be *graceful*23:45
dstufftit is graceful for most situations23:45
lifelessclarkb: and this - us scrambling - is so not graceful.23:45
clarkbright setuptools forced the issue23:45
clarkbyou cannot be graceful anymore23:45
lifelessdstufft: in what way is causing us to throw out 6 months of work graceful?23:45
lifelessalternative fix: blacklist setuptools >= 7.0.023:46
dstufftlifeless: I have no idea what the 6 months of work is, the problems were that you had a somewhat insane version specifier and that you needed to switch .githash to +githash23:46
clarkblifeless thats the immediate fix yes23:46
*** salv-orlando has joined #openstack-infra23:46
clarkbbut we have to do that to pip and virtualenv if we dont fix asap23:47
clarkband blacklisting all the things is :(23:47
clarkboh and tox23:47
*** andreykurilin_ has quit IRC23:48
dstufftthe things that were broken wern't an accident. y'all were outliers and relying on things that we explicitly wanted to disallow23:48
clarkbwell23:48
clarkbthey were allowed back in june23:48
lifelessdstufft: which you knew we a) were relying on, b) had not yet fixed.23:49
clarkbwhen we started our process of being compliant23:49
dstufftclarkb: I don't think there was ever a version of PEP 440 that allowed 1.0.githash23:49
clarkbdstufft there was23:49
clarkbsame diff that removed rc from grammar23:49
lifelessdstufft: 1.0.g$HASH FTR. And yes, there was.23:49
lifelessdstufft: we cross referenced everything against the PEP when we wrote our spec.23:50
clarkbyup23:50
clarkbbut then pep drastically changed as it relates to us23:50
dstufftclarkb: that diff was 1.0-githash23:50
dstufftnot 1.0.githash23:50
clarkbno 1.0.ggiyhash was allowed23:50
dstufftacutally it wasn't even 1.0-githash, it was 1.0-integer23:50
clarkbhad to start with not digit iirc23:51
lifelessdstufft: and yes it was a moving target, we just didn't expect to be penalised by setuptools deciding anything previously valid and not anymore was broken in a release with NO DEPRECATION PERIOD23:51
dstufftclarkb: https://hg.python.org/peps/rev/59a0d31a1bc2 can show me where? because I don't see it23:51
*** SumitNaiksatam has quit IRC23:52
lifelessdstufft: IMO forget the pep for a second. setuptools worked. Now it doesn't. It is deliberate. Where was the deprecation period ?!23:53
clarkbdstufft source labels23:53
*** SumitNaiksatam has joined #openstack-infra23:53
dstufftclarkb: source labels were never part of the version tag23:54
fungilifeless: so anyway i think the revert can be dealt with using a temporary backport branch instead. basically we need to release a pbr which switches .g to +g without necessarily also releasing the current semver work in progress along with it. i think if we branch from the last tag, apply the trivial patch, tag that and then delete the backport branch and merge that tag back into master we'll be23:54
fungifine?23:54
dstufftlifeless: there wasn't one, because the technical feasibility of doing one is dificult, and this only breaks a handful of projects that we were able to determine23:54
clarkbfungi ya I think that is a reasonable step23:55
fungithat also avoids muddying the git history with a largeish rollback followed by a revert of the same23:56
clarkbfungi it was my original suggestion to mordred23:56
fungiahh, i probably skimmed past that23:57
dstufftlifeless: in particular, one side effect of this change is that for many people, setuptools is now acting in accodrance with how they _expected_ it to act, so for many people this is fixing bugs not breaking things, and there are more situations like that according to our surveying than situations where this broke things, so adding a warning is going to confuse those people23:57
lifelesssaid warning would have said 'something odd is happening here and its going to be prohibited in future' - I don't see why that would confuse them23:58
*** pcrews has joined #openstack-infra23:59

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