Saturday, 2014-06-14

*** dims has joined #openstack-infra00:01
*** atiwari has quit IRC00:09
*** wenlock_ has quit IRC00:16
*** asselin has quit IRC00:20
*** hemna is now known as hemna_00:21
anteayathe delting nodes went away00:24
anteayathey just all disappeared00:24
anteayawho did something?00:24
anteayabuilding and in use appear to be around where they were before00:25
anteayabut the purple team all went home all of a sudden00:25
*** salv-orlando has quit IRC00:25
*** salv-orlando has joined #openstack-infra00:26
anteayadeleting nodes00:27
*** medieval1 has quit IRC00:29
*** medieval1 has joined #openstack-infra00:30
*** sarob__ has quit IRC00:30
*** sarob_ has joined #openstack-infra00:31
anteayait was right at 0:00 utc00:31
anteayathe disappearance of the deleting nodes00:31
*** harlowja has joined #openstack-infra00:31
*** gyee has quit IRC00:34
*** medieval1 has quit IRC00:34
*** sarob_ has quit IRC00:35
*** CaptTofu_ has quit IRC00:35
*** CaptTofu_ has joined #openstack-infra00:35
*** harlowja has quit IRC00:36
*** CaptTofu_ has quit IRC00:39
*** CaptTofu_ has joined #openstack-infra00:39
*** harlowja has joined #openstack-infra00:40
openstackgerritK Jonathan Harker proposed a change to openstack-infra/config: Fix nodepool instance hostnames
*** matjazp has joined #openstack-infra00:41
jesusaurusclarkb: we had the logic backwards in the fix_hostname script ^^00:41
clarkbfungi: mordred sdague: ok cluster is rebalanced I am stopping ES on 01 now00:41
clarkband calling it a day00:41
clarkbjesusaurus: that looks wrong00:43
*** ArxCruz has quit IRC00:43
clarkbjesusaurus: you want -n00:43
clarkbelasticsearch01 does not have an ES daemon running on it now00:45
clarkblets see what this looks like tomorrow00:45
*** mmaglana has quit IRC00:46
*** matjazp has quit IRC00:46
*** CaptTofu_ has quit IRC00:46
*** mmaglana has joined #openstack-infra00:46
jesusaurusclarkb: sorry, im debugging some weird error in my nodepool setup00:47
openstackgerritK Jonathan Harker proposed a change to openstack-infra/config: Fix nodepool instance hostnames
*** mmaglana has quit IRC00:51
openstackgerritAlexandre Viau proposed a change to openstack-infra/config: Added the Surveil project to gerritbot and stackforge config
*** CaptTofu_ has joined #openstack-infra00:55
*** HenryG has quit IRC00:55
*** marcoemorais has quit IRC00:55
*** CaptTofu_ has quit IRC00:56
*** CaptTofu_ has joined #openstack-infra00:57
*** CaptTofu_ has quit IRC01:01
*** harlowja has quit IRC01:06
*** HenryG has joined #openstack-infra01:12
*** Ryan_Lane1 has quit IRC01:12
*** sarob_ has joined #openstack-infra01:13
*** harlowja has joined #openstack-infra01:13
*** mriedem has joined #openstack-infra01:14
anteayathe check queue just disappeared, we are down to 6 in check now01:18
anteayacan't remember what it was but I had thought it was around 10001:19
anteayaI could be imagining things though01:19
*** timrc is now known as timrc-afk01:19
*** dims has quit IRC01:21
*** harlowja has quit IRC01:28
*** timrc-afk is now known as timrc01:35
*** zzelle has quit IRC01:37
*** zns has joined #openstack-infra01:37
*** zns_ has joined #openstack-infra01:40
*** matjazp has joined #openstack-infra01:41
*** zns has quit IRC01:42
*** CaptTofu_ has joined #openstack-infra01:44
*** CaptTofu_ has quit IRC01:44
*** CaptTofu_ has joined #openstack-infra01:44
*** matjazp has quit IRC01:46
*** dims has joined #openstack-infra01:47
*** jhesketh has quit IRC01:48
*** basha has joined #openstack-infra01:49
*** CaptTofu_ has quit IRC01:49
*** mmaglana has joined #openstack-infra01:50
*** dims has quit IRC01:52
*** sarob_ has quit IRC01:54
*** lcostantino has quit IRC01:54
*** sarob_ has joined #openstack-infra01:54
*** sarob_ has quit IRC01:59
*** arnaud has quit IRC02:00
*** mriedem has quit IRC02:04
*** cody-somerville has joined #openstack-infra02:04
*** harlowja_at_home has joined #openstack-infra02:09
*** salv-orlando has quit IRC02:15
*** harlowja has joined #openstack-infra02:15
*** cody-somerville has quit IRC02:17
*** zns_ has quit IRC02:21
*** e0ne has quit IRC02:26
*** medieval1 has joined #openstack-infra02:31
*** medieval1 has joined #openstack-infra02:31
*** jhesketh has joined #openstack-infra02:33
*** chuckC has quit IRC02:35
*** medieval1 has quit IRC02:37
*** matjazp has joined #openstack-infra02:42
*** nati_ueno has quit IRC02:46
*** matjazp has quit IRC02:47
*** plars has joined #openstack-infra02:47
*** dims has joined #openstack-infra02:48
*** dims has quit IRC02:53
*** CaptTofu_ has joined #openstack-infra03:00
*** slamont has quit IRC03:10
*** mmitchell_ has quit IRC03:11
*** slamont has joined #openstack-infra03:13
*** zns has joined #openstack-infra03:15
*** mmitchell_ has joined #openstack-infra03:17
*** sweston has joined #openstack-infra03:18
*** sweston has quit IRC03:23
*** harlowja_at_home has quit IRC03:28
*** CaptTofu_ has quit IRC03:32
*** matjazp has joined #openstack-infra03:43
*** matjazp has quit IRC03:47
*** dims has joined #openstack-infra03:49
*** rwsu has quit IRC03:49
*** pcrews has quit IRC03:51
*** harlowja_at_home has joined #openstack-infra03:53
*** dims has quit IRC03:54
*** harlowja is now known as harlowja_away03:58
*** gnuoy has quit IRC04:00
*** jamespage has quit IRC04:00
*** gnuoy has joined #openstack-infra04:00
*** jamespage has joined #openstack-infra04:00
*** timrc is now known as timrc-afk04:11
*** cody-somerville has joined #openstack-infra04:35
*** cody-somerville has quit IRC04:41
*** matjazp has joined #openstack-infra04:44
*** dims has joined #openstack-infra04:46
*** zns has quit IRC04:47
*** matjazp has quit IRC04:48
*** zns has joined #openstack-infra04:51
*** dims has quit IRC04:51
*** mmaglana has quit IRC04:51
*** mmaglana has joined #openstack-infra04:52
*** mmaglana has quit IRC04:57
openstackgerritA change was merged to openstack/requirements: Adding ldappool module dependency as needed by keystone bug #1320997.
uvirtbotLaunchpad bug 1320997 in keystone "Common Ldap handler connection pooling" [Medium,In progress]
*** basha has quit IRC05:12
*** harlowja_at_home has quit IRC05:16
*** harlowja_at_home has joined #openstack-infra05:16
*** harlowja_at_home has quit IRC05:17
*** harlowja_at_home has joined #openstack-infra05:17
*** wenlock_ has joined #openstack-infra05:17
*** praneshp has joined #openstack-infra05:27
*** wenlock_ has quit IRC05:28
*** marcoemorais has joined #openstack-infra05:29
*** marcoemorais has quit IRC05:29
*** harlowja_at_home has quit IRC05:40
*** zns has quit IRC05:43
*** matjazp has joined #openstack-infra05:44
*** matjazp has quit IRC05:49
*** basha has joined #openstack-infra05:55
*** basha has quit IRC06:00
*** Longgeek has joined #openstack-infra06:06
*** wenlock_ has joined #openstack-infra06:06
*** alkari has quit IRC06:07
*** Longgeek has quit IRC06:10
*** Longgeek has joined #openstack-infra06:10
*** praneshp has quit IRC06:15
*** Longgeek has quit IRC06:15
*** Longgeek has joined #openstack-infra06:15
*** Longgeek has quit IRC06:19
*** arnaud has joined #openstack-infra06:24
*** Longgeek has joined #openstack-infra06:27
*** wenlock_ has quit IRC06:30
*** matjazp has joined #openstack-infra06:31
*** dims has joined #openstack-infra06:49
*** matjazp has quit IRC06:52
*** dims has quit IRC06:54
*** ihrachyshka has joined #openstack-infra06:56
*** ihrachyshka has quit IRC06:57
*** _nadya_ has joined #openstack-infra06:57
*** arnaud has quit IRC06:59
*** arnaud has joined #openstack-infra07:01
*** Ryan_Lane has quit IRC07:09
*** e0ne has joined #openstack-infra07:09
*** e0ne has quit IRC07:10
*** _nadya_ has quit IRC07:13
*** arnaud has quit IRC07:14
*** penguinRaider has joined #openstack-infra07:15
*** zns has joined #openstack-infra07:18
*** tchorizo is now known as tchaypo07:29
*** fbo_away is now known as fbo07:34
*** andreykurilin_ has joined #openstack-infra07:34
*** rcarrill` has joined #openstack-infra07:53
*** rcarrillocruz has quit IRC07:54
*** zhiyan_ is now known as zhiyan08:05
*** trinaths has joined #openstack-infra08:09
*** saper has quit IRC08:23
*** trinaths has quit IRC08:25
*** CaptTofu_ has joined #openstack-infra08:28
*** Longgeek has quit IRC08:31
*** CaptTofu_ has quit IRC08:33
*** Longgeek has joined #openstack-infra08:42
*** willroberts has joined #openstack-infra08:45
*** _nadya_ has joined #openstack-infra08:51
*** _nadya_ has quit IRC09:06
*** basha has joined #openstack-infra09:10
*** andreykurilin_ has quit IRC09:10
*** zhiyan is now known as zhiyan_09:28
*** _nadya_ has joined #openstack-infra09:38
*** andreykurilin_ has joined #openstack-infra09:39
*** salv-orlando has joined #openstack-infra09:39
*** _nadya_ has quit IRC09:44
*** dims has joined #openstack-infra09:53
*** dims has quit IRC09:57
*** sarob_ has joined #openstack-infra10:00
*** sarob_ has quit IRC10:05
*** freyes has joined #openstack-infra10:08
*** afazekas has quit IRC10:11
*** kmartin has quit IRC10:19
openstackgerritBoris Pavlovic proposed a change to openstack-infra/config: Publish osprofiler on pypy and add check for requirments
*** salv-orlando has quit IRC10:49
*** dims has joined #openstack-infra10:54
*** dims has quit IRC10:58
*** salv-orlando has joined #openstack-infra10:59
*** sarob_ has joined #openstack-infra11:00
*** sarob_ has quit IRC11:04
*** CaptTofu_ has joined #openstack-infra11:31
*** andreykurilin_ has quit IRC11:52
*** andreykurilin_ has joined #openstack-infra11:53
*** dims has joined #openstack-infra11:55
*** salv-orlando has quit IRC11:59
*** dims has quit IRC12:00
*** sarob_ has joined #openstack-infra12:00
*** mugsie has quit IRC12:03
*** sarob_ has quit IRC12:05
*** timrc-afk is now known as timrc12:46
*** basha has quit IRC12:48
*** dims has joined #openstack-infra12:52
*** sarob_ has joined #openstack-infra13:00
*** sarob_ has quit IRC13:04
*** basha has joined #openstack-infra13:08
openstackgerritRoger Luethi proposed a change to openstack-infra/config: Add manuals-jobs for training-guides
openstackgerritA change was merged to openstack-infra/devstack-gate: don't delete grenade logs
openstackgerritRoger Luethi proposed a change to openstack-infra/config: Add manuals-jobs for training-guides
*** sarob_ has joined #openstack-infra13:37
*** penguinRaider has quit IRC13:39
*** andreykurilin_ has quit IRC13:41
*** sarob_ has quit IRC13:42
*** penguinRaider has joined #openstack-infra13:52
*** zzelle has joined #openstack-infra13:54
*** basha has quit IRC13:54
*** zns has quit IRC14:08
*** salv-orlando has joined #openstack-infra14:08
*** zns has joined #openstack-infra14:13
*** dims has quit IRC14:20
*** mriedem has joined #openstack-infra14:27
*** freyes has quit IRC14:30
*** andreykurilin_ has joined #openstack-infra14:31
*** sarob_ has joined #openstack-infra14:38
*** zns has quit IRC14:39
*** dims has joined #openstack-infra14:39
*** timrc is now known as timrc-afk14:42
*** sarob_ has quit IRC14:43
*** CaptTofu_ has quit IRC14:48
*** CaptTofu_ has joined #openstack-infra14:48
*** CaptTofu_ has quit IRC14:53
*** sunrenjie6 has joined #openstack-infra14:59
mordredmattoliverau: I disagree with your comment on 98656 - the exim class looks like it protects against empty list....15:06
*** nati_ueno has joined #openstack-infra15:11
*** penguinRaider has quit IRC15:11
openstackgerritMonty Taylor proposed a change to openstack-infra/config: Run stackalytics in infra
openstackgerritMonty Taylor proposed a change to openstack-infra/config: Align exim module parameter name with the tree
openstackgerritMonty Taylor proposed a change to openstack-infra/config: Make the fallback sysadmins value the same
mordredmattoliverau: but I did fix the thing you pointed out differently anyway - so thanks15:12
*** mattoliverau has quit IRC15:14
*** pcrews has joined #openstack-infra15:15
*** adalbas has joined #openstack-infra15:22
*** saper has joined #openstack-infra15:22
*** salv-orlando has quit IRC15:26
fungimordred: i'm not really here but since you are, any ideas on our best course of action in light of ? is it sane/possible for us to blacklist setuptools versions in our requirements lists? should we consider that we can't know the state of mirrors managed by downstream users? does someone need to push the setuptools maintainer for a15:31
fungimore downstream-considerate solution wrt version numbers?15:31
mordredO M G15:31
fungidstufft: ^ (if you're around)15:31
fungithis basically boils down to a case of "version numbers going backward"15:32
mordredfungi: well, a) if they've removed things from pypi I think we shoudl remove them from our mirror to be sure15:32
*** andreykurilin_ has quit IRC15:32
mordredfungi: but we don't really have a mechanism to do any version manip of setuptools itself15:32
fungiyeah, we can remove them from *our* mirror, but that only goes so far (though fwiw it at least solves our py3k unit testing problem for swiftclient et al)15:33
mordredwell, I'm not sure it's our job to fix the world of python15:33
mordredif someone does a COMPLETELY IRRESPONSIBLE thing like that15:33
*** superdan is now known as dansmith15:33
mordredI mean, other than publically shaming them, there isn't much we can do15:33
fungire-releasing 3.8.1 as 4.2 or 5.0 or something would have made much more sense, in my opinion15:34
mordredcorrect action on his part would be to release a 4.1 with the same contents as 3.8.115:34
mordred_then_ he could remove the other 4.x stuff safely15:34
mordredfungi: well, I'm going to go blow away setuptools 4 stuff from our mirror15:35
mordredof course, all of our current slaves and their slave image will still have 4.x15:36
mordredso this is going to take a bit to cycle out15:36
fungii really don't comprehend the reason for rolling version numbers backward though. are we running into a global version number shortage and need to conserve them?15:36
mordredno clue15:36
fungianyway, i'm short on free time to devote to public shaming, but figured i'd bring the situation to your attention15:38
mordredkk. thanks15:38
*** dims has quit IRC15:46
mordredfungi: btw - the mirror on mirror26 doesn't work15:46
mordredand looks like it never has in the history of the exitence of the node15:47
mordredthere are no packages in its cache or its mirror dir15:47
*** julim has quit IRC15:48
mordredwhy do we install python_requests from packages on our slaves?15:49
*** wenlock_ has joined #openstack-infra15:49
mordredsame questino for python-lxml and python-magic and python-zmq15:50
mordredI'm pretty sure that's all a waste of time15:50
openstackgerritMonty Taylor proposed a change to openstack-infra/config: Add support for disk-image-builder in nodepool
*** andreykurilin_ has joined #openstack-infra15:56
openstackgerritChris Krelle proposed a change to openstack-infra/config: Move check-tripleo-ironic-undercloud-precise check queue
*** adalbas has quit IRC15:57
NobodyCammorning mordred :)15:58
NobodyCamand fungi :)15:59
mordredmorning NobodyCam15:59
NobodyCamhope that patch is correct :-p15:59
*** e0ne has joined #openstack-infra15:59
NobodyCamso who got patch 100000 ... /me goes to look16:00
mordredNobodyCam: greghaynes16:00
mordredNobodyCam: you don't need the noops16:00
mordredother than that, it looks good16:00
NobodyCam:) nix the section or just the noop16:01
mordrednix the section16:01
openstackgerritChris Krelle proposed a change to openstack-infra/config: Move check-tripleo-ironic-undercloud-precise check queue
NobodyCamty mordred :)16:04
*** andreykurilin_ has quit IRC16:08
openstackgerritMonty Taylor proposed a change to openstack-infra/config: Fix mirror build on py26
*** dims has joined #openstack-infra16:13
*** e0ne has quit IRC16:17
mordredalso - I had an old file - so I have answers to why we install those python pacakges from above16:17
*** dims has quit IRC16:17
*** e0ne has joined #openstack-infra16:17
mordredmorganfainberg: ping16:22
mordredclarkb, morganfainberg: any idea why we're installing mod_wsgi on our jenkins slaves? it seems like devstack should be installing that for the apache keystone tests and I can't think of any other reason to have it16:23
*** dims has joined #openstack-infra16:26
*** yamahata has quit IRC16:27
*** sunrenjie6 has quit IRC16:28
*** sarob_ has joined #openstack-infra16:40
*** e0ne has quit IRC16:40
*** e0ne has joined #openstack-infra16:41
*** sweston has joined #openstack-infra16:42
*** arnaud has joined #openstack-infra16:42
*** sunrenjie6 has joined #openstack-infra16:47
*** wenlock_ has quit IRC16:47
dstufftfungi: mordred sigh16:47
dstufftfungi: mordred I'll talk to jaraco16:47
fungimordred: on the mirror26 fix, did you confirm /usr/local/bin is in the shell path jenkins uses to run that?16:49
*** basha has joined #openstack-infra16:50
dstufftsetuptools is getting a 5.0 w/ the contents of 3.8.116:50
*** nati_ueno has quit IRC16:50
dstufftmordred: fungi ^16:50
fungidstufft: yay--thanks!!!16:51
dstufftfungi: mordred FWIW the officially recommended mirroring client (bandersnatch) is perfectly capable of handling deleted files.16:53
dstufftNot sure if devpi can16:53
*** sunrenjie6 has quit IRC16:53
dstuffttechincally the mirroring PEP says you have to delete the files16:53
dstufftbut i suspect y'all aren't the only ones who don't have that implemented16:54
*** sunrenjie6 has joined #openstack-infra16:54
dstufft(Also Arch already has 4.0.1 in their archives, and I'm not sure a linux distro can handle going backwards other than with an epoch)16:54
openstackgerritMonty Taylor proposed a change to openstack-infra/config: Move ansible things into a module
openstackgerritMonty Taylor proposed a change to openstack-infra/config: Add playbook for cleaning workspaces
openstackgerritMonty Taylor proposed a change to openstack-infra/config: Add mirror management playbooks
mordreddstufft: yeah. so that's the thing16:55
mordredit's not about the mirroring technology16:55
mordredit's about the backwards versions16:55
mordredbecause of people who may have installed something16:55
mordreddoesn't bother me that he deleted the files16:56
mordredit bothers me that the "fix" is a lower version than the broken thing16:56
dstufftFWIW if I'm not around, his name is jaraco on Freenode and he hangs out in #pypa-dev. He's not always there but he's the setuptools guy16:56
mordredfungi: I did not16:56
mordreddstufft: awesome16:57
dstuffthe's a nice guy16:57
mordreddstufft: I think I remember him being nice from pycon16:57
mordredbut I don't know him and I'd be slightly reluctant to give him release advice out of the clear blue - I don't want MORE people in the python world thinking I'm a jerk than already do16:58
*** sunrenjie6 has quit IRC16:58
mordredfungi: how would I verify that? just su - jenkins  and then echo $PATH? or does jenkins override path?16:58
dstufftmordred: yea understood :) Just saying in case there's ever something that is breaking stuff real bad and I'm not around (crazy thought right? I wouldn't be on the computer)16:59
openstackgerritMonty Taylor proposed a change to openstack-infra/config: Remove old salt references from the puppet
mordreddstufft: ah - awesome. appreciate that17:00
mordreddstufft: also, why would you not be on the computer?17:00
dstufftmordred: well sometimes the power goes out17:01
*** otter768 has joined #openstack-infra17:01
mordreddstufft: that sounds terrible17:01
dstufftit is!17:01
dstufftit was waaaay worse growing up though17:01
*** Longgeek has quit IRC17:01
dstufftI grew up like a super rural area, I lived half way up a mountain17:02
dstufftwe lost power for *days* when it went out17:02
dstuffthere it's like... an hour?17:02
mordredso did fungi17:02
fungimordred: not sure--mostly just curious. i think maybe the jenkins webui mentions the path it adds to the environment for workers, but i'm not certain of that17:02
mordredI wonder what it is about this channel that attracts mountain people...17:02
mordredfungi: yes.17:03
fungimordred: dstufft: yeah, in the winter we could go without power for a week or two in storms, so we were used to keeping supplies, hauling water by hand (electric pumps aren't so helpful in an outage), et cetera17:03
fungimordred: lgtm!17:04
mordreddstufft: dare I ask why redhat thinks it's the right thing for "pip install $foo" to install things in /usr/bin and not /usr/local/bin?17:05
mordredfungi: so, as I make more ansible playbooks17:05
dstufftfungi: yes we had the electric well pump too17:05
mordredfungi: it's amusing me how close the syntax is to our jjb macros17:05
dstufftmordred: because it's where Python default to doing it17:05
mordredfungi: like, it's REALLY close17:05
*** Longgeek has joined #openstack-infra17:05
dstufftmordred: Debian adds a patch that makes pip go to /usr/local/bin17:05
fungimordred: convergent evolution17:06
mordreddstufft: why does python think third-party things should default to /usr/bin/ when make install has, by default, installed into /usr/local for about 30 years?17:06
* mordred should maybe just give up on this one17:07
mordredfungi: look at how similar that is to:17:07
*** paul-- has quit IRC17:07
dstufftmordred: Python doesn't think *third party* things, Python has no concept of Third party vs Linux distro stuff, it has a bin directory and it uses a prefix, the Linux Distros set the prefix to be /usr/ because Python is part of the OS17:07
dstufftso Python knows it's bin dir is /usr/bin/17:08
dstufftbecuase that's what it's configured to use17:08
* fungi disappears to run more errands17:08
mordreddstufft: ah. gotcha17:08
*** dims has quit IRC17:08
dstufftDebian adds a patch that makes distutils default to /usr/local/ and add a flag to switch it to back to /usr/ which they use for their own packages17:08
mordreddstufft: it makes total sense and I can see the logic - and it still is just super strange to me that anything similar to "make install" would put anything in /usr by default without adding arguments17:09
mordredbut that may just be from my many years of doing c things17:09
dstufftmordred: well the thing is, your general C thing is it's own seperate thing, you're not normally installing a C thing *into* another C thing17:10
mordreddstufft: yah17:10
dstufftbut Python will probably adopt something similar to Debian's solution at some point17:10
dstufftI plan to write a PEP for it17:10
mordreddstufft: well - I can TOTALLY see the install into /usr/lib/python2.7/site-packages17:10
dstufftI just haven't yet because it's not that big of a deal17:10
mordredlike, that makes 100% sense to me for exactly that reason17:11
mordredit's purely the script/bindir installation that's strange17:11
mordreddstufft: I would be more than happy to help with that PEP - and also, yeah - not urgent :)17:12
mordredfungi, jhesketh, zaro: so - with the large amount of similarity between the ansible playbooks and the jjb macros - I wonder if there is an opportunity to leverage anything directly17:12
mordredfungi, jhesketh, zaro: like, both are descriptions of how to run tasks17:13
*** mattoliverau has joined #openstack-infra17:13
*** otherwiseguy has joined #openstack-infra17:16
*** paul-- has joined #openstack-infra17:18
openstackgerritA change was merged to openstack-dev/hacking: Updated from global requirements
openstackgerritMonty Taylor proposed a change to openstack-infra/config: Remove salt
openstackgerritMonty Taylor proposed a change to openstack-infra/config: Remove old salt references from the puppet
openstackgerritMonty Taylor proposed a change to openstack-infra/config: Notify in IRC when puppet run fails
openstackgerritMonty Taylor proposed a change to openstack-infra/config: Use ansible instead of direct ssh calls
openstackgerritMonty Taylor proposed a change to openstack-infra/config: Add mirror management playbooks
openstackgerritMonty Taylor proposed a change to openstack-infra/config: Move ansible things into a module
openstackgerritMonty Taylor proposed a change to openstack-infra/config: Remove salt
openstackgerritMonty Taylor proposed a change to openstack-infra/config: Remove old salt references from the puppet
openstackgerritMonty Taylor proposed a change to openstack-infra/config: Add playbook for cleaning workspaces
openstackgerritMonty Taylor proposed a change to openstack-infra/config: Rearrange into using roles
mordredsorry all - had to rebase against master to clear a merge conflict :(17:30
*** sarob__ has joined #openstack-infra17:33
*** e0ne has quit IRC17:33
*** sarob_ has quit IRC17:36
*** sarob__ has quit IRC17:37
*** otherwiseguy has quit IRC17:38
*** otter768 has quit IRC17:39
mordreddstufft: there now seems to be a setuptools 5 - and it seems to break when I try to install it17:43
dstufftof course17:43
mordred  File "/tmp/user/0/pip_build_root/setuptools/setuptools/script", line 217:43
mordred    __requires__ = %(spec)r17:43
mordred                   ^17:43
mordredSyntaxError: invalid syntax17:43
mordreddstufft: that was in a virtualenv fwiw17:43
*** ihrachyshka has joined #openstack-infra17:44
*** CaptTofu_ has joined #openstack-infra17:47
*** ihrachyshka has quit IRC17:51
*** ihrachyshka has joined #openstack-infra17:51
*** wenlock_ has joined #openstack-infra17:52
*** _nadya_ has joined #openstack-infra17:52
*** dims has joined #openstack-infra18:05
*** arnaud has quit IRC18:05
*** Longgeek has quit IRC18:08
*** dims has quit IRC18:09
*** wenlock_ has quit IRC18:10
*** krtaylor has quit IRC18:19
*** CaptTofu_ has quit IRC18:21
*** CaptTofu_ has joined #openstack-infra18:22
openstackgerritA change was merged to openstack-infra/nodepool: Check for stale PID lock when starting
*** CaptTofu_ has quit IRC18:26
clarkbmordred: I do not know why we are installing mod_wsgi18:30
fungimordred: was it setuptools we previously discussed as being developed primarily in python 3 on windows?18:30
* notmyname is alive18:34
mordrednotmyname: that's excellent18:35
notmynamemordred: terms and conditions may apply ;-)18:35
mordrednotmyname: :)18:35
*** alexpilotti has joined #openstack-infra18:38
clarkbmordred: univision is the best thing ever by the way. Seriously ABC we get colombia greece, uruguar costa rica, but no England Italy?18:40
mordredclarkb: england italy is on espn18:40
mordredclarkb: btw- mod_wsgi was added by me in commit b47dbcdef0e2e4b1b30b0eab3ebf6d5ba929ea3118:41
mordredclarkb: Date:   Tue Oct 11 15:56:11 2011 -070018:41
notmynamemordred: clarkb: what time? my son wants to watch that one18:41
mordredclarkb: Rework all of the slaves for virtualenv.18:41
mordrednotmyname: 3pm18:41
notmynamemordred: thanks18:41
clarkbnotmyname: it will also be on univision18:42
clarkbnotmyname: which is where I will watch it as I don't haev cable18:42
notmynameheh. well he did do spanish-immersion kindergarten ;-)18:42
mordredclarkb: best I can tell, the list of depends was based on what was in the apts files in devstack at the time18:42
*** sweston has quit IRC18:42
clarkbnotmyname: the "GGGGGOOOOOOLLLLLLLLL" is so much better on univision too18:42
clarkbmordred: oh so we can probably clean that up a bit18:43
mordredclarkb: yah18:44
mordredclarkb: I mean, most of the other things we install seem sane18:44
openstackgerritMonty Taylor proposed a change to openstack-infra/config: Remove mod_wsgi package
mordredclarkb: there ya go ^^18:47
mordredbtw - looking at commit b47dbcdef0e2e4b1b30b0eab3ebf6d5ba929ea31 is fun18:47
mordredalso, I'd forgotten just how far I'd gotten with apt repo automation18:49
*** mriedem has quit IRC18:54
morganfainbergmordred, out of curiosity ^ mod_wsgi stuff that affects which jenkins systems?18:55
*** basha has quit IRC18:55
morganfainbergmordred, i ask because if this would affect the tempest running systems it would break apache deployed keystone effort (i'll look more closely later on need to run today though).18:57
*** Ryan_Lane has joined #openstack-infra18:58
morganfainbergunless devstack handles installing it ... like i said i'll look into it later on19:00
*** Ryan_Lane has quit IRC19:02
*** Ryan_Lane has joined #openstack-infra19:03
*** _nadya_ has quit IRC19:04
*** ihrachyshka has quit IRC19:05
*** dims has joined #openstack-infra19:05
*** adalbas has joined #openstack-infra19:06
*** yfried_ has joined #openstack-infra19:08
*** dims has quit IRC19:10
*** Ryan_Lane has quit IRC19:11
*** andreykurilin_ has joined #openstack-infra19:12
mordredmorganfainberg: yeah - that's the thing ... if you devstack doesn't handle installing it, we should def fix that19:15
mordredmorganfainberg: ok- install_apache_wsgi installs it - but it's actually only listed in the apts file for horizon and not for keystone19:17
mordredmorganfainberg: so nothing shoudl break in the gate, but there is certainly a place where we're not being explicit19:17
*** sweston has joined #openstack-infra19:17
*** arnaud has joined #openstack-infra19:18
*** andreykurilin_ has quit IRC19:19
*** andreykurilin_ has joined #openstack-infra19:19
*** sarob_ has joined #openstack-infra19:36
*** andreykurilin_ has quit IRC19:38
*** e0ne has joined #openstack-infra19:38
*** zzelle has quit IRC19:39
*** sarob_ has quit IRC19:40
*** andreykurilin_ has joined #openstack-infra19:41
*** zzelle has joined #openstack-infra19:44
*** andreykurilin_ has quit IRC19:46
*** sweston has quit IRC19:48
*** arnaud has quit IRC19:49
*** arnaud has joined #openstack-infra19:51
*** andreykurilin_ has joined #openstack-infra19:51
*** sarob_ has joined #openstack-infra19:51
*** sarob_ has quit IRC19:56
*** andreykurilin_ has quit IRC19:56
*** andreykurilin_ has joined #openstack-infra19:57
mordredclarkb: today's games  have thus-far not been as good as yesterday's19:58
*** ihrachyshka has joined #openstack-infra20:00
clarkbmordred: ya20:01
clarkbbut spain netherlands was going to be a good one20:01
*** ihrachyshka has quit IRC20:01
clarkbgermany portugal should be good too (thats monday?)20:01
mordredengland italy might not be bad20:04
mordredivory coast japan is not going to be great20:05
clarkbI am going to have to figure out seattle office streaming assuming no one else has sorted it out yet20:05
clarkbjesusaurus: ^20:05
*** arnaud has quit IRC20:12
mordredthe game went from being boring to quite good20:18
greghayneswow crc20:18
*** lttrl has joined #openstack-infra20:21
*** sarob_ has joined #openstack-infra20:24
*** mriedem has joined #openstack-infra20:31
*** Sukhdev has joined #openstack-infra20:35
*** sarob_ has quit IRC20:36
lifelessnow 3.3 is failing20:38
lifeless2014-06-14 18:41:56.622 |     error: /home/jenkins/workspace/gate-pbr-python33/.tox/py33/lib/python3.3/site-packages/pbr_testpackage-0.0-py3.3.egg-info: File exists20:38
mordredlifeless: btw... most annoying bug evar20:38
mordredlifeless: it's next up on my list of things to smash my facehole against20:39
lifelessmordred: py26 started working20:39
lifelessmordred: py33 stopped20:39
lifelessmordred: this makes me think its a isolation issue / race condition in the test suite20:40
mordredlifeless: I would agree with atht20:40
lifelessmordred: e.g. - note that its writing into the tox's own site packages20:40
lifelessmordred: this is is in pbr.tests.test_commands.TestCommands.test_custom_build_py_command20:40
mordredlifeless: yeah. I think that's a mistake20:40
lifelessmordred: if two such testpackage installs run at the same time20:40
lifelessmordred: what will happen...20:41
mordredI think we shoudl not be installing pbr_testpackage into the tox venv20:41
mordredlifeless: oh! hang on. I have an idea...20:43
lifelessmordred: btw did you see my 'is it ok to cut a release' query ?20:45
openstackgerritMonty Taylor proposed a change to openstack-dev/pbr: Use the current pbr for testpackage tests.
mordredlifeless: I did not20:45
mordredlifeless: ^^ there is an attempt20:45
lifelessmordred: check scrollback, here ;)20:46
mordredlifeless: I do not see it - you want to cut a pbr?20:46
lifelessI was thinking about it yes. Inventory bad mmkay.20:47
lifelessalso, I want to know what your general policy on doing such things is20:47
lifelessI will be interested if that attempt works20:48
lifelessbecause its not failing on that code20:48
lifelessmordred: ^20:48
lifelessmordred: that code doesn't install the test package20:48
*** markmcclain has joined #openstack-infra20:48
mordredoh. good point20:49
mordredlifeless: in general, the policy is "hey man, we should maybe release" ... or "holy crap, there's a disastrous bug, we need to release right now"20:49
lifelessmordred: its very confusing20:50
lifelessmordred: because line 128 - the one you changed - is whats failing20:50
lifelessmordred: but thats meant to be installing *pbr* not pbr_testpackage20:50
mordredlifeless: nope! I see it20:51
mordredlifeless: wait. I may be lying20:51
lifelesshowever, I have spotted a clear problem myself20:52
mordredlifeless: yeah. so ...20:53
lifelesspip isn't concurrency safe apparently20:53
lifelessso this won't work for two reasons20:53
mordredwe're working off of pbr.__file__20:53
lifelessa) even if it was correctly installing pbr20:53
lifelessit would race with other testr backends.20:53
lifelessb) its not currently installing pbr for f*only knows reasons20:54
mordredlifeless: what are we intending to install pbr _into_ ?20:56
lifelessthe venv20:56
mordredthe test suite doesn't make virtualenvs20:56
lifelessI know20:56
lifelesstox does20:56
lifelessjust about to push20:56
mordredright. tox also installs pbr into that venv20:56
lifelessmordred: implicitly ?20:56
mordredin all cases20:57
mordredit does it before every time you run it20:57
lifelessoh,then this is a no-op20:57
lifelessit was entirely unobvious that this happens20:57
* mordred just now groks the whole picture20:57
mordredyou know - the test suite should potentially create virtualenvs and install things into them20:58
openstackgerritlifeless proposed a change to openstack-dev/pbr: Allow examining parsing exceptions.
openstackgerritlifeless proposed a change to openstack-dev/pbr: Teach pbr VersionInfo about debian versions.
lifelessIt could do one per thread yes20:58
openstackgerritlifeless proposed a change to openstack-dev/pbr: Teach pbr about post versioned dev versions.
lifelessfuture work20:58
openstackgerritlifeless proposed a change to openstack-dev/pbr: Add a converter to version_tuples.
mordredlifeless: yup20:58
openstackgerritlifeless proposed a change to openstack-dev/pbr: Break out a common version object from VersionInfo
mordredlifeless: sorry, I should have caught this weeks ago20:58
lifelesslet me just sign into gerrit again. sigh.20:59
mordredlifeless: I'm still not 100% sure why the code was installing the testpackage instead of pbr itself - pip concurrency problems notwithsstanding. your abspath stuff _should_ have worked best I can tell20:59
lifelessit did the right thing here AFAICT20:59
lifelessnow, let me see which things should land now21:00
lifeless80856 should21:00
*** adalbas has quit IRC21:00
*** markmcclain has quit IRC21:01
mordred+A'd 8085621:02
lifelessmordred: I think there is enough consensus on the semver spec that we could land 80449 if we announce it to -infra and -dev; or we can wait and I'll tie it all up with a bow next week I hope21:03
lifelessmordred: 95625 needs infra reviewers21:03
mordredlifeless: I'm +2 on 8044921:04
*** sarob_ has joined #openstack-infra21:05
mordredlifeless: maybe dhellmann or clarkb or jhesketh or SergeyLukjanov or fungi will feel like reviewing it sometime today :)21:07
*** sarob__ has joined #openstack-infra21:07
dhellmannmordred, lifeless : is 80449 tied to the spec ?21:08
lifelessdhellmann: yes21:09
lifelessdhellmann: in the sense that the spec implies 8044921:09
lifelessdhellmann: 80449 is a very small subset of the specs work21:10
*** sarob_ has quit IRC21:10
dhellmannlifeless: ok, I'd like to get that spec approved before the code change then21:10
*** e0ne has quit IRC21:10
lifelessdhellmann: its waiting on you AFAICT21:10
mordreddhellmann, lifeless the reason I think we need another digit, btw21:10
lifelessdhellmann: I lie21:11
mordreddhellmann, lifeless: is to be (waves hands) compatible with upstream semver21:11
lifelessdhellmann: its waiting on me doing a rewrite. I will do monday.21:11
dhellmannlifeless: maybe you can convince mordred to weigh in on that spec, too ;-)21:11
lifelessmordred: upstream specifieds 3 and only 321:11
mordredexcept, they'll allow a suffix aftera  -21:11
mordredand they dont' really care what goes into the suffice21:11
lifelessmordred: they care a lot21:11
*** sarob__ has quit IRC21:11
mordredok. hang on - not my point right now, let's come back to that21:12
lifelessmordred: they specify complex and bong sorting rules about the suffixes21:12
mordredwhat I'm saying is, 3 meaningful numbers is fairly important21:12
mordredand having the third have an a in it is clearly a weird thing from that view point21:12
*** jamespage_ has joined #openstack-infra21:12
lifelessmordred: oh right, so I don't need to rework it.21:13
mordreddhellmann: ^^ does that make sense to you?21:13
lifelessOther than to note this point.21:13
dhellmannthat's fine, just document it21:13
lifelessmordred: I agree21:13
mordred(I'll also write it in the spec stuff)21:13
mordredyou want lifeless to put it in the spec text? or me to put it in a comment? or both?21:13
dhellmannin the spec text21:13
dhellmannthat way our grandchildren will have an artifact to refer to21:14
lifelessI'm putting it in right now21:14
lifelesswe don't have follow on feedback from josh about rpm21:14
lifelessbut I think we can fine tune that and update the the spec as we go21:14
*** dims has joined #openstack-infra21:15
dhellmannlifeless: I'll wait for a +1 from mordred on the spec and a couple from other oslo cores; the stuff for rpm can come in another spec (or an update to this one, I guess)21:15
dhellmannit is steak cooking time, so I'll check back tomorrow for updates :-)21:16
mordreddhellmann, lifeless: once we're finally solid with this, I think we should get aroudn to writing a pep too21:16
dhellmannfor the ppa to look at?21:16
mordreddhellmann: ppa == ? (ppa means personal package archive in my brain)21:16
lifelessmordred: sure, we can toss it at ncoghlan21:17
dhellmannoh, pypa -- whatever the packaging team calls itself this year21:17
mordredlike, as a follow on pep to 440 - "semver as it relates to pep440" or something21:17
lifelessmordred: so - can you review 96608 as a priority21:17
dhellmannthat makes sense21:17
dhellmannthe pep, that is21:17
lifelessmordred: since thats now the blocking thing, and dhellmann can you shop it around the oslo cores you have in mind?21:18
lifelessdhellmann: this is FWIW what blocks more of my test libraries moving to git. So its a deep dependency tree to improve a bunch of things.21:18
dhellmannlifeless: maybe we should get pbr cores to look at this one?21:18
dhellmannok, that's good to know21:18
mordredlifeless: yup. I'm going to review it right after I get back from the store21:19
dhellmannugh, there are 17 pbr core reviewers? wth21:19
mordredlifeless: but I'm pretty sure it's good with me21:19
lifelessdhellmann: welcome to inclusion.21:19
mordreddhellmann: infra-core + oslo-core + lifeless I beleive21:19
dhellmannyeah, that's what it looks like21:19
lifelessmordred: I suspect i might describe the fine existing preversion detail a little wrong, I will check and possibly push a new rev up nowish21:19
dhellmannwho should we be looking to for feedback here?21:19
lifelessdhellmann: ops and cd folk, its not about the code :)21:20
lifelessdhellmann: packagers21:20
mordredso - it needs to be the people who can hold both packaging AND CD in their heads simulatenously21:20
dhellmannlifeless: feel free to add some reviewers, then.21:20
mordredotherwise, there's too much "why don't you just ..."21:20
*** dims has quit IRC21:21
mordredI think dhellmann, lifeless, ttx, jeblair and clarkb are the ones who have up until now shown interest in diving in to the subject matter fully21:21
*** davidhadas has joined #openstack-infra21:21
mordredand dstufft21:22
mordredand Alex_Gaynor21:22
mordredI like having them aroudn :)21:22
dstufftwhat'd I do now21:22
dhellmannthat's a good list, I added them21:22
lifelessdstufft: know stuff about stuff21:22
dstufftalways a bad choice to know stuff about stuff21:22
dstufftthen people expect you to do stuff with the stuff you know about stuff21:23
dhellmanntruer words were never spoken21:23
* dhellmann knows this charcoal isn't going to light itself, and heads off to do stuff with fire21:23
clarkbnow I really want to do another brisket but that will have to wait until next weekend21:23
Sukhdevclarkb: Something changed recently which is causing all (most) of the third party CI's to fail21:24
dstufftoh man CD versioning is so hard to do nicely21:24
dstufftI'm trying to figure that out for Warehouse lately21:25
clarkbSukhdev: ok? I think you need to be more specific than that21:25
clarkbSukhdev: I doubt it was an infra thing we have been too busy this week to change things21:25
clarkb(certainly could be though)21:25
Sukhdevclarkb: let me gather some info and will provide - I noticed large number of failures and thought of letting you know21:26
mordreddstufft: well then, definitely review the above!21:26
mordreddstufft: because we're insane enough that we need to do CD versioning AND traditional released software versioning21:26
*** zns has joined #openstack-infra21:27
lifelessok, clarified the post-version/pre-version some and pushed21:27
dstufftprobably I'd just encode the "breaking" information in whatever you use for changelog21:27
lifelessdstufft: dhellmann: e.g. refres now, I think its on /6 now21:28
Sukhdevclarkb: I pasted the failure here - please take a look
mordreddstufft: that's an interesting idea ...21:28
lifelessdstufft: that roughly what I propose but putting in changelog is problematic21:28
Sukhdevclarkb: is failing21:28
lifelessdstufft: since we use git for changelog, and its not editable.21:29
mordredlifeless: whyfor?21:29
clarkbSukhdev: I believe that is the setuptools bug. Remove setuptools version 421:29
mordredbut we could totally put a "BREAKING" or something in there21:29
*** sweston has joined #openstack-infra21:29
clarkbSukhdev: and install latest 3.X version (I think 3.8)21:29
lifelessdstufft: which means if you make a mistake you can't fix it. Where as if its metadata you can edit that without having to do history re-writes21:29
clarkbalso woo setuptools21:29
dstufftmordred: like y'all use git commit message for your change log, so you could add a field (ala Signed-Off-By) that says like (Compatability-Statement: Breaking/Feature/Buffix)21:29
lifelessmordred: ^21:29
dstufftlifeless: well I think using git commit messages for change log is a bad idea for that reason in general ;)21:29
dstuffttopfiles approach++21:29
lifelessdstufft: I propose just putting it in setup.cfg21:29
Sukhdevclarkb: can you please provide the link to the bug?21:30
mordredtopfiles is still too much repitition for me, but I can see how folks would prefer it21:30
lifelessdstufft: if you attempt to merge stuff cross-releases it will conflict, and otherwise it will be identical, so should be fairly straightforward.21:30
fungiSukhdev: clarkb: bug 132697221:31
uvirtbotLaunchpad bug 1326972 in python-swiftclient "swiftclient fails to install under tox with Python3" [Undecided,New]
clarkblifeless: mordred dhellmann so initial feedback. I think we are making this far more complicated than it is today21:31
clarkbthe intent is good but the proposal seems to make it harder to get right21:31
lifelessdstufft: my projects maintain separate changelogs yes, same reason as you :).21:31
dstufftlifeless: yea, sounds impossible to mechanically enforce though, e.g. if you include it with your change log entries (git commit, topfile whatever) you can enforce that you include a statement about the compatability of every change21:31
clarkball of a sudden there are a zillion knobs to turn in order to get the proper versions21:31
Sukhdevfungi, clarkb: Thanks21:31
lifelessclarkb: we're releasing 6? projects/week within tripleo and doing this check every week.21:32
dstufftwhereas if you're just recording the last thing that did X, you're relying on humans to check to make sure that you did it21:32
lifelessdstufft: including a statement doesn't mean you get the statement right.21:32
clarkbfungi: we have a bug on our side?21:32
dstufftlifeless: well sure, but that's an argument agaisnt git as a changelog source imo ;)21:32
lifelessclarkb: are you able to help me see where we can simplify it ?21:32
clarkblifeless: I like the git log thing21:33
lifelessclarkb: the knobs are opt-in.21:33
clarkblifeless: rather than setting a bunch of knobs in a config file. Enforce it through the log itself21:33
lifelessclarkb: folk can just do what they do today.21:33
lifelessclarkb: if you are willing to rebase trunk, sure.21:33
clarkblifeless: so start with a seed tag eg 1.0.021:33
clarkbthen all tag versions after that are generated based on the git log back to seed tag21:33
dstufftI'm not sure you can really change it without breaking existing versions21:33
clarkbit may be expensive to do that parsing of the graph but I really don't want to set knobs21:34
fungiclarkb: the bug on our side which is referenced in the post about removing setuptools 4.x (indirectly by way of a link in the bitbucket bug) is for swiftclient installation breaking under py3321:34
dstufftif you claim this was a breaking change but it wasn't, then you can't go back and pretend it wasn't, because you have versions already that had the new version21:34
fungiso not sure why this would affect devstack runs21:34
lifelessclarkb: my concern isn't cost.21:34
clarkbdstufft: I think that is ok21:34
clarkbdstufft: the opposite wouldn't be21:34
mordredclarkb: ++21:35
lifelessdstufft: releases are a boundary where that happens; if you haven't released you only have devN builds to deal with21:35
mordredlifeless: but isn't it goign to be calculating next_Version differently?21:35
mordredso it'll be either or depending on whether you've indicated breaking change21:35
lifelessmordred: if it wasn't a breaking fix, just roll the setup.cfg change back.21:35
lifelessmordred: right, dev versions.21:35
mordredexcept that someone may have deployed
lifelessmordred: it wouldn't be a trivial thing to do because it will give CDers headaches.21:36
mordredright. I guess I'm just saying, allowing for having made mistakes and rolling them back is not really a feature21:36
mordredit shouldn't be done21:36
lifelessso lets work through this21:36
mordredthere are two possilibiies21:36
mordredeither you land a change which broke things but you didn't mark as such21:37
lifelessyou make a mistake that makes a version higher than needed21:37
lifelessyou make a mistake that makes a version lower than needed21:37
mordredor you land a change marked as breaking which wasnt' really21:37
clarkbmordred: you deleted setuptools 4 from our mirror right?21:37
mordredclarkb: yes21:37
clarkbmordred: can I fix released on 1326972?21:37
mordredclarkb: yah21:37
clarkbmordred: fix released adn assigned to you21:37
mordredlifeless: right. we're saying the same thing in our setup21:37
lifelessif we say that case A is fixed by living with it21:37
mordredlifeless: what I'm saying is that if you release a version higher than needed - tough21:37
mordredyou live with it - the version is in the wild21:38
dstufftCase A is what happened with setuptools today21:38
dstufftsort of21:38
lifelesscase B can be solved by making a no-op commit that just claims the needed break.21:38
mordredlifeless: yup21:38
mordredwhich is the equiv of "oops, I shoulda bumped the vesrion before"21:38
lifeless+ deleting the bad version so folk not ready for the break are not broken.21:38
dstufftif you put it in the gitlog, you can enforce it so that you require a compatability statement on every commit21:38
mordredlifeless: no21:38
dstuffteither bugfix, feature, or breaking21:39
clarkbdstufft: right thats sort of what I am thinking21:39
clarkbdstufft: then you don't really need a config file21:39
clarkbdstufft: you just need good logs21:39
mordredI'm more on board with the git log the more we talk through it21:39
lifelessmordred: no ? you force them to go from < 3.0.0 to < 2.4.6 or whatever ?21:39
mordredlifeless: no, I mean you can't delete the version21:39
mordredit's out there21:39
mordredit exists21:39
dstufftif all the changes are bugfixes, then you increment the third digit, if ther are any features, you increment the second digit, if any breaking you increment the first digit21:39
lifelesssure, and you can't re-issue it, but removing it from mirrors can be helpful to users. Its a separate discussion to this.21:40
mordredyes. separate discussion21:40
lifelessdstufft: well, you're missing the 0 right shift, butyes.21:40
clarkblifeless: those increment between tags21:40
dstufftand you get to mechanically require that every change has a statement21:40
clarkblifeless: so two separate things going on21:40
mordredlifeless: I think he's saying that, when you calculate next version, you can examine the log and look for each of those characteristics21:40
clarkbthere is the tagging and there is the more verbose CD version generation. Both should work with the log system21:40
dstufftso you know what kind of changes exist in any set of changes21:41
dstufftif they are all bugfix or whatever21:41
lifelessclarkb: mordred: no, I think you both just misunderstood me.21:41
mordredlifeless: awesome21:41
lifelessclarkb: mordred: semver versions beginning with 0 are different.21:41
lifelessa breaking change to version 0.1.2 results in 0.2.021:41
lifelessnot in 1.0.021:41
mordredlifeless: sure. I largely don't care about 0 versions and think we shoudl stop using them21:42
lifelesssemver rules will never force you to hit 1.0.0 automatically.21:42
clarkbright just start with 1.0.0 everywhere21:42
dstufftsemver states if youre using it in production you shouldn't be using a leading zero21:42
mordredbut if we support them, then fine21:42
lifelessdstufft: no, it claims there is no api compat guarantee. Slightly different.21:42
mordreddstufft: I mostly agree with you on the tagging - except I don't actually want to add the word 'bugfix' into all 500 commits I make every day21:42
lifelessright so I was going to say21:43
lifelessthere is a common case21:43
mordredthere is already a thread somewhere suggesting that we stop consuming or producing 0.x things21:43
lifelessthat shouldn't need an assertion21:43
mordredlifeless: ++21:43
lifelesswe can do 0 easily, so lets not rathole into a different debate. And folk use pbr for non-openstack, and they may want 0.x, and 0.x can be defined sanely.21:43
mordredlifeless: yes21:44
dstufftwell the problem with that is just that it's easier to forget to include a statement saying it was breaking or whatever21:44
mordredI'm fine with that21:44
dstufftbut if you'e OK with that, then ok21:44
mordreddstufft: I think it's worth trying without it21:44
lifelessdstufft: if you train folk to just say 'bugfix' they will do ONLY THAT.21:44
lifelessdstufft: and you're screwed.21:44
dstufftperhaps git-review or whatever could add a Bugfix thing automatically if one doesn't exist21:44
dstufftthen your reviewers will see it21:45
dstufftand seeing something wrong is easier to realize it's wrong then seeing something that's missing21:45
mordredI agree with the intent - I think it'll break with our folks21:45
lifelessdstufft: I don't think thats the case.21:45
mordredthere's already too much blind operation - I think it'll just be extra word noise21:45
lifelessdstufft: operationally, we don't specify 'Impact: x,y,z' we say 'DocImpact; IFF there is docimpact21:45
mordredbut I do like the opportunity to do positive assertions and have that be helpful21:46
lifelessand that works because folk that care about it can look for it.21:46
mordredalso, now that we can edit commit messages in gerrit ... reviewers coudl totally add a "Breaking" tag21:46
lifelessI know why I used setup.cfg.21:46
lifelessBecause its there when we've shipped an sdist21:47
dstufftshouldn't an sdist already have a version baked into it21:47
lifelessno, thats bogus.21:47
mordredlifeless: it might have gotten you there though21:47
lifelessdstufft: they do, but my head was saying no-rc impacted.21:47
dstufftwaht is version_info style21:48
mordreddstufft: that's an object thing  we've had aroudn openstack projects for since before pbr21:49
mordredok. seriously. I just failed at going to the store21:50
mordredI'll be back in a sec21:50
lifelessmordred: dstufft: huh no - its the python version tuple thing itself.21:50
dstufftwhy is there a fourth digit in the version again21:50
dstufft(Sorry I'm failing to remember some of these things)21:51
lifelessdstufft: because 1.2.3a4 is very much not semver comaptible.21:51
*** sarob_ has joined #openstack-infra21:51
dstufftsemver compatible in which way, syntax or semantics21:51
dstufftmakes sense then21:52
dstufftI generally don't care about syntax compatability w/ semver when I'm working on PEP440 stuff, but that makes sense21:52
lifelessits not strictly compatible but its more compatible.21:55
*** sarob_ has quit IRC21:56
dstuffteh, maybe slightly so. But easy to convert in either case21:58
*** yfried_ has quit IRC22:01
*** yfried_ has joined #openstack-infra22:01
*** fbo is now known as fbo_away22:02
*** zns has quit IRC22:03
Sukhdevfungi, clarkb: removal of setuptools and reinstalling version 3.8 did not help. my present version is setuptools 3.8 - I still get the same failures22:05
dstufftlifeless: mordred clarkb  other than the git log thing I think the semver thing looks pretty OK, the PEP 440 compat isn't actually compat with PEP 440 at the moment though. but making it be compat is just syntax changes so not sure if that needs to be nailed down exactly in a spec or not22:09
lifelessdstufft: tell me whats wrong22:13
lifelessclarkb: mordred: dhellmann: dstufft: new version pushed up with git log rules.22:14
dstufftlifeless: x.y.z.dev4.gHASH isn't compatible, you can't have a .something after a .devN version, you probably want x.y.z.dev4~gHASH but PEP 440 isn't actually finalized yet so that *might* change, but I don't think it will, it's pretty close to be finalized I think22:15
*** dims has joined #openstack-infra22:17
*** mriedem has quit IRC22:18
*** sweston has quit IRC22:19
persiax.y.z.$(git describe)22:20
*** sweston has joined #openstack-infra22:20
lifelessdstufft: ~ has special meaning in debian version #'s22:21
*** dims has quit IRC22:21
lifelessdstufft: please tell me PEP 440 doesn't use it differently ?22:22
dstufftit uses it to differentiate between the prublic version and the "local" version22:22
*** sweston has quit IRC22:22
lifelesswhats the precedence rule there ?22:22
*** zns has joined #openstack-infra22:23
lifelessdstufft: in debian, '~' sorts *before* ''22:24
lifelessdstufft: so 1.2.3 is > 1.2.3~22:24
lifelessdstufft: I don't see ~ in other than in the ~= stuff22:26
lifelessdstufft: <public version identifier>[-N[.N]+]22:27
lifelessdstufft: is the defn for local22:27
lifelessso - seems to be the desired separator22:28
dstufftlifeless: 1.2.3 < 1.2.3~whatever I think, but they are considered API equivialant, it's used for denoting local patches, like maybe debian patches pip 1.5.4, so it could have pip 1.5.4~debian1 which is API equiv with 1.5.4 but has modifications.22:28
dstufftlifeless: that version isn't up to date22:28
dstufftwe're working on another draft of it22:28
lifelessdstufft: ok so please please please do not use ~ for this22:28
dstufftwe switched from - to ~ because there are projects on PyPI already using -22:28
lifelessin debaian 1.2.3~ is entirely opposite to what you just wrote22:29
dstufftand setuptools already uses - to denote a pre-release22:29
dstufftthere aren't a lot of choices for what we can use as a seperator22:29
lifelessif debian has a 1.5.4~debian1, its a pre-release of 1.5.422:29
lifelesstwin towers, airplane, up arrow. Something.22:29
dstufftis the discussion around moving from - to ~22:30
greghaynesI propose tableflip emoticon22:30
dstufftlifeless: I don't think it's going to be a big deal, ~ shouldn't be used anywhere that a debian version is going to get to it really, and if it is then it can be mechanically transformed for debian's sake22:32
lifelessdstufft: commented there.22:33
*** otherwiseguy has joined #openstack-infra22:34
dstuffte.g. you're not going to be allowed to upload a ~ version to PyPI or anything, you can't use it as an "official" version anywhere on the official tooling22:34
lifelessdstufft: this makes me nervous and uncomfortable. I may be overreacting of course.22:34
*** Sukhdev has quit IRC22:35
lifelessstill, time for swimming with Cynthia, so - will talk more later22:38
lifelessmordred: ^ for your entertainment22:38
*** Sukhdev has joined #openstack-infra22:38
*** sarob_ has joined #openstack-infra22:45
*** sarob__ has joined #openstack-infra22:47
*** sarob___ has joined #openstack-infra22:49
*** sarob_ has quit IRC22:50
*** sarob_ has joined #openstack-infra22:51
*** sarob__ has quit IRC22:51
mordreddstufft: it makes me similarly uncomfortable22:53
mordreddstufft: not because of tooling22:53
*** sarob___ has quit IRC22:53
mordredbut because ANYONE with a debian or ubuntu background is going to see that with their eyes and make very incorrect assumptions about meaning22:54
*** sarob_ has quit IRC22:55
dstufftmordred: suggest a better character ;) I think - is bad because it'll change the meaning, in a fairly significant way, about ~2% of the current versions on PyPI22:56
mordredwhat about + ?22:56
dstufftusing ~ means we get 99.9% compatability with pkg_resources for how versions are sorted22:57
mordredbut you confuse all of the debian and ubuntu users22:57
dstufftmoment on +22:57
dstufftneed to see if folks are using that22:57
openstackgerritDavid Caro proposed a change to openstack-infra/jenkins-job-builder: Added parallelization options
dstufft30 versions in my local copy of PyPI using + in their version22:59
dstufft*sees what for*22:59
mordreddstufft: what ever happened to putting this stuff into md 2.0?22:59
dstufftmordred: metadata 2.0?23:00
mordredI liked the idea of being able to put git sha there and  not in the version itself23:00
dstufftmordred: so techincally local version isn't exactly for git sha, though it could be. It's mostly for someone to denote an API compatible patch, so like if pip releases 1.5.6, but openstack takes that and patches it for themselves (maybe y'all want to fix a bug or something), they need to version that somehow, your choices are A) Keep the same version and be confused because "1.5.6" means different things in different contexts or B)23:02
dstufft do something like or something and hope pip never releases a which is bad because well pip could release a
dstufftso you'd do something like 1.5.6~openstack123:02
dstufftwhich says it's API compatabile with 1.5.6, but it has some patches applied to it23:03
mordredyeah. this is wandering directly into the world of the distros except without the distros23:03
mordredbecause that's exactly the problem space they have to deal with constantly :)23:03
Sukhdevfungi: ping23:03
mordredthis is the reason the debian release 1.5.6-1 and ubuntu release 1.5.6-0ubuntu123:03
dstufftright now debian has 1.5.6-1 for pip, but their *python* metadata has 1.5.623:04
mordredbecause 1 is a local debian patch version23:04
mordredthey're asserting that they're shipping you 1.5.623:04
dstufftwe want them to put that -1 in the python metadata23:04
mordredthey will not do that23:04
dstufftthey are shitheads then23:04
mordredit would be incorrect23:04
mordredthey don't WANT to modify the code at all23:05
dstufftbecause it's fucking annoying as fuck to debug a problem with their patches when pip --version is lying23:05
dstufftthey don't want to, but they do23:05
mordredwell, so there I agree - sorry - I think we're talking about different things potentially23:05
mordredthey're going to have -1 whether they ahve patches or not to the python code23:05
dstufftif they don't modify the code, then they don't need to change the python version23:05
dstufftthe idea is that if you modify the code, then what you have is no longer 1.5.623:05
dstufftit's 1.5.6 with some patches23:05
mordredright. or you have redhat shipping the linux 2.4 kernel with half of 2.6 backported in23:06
dstufftand the "local versions" primary purpose it to encode that this is 1.5.6 with some patches and specifically what version of the patches23:06
mordredok, so, if that's what it is, you're not goign to get that by getting them to put it in the tarball version23:06
mordredyou might could get them to patch pkg-info I suppose23:07
dstufftthe Python version string is used in many places, the tarball name is one of them23:07
dstufftPKG-INFO is another23:07
mordredso where does it live canonically?23:07
dstufftin the generally for a sdist23:07
mordredlike, what would I need to do as a packager to set the local version suffix stuff?23:08
mordredso you'd be asking them now to patch setup.py23:08
mordredin order to communicate that they'd patched something23:08
mordredmaintaining a serial number there is going to be hard if they're using dvcs to maintain packaging23:08
mordredyou and I both have copies of the packaging23:10
mordredyou add an overlay patch to the python and also patch to add a -1. I do the same thing23:10
mordredyou push your commit23:10
mordredI try to push, get told I need to update23:10
mordredso I do, and in the process of merging, git quite happily notes that we both made the same change and doesn't show me a conflict23:11
mordredor  ... you added 2 patches and I added 3 before we sync, in which case I get to merge conflict the serial number23:11
dstufftdoesn't sound like a problem to me, unless I somehow released a new copy of the package between when you updated and when you pushed23:12
mordredit's not a PROBLEM - but it's a bit of a pita. if we ever start doign packaging out of the openstack systems, it'll fall apart completely23:13
dstufftafaik debian doesn't update their local -N for each patch they apply, but for each release they make23:13
mordredthat's correct23:13
mordredbut I was talking about the... oh, you're thinking23:14
SukhdevFolks, something have changed recently which is making python-swiftclient fail during - please see the logs
dstufftso they just have a single patch that they overlay which adjusts the, and they bump that version whenever they bump the debian/control version23:14
mordredyou're thining that that the debian -1 would be the thign taht would go in, not a tracked-with-each-patch patch count23:14
SukhdevI tried changing the seuptools to 3.8, that does not help either23:14
mordredSukhdev: those arent' really errors23:15
mordredSukhdev: those are things that should be suppressed and there is an upstream bug filed to do so23:15
dstufftyea I don't care if they have 1 patch or a billion patches, it just needs to be some indicator that they've patched it, and ideally also some way to figure out what patches they've applied, but even that isn't strictly required23:15
mordredSukhdev: do you have errors further down?23:15
mordreddstufft: ok. well, honestly, we've surpassed where I should be taking their side, because I think that how they manage this is wrong anyway23:16
dstufftwe don't add any semantics to the local version other than it denotes an API compatible release23:16
dstufftso they can do whatever the want, even if it's just "add ~ubuntu to the end"23:16
mordredfor me, I would personally prefer it if you did not use ~ because ~ will confuse me23:16
Sukhdevmordred: yes…let me capture those23:17
dstufftso it becomes 1.0~ubuntu and leav eout the versioning info all together, because at least that tells me if someone does pip --version, and I get back a 1.0~ubuntu, that I can tell them to go tell me what dpkg says is installed23:17
dstufftmordred: I think + will work OK23:17
mordredlifeless: ^^ any issues you can see with + ?23:17
dstufftit's slightly more versions than use ~, but slightly is like... 1023:18
*** dims has joined #openstack-infra23:18
dstufftout of 234k23:18
Sukhdevmordred: please see
dstufftand some of those versions look like they are using it for this anyways23:19
persia'+' is an RFC2396 reserved character, so needs URI escaping, if that matters.23:19
dstufftoh right, that's why I didn't look at + before23:19
mordredthese are not supposed to be uploaded to pypi - is RRC2396 really important?23:19
persiaBut I think '+' is widely used for that purpose anyway: urlescape isn't especially hard.23:19
mordredpersia: ++23:19
dstufftthat's not a killer for this application or anything23:19
dstufftwe already use : in version numbers in places where it _can_ be uploaded to PyPI23:20
dstufftit's just a nice to have23:20
persiaSemantically, to me, '+' clearly indicates "with additional stuff identified by:", but that might just be me.23:21
dstufftit's not unreasable23:21
mordreddstufft: while we're bothering you ... seems to show something actually dying due to that pip bug you filed earlier23:21
mordreddstufft: which is potentially unhappymaking23:21
dstufftdiffernt error message23:22
dstufftth epip bug was a about a syntaxerror23:22
dstufftthis is a missing file23:22
mordredoh. so you're right23:23
*** dims has quit IRC23:23
dstufftthere's a 3.8.1, not sure what it fixed23:23
dstufftguess just that one bug which isn't this23:24
Sukhdevmordred: did you look at the paste?23:24
mordredSukhdev: yes. that's what we're talking about23:24
dstufftI'm not sure what's causing that error23:27
mordredme either23:28
dstufftalso i'm going to go play wolfenstein: The New Order, my step daughter got it for me for father's day23:28
*** andreykurilin_ has quit IRC23:29
mordreddstufft: nice!23:29
Sukhdevdstufft, mordred: I tried to follow the fix in this, but, that does not seem to help23:31
uvirtbotLaunchpad bug 1326972 in openstack-ci "swiftclient fails to install under tox with Python3" [High,Fix released]23:31
Sukhdevdstufft, mordred: BTW, this problem has manifested only 2 hours ago and is failing all (most) Third party CI's23:33
Sukhdevdstufft mordred: I see all tests pass until 12:28:54 PST, and every single test fails starting 1:18:01 PST - every single failure is because of this23:35
dstufftthat doesn't make any sense23:35
dstufft3.8 has been out for like 2 weeks23:35
Sukhdevdstufft: Perhaps something got checked into the master branch only few hours ago which is causing this issue23:36
dstufftwhich master branch23:37
Sukhdevdstufft: neutron/master - all the failing tests are on that  branch23:37
mordredI HATE PYTHON23:37
mordredTypeError: can't concat bytes to str23:38
mordredthis ^^^ is the result of people being complete and utter crackheads. AAAAAAAAHHHHHHHHHHHHHH23:38
dstufftwell don't do that23:38
dstufftconcating bytes and str is a bad thing to do23:38
mordredso, I call it like this:23:38
mordredheader = easy_install.get_script_header("", executable, is_wininst)23:38
mordredthat first arg winds up being script_text23:38
mordredthen the error happens here:23:39
mordred    first = (script_text+'\n').splitlines()[0]23:39
mordredso. uhm. which is the bytes and which is the string?23:39
*** otherwiseguy has quit IRC23:40
SukhdevBTW, I see the failure with setuptools 5.0.1 as well as 3.8. Would you recommend me trying out some other version?23:40
dstufftscript_text is the bytes23:40
dstufftbecause "\n" is a str23:40
mordreddstufft: but why is script_text bytes? I'm passing it ""23:41
dstufftoh I see what you're saying23:41
dstufftI misunderstood23:41
dstufftare you sure that's the line that's doing it, and that nothing else has modified script_text23:42
mordreddstufft: I mean, I'm about to dive deep in - but looking in to the source code, this is the most immediate path I'm seeing23:42
mordredthe line above starting with first = is the first line in the function23:42
*** otherwiseguy has joined #openstack-infra23:43
mordredand I'm calling it directly and not through other indirection23:43
mordredbut - that doesnt' mean anything :)23:43
dstufftare you sure you're passing it "" and not b"", like did you manually type in "" or is it coming from somewhere else23:43
mordreddstufft:     header = easy_install.get_script_header("", executable, is_wininst)23:44
mordreddstufft: it's hardcoded in the calling context23:44
dstufftalso you've worked on pbr long enough to know you should never expect something reasonable from packaging tools23:44
mordredoh yeah23:44
mordredno, I mean23:44
*** ryanpetrello has quit IRC23:44
mordredthere's nothing surprising here23:44
dstufftI'm not sure what's causing that error though ;/23:44
dstufftis this pbr23:44
mordredit's an error I just got from Alex_Gaynor on python-swiftclient23:45
mordreddstufft: it may or may not, actually, be pbr related23:45
dstufftare you generating your own script wrappers?23:45
dstufftwell there's your problem, don' listen to that Alex_Gaynor guy23:46
dstuffthe finds too many errors23:46
mordredI know. he's pretty crazy23:46
dstufftmordred: you might wanna use distlib to generate your script wrappers, it's kinda lame but its also kind of less shitty than setuptools script wrappers23:46
dstufftalso why are you generating your own script wrappers23:46
mordredbecause ... we don't actually want to... example is easier23:48
mordredthat's what our scripts look like23:48
clarkbiirc pkg_resources took seconds to spin up23:48
dstufftso install from wheels23:48
dstufftusing pip23:48
dstufftyour script wrappers will look functionally equivilant to that23:49
mordredwe don't fully have that power23:49
dstufft is what that would look like pip via wheel23:50
dstufftand I plan on making it d that pip via setuptools in the future too23:50
dstufftI just need to figure out how to hack that in23:50
mordreddstufft: well - I've got the code that does it - you're welcome to it :)23:50
mordreddstufft: it's a surprisingly easy thing to do23:50
dstufftyea I doubt it'll take long, I jsut have to actually do it23:51
mordreddstufft: as soon as pip does that for non-setuptools installs, I can remove that from pbr23:51
mordredI just can't count on wheel-based installs just yet23:51
*** sarob_ has joined #openstack-infra23:51
clarkbmordred: I don't know that you can ever23:51
dstufftNot sure why, if you publish a wheel pip will default too it unless the person says "don't install from wheels"23:51
clarkbmordred: we use enough of that lxml crap23:52
mordreddstufft: many many many people do not install from pypi but instead from git23:52
mordreddstufft: and I have to support them23:52
mordredquite honestly, our tarballs and release artifacts are probably the least important thing we have23:52
mordredfor better or for worse23:52
mordreddstufft: alright. I have confirmed the Alex_Gaynor bug exists and isn't just him23:53
mordredof course, it's making me think it's a bug in tox, because I could have SWORN when I wrote that patch for them that I used pip -e and not develop23:53
clarkbmordred: you have to specify pip -e as the install command23:54
clarkbmordred: its not hard coded iirc23:54
mordredclarkb: install_command = pip install -U {opts} {packages}23:54
mordredclarkb: that's "how do you install deps"23:54
mordredclarkb: usedevelop = True triggers something different23:54
openstackgerritA change was merged to openstack-infra/elastic-recheck: Broaden 1326312 to match py26/py27 failures
mordreddstufft: I mean, I _think_ I'm about to report a python 3.4 setuptools bug ...23:55
*** sarob_ has quit IRC23:56
dstufftI hate installing directly from git :|23:58
dstufftit screws everything up23:59
dstufftit should be from git -> generates a one off artifact -> installs artifact23:59
dstufftbut instead we have install23:59

Generated by 2.14.0 by Marius Gedminas - find it at!