Wednesday, 2013-08-14

clarkbjeblair: looks like removing gate-tempest-devstack-vm-full.FAILURE makes it render00:01
clarkbjeblair: does that imply there are no failures over the last 24 hours? seems odd it wouldn't render that as a flat line on the bottom of the graph00:01
fungiyeah, https://review.openstack.org/41698 merged at about 18:30 utc, so about 5.5 hours ago?00:01
clarkbhmm it has had failures00:03
*** danger_fo is now known as danger_fo_away00:03
clarkbI must be doing something wrong00:03
jeblairclarkb: no, i think there's something wrong with that metric00:04
clarkbregular job is 65:9 pass:fail over the last 24 hours in the gate. testr job is 12:200:05
clarkb14% vs 16%00:05
clarkbbut the samples are small00:06
*** fifieldt has joined #openstack-infra00:06
jeblairclarkb: the whisper file was 0 bytes.  i removed it, and it has been replaced, but there's no data for that metric00:06
clarkbjeblair: ok, thanks00:06
jeblairthere are 17 other gate job files that are 0 bytes, i will remove them00:06
clarkbthe initial trned according to logstash is good, but getting graphite to report the numbers is better00:08
jeblairclarkb: erm, how hard would it be for the zmq plugin to include the node name on all its reports?00:09
*** sarob_ has joined #openstack-infra00:10
jeblairi just ran: git clone git://git.openstack.org/openstack-infra/zmq-event-publisher00:10
jeblair:)00:10
jeblairclarkb: i'll try to hack on that00:12
clarkbjeblair: shouldn't be too hard if that data is provided to the listener somehow00:12
clarkbjeblair: if the Run carries that info or refers to it then you can add it00:13
clarkband you just need to update the gson model and set the value00:13
*** sarob has quit IRC00:14
*** sarob_ has quit IRC00:14
*** pcrews has quit IRC00:16
clarkbjeblair: you can get the executor of the Run if it is being built00:19
jeblairyeah, i'm hoping that will be enough00:20
jeblairtrying now00:20
*** sandywalsh has quit IRC00:21
morganfainbergclarkb: ping00:23
clarkbmorganfainberg: hi00:23
morganfainbergclarkb: i figured i'd come in here and ask you, since you might know00:23
morganfainbergclarkb: iirc run_tests is deprecated across all projects (or should be), am i remembering wrong?  i.e. tox is the way forward00:24
morganfainbergclarkb: and if you don't know, thats fine, just curious if i remeber it right00:24
clarkbmorganfainberg: run_tests is something we would like to deprecate but haven't gotten to that point00:25
clarkbthere are a couple things that tox doesn't do well that causes some problems00:25
morganfainbergclarkb: ok, see, that's what i wanted to hear.  there is a review in keystone's queue that is advocating changes to run_tests so you can do run_tests <module>.<class> for example00:26
morganfainbergclarkb: i was hesitant to say a hard no if run_tests was … still in reality used.00:26
morganfainbergclarkb: i still prefer tox personally :P00:26
clarkball of the other run_tests and tox should already support that feature00:27
clarkbtox -epy27 foo.bar00:27
clarkbor run_tests.sh foo.bar00:27
morganfainbergah, ok. yeah it's due to a lack of __init__ in keystone's test dir i think00:28
morganfainbergi know tox does the right thing00:28
jeblairclarkb: cool, we get it for all 3 phases00:28
clarkbjeblair: awesome00:29
jeblairclarkb: James E. Blair proposed a change to openstack-infra/zmq-event-publisher: Include the node name  https://review.openstack.org/4181400:29
clarkblgtm00:31
openstackgerritElizabeth Krumbach Joseph proposed a change to openstack-infra/config: Add high max-repo-count for index page in cgit  https://review.openstack.org/4181500:33
pleia2there, commit from train00:33
mgagne*cough* trailing whitespaces *cough*00:34
* mgagne has an OCD00:34
pleia2heh00:35
openstackgerritElizabeth Krumbach Joseph proposed a change to openstack-infra/config: Add high max-repo-count for index page in cgit  https://review.openstack.org/4181500:37
*** sandywalsh has joined #openstack-infra00:37
pleia2there, no more OCD triggering00:37
mgagne:O00:37
pleia2there are lots of options for cgit (all documented in the man page), worth a browse00:37
mgagnepleia2: I'm curious about cgit as gitweb has its limitations00:38
* mgagne observes how it's being installed/configured by infra00:38
pleia2mgagne: feedback on git.openstack.org/cgit welcome :)00:38
mgagnepleia2: it needs an openstack skin :D00:39
pleia2yes!00:39
pleia2must find some art-inclined person00:39
*** ryanpetrello has quit IRC00:41
mgagnepleia2: I guess updating logo would be a good start00:41
pleia2yeah, we don't have a static files directory on that server for apache at the moment, so I should make one and drop things like logo and favicon in there00:42
pleia2both are cgit config file options, so that helps00:42
mgagnepleia2: OpenStack logo and background look to fit without problem00:44
pleia2great00:45
*** ryanpetrello has joined #openstack-infra00:50
*** dina_belova has joined #openstack-infra00:51
openstackgerritlifeless proposed a change to openstack-dev/pbr: Stop checking periods in commit messages  https://review.openstack.org/4083800:51
openstackgerritlifeless proposed a change to openstack-dev/pbr: Fix python-ldap mirroring.  https://review.openstack.org/4073200:51
*** woodspa has joined #openstack-infra00:52
*** dina_belova has quit IRC00:57
*** enikanorov-w has quit IRC00:57
*** blamar has joined #openstack-infra01:01
*** enikanorov-w_ has joined #openstack-infra01:03
*** cody-somerville has quit IRC01:03
*** colinmcnamara1 has joined #openstack-infra01:03
*** cody-somerville has joined #openstack-infra01:04
colinmcnamara1Jeremy, are you there. Have a new contributor that has a borked username issue getting this error in git-review - http://pastebin.com/TYXuuWC401:04
colinmcnamara1remote: Permission to openstack/openstack-manuals.git denied to sarahnovotny.01:05
colinmcnamara1fatal: unable to access 'http://github.com/openstack/openstack-manuals.git/': The requested URL returned error: 40301:05
*** zul has joined #openstack-infra01:06
*** senk has joined #openstack-infra01:08
clarkboh cool sarah novotny is going to contribute?01:08
colinmcnamara1absolutely01:08
senk:)01:08
clarkbcolinmcnamara1: the problem there is you cannot push to github01:08
mordredneat01:08
colinmcnamara1sitting right next to me in a bar in vail01:08
colinmcnamara1:)01:08
colinmcnamara1awesome01:09
* senk waves01:09
colinmcnamara1walking her through her first commit01:09
mordredhey senk !01:09
clarkbis `git review` spitting that out?01:09
mordredsenk: happy to have you aboard!01:09
colinmcnamara1and when she is submitting to git review is getting a 403 error01:09
colinmcnamara1yes01:09
jeblairthat's slightly confusing because it has 'github.com' in the url01:10
clarkbya https://github.com/openstack/openstack-manuals/blob/master/.gitreview should force it to talk to review.openstack.org01:10
colinmcnamara1her lauchpad and githib id's weren't the same01:10
colinmcnamara1there is a entry in the mailing lists where jeremy had to tweek something in gerrit for an earlier user with a username change01:10
mordredpleia2: \o/01:10
clarkbunless you have a gerrit remote in the repo that points to github01:10
anteayaif she is changing her username in gerrit, yes the db must be changed manually01:10
clarkbcolinmcnamara1: I don't think this is related to the username though01:10
colinmcnamara1ok01:10
colinmcnamara1you are the expert, not em01:11
jeblairsenk, colinmcnamara1: can you run 'git remote -v' and paste the output?01:11
colinmcnamara1it is openstack-manauls01:11
colinmcnamara1err openstack-manuals01:11
colinmcnamara1having sarah run it01:11
senkpixie:openstack-training sarah.novotny$ git remote -v01:11
senkgerritssh://sarahnovotny@review.openstack.org:29418/openstack/openstack-manuals.git (fetch)01:11
senkgerritssh://sarahnovotny@review.openstack.org:29418/openstack/openstack-manuals.git (push)01:11
senkoriginhttp://github.com/openstack/openstack-manuals.git (fetch)01:11
senkoriginhttp://github.com/openstack/openstack-manuals.git (push)01:11
senkpixie:openstack-training sarah.novotny$01:11
senkew.  sorry.  i'll pastebin01:11
jeblairthat looks right... :/01:11
senkhttp://pastebin.com/A7D7ueem01:12
clarkbcan you also paste what `git review -v` outputs?01:12
jeblairsenk: can you pastebin 'git review -v' ?01:12
senkhttp://pastebin.com/2BbFqT7s01:13
jeblairneat, why would git-review chose origin?01:14
senkthat's me.01:14
clarkbsenk: what version of git review? `git review --version`01:14
senkkill it?01:14
clarkbya I think that last pastebin captures the relavent info01:15
colinmcnamara1so, she did put a weird setting in .gitreview that specifies origin. that may be it01:15
senkgit-review version 1.2201:15
jeblaircolinmcnamara1: in ~/.gitreview ?01:15
clarkbya, new versions have also allowed you to set things in a global config too (to support wikimedia) but they may have been too helpful01:15
clarkb1.22 is new enough to have that goodness01:16
pleia2for reference, which may clear up some of the confusion, we don't actually use github directly, for us it's simply a discoverable mirror01:16
jeblairsenk: can you pastebin ~/.gitreview ?01:16
senkit was the origin.01:16
colinmcnamara1WOOOT!!!01:16
jeblairsenk: cool :)01:16
colinmcnamara1as always, you guys are awesome01:16
senk<301:16
pleia2welcome to the project senk :)01:17
senkmedianici lies about using the "defaultremote = origin" that if you don't know what you're doing.01:17
senks/medianici/mediawiki/01:17
jeblairhttps://review.openstack.org/#/c/41820/01:17
clarkbsenk: ya their workflow is slightly more special than ours01:17
clarkbsenk: and they end up doing weirder stuff01:17
jeblairwhich is impressive, i mean, i thought we were pretty special.01:17
clarkbwell they don't mirror to github or other places so they expect the origin to me gerrit01:18
senk\o/01:18
pleia2https://wiki.openstack.org/wiki/Gerrit_Workflow is what we point folks at01:18
senkaaah.01:19
senki'll read the gerrit workflow.01:20
anteayaBobBall_Away: if you are still awake, the new patch also works - yay!01:20
senksqueeze!  @colinmcnamara1 just approved my first commit!  thanks for all your help, all.01:22
colinmcnamara1WOOOTT!!!!!01:22
pleia2\o/01:22
senki hate autocorrect.  that was squee.01:22
mordredsenk: I kinda read it as "squee" anyway01:23
*** colinmcnamara1 has quit IRC01:23
anteayacongratulations senk01:23
mordredmorganfainberg: (reaching WAY back in to scrllback) - keystone's test suite needs work to get it into alignment with project goodness01:25
fungisquee ideed!01:25
fungisorry i'd stepped away for a bit01:26
mordredmorganfainberg: most specifically, it needs to a) stop fetching client libs from the internets b) start using testr and c) move tests into keystone01:26
mordredmorganfainberg: unti lit does that, it's going to be a special snowflake01:26
lifelessspethial01:26
mordredand not able to take advantage of global work in the areas of testing01:26
*** senk has quit IRC01:27
morganfainbergmordred: that much i figured.01:27
mordredmorganfainberg: :) just trying to catch up on scrollback. I think I'm going to lose01:28
openstackgerritMonty Taylor proposed a change to openstack-infra/reviewstats: Add nodepool to infra projects  https://review.openstack.org/4182301:28
morganfainbergmordred: hehe no worries01:28
fungilifeless: if you get a bit, your input on my comment at https://review.openstack.org/#/c/41731/2/modules/openstack_project/files/gerrit/acls/stackforge/diskimage-builder.config would be most welcome01:30
lifelesswhat is milestone-proposed ?01:32
fungilifeless: that more or less answers my question then ;)01:32
fungilifeless: it's the pre-release freeze branch the openstack server projects use01:32
fungilifeless: just wanted to confirm it was in that acl by mistake01:32
*** jerryz has joined #openstack-infra01:33
lifelessright, this is more like a client01:33
lifelesswill release when it needs to01:33
fungigreat. approving then01:33
jeblairclarkb: do you want to approve 41814 and release?  exercise the publish machinery, and tomorrow i can try upgrading from the update center?01:34
clarkbjeblair: sure.01:34
openstackgerritA change was merged to openstack-infra/reviewstats: Add nodepool to infra projects  https://review.openstack.org/4182301:35
*** emagana has quit IRC01:35
*** ^d has joined #openstack-infra01:36
*** ^d has joined #openstack-infra01:36
openstackgerritA change was merged to openstack-infra/config: Set tag uploading permissions for TripleO  https://review.openstack.org/4173101:36
*** gyee has quit IRC01:37
morganfainbergmordred: i think we have a patchset pending that moves the tests (at the very least).01:38
openstackgerritMonty Taylor proposed a change to openstack-infra/config: Use cgit server instead of github for everything  https://review.openstack.org/3817701:40
openstackgerritMonty Taylor proposed a change to openstack-infra/config: Rename github-org to repo-group  https://review.openstack.org/3817801:40
clarkbjeblair: do you know if https://review.openstack.org/#/c/40455/ has been tested since it merged?01:40
mordredmorganfainberg: there is. termie -2'd it and then disappeared again01:40
clarkbjeblair: pushing a new version of zmq-event-publisher will exercise that01:40
clarkbmordred: thats not very nice01:40
clarkbzaro: ^01:40
mordredmorganfainberg: I've been thinking about proposing a new version of that patch01:40
jeblairclarkb: i think this is the first one01:41
mordredmorganfainberg: maybe you'll get lucky and I'llwrite hte patches to migrate _everything_ on my plane flight on thursday night :)01:41
clarkbjeblair: I am semi inclined to not do the first release with the new script at almost 7pm01:41
morganfainbergmordred: hehe ok01:41
*** changbl has joined #openstack-infra01:42
mordredmorganfainberg: oh - sasha already did that01:43
morganfainbergmordred: yeah i was looking at that one specifically01:43
morganfainbergthat sascha provided.01:43
clarkbjeblair: if you are going to around to help sort through any potential issues I am ahppy to do it though01:43
mordredmorganfainberg: reviewed01:44
morganfainbergnod.01:44
jeblairclarkb: oh, ok, er not really, but i'm not anticipating anything beyond "it worked" or "it did not work".01:44
clarkbbut if it did not work it will need correcting :)01:44
jeblairclarkb: if it does not work, we are no worse off than now.01:44
jeblairclarkb: sure, but that can wait, right?01:44
clarkbthats true, I will go ahead and give it a shot01:44
clarkbjeblair: tag pushed01:50
*** dina_belova has joined #openstack-infra01:51
jeblairhttps://jenkins.openstack.org/job/zmq-event-publisher-jenkinsci-upload/2/console01:52
clarkbhttp://repo.jenkins-ci.org/list/releases/org/jenkins-ci/plugins/zmq-event-publisher/0.0.2/ seems to have worked01:55
clarkbwe'll know when the updates site updates01:55
*** dina_belova has quit IRC01:56
SpamapSdid I see the tripleo-ptl thing land in my email jenkins updates, or was that just a merged (but something has to be HUP'd?)02:05
SpamapS ! [remote rejected] 0.1.0 -> 0.1.0 (can not create new references)02:06
SpamapSfor os-apply-config02:06
mordredSpamapS: it takes a potential double cron cycle02:06
mordredlemme see if the grou pis there02:06
SpamapSGrou's?02:07
* SpamapS hides02:07
mordredSpamapS: try again02:07
clarkbthe group is there but os-apply-config does not have it in its acl02:08
mordredoh. piddle02:08
SpamapScron: keeping the coffee machine brewing since 198302:08
clarkbprobably needs to be run by hand (this is the race condition in puppet that I am talking about)02:09
* mordred goes to re-run manage_projects (man, I REALLY want to figure out what the heck is up with the race condition)02:09
clarkbI don't think all of the files are updated befure the subscription can run02:09
mordredah.02:09
* mordred running02:09
clarkbsome other project added the ptl group, runs manage_projects then os-apply-configs acl file is updated02:09
jgriffithanybody want to educate me on sitepackages=True/False in tox.ini02:09
jgriffithie https://review.openstack.org/#/c/39501/102:09
jgriffithMy first thought was "sure, sounds good"02:10
clarkbjgriffith: sure02:10
clarkbsitepackages are evil02:10
jgriffithbut I'm wondering if there's a caveat I'm missing02:10
*** yaguang has joined #openstack-infra02:10
jgriffithclarkb: well, then that was easy :)02:10
jgriffithclarkb: My thought was if you're using venv, use venv02:10
clarkbthey are evil because if you have package foo at version X.Y installed globally but you depend on foo version X.Y+1 tox and pip will not install the proper version in the virtualenv02:10
jgriffithbut I'm not the most familiar with that workflow so I wanted to make sure there wasn't something I need to be considering here02:10
jgriffithclarkb: got ya... which I tend to run in to a bit lately :(02:11
clarkbthere is a work around for that where you can add -U to the deps on line 11 and 1202:11
jgriffithoooo... goody!02:11
clarkbwhich will force pip to update the existing packages as necessary02:11
jgriffithclarkb: nice02:11
clarkbbut typically we just disable site packages if they aren't necessary for something like libvirty02:12
clarkbkeeps things simple02:12
jgriffithclarkb: ok, so I'm not missing something that I should be thinking of with respect to this change02:12
* mordred looing02:12
mordredhey jgriffith02:12
jgriffithmordred: hola02:12
* jgriffith ducks02:12
clarkbjgriffith: I don't think so. The exception to the rule is when you have a python dep that cannot be satisfied by pip02:12
clarkblibvirt being the big one02:12
jgriffithhmmm... psql-dev perhaps?02:12
mordredjgriffith: ah! I believe you inherited that line from nova02:12
jgriffith:)02:13
mordredjgriffith: the default is off, so technically you could just delete that line02:13
mordredjgriffith: commit 930f5891b0815e1b49b9b2cc840e0c24b2796e8402:13
mordredis where it came into your tree02:13
jgriffithmordred: ohhh interesting02:13
*** woodspa has quit IRC02:13
mordredI FULLY support removing it from your tree02:13
*** nati_ueno has quit IRC02:13
mordrednova is the only project we expect it to be on in, and that's because we cannot do the other thing02:14
jgriffithI noticed that in the tox docs02:14
jgriffithgot ya02:14
jgriffithexcellent'e02:15
jgriffiththanks guys!02:15
mordredjgriffith: thank you for coming in and asking! :)02:15
jgriffith:)02:15
jgriffithmordred: nothing worse than *thinking* I know the answer and finding out my assumptions are wrong ;)02:15
mordredjgriffith: now you're describing every moment of my life02:17
jgriffithmordred: hehe... truly, that holds for all of us.  Just some admit it, others pretend02:17
jgriffith:)02:17
*** mriedem has quit IRC02:17
*** ryanpetrello has quit IRC02:19
openstackgerritbenley proposed a change to openstack-infra/jenkins-job-builder: Add support for parameter filters in copyartifact  https://review.openstack.org/4158202:23
openstackgerritbenley proposed a change to openstack-infra/jenkins-job-builder: Add support for parameter filters in copyartifact  https://review.openstack.org/4158202:24
openstackgerritbenley proposed a change to openstack-infra/jenkins-job-builder: Add support for parameter filters in copyartifact  https://review.openstack.org/4158202:24
*** cody-somerville has quit IRC02:29
*** dguitarbite has joined #openstack-infra02:31
SpamapSmordred: push worked this time02:32
openstackgerritbenley proposed a change to openstack-infra/jenkins-job-builder: Add display-name job property.  https://review.openstack.org/4182802:33
openstackgerritbenley proposed a change to openstack-infra/jenkins-job-builder: Add display-name job property.  https://review.openstack.org/4182802:34
*** anteaya has quit IRC02:40
*** cody-somerville has joined #openstack-infra02:41
*** ^d has quit IRC02:44
*** rcleere has joined #openstack-infra02:46
*** dina_belova has joined #openstack-infra02:52
mordredSpamapS: woot02:56
*** dina_belova has quit IRC02:57
mordredjog0: ping02:58
clarkbwe should store our longs in https://github.com/philipl/pifs02:59
clarkbs/longs/logs/03:00
mordredomg03:00
SpamapSmordred: so now we wait for something magical to happen and the tag to appear on pypi?03:03
mordredSpamapS: it sohuld have showed up a long time ago if it was gonna03:04
SpamapShttps://pypi.python.org/pypi/os-apply-config03:04
SpamapS0.0.1 still03:04
mordredSpamapS: hahahahahahaha03:05
SpamapSyou did the old name03:05
SpamapS?03:05
mordredSpamapS: you sure don't have pypi jobs03:05
*** jfriedly has quit IRC03:06
jog0mordred:  pong03:06
openstackgerritMonty Taylor proposed a change to openstack-infra/config: Actually let os-*-config release to PyPI  https://review.openstack.org/4183203:08
mordredSpamapS, clarkb ^^03:08
mordredjog0: re: the new pep8 thing...03:08
mordredjog0: a) do you think then that it should wind up as a thing that tox -epep8 just runs every time?03:08
mordredjog0: b) there is no b)03:08
jog0mordred: you see my second comment03:09
mordredjog0: yup03:09
jog0actually the logic could be  if 'git status' shows nothing, run git diff HEAD^, else do git diff03:10
mordredjog0: that's what I'm saying - how do we not break that workflow, but still get the ability for me to check to see if I'm doing something evil in the future?03:10
mordredjog0: good call03:10
mordredjog0: maybe it wants to be a script that gets called from tools/* and gets added to oslo-incubator?03:10
jog0mordred: I don't think there is away to not break the workflow03:10
*** yaguang has quit IRC03:10
mordredjog0: we could make hacking/flake8 MUCH smarter...03:11
mordredand be able to configure it to a) do this and b) what the expanded list is03:11
jog0in part because if: a) the extra rigid checks are the default config, I run flake8 via the VIM plugin on the file I am working on and everything looks good so  I push but then the new code only checks catch me03:11
jog0err I got that backwards, if extra rigid is default then I fix things outside of my patch03:12
mordredoh yeah. hrm03:12
jog0I do like the autofix a big bug in several 500 line patches and just ram it through03:13
jog0and then fix for everything03:13
jog0although we can tweak that to be per directory03:13
jog0that may be a better middleground03:13
*** ryanpetrello has joined #openstack-infra03:16
*** ryanpetrello has quit IRC03:17
jog0also this is a nova only problem I think03:18
jog0due to size03:18
jog0mordred: ^03:18
mordredjog0: yeah. agree03:21
mordredjog0: that's sort of why I was thinking that the summit might be a nice time03:21
mordredBUT03:21
mordredeven then there will be like 200 outstanding patches that are going to get rebase screwed03:21
jog0mordred: do it right when Icehouse opens03:22
lifelesswhat are you brewing up?03:22
jog0those few weeks between the release and summit when everyone is drunk and not coding03:22
mordredjog0: :)03:23
jog0mordred: there is also the path taken with pylint03:23
*** jerryz has quit IRC03:23
jog0which is make sure the number of errors doesn't go up03:23
*** yaguang has joined #openstack-infra03:24
jog0err warnings*03:24
jog0that should leave the workflow mostly the same if not totally03:24
fungii think i want a test which does an sdist, then blows away everything except .git and .gitignore, then untars the sdist tarball in and confirms that git shows no changes. not sure if that warrants a separate job or can be combined into an existing one03:29
fungiseems a bit destructive for hacking or any flake8 plugin03:30
*** vipul is now known as vipul-away03:30
*** vipul-away is now known as vipul03:30
*** vipul is now known as vipul-away03:33
*** vipul-away is now known as vipul03:33
mordredfungi: well ...03:33
mordredfungi: that was a job that ttx wanted a long time ago - we did the other thing and did the setuptools-git route03:34
mordredfungi: although I believe you are wanting to prove different things03:34
fungiwanting to prove that we don't break our ability to consistently validate tarballs later03:35
fungiparticularly guarding against mistakes in changes to the way tarballs get created03:37
fungiso that we can then have confidence that when a post-merge job expects to be able to do that to validate a release tarball is not tampered with or corrupted, we avoid false positives03:40
locke105anyone used vagrant at all before? been playing with it for testing deployments with chef and stuff... wondering if anyone knows of an OpenStack provider plugin for it...03:43
*** SergeyLukjanov has joined #openstack-infra03:43
mordredwarning - discussion about pip requirements incoming03:45
mordredlocke105: vagrant has never worked for me at all03:45
lifelessdum-dum-dum-ddddduuuuummmmmm03:45
mordredlocke105: but I hate ruby, and it hates me, and I have free openstack cloud accounts03:45
locke105lol03:45
mordredlocke105: so ignore me03:45
locke105personally i'm more a python fan03:45
lifelessso context03:45
locke105but ruby is alright besides the silly syntax03:45
lifelessmordred put up a patch that just tweaks minor versions on the pip requirements for os-collect-config03:46
locke105"just tweaks"03:46
locke105:)03:46
lifelessI whinged about it, not because I want to work with different versions [at least it's not an issue today], but because I don't want daily 'here is the latest tweak because $otherproject is incompat with that thing'03:46
mordredhttps://review.openstack.org/#/q/status:open+branch:master+topic:openstack/requirements,n,z03:46
lifelessSo I want to understand why we're doing it the way we are03:46
lifelessand mordred quite reasonably said 'well, how else?'03:47
lifelessIt seems to me that if we have a centralised list of what works03:47
SpamapSbecause we don't have a way to tell pip install -r "union with URL x"03:47
lifelesswe should decouple 'things needed' and 'versions needed'03:47
mordredbut when do you recouple them03:48
mordred?03:48
SpamapSwhat if we put in requirements.txt  "openstack-requirements>=2013.2"03:48
lifelessNow, if pip doesn't have support for that built-in - and we can look at that separately - we could always just compile a fixed central list in the global requirements repo, so there is one and only one place it's stored.03:48
mordredSpamapS: that breaks for other reasons03:48
mordredlifeless: I would like to go back to the problem you are trying to solve03:49
lifelessthe reason I care about this is that slow changing projects - like oac/occ/orc will quickly become mostly requirements.txt changes.03:49
lifelessand by quickly I mean in a month or two.03:49
mordredso don't merge it03:49
mordredmerge like, once every 2 months or so03:49
lifelessThat will cause problems won't it ?03:49
mordredwhy?03:49
lifelessI mean the reason you're doing this is to avoid breaking devstack, isn't it?03:50
mordredright. so, devstack is goingto force upgrade you anyway03:50
locke105what about an auto posted change like the transifex stuff03:50
mordredyou don't get a choice about that03:50
mordredlocke105: that's what we're doing/talking about03:50
lifelessmordred: upgrades are fine; *we're* very compatible. It's the *tighter* constraints your review adds that set of alarm bells for me.03:50
mordredlifeless: devstack's setup_develop function now runs update.py from trunk requirements.txt03:50
SpamapSmordred: ergo the point... "don't crap deps on X if you're going to get them from the actual place that needs them anyway in the deploy scenario you are testing"03:51
mordredSpamapS: sorry, can't parse that sentence03:51
lifelessmordred: if we merge any patch that sets an upper bound on $thing, pip will start whinging when trunk accepts a newer version if the newer version is already installed, and the havoc we're trying to fix will occur03:51
clarkbmordred: he is saying stop proposing changes if devstack will do it anyways03:51
clarkbthe problem here is we are a lot more than devstack03:51
mordredright. unittests, etc03:52
SpamapSmordred: "regarding 'right. so, devstack is going to force upgrade you anyway'"03:52
SpamapSgah too many quotes03:52
clarkbspecifically this is a major problem for people like tripleo trying to package this up distro like03:52
mordredwe WANT everything to be COMPLETELY ALIGNED by release03:52
clarkbSpamapS: I think you are working around that by venv'ing everythin03:52
lifelessmordred: so I don't want to land overly tight requirements in the first place, because they are the cause of e.g. occ causing issues.03:52
clarkbubuntu and fedora and rhel and suse and so on don't have that as an option03:52
SpamapSpoor buggers03:52
SpamapS;)03:52
lifelessclarkb: we do, because we may well end up with cross-release situations.03:52
lifelessclarkb: e.g. havan * + trunk nova-baremetal03:53
mordredlifeless: to a degree, strict alignment with openstack/reuqiremnets is just one of the prices you pay for being a part of openstack03:53
*** dina_belova has joined #openstack-infra03:53
mordredsome projects don't strictly need it03:53
mordredbut we're not really designed for 22 snowflakes03:53
mordredopenstack is One Project03:53
lifelessmordred: sure, but this isn't about being part of openstack - I'm talking about the technical approach in solving the devstack pain for CI03:53
SpamapSmordred: can you unblock my head by explaining why we can't just depend on a single openstack-requirements pypi package?03:53
mordredthis isn't about solving the devstack pain per se03:53
mordredthat's solved03:53
lifelessmordred: and framing this as a snowflake question is also missing the point03:53
mordrednow it's about solving requirements drift03:53
mordredwe want projects to stop having divergent requirements files03:54
clarkbSpamapS: because openstack requirements is a super set that you almost never want (my issue with that approach, not sure if that is what mordred will say)03:54
lifelessso the reason divergence exists is because we have redundant information in them.03:54
lifelessI'm proposing that we tackle that directly.03:54
mordredok. let's come back to that then03:55
mordredbecuase I don't see how it's different in result03:55
mordredif you are going to make an artifact that one can pip instal03:55
mordredthat artifact needs to list the versions that are in openstack/requirements, no?03:55
mordredand if you are going to ahve a git repo and you want tox -epy27 to work, you'll need the versions03:56
lifelesslets start by setting the use cases03:56
mordredso either they're self-contained, or somethign is going to have to make additional hits out to o/r03:56
lifelessthere is install from git03:56
lifelessthere is install from pypi03:56
lifelessand there is setup a developer test-running-environment03:56
lifelessare there more ?03:56
mordrednope, I think those are the main ones03:57
lifelessnow, install from pypi is easy: we can materialise the current set of constraints at sdist time.03:57
mordredagreed03:57
*** dina_belova has quit IRC03:58
SpamapSclarkb: hrm. Not sure that is actually a big deal to me.. the overlap is probably "a few modules here and there", but "mmk"03:58
SpamapSerr03:58
mordredSpamapS: think about if you are python-swiftclient03:58
lifelessSpamapS: uhm, it's huge.03:58
SpamapSnot overlap, but the "inverse of overlap"03:58
mordredSpamapS: and o/r makes you install django03:58
lifelessSpamapS: postgresql client libs on every install, for instance...03:58
SpamapSOh are we putting those things in reqs too?03:58
SpamapSI had thought deploy reqs where there are multiple choices are not in there.03:58
mordredno - but you need them to install the postgres python lib03:58
lifelessSpamapS: the python lib yes, which transitively ...03:58
SpamapSIndeed, if they're all in there, then it is not what I thought it was. :)03:59
lifelessSpamapS: they should be in extras, but the *version pins* for them are in o/r.03:59
SpamapSOk so pip needs a --union-with X feature. :)03:59
mordredextras is bs, btw03:59
mordredalthough I'm willing to be swayed on that _later_03:59
lifelessSpamapS: so the issue is that -r installs everything in the list.04:00
lifelessSpamapS: the way pip upstream seem to think it works is that you have one -r for each app you're installing.04:00
locke105so.. we have something similar already with oslo-incubator04:00
lifelessSpamapS: the result of that here is that there is a requirements.txt *in the repos* for each app04:01
SpamapSright04:01
locke105each project has an openstack-common.conf which says which modules in oslo it uses04:01
lifelessSpamapS: which is not the pip upstream story, because they are focused on web devs deploying their own thing04:01
locke105so we could do the same with requirements04:01
mordredlocke105: already done04:01
mordredlocke105: we're debating whether it's a good idea to do so04:01
locke105oh04:01
lifelessmordred: so, is there a requirement that the per-project requirements bumps be async ?04:01
clarkblifeless: I think that is an important point04:01
mordredlocke105: we're about to get way down in the weeds - it'll be fun04:02
clarkblifeless: the existing tools are built around deploy your super specific app in secret04:02
mordredlifeless: there is a request from the projects about that so far04:02
lifelessmordred: or do we test that a new global requirements change works with all current repos already ?04:02
locke105so thats what was meant by "superset"04:02
mordredlifeless: we do test that04:02
locke105makes sense now04:02
mordredlifeless: requirements changes now also gate on devstack04:02
clarkbthe use case of install this thing with a ton of optional requirements with a set of valid versions for each requirement across many distros is not something they try to solve04:02
lifelessmordred: so, I think the simplest thing with no need to evolve pip or whatever is to put the per-project requirements files in the global repo.04:03
mordredwe do _not_ test that requirements changes break or not break all the unittests - although I believe we're getting closer to changing how that works04:03
clarkbits all geared around deploy one app to one place in a non open friendly manner04:03
mordredlifeless: how is that simpler?04:03
mordredlifeless: can we go back to the use cases?04:03
jgriffithmordred: BTW, I did some more digging and the issues I was having earlier were in fact due to vagrant caching of things04:03
lifelessmordred: it means you /can't/ have skew between versions.04:03
mordredlifeless: I believe we're jumping again04:03
jgriffithmordred: just FYI if somebody mentions it again04:03
lifelessmordred: almost certainly04:03
mordredjgriffith: awesome! locke105 was just asking about using vagrant04:03
lifelessmordred: use cases; pypi - tick. local dev and isntall from git.04:04
mordredalthough if you guys talk about that, can I request that it not be in here just right now04:04
jgriffithlocke105: if you want to hear about my experience and new method gimmie a shout04:04
lifelessmordred: so 'pip install git+https://github.com/openstack/nova' should work04:04
lifelessmordred: which will pull the repo, and do setup.py stuff right?04:05
mordredyes04:05
lifelessmordred: could that sanely look for a subdirectory and if missing clone the global requirements repo to it ?04:05
lifelessmordred: I'm considering implementation obviously04:05
mordrednow you're desribing the submodule approach, essentially - but, it might be able to do that04:06
lifelessso git submodules might be an answer, but that can be a bucket of worms, so I deliberately stayed away04:06
mordredright. I'm just saing - the idea is the same04:07
lifelessyes04:07
lifelesstox -epy27 could operate basically the same way04:07
mordredright. but then we're in a world of complexity that's hard to reason about04:07
mordredwhat happens if I do git clone nova nova-blah locally on my laptop04:08
mordredand then want to run setup.py in that dir04:08
mordredand I'm not on the internet04:08
lifelessmordred: well, today it blows up.04:08
lifelessmordred: because you're not on the internet.04:08
mordredI keep a local pypi mirror on my laopt04:08
mordredlaptop04:08
lifelessso this scenario is one where git submodules look nicer still04:09
mordredwhich is configured in my ~/.pip/pip.conf04:09
mordredbut we're still winding up with the specific versions in the project repo - we're just making the dev run the syncing code a bunch at times the dev may not know he's doing it04:10
mordredrather than storing the result of the sync in the repo04:10
mordredright?04:10
lifelesswhat you wrote appears to have a contradiction04:10
lifelessspecific versions in the project repo <=> rather than storing the result of the sync in the repo04:11
mordredsorry - specific versions in the local working tree04:11
mordredor on the local dev env04:11
lifelessyes, at any point in time there are specific versions selected04:11
lifelesswhich is AIUI one of your goals04:12
lifelessto avoid spurious failures due to random incompat or shit hanging around.04:12
mordredright.04:12
mordredhave you interacted with the transifex patches?04:12
lifelessa little04:12
lifelessnone of tripleo is translated yet04:12
mordredconstant stream of update patches, projects land them whenever04:12
lifelessbut transifex is different, because they are project specific04:12
mordredit's still patch churn04:13
lifelessas in, if the project stops changing, they will stabilise as translators catch up04:13
mordredand the content is largely opaque to the reviewer04:13
lifelessalso if the project doesn't merge them it has no impact on installability or CI04:13
mordredright. if the project does not merge a requirements change, nothing breaks04:13
mordredthe only time you'll be forced to merge your outstanding reuqirements change04:14
lifelessI have a scenario I think will break.04:14
lifelessI'd be happy to know I'm wrong.04:14
*** vogxn has joined #openstack-infra04:14
mordredyou may get pressure to do something if someone tries to land a change to requirements and it's not compatible with your project04:14
mordredbut, by definition, your project will always be compatible with its own local set and the global set04:15
mordredbecause it's not possible land a breaking change to the global set - if you're in the d-g and your code actually gets tested there )04:15
lifelessThe scenario is - say we land the patch you put forward that caps testscenarios at <0.504:15
mordred:)04:15
lifeless[btw, why do that - I do backwards compat!]04:15
clarkbyes I questioned capping testscenarios and other lifeless libs04:16
mordredwe've been bitten too many times - propose a change removing the caps04:16
lifelessThen, to have our project successfully install you have to have testscenarios < 0.5.04:16
mordredk04:16
lifelessWhen I then release 0.504:16
lifelessand the global project wants to raise the cap.04:16
lifelessThe per-project cap will make my project not installable.04:17
mordredwhy?04:17
lifelessbecause it still says < 0.504:17
mordredwhere will it not be installable?04:17
lifelesswell, it would have to downgrade testscenarios in the test environment04:17
mordredlocally, it will be installable, because you will have not touched your cap, nor will you have touched your code, and g-r will not be in context04:18
mordredwhat test environment?04:18
lifelessdevstack-gate04:18
mordredah. see, that's just the thing04:18
mordredwe update your requirements in devstack04:18
mordredbefore we install you04:18
mordredyou are not asked about it04:18
mordredthis is already landed04:18
lifelessok04:18
lifelessso, if we said 'we merge these proposals before we cut a pypi release', would -infra be happy?04:19
mordredbecause that's where the major pain is04:19
mordredsure!04:19
lifeless[and if there is a minimum version that we actually need]04:19
mordredhonestly - I'm not sure we _need_ auto proposals anymore04:19
mordredI think that devstack autoupdate04:19
mordredcombined with gating reuqirements on that04:19
mordredcombined with making sure that when you change reuqirements you only change to things in the gate04:19
mordredis probably fine moving forward04:20
mordredthat said - I'd like to get people up to the current baseline as of when we started gating requirements04:20
mordredand then let's let it run for a while and see if anything breaks without doing autosync proposals, yeah?04:20
lifelessdamn04:21
lifelessI just -2'd04:21
mordredhah04:21
mordredlifeless: _you_ are fine in this case04:21
lifelessmordred: ok back to -1, I'd like the testscenarios thing changed04:22
lifelessI realise the global set is different, I'll dig up the repo and propose a change to it there04:22
mordredcool. please do04:22
mordredand I'll happily update the patch04:22
lifelessfor now, Ineed to pickup Cynthia04:22
mordredthe main reason I want to sync everyone now04:22
lifelessthanks for the chat04:22
mordredis to get rid of referneces to d2to1, btw04:23
mordredlifeless: thank you! it was a good one04:23
mordredlifeless: I think you have strengthend the side of me leaning towards holding off on auto proposals for a while04:23
clarkbI don't see what is wrong with auto proposals04:24
clarkbthere will only ever be one per project at any given time04:24
clarkbjust ignore it04:24
mordredclarkb: I don't think they're wrong - but I do think I want to see how the recent changes we make affect things04:25
mordredclarkb: and whether or not we still feel like they are a thing that will be helpful04:25
mordredclarkb: btw - not related- https://review.openstack.org/#/c/41832/04:25
lifelessclarkb: the thing about dashboards of 'I need to review X' is that having a thing there always is really annoying04:26
clarkblifeless: you can ignore it with a -2 I think04:26
lifelessclarkb: I'd rather say 'make it reliable and automerge' or 'don't do it'; but thats a different discussion.04:26
clarkbbecause that will put it in the reviewed column until you remove the -204:27
lifelessclarkb: it will get refreshed on every o/r change.04:27
clarkblifeless: but -2's are always reapplied04:27
morganfainbergmordred: any insight on what causes: https://review.openstack.org/#/c/36184/ the gerrit claiming a path conflict?  I've been unable to duplicate the issue in cherry-picks, merges, etc locally  but i might be missing something obvious.04:27
lifelessand then it's not there when you need it04:27
mordredmorganfainberg: lemme try04:27
morganfainbergmordred: thanks :)04:27
morganfainbergmordred: sometimes my git-fu is lacking.04:27
clarkbmorganfainberg: jgit04:28
morganfainbergclarkb: oh. right.04:28
morganfainbergclarkb: jgit is special.04:28
clarkblifeless: I don't think we will have a perfect thing that makes everyone happy... some people want auto merge, others are firmly against it04:28
clarkbso we tend to be a little conservative and deal with it, but I really don't think the transifex or requirements changes are that intrusive04:29
clarkbI mean my queue of things is like 60 long a couple extra changes that I can ignore doesn't bother me04:29
clarkbmorganfainberg: yup, it often fails where normal git is fine04:30
mordredmorganfainberg: I rebased locally and repushed - for the reasons clarkb says04:30
morganfainbergmordred: thank you :)04:30
mordredclarkb: we have assininely long review lists, you and I04:31
mordredmorganfainberg: and I've re-+2'd it - so you sohuld be good to go if you want to aprv04:31
morganfainbergmordred: i typically wait till jenkins doesn't explode if it's going to run the normal tests04:32
morganfainbergjust paranoid04:32
mordredyup04:32
clarkbmordred: we appreciate the paranoia. It keeps zuul happy04:32
morganfainbergso i'll app once thats done tonight :)04:32
clarkber morganfainberg ^04:32
morganfainbergclarkb: i am running a zuul/gerrit internally for my company's code04:32
morganfainbergi totally get it :)04:32
mordredclarkb: any reason to not land the devstack don't relable patch?04:33
clarkbmordred: I have been letting jeblair coordinate those04:33
morganfainbergreminds me, i need to upgrade our zuul… it's ancient04:33
clarkbmordred: I think he ahs the whole thing planned out in his head04:33
mordredclarkb: good call. I'll just +204:33
mordredclarkb: by the whole thing, do you mean the universe?04:34
clarkbmorganfainberg: keep in mind tip of master zuul does gearman with jenkins now04:34
clarkbmordred: yes, I am pretty sure when it rains up here jeblair is at fault04:34
mordredclarkb: ++04:34
morganfainbergclarkb: thats why i need to upgrade :)04:34
mordredclarkb: btw - the queue for o/config is stupid04:35
clarkbqueue?04:35
clarkbreview queue?04:35
mordredyeah04:36
clarkbI was new change submission freeze04:36
clarkbno new changes until everything else is either merged or abandoned :)04:37
mordredyeah - but - but04:37
mordredponies!04:37
mordredclarkb: you know - I'm thinking with custom dashboards I might be able to cook up what I really need right now04:38
mordredwhich is "show me things which I haven't reviewed, but which also don't have a -1 on them anywhere04:38
*** melwitt has quit IRC04:39
lifelessclarkb: /all/ proposals in tripleo projects are fully reviewed, every day.04:43
lifelessclarkb: you having 60 open is a defect in something :)04:43
clarkblifeless: the number of changes submitted is far too large04:44
clarkband the number of reviewers is too small04:44
clarkblifeless: also having mordred submit code really makes it hard to keep up04:45
clarkbwill submit like 15 patches a day04:45
mordredclarkb: dammit04:49
mordredclarkb: there does not seem to be a searchable boolean for Util.M.changesReviewedBy04:49
mordredthere is one for changesReviewedBy04:50
mordredso, as best I can tell04:50
mordredthere is no way for me to search for haveReviewed04:50
clarkbya it is one of the weird things that the important changes had to work around04:51
clarkband requires a patch which upstream does not want04:51
* mordred is reading your patch04:51
mordredthey don't want me to be able to filter out shit I've dealt with?04:51
mordredbecause this:04:52
mordredhttps://review.openstack.org/#/q/watchedby:mordred%2540inaugust.com+-label:CodeReview%253C%253D-1+-label:Verified%253C%253D-1++-status:workinprogress,n,z04:52
clarkbapparently not, but I think gerrit 2.6 exposes all this through the REST API04:52
mordredis really close to being a todo list04:52
clarkbso, in addition to custom dashboards writing some js to show you what you want shouldn't be too bad04:52
*** luisg has quit IRC04:52
clarkbbut that is all theory at this point04:52
*** luisg has joined #openstack-infra04:52
mordredgod04:52
mordredall I need is one more single boolean search criteria04:52
mordredand I wouldnt' even need custom dashboards04:53
clarkbmordred: the problem is in the DB schema04:53
clarkbthere is no good way to check if you ahve reviewed a thing04:53
mordredwell, that's because their db schema is bonghits04:53
*** dguitarbite has quit IRC04:53
*** dina_belova has joined #openstack-infra04:53
clarkbI can't remember all the reasons now but it had to do with a vote of 0 being different than a non zero vote04:53
clarkbso important changes approximates and only looks at non zero votes04:53
mordredoh my. I just thought of an evil thing I could do04:54
mordredI could use that view04:54
mordredbut put in -is:starred04:54
mordredand then I could star something to mean I'm done with it04:54
clarkbmordred: I have been doing the inverse lately04:54
clarkbI do a quick skim of the list to find things that need attention, start them all, then go through the starred list removing stars as I review04:55
mordredyeah - alternately I could use the above view to show me things I havne't seen at all04:55
mordredI could star those04:55
mordredthen go through star list and unstar04:55
mordredyeah04:55
mordredI might try that04:55
*** emagana has joined #openstack-infra04:57
*** dina_belova has quit IRC04:58
*** cody-somerville has quit IRC04:58
mordredok. I have constructed a "I need to deal with these reviews" link04:58
mordredand I'm going to try the star thing04:58
*** vipul is now known as vipul-away05:02
*** vipul-away is now known as vipul05:02
*** rcleere has quit IRC05:10
*** vogxn has quit IRC05:20
*** blamar has quit IRC05:23
*** vogxn has joined #openstack-infra05:26
*** emagana has quit IRC05:34
openstackgerritSergey Kolekonov proposed a change to openstack-infra/jenkins-job-builder: Existing plugins improvements  https://review.openstack.org/4137505:45
*** nicedice_ has quit IRC05:46
*** SergeyLukjanov has quit IRC05:55
*** SergeyLukjanov has joined #openstack-infra05:56
*** SergeyLukjanov has quit IRC06:02
*** dguitarbite has joined #openstack-infra06:06
*** yaguang has quit IRC06:13
*** yaguang has joined #openstack-infra06:19
*** markmcclain has quit IRC06:27
*** odyssey4me has joined #openstack-infra06:28
Alex_GaynorThere seem to be a few builds stuck in the queued state again.06:29
*** yaguang has quit IRC06:32
*** ruhe has joined #openstack-infra06:33
*** dguitarbite has quit IRC06:36
*** odyssey4me has quit IRC06:45
*** afazekas has joined #openstack-infra06:50
*** yaguang has joined #openstack-infra06:52
*** dina_belova has joined #openstack-infra06:54
*** ruhe has quit IRC06:57
*** yaguang has quit IRC06:58
*** dina_belova has quit IRC06:58
*** dina_belova has joined #openstack-infra06:58
*** dina_belova has quit IRC07:03
*** afazekas_ has joined #openstack-infra07:08
*** nayward has joined #openstack-infra07:09
*** jhesketh has quit IRC07:12
*** afazekas_ has quit IRC07:13
*** yaguang has joined #openstack-infra07:17
*** Ryan_Lane has joined #openstack-infra07:37
*** vogxn has quit IRC07:47
*** jpich has joined #openstack-infra07:48
*** fbo_away is now known as fbo07:52
*** odyssey4me has joined #openstack-infra07:59
*** dina_belova has joined #openstack-infra07:59
*** dina_belova has quit IRC08:03
*** SergeyLukjanov has joined #openstack-infra08:04
*** vogxn has joined #openstack-infra08:04
*** odyssey4me has quit IRC08:06
*** odyssey4me has joined #openstack-infra08:07
*** dina_belova has joined #openstack-infra08:09
*** dina_belova has quit IRC08:14
*** locke105 has quit IRC08:26
*** fbo is now known as fbo_away08:26
*** derekh has joined #openstack-infra08:28
*** ruhe has joined #openstack-infra08:29
*** SergeyLukjanov has quit IRC08:44
*** fbo_away is now known as fbo08:46
*** SergeyLukjanov has joined #openstack-infra08:49
*** BobBall_Away is now known as BobBall08:51
*** psedlak has quit IRC08:56
*** morganfainberg is now known as morganfainberg_a09:10
*** mrmartin has joined #openstack-infra09:12
*** odyssey4me has quit IRC09:13
*** vogxn has quit IRC09:22
*** vogxn has joined #openstack-infra09:25
*** Ryan_Lane has quit IRC09:30
*** psedlak has joined #openstack-infra09:39
openstackgerritMark McLoughlin proposed a change to openstack/requirements: Allow use of oslo.messaging 1.2.0a4  https://review.openstack.org/4169609:46
*** dstufft has quit IRC09:46
*** dstufft has joined #openstack-infra09:47
*** huangtianhua has joined #openstack-infra09:54
koolhead17mordred, https://review.openstack.org/#/c/41874/ <<--- needs immediate attention :)09:56
*** w_ has joined #openstack-infra09:58
*** enikanorov has quit IRC10:00
*** olaph has quit IRC10:00
*** dina_belova has joined #openstack-infra10:10
*** dina_belova has quit IRC10:15
*** pcm__ has joined #openstack-infra10:36
*** odyssey4me has joined #openstack-infra10:41
*** pcm__ has quit IRC10:44
openstackgerritPetr Blaho proposed a change to openstack-infra/config: Adds Jenkins jobs for python-tuskarclient  https://review.openstack.org/4188710:44
*** pcm__ has joined #openstack-infra10:44
*** vogxn has quit IRC10:44
*** koobs has quit IRC10:53
*** dina_belova has joined #openstack-infra10:55
*** yaguang has quit IRC10:57
*** enikanorov has joined #openstack-infra10:57
*** vogxn has joined #openstack-infra10:57
*** koobs has joined #openstack-infra11:00
*** koobs has quit IRC11:02
*** koobs has joined #openstack-infra11:02
*** yolanda has joined #openstack-infra11:20
yolandahi fungi, jeblair11:20
yolandai moved my deployment to use geard instead of gearman11:20
yolandabut then i'm finding a problem, gate-noop job doesn't seem to be working11:20
yolandaand a telnet to geard with "status" shows no jobs, should i need to configure something by default?11:21
*** fifieldt has quit IRC11:22
*** weshay has joined #openstack-infra11:22
*** sgviking has quit IRC11:30
*** sgviking has joined #openstack-infra11:31
*** boris-42 has joined #openstack-infra11:31
*** woodspa has joined #openstack-infra11:31
*** vogxn has quit IRC11:39
*** rfolco has joined #openstack-infra11:42
*** ArxCruz has joined #openstack-infra11:45
*** derekh has quit IRC11:50
*** psedlak_ has joined #openstack-infra11:54
*** markmc has joined #openstack-infra11:56
*** psedlak has quit IRC11:58
*** afazekas has quit IRC11:58
*** paul-- has joined #openstack-infra12:03
*** mikal has quit IRC12:06
*** afazekas has joined #openstack-infra12:07
*** mikal has joined #openstack-infra12:07
*** dprince has joined #openstack-infra12:08
*** HenryG has quit IRC12:11
*** Ryan_Lane has joined #openstack-infra12:11
*** prad_ has quit IRC12:12
*** adalbas has joined #openstack-infra12:15
*** afazekas is now known as afazekas_mtg12:15
*** w_ is now known as olaph12:17
*** HenryG has joined #openstack-infra12:23
*** SergeyLukjanov has quit IRC12:33
*** nayward has quit IRC12:38
*** nayward has joined #openstack-infra12:38
*** senk has joined #openstack-infra12:38
*** afazekas_mtg has quit IRC12:44
*** senk has quit IRC12:46
*** dina_belova has quit IRC12:51
*** weshay has quit IRC12:52
*** sandywalsh has quit IRC12:52
yolandaseing that messages in zuul log: Unable to find change queue for project12:54
yolandais that a normal issue?12:54
*** dina_belova has joined #openstack-infra12:54
mordredyolanda: did you change your config on jenkins to point at geard too?12:55
yolandamordred, yes12:55
mordredyou might also need to restart jenkins to cause it to run the registration code (I'm not sure, I'm just guessing)12:56
*** dkliban has joined #openstack-infra12:59
*** SergeyLukjanov has joined #openstack-infra12:59
*** nayward has quit IRC13:00
yolandamordred, about the gate-noop that is solved, i hadn't added the gate-noop project in jenkins, now it works13:01
yolandaproblem i have now is that gate pipeline isn't triggered, not sure why13:01
*** psedlak__ has joined #openstack-infra13:01
mordredah - for that we'll have to wait for jeblair13:01
yolandai have something like that:13:01
yolanda    trigger:13:01
yolanda      gerrit:13:01
yolanda        - event: comment-added13:01
yolanda          approval:13:01
yolanda            - approved: 113:01
yolandabut although i approve some change, that isn't queued into to gate queue13:02
mordredyolanda: and you have a manager: field for that pipeline?13:03
yolandamanager: DependentPipelineManager13:04
mordredhrm. yeah. sorry - I'm no use - jeblair or fungi will be more help13:04
yolandathx anyway :)13:05
*** weshay has joined #openstack-infra13:05
*** nayward has joined #openstack-infra13:05
*** weshay has quit IRC13:05
*** psedlak_ has quit IRC13:05
*** sandywalsh has joined #openstack-infra13:06
*** weshay has joined #openstack-infra13:06
*** dkehn has quit IRC13:10
*** dkehn has joined #openstack-infra13:10
*** afazekas has joined #openstack-infra13:11
*** derekh has joined #openstack-infra13:13
*** blamar has joined #openstack-infra13:19
fungilet's see if i'm of any use13:21
fungigimme a sec to catch up on scrollback... i was coaching christine on prepping for a job interview she has coming up with one of red hat's marketing teams dealing with their openstack stuff13:23
* fungi crosses fingers13:23
*** changbl has quit IRC13:25
*** pentameter has joined #openstack-infra13:25
*** mriedem has joined #openstack-infra13:25
*** rnirmal has joined #openstack-infra13:29
*** ryanpetrello has joined #openstack-infra13:31
*** dina_belova has quit IRC13:32
fungiyolanda: the "unable to find change queue for project" message is potentially a benign warning. we see it when trying to match events against the silent pipeline, if memory serves13:32
yolandafungi, main problem i had is that gate pipeline isn't working, so i was looking for all the potential problems13:33
fungiyolanda: if status shows no jobs, that may mean your jenkins isn't reporting the jobs it knows it can run into the geard?13:33
fungii'm still a little fuzzy on the gear interface13:33
yolandaif i remove the approval:13:33
yolanda            - approved: 1 conditional from trigger it works, just when i send some comment, and pushes job to jenkins13:33
fungiahh, i see you got past that. still reading through what you've written13:34
yolandabut for some reason it doesn't like that filter, isn't that correct?13:34
mordredyolanda: have you added the approval column to your gerrit?13:34
fungii think gerrit won't give a radio selection widget for approve in the interface if you don't?13:35
*** burt has joined #openstack-infra13:35
yolandamordred, what i do is that i send a +2 to code review13:35
mordredyup. so that will be a different event13:35
mordredinstead of approval13:35
yolandamordred, do you have some doc for that events?13:35
* fungi dredges up a link to the database update queries to add the column13:35
mordredyou'll want, um, I think code-review13:36
mordredfungi: I don't think they need the approval column per-se13:36
*** nayward has quit IRC13:36
fungioh13:36
mordredyolanda: try changing to13:36
mordred- event: comment-added13:36
mordred  codereview:13:37
mordred    - codereview: 213:37
fungiahh, i see they want to treat cdrv +2 as approval13:37
yolandalet me try13:37
mordredyah. that's the 'normal' gerrit approach13:37
* fungi gets tunnel vision dealing with our hacked-up gerriting all the time13:38
*** nayward has joined #openstack-infra13:38
mordredfungi: well, I'm watching stream-events right now13:39
yolandamm, layout.yaml error13:39
mordredfungi: if you wanted to approve https://review.openstack.org/#/c/41832/13:40
mordredfungi:  I could watch what the vote looks lke13:40
mordredok.13:41
mordredit seems lke it wants to be13:41
mordred  approvals:13:41
fungimordred: revewed and approved 4183213:41
fungier, reviewed13:41
mordred    - code review: 213:41
mordredbut I don't think a space there is avlid in yaml is it?13:42
mordredoh. it is13:42
mordredneat13:42
yolandafungi, ok, fixed13:43
yolanda      gerrit:13:43
yolanda        - event: comment-added13:43
yolanda          approval:13:43
yolanda            - code-review: 213:43
openstackgerritA change was merged to openstack-infra/config: Actually let os-*-config release to PyPI  https://review.openstack.org/4183213:43
yolandathat's the right syntax13:43
*** mestery_ has joined #openstack-infra13:43
fungitoo cool. this could use some examplishness in the zuul docs, methinks13:43
fungialso, SpamapS, you should be able to tag releases and get them uploading automatically now, finally :/13:44
*** mestery has quit IRC13:46
mordredfungi: at this point, there is no way for us to manually trigger just the pypi upoad job is there?13:47
fungimordred: in fact there is13:47
fungimordred: jeblair wrote an awesome quick-n-dirty script13:47
mordredneat! because the tag is already pushed and the tarball already uploaded13:47
yolandafungi, do you have some sample of the gate-noop jenkins task? i just created a dummy shell project, but it complains with Reported result: ERROR, although the job is executed correctly13:48
fungibasically uses the gear library to connect to the gearman server and request the job be run with the right set of params13:48
*** prad_ has joined #openstack-infra13:48
fungiyolanda: sure, just a sec13:48
yolandathx13:48
fungiyolanda: https://git.openstack.org/cgit/openstack-infra/config/tree/modules/openstack_project/files/jenkins_job_builder/config/misc.yaml#n113:49
fungioh, wait, wrong file13:49
yolandawe are not using jenkins_job_builder at the moment, just creating some jobs manually on jenkins for testing13:50
fungihuh, actually i don't see any more specific scripting in the yaml for it. i'll pastebin the xml13:51
fungiyolanda: http://paste.openstack.org/show/44118/13:53
*** cppcabrera has joined #openstack-infra13:54
*** huangtianhua has quit IRC13:54
openstackgerritMonty Taylor proposed a change to openstack-infra/config: Add job to propose tag merges  https://review.openstack.org/4192713:54
fungii guess that's what we get from jjb when all we specify is a job name and a node label13:54
mordredttx, fungi ^^ turns out it's really easy13:54
openstackgerritMonty Taylor proposed a change to openstack-infra/config: Add job to propose tag merges  https://review.openstack.org/4192713:55
mordredoops. forgot to add the bug tag13:55
fungiaha! so that fixes the versioning i guess... you tried this approach with the swift merge back to master?13:55
*** cppcabrera has left #openstack-infra13:56
*** mestery_ is now known as mestery13:57
yolandafungi, i was just trying to execute some shell job13:57
yolandathat's a bit different13:58
mordredfungi: I did - although I mostly did it by hand13:58
fungittx: on the topic of capping folsom dependencies, i just realized another hole in the idea... the last time it broke was because we released a new client which broke backward compatibility and was getting sucked into the folsom tests--but we *do* want to catch that right? so we should not cap our own projects when listed as dependencies and let those breaks pop up?13:58
*** markmc has quit IRC13:59
mordredyes. that's correct13:59
fungiunfortunately that took a couple months for someone to care enough about folsom to fix it. capping outside dependencies is not going to save us from ourselves :/14:00
mordredyup14:01
mordredand nope14:01
fungidid we get anywhere with backward-compat gating jobs for changes to our clients/libs?14:01
*** dina_belova has joined #openstack-infra14:01
*** markmcclain has joined #openstack-infra14:01
fungiunfortunately, like the requirements testing, the holy grail would be to calculate reverse-dependencies of the project being changed and run all the tests associated with those projects14:02
fungion all affected branches14:03
mordrednope. we've gotten nowhere with those14:03
mordredI think it could maybe be done with a flag to d-g14:04
mordredso that it uses different logic when figuring out the branches of the other projects to pull14:05
fungiwell, i'll get changes proposed to cap all of the third-party dependency tree for each project supported in folsom and hope for the best, for now14:05
mordredzomg14:06
mordredI just realized I think it's easy14:06
mordrednew d-g job that simply overrides ZUUL_BRANCH14:06
mordredproposed changes get pulled based on their refs...14:06
mordredso they wou;dn't be affected14:06
mordredand we only add that job to the client libs14:07
fungioh, and then override the branch so the remainder of the projects integrated get chosen correctly and anchored to that branch14:07
mordredyup14:07
mordredso we make a job that overrides ZUUL_BRANCH=stable/grizzly14:07
fungid-g bases the services/projects list on ZUUL_BRANCH right?14:07
mordredand one that does stable/folsom14:07
mordredyup14:07
fungii think it might work14:08
fungithat'll at least get you devstack-tempest covered for backward-compat. doesn't directly help unit testing14:08
fungibut on the other hand, broken unit tests are going to be specific to one project, so they won't hold up every integrated project on that branch while waiting for a fix14:10
fungiso i guess that's less of a risk to stable branch management overall14:10
mordredalso, I'm more and more of the opinion that we should be doing unitests on devstack nodes14:10
*** mrodden has joined #openstack-infra14:11
mordredfungi: also, it means we'll be running stable branches more regularly - so the periodic jobs will probably cease being important14:11
annegentlehey guys, I think I have a fundamental conceptual gap for spinning up a slave server... sounds like a crisis eh?14:11
annegentle:)14:11
mordredit does!14:11
*** locke105 has joined #openstack-infra14:11
annegentleso I have a Rackspace Cloud server.14:11
fungiannegentle: it is no small feat14:11
annegentleMy thinking is I just "turn it into" a slave server14:11
annegentleso I made a local.pp14:12
annegentleturned my cloud server into a puppet server14:12
annegentleran the local.pp14:12
fungisounds right so far14:12
annegentlebut then what? Would the scripts be available in usr/?14:12
*** cody-somerville has joined #openstack-infra14:13
*** cody-somerville has quit IRC14:14
*** cody-somerville has joined #openstack-infra14:14
fungiannegentle: so, for example with a server destined to run python 2.7-based jobs we use an ubuntu 12.04 lts (precise pangolin) vm and instantiate openstack_project::slave for it14:14
jeblairmordred: why do you want to run unit tests on devstack nodes?14:14
annegentlefungi: ok so maybe I don't want to "puppet apply" the local.pp I made?14:15
fungiannegentle: something along these lines (but you'd have variable assignments in place of hiera lookups)... https://git.openstack.org/cgit/openstack-infra/config/tree/manifests/site.pp#n51614:15
jeblairannegentle, fungi: we also have this script: https://git.openstack.org/cgit/openstack-infra/config/tree/install_jenkins_slave.sh14:15
fungiahh, good point. why do i keep forgetting about install_jenkins_slave.sh (rhetorical question)14:16
annegentlejeblair: fungi: maybe I should try the install_jenkins_slave.sh then14:16
jeblairfungi: though i wonder if it works now that the 27/33 stuff has made things more complicated?14:16
fungiannegentle: that is probably what you want, yes14:16
*** ruhe has quit IRC14:16
annegentlejeblair: fungi: ok trying it now, but I get "host is missing hostname and/or domain14:17
fungijeblair: i think the py33 bits shouldn't complicate it unless you specifically want to test python 3.3 since it depends on a variable being added and set to true14:17
annegentlefungi: and clarkb told me what to change but I guess I didn't do it right? /etc/hosts and /etc/hostnames?14:17
jeblairfungi: makes sense14:17
* annegentle is grasping at straws14:18
fungiannegentle: well, the hostname shouldn't matter so much in this case, depending on what you're trying to do14:18
fungibut in theory you should just be able to create an ubuntu precise vm in rackspace, log into it, pull down the current install_jenkins_slave.sh and run it as root14:19
* fungi tries that to see if it's still working as intended14:20
annegentlefungi: okie, trying it now14:20
*** anteaya has joined #openstack-infra14:20
mordredjeblair: cause I'm crazy. ignore me14:21
mordredjeblair: in other news- python-swiftclient does not participate in the devstack-gate14:21
fungi...yet? ;)14:21
jeblairmordred: neat.  i don't think we've quite fully integrated django-openstack-auth either14:21
mordredalso, neither does ceilometerclient14:22
mordredjeblair: did you see my idea above on how to run trunk client with stable branches? am I missing a clear logic hole?14:22
jeblairmordred: lemme reread and think more.  i'm pre-breakfast here.14:23
mordredjeblair: ok. I'm about to send up a patch that might explain it more succinctly14:23
*** datsun180b has joined #openstack-infra14:24
BobBall:(  Can I bang my head on something?14:25
yolandafungi, jeblair, problem i have now is that job is executed correctly in jenkins, but it seems like it doesn't report it back to zuul14:25
BobBallhttps://bugs.launchpad.net/devstack/+bug/1212280 - python-crypto is actually broken on xenserver-core because it's now not uninstalled...14:25
uvirtbotLaunchpad bug 1212280 in devstack "python-crypto mismatch on CentOS 6.4 when using XenServer-Core" [Undecided,New]14:25
yolandathere is an error in jenkins like: Reported result: ERROR14:25
yolandaalthough job ends with SUCCESS14:26
yolandais there some extra config needed for jobs or for jenkins communication, rather than having gearman plugin installed?14:26
openstackgerritMonty Taylor proposed a change to openstack-infra/config: Gate current clients on stable branches  https://review.openstack.org/4193114:27
mordredjeblair: ^^ there you go (you too clarkb and fungi)14:27
*** adalbas has quit IRC14:27
mordredI _think_ that might just do what we want14:27
*** SergeyLukjanov has quit IRC14:28
BobBallmordred: any thoughts on other ways to get the python-crypto/python-lxml mess sorted on xenserver-core?  a fresh install shows that your patch at https://review.openstack.org/#/c/40431/ doesn't work after all :/ (sorry - I should have tested from fresh rather than on the system that was close-to-working)14:28
mordredBobBall: yes. my main thoughts in devstack right now are single-global-venv14:28
* fungi wonders if xenserver works in/with a virtualenv14:29
BobBallThat sounds like fun14:29
*** SergeyLukjanov has joined #openstack-infra14:29
BobBallwhy might it not fungi?14:29
fungieh, i don't currently fathom the depths to which xenserver is something nova runs in vs on vs manages vs is managed by14:30
mordredBobBall: here is what I'm at with it so far https://review.openstack.org/#/c/40534/14:30
mordredBobBall: it's not fully operational, as you can see14:30
BobBallhaha fungi :) Got it :) Xenserver-core is the thing I'm worried about at the moment - which is just running in a CentOS6.4 at the same level as devstack14:31
jeblairmordred: i think there's a problem with that -- if the queue is A[nova/master] <- B[novaclient/master], then to test B you will checkout grizzly projects and checkout the zuul ref for B.  but you will also checkout the zuul ref for A, which is not on the grizzly branch.14:31
BobBalli.e. no different architecturally to libvirt14:31
mordredjeblair: I didn't add it to the server projects14:31
mordredjeblair: so the queue should only be clientlib projects14:31
fungiBobBall: ahh, okay, so there are no xenserver tools which would need to be able to run within the context of the same virtualenv or anything14:31
jeblairmordred: however, the branch _is_ encoded in the zuul ref, so you can probably update the devstack-gate setup logic to ignore zuul refs in that circumstance14:32
jeblairmordred: i didn't say that you did.  :)14:32
BobBallfungi: not AFAIK, no.  All of the calling will go out of the venv and nothing needs to then run from within it.14:32
jeblairmordred: there is a single queue for all changes to all devstack projects14:32
mordredjeblair: of the same name14:32
fungiBobBall: okay, sounds like it should work then14:32
jeblairmordred: wha?14:32
BobBallfungi: because we're coming from a Dom0/DomU environment I think we can guarantee that separation more than most others ;)14:32
mordredjeblair: the single global virtual queue thing is about job name maching, no?14:33
jeblairmordred: look at http://status.openstack.org/zuul/14:33
fungiBobBall: yeah, makes sense14:33
jeblairmordred: you will see that it includes server projects (cinder, horizon) as well as client projects (python-cinderclient)14:33
mordredjeblair: yes. I undersatnd that. can you explain how it constructs that queue - because clearly my undersatnding is erroneous14:34
mordredit's projects sharing a job, right?14:34
jeblairmordred: all projects that share at least one job have their queues merged.14:34
mordredAHHHH14:34
mordredk14:34
mordredwith you14:34
jeblairmordred: (because that means they have the ability to affect each others outcome in each of those jobs)14:35
mordredyup. so I'd probably also want to add a flag or something that lets d-g know I'm doing this14:35
mordredand then add logic to d-g to strip out changes... hrm. that just became way more complex. dammit14:36
jeblairi think that's about it though.14:36
annegentlefungi: I see the same error on a fresh precise server, abotu the fqdn14:36
mordredbecause I can't tell it that I want it to strip out any master changes14:36
mordredbecause master changes to other client libs in the queue we'd want to keep14:37
fungiannegentle: can you paste the error?14:37
mordredannegentle: in addition to editing /etc/hosts14:37
mordredannegentle: you should run sudo hostname my.new.fqdn.com14:37
mordredannegentle: also, you should join me in yelling and your bosses and my bosses about providing a cloud that sets fdqn's when it spins up hosts14:38
mordredbecause it's pretty much exactly zero times when you explicitly want an invalid hostname14:38
mordredjeblair: do you think it would be super ugly to have the flag to d-g be a list of projects that should not have their master branch refs stripped?14:39
annegentlemordred: heh. but help me understand fqdns... so I can yell appropriately. I have to hand-edit /etc/hosts?14:39
ttxfungi: clearly we won't catch all cases.. But if we can get rid of the stupid ones maybe there will be more focus on the really interesting ones14:39
mordredannegentle: main thing is, you need to tell the current running server what its hostname is - so you need to run the hostname comand with an argument to set the hostname14:39
fungittx: yes, i think once mordred polishes https://review.openstack.org/41931 that will address the concern14:40
annegentlemordred: ok that definitely gets me further. I'll see if I can write this up14:40
ttxfungi: indeed. It's about the only way to preserve backward compat anyway14:41
jeblairmordred: i'm not sure i fully comprehend the case you're concerned about... but one second.14:41
fungittx: i'm feeling much better about our chances of keeping it stable at this point, actually14:41
jeblairmordred, fungi, ttx: it's worth mentioning that this would only test library source code api backwards-compatibility, not network api backwards-compatibility (which is also something we want to test)14:42
BobBallmordred: Does that patch depend on anything else?  "pip_install pip" fails because it's not running things as root.  cache_download (pip/util.py) tries to copy the cache file from /var/cache/pip/... which is owned by root.14:42
jeblairjust wanted to make sure we're clear on that and don't forget the other thing by using terms losely.14:42
mordredBobBall: yes. it does, but both of those things should be self contained14:42
mordredjeblair: totally. purely library backwards compat14:43
ttxjeblair: ok14:43
fungijeblair: our biggest pain point recently on stable/folsom was when a new version of a client was released which was not backward-compatible, so devstack-tempest no longer worked and we couldn't land security fixes for folsom for a couple months until someone cared enough to fix the client lib14:43
*** adalbas has joined #openstack-infra14:43
mordredright. and I believe that a working version of this would prevent that from happening14:44
jeblairfungi: yeah, i know, i'm not knocking this -- i just want to avoid us saying "oh, yeah, we test backwards compat.  totally."14:44
mordred:)14:44
fungiso preventing changes from landing which could put us in that position, hopefully14:44
jeblairthis is really important.14:44
* fungi agrees14:44
fungii mean, we also acknowledge that we probably won't (any time soon, maybe ever) test that a change to project 1 doesn't break unit tests for project 2 depending on it, much less across dev and stable branches14:46
mordredfungi, jeblair ^^ that, actually, is why I'm crazy and think we should just start running unittests on a prepped devstack node14:46
mordredbut seriously, ignore me - too many other things right now14:47
jeblairmordred: the set of projects where you don't want to mask their zuul refs is equal to the set of projects that only have a master branch, right?14:47
mordredjeblair: ah. yes. good call14:47
jeblairmordred: 'this project does not have this branch; therefore use master' is already a logic bit in d-g; you could re-use that to avoid the mask operation14:48
mordredjeblair: ++14:48
mordredjeblair: can you point mein the right direction in d-g to where this happens? setup_workspace doesn't seem to be the right place14:48
jeblairmordred: in fact, because it sets BRANCH=master in that case, depending on exactly how you implement the branch mask, it may already be taken care of?14:48
*** emagana has joined #openstack-infra14:49
jeblairmordred: setup_workspace14:49
*** jjmb has joined #openstack-infra14:49
jeblairmordred: https://git.openstack.org/cgit/openstack-infra/devstack-gate/tree/devstack-vm-gate-wrap.sh#n10514:49
mordredyup. that's what I'm loking at14:50
mordredlooking14:50
mordredI grok how this gets the right ref for the current change to be tested14:50
mordredI don't grok how it handles the previous projects in the queue14:50
jeblairmordred: zuul sets a ref for every project with a change14:50
mordredbut there is only one ZUUL_REF variable14:51
jeblairmordred: it sets the same ref.  :)14:51
jeblairmordred: i will type more, be patient:14:51
*** pcrews has joined #openstack-infra14:52
*** dina_belova has quit IRC14:52
jeblairmordred: so change A to project foo causes foo:refs/zuul/Z1 to be created; change B to project bar causes foo:refs/zuul/Z2, bar:refs/zuul/Z2 to be created14:52
mordredgotcha. I follow now14:52
jeblairmordred: so all devstack gate has to do is say "i'm supposed to test Z2, i'll check it out on every project that has one"14:53
*** markmcclain has quit IRC14:53
Alex_GaynorJust a heads up, there are a few jobs stuck in queued on the zuul status page, probably need to be killed / cycled / whatevered.14:54
fungijeblair: on a separate note, Alex_Gaynor pointed out earlier that we have accumulated a couple more jobs stuck in a queued state in zuul... is that what the latest gearman-plugin patch (41488) is supposed to solve?14:56
jeblairmordred: i _think_ (and i really need breakfast before i can say this for sure) that if you perform the mask operation using the $BRANCH variable after it's reset on line 109, you probably don't have to worry about the clientlib case.14:56
BobBallmordred: /var/cache/pip is only accessible by root in the generic case - so I think that your change requires PIP_DOWNLOAD_CACHE be set to a new directory that the stack user can create? do you agree?14:56
fungiheh, clearly i had you on my mind, Alex_Gaynor14:56
openstackgerritAnne Gentle proposed a change to openstack-infra/config: Adds info about building a Jenkins slave with script  https://review.openstack.org/4194214:56
mordredjeblair: yes. I think I see a simple way to do it14:56
jeblairfungi: yes; we should try rolling that out today.14:57
mordredBobBall: as in, it's only READABLE by root?14:57
fungik14:57
BobBallmordred: no, writeable - but that means you can't store the pip tarball in there running as the stack user14:57
BobBallmordred: and if you had already downloaded it as root then the file is likely to be read-only (at least it was in my setup :) )14:58
mordredBobBall: yes. I follow you now14:58
mordredI thought I'd put in a patch ot help with that - but might have missed it14:58
*** dina_belova has joined #openstack-infra14:58
mordredthe idea was to copy /var/cache/pip to somewhere writable by the stack user and then set PIP_DOWNLOAD_CACHE to that locaiton14:58
mordredand if /var/cache/pip happens to be empty, then an empty dir forthe stack user will e just fine :)14:59
*** _TheDodd_ has joined #openstack-infra14:59
SpamapSfungi: thanks, do I have to manually push 0.1.0 ?15:00
BobBallyup - I can fix it for me like that, but I guess we need a change to the patch (or a depends on another one)15:00
SpamapSfungi: or can I delete the tag, re-ad, re-push, and have it do something meaningful?15:00
fungittx: thinking through workflow, if i had capped, say, horizon stable/folsom's requirements yesterday we'd have set Django>=1.4,<=1.4.5 but today a security fix 1.4.6 was released. would we need to keep tabs on announcements and adjust pip-requires accordingly for the remainder of the support period of folsom?15:01
*** SergeyLukjanov has quit IRC15:01
fungiSpamapS: i'll need to run a script to trigger the job for you15:02
fungiSpamapS: now that it actually exists15:02
BobBallmordred: there is a change that sets it to ~/pipcache - but this is after pip_install pip (which fails for me)15:02
jeblairfungi: will you help me with some clicking?15:02
fungijeblair: gladly15:02
*** SergeyLukjanov has joined #openstack-infra15:03
jeblairfungi: would you mind logging into jenkins01?15:03
mordredBobBall: ah. then I just suck15:03
fungijeblair: lemme get my clicky finger warmed up. logging in15:03
*** ruhe has joined #openstack-infra15:03
ttxfungi: I'm not sure who that would serve...15:03
ttxfungi: I'd rather react to distros asking us to bump so that they don't get caught when upgrading deps... maybe15:03
fungittx: okay, so we just leave the cap there as a historical artifact and don't need to test that 1.4.6 broke nothing i guess15:03
jeblairfungi: in a minute (not just yet), i'd like you to manually abort all of the running jobs (except the ones that start with "ceilometer-")15:04
fungijeblair: okay15:04
fungijeblair: i'm there, so just say when15:04
ttxfungi: right. FWIW distros would try to backport security patches only in that 1.4.615:04
jeblairjust waiting for a change to merge15:04
fungik15:04
*** emagana has quit IRC15:04
ttxso we might actually serve them better by NOT upgrading ours15:04
fungittx: and you're good with leaving the lower bound untouched but changing/adding the upper bound on everything to <= today's releases15:05
fungi(except for things we release)15:05
fungittx: and as for new transitive dependency entries i add in the process (so we can cap those) should i bother specifying a lower bound?15:06
openstackgerritA change was merged to openstack/requirements: Allow use of oslo.messaging 1.2.0a4  https://review.openstack.org/4169615:06
jeblairzuul is stopped15:07
fungibecause if so, i'm not really sure what a meaningful one would be. maybe >=015:07
jeblairfungi: please proceed15:07
fungijeblair: okay, so start clicking through?15:07
fungion it15:07
jeblairfungi: oh, don't abort devstack-launch jobs15:07
*** emagana has joined #openstack-infra15:07
fungiah, oops. i only did one i think15:08
jeblairis ok15:08
*** mrmartin has quit IRC15:09
ttxfungi: probably not15:09
jeblairfungi: let me know when you're done15:11
fungiwill do--still clicking15:11
jeblair(i'll pitch in too)15:12
*** markmcclain has joined #openstack-infra15:13
openstackgerritMonty Taylor proposed a change to openstack-infra/devstack-gate: Add ability to do smart backwards compat testing  https://review.openstack.org/4194515:13
fungikill the launch jobs too, or no?15:13
jeblairfungi: nope15:13
jeblairall done15:14
fungii think that's all then15:14
openstackgerritMonty Taylor proposed a change to openstack-infra/config: Gate current clients on stable branches  https://review.openstack.org/4193115:14
fungiso once these finish, you'll be able to restart zuul?15:14
mordredjeblair: after breakfast, I think those two changes together might do it15:14
fungigah, two keystone jobs popped up, so knocked them down15:15
*** pabelanger has quit IRC15:15
jeblairfungi: that's cause i restarted zuul15:15
fungioh, oops15:15
jeblairi'll abort the rest and recheck that change15:15
fungii thought i had simply missed those two jobs down at the bottom of the list. my bad. didn't realize zuul was already back up15:16
*** mkerrin has joined #openstack-infra15:19
*** Protux has quit IRC15:21
*** Protux has joined #openstack-infra15:21
jeblairmordred: you should recheck those changes (zuul was down)15:22
*** changbl has joined #openstack-infra15:23
mordredjeblair: I will15:24
mordredspeaking of - I had an idea just now walking for coffee15:24
mordredwhat if - instead of the huge amount of non-voting jobs we have - we added a feature similar to recheck that would allow someone to request a non-voting job be run against their patch15:25
mordredso something like "please-tests gate-devstack-vm-tempest-cells"15:25
jeblairi'm not sure we have a huge number of non-voting jobs; i think we have 4, one of which is about to flip.15:26
jeblairmordred: but yes, we could do that.15:26
mordredby huge - I meant huge number of runs of those jobs that are not cared about :)15:26
jeblairah, that, yes.  :)15:26
mordredmore to enable the people actually working on those issues to get real gate feedback15:27
jeblairmordred: we could have an 'experimental' pipeline, and if you leave a comment, it triggers that.15:27
mordredyes. that would actually be even easier - and so what if you also get another experimental test15:27
mordred(I was thinking about this while thinking about adding two more devsack runs to every client change :) )15:28
jeblairexactly.  i think there's a special flag you have to set to get it to leave a comment but not vote.15:28
* mordred seems to be hacking on an area of our testing that he does not normally hack on a lot this morning15:30
* mordred wonders what he ate...15:30
openstackgerritMonty Taylor proposed a change to openstack-infra/config: Add missing tests to swiftclient  https://review.openstack.org/4195115:32
*** Shrews has quit IRC15:35
*** Shrews has joined #openstack-infra15:35
*** mrodden has quit IRC15:37
*** emagana has quit IRC15:40
*** ruhe has quit IRC15:43
*** mrodden has joined #openstack-infra15:46
openstackgerritMonty Taylor proposed a change to openstack-infra/config: Move non-voting jobs to an experimental queue  https://review.openstack.org/4195415:48
mordredjeblair: ^^ there's a stab at that15:48
fungiooh, the docs team is looking at doing parallel manual rebuilds and seeing some serious speed-up. it'll be nice to see those not running nearly so long in the future... http://lists.openstack.org/pipermail/openstack-docs/2013-August/002509.html15:48
jeblairgah15:49
jeblairthe new right-alignment sometimes causes every job result to shift down a row.15:50
*** jergerber has joined #openstack-infra15:51
BobBallmordred: Why are you setting up the virtualenv with --system-site-packages? This is causing me problems because I've got an env where pip has installed things previously (and broken the python-crypto library)15:51
openstackgerritYegor Minin proposed a change to openstack-infra/gerritlib: Add option to query commit messages  https://review.openstack.org/3886515:51
fungiBobBall: i think nova needs it for libvirt, since pip can't install that into the virtualenv?15:53
BobBallPoo15:53
fungiBobBall: though i may be misunderstanding the question15:53
BobBallunderstood15:54
fungiand apparently there's been little interest from libvirt upstream in generating a setup.py-able python-libvirt with the necessary library bindings so that it can be uploaded to pypi as part of their release automation15:55
fungi(it gets built directly out of their c lib sources currently)15:56
jeblairwhich is interesting, considering who the libvirt authors are15:56
BobBall Do you think breaking devstack for libvirt would encourage them to fix it? :)15:57
mordredBobBall: no15:57
BobBallshame15:57
mordredit's an upstream thing and a HUGE engineering issue15:58
mordredthat said - if we _start_ from a venv-based machine15:58
mordredwe shouldn't get you in to broken state in the first place15:58
mordredand if we pip install -U everything, we shoudl install what we ask for into the venv even if there is something in the system location15:58
mordredso it _should_ actually have the result that we're wanting15:58
mordred(other than you having a broken base system to start from :) )15:59
BobBallI think the problem is that the pycrypto in the system libs was broken but new enough - so the venv didn't think it needed it's own one15:59
_TheDodd_Greetings, jeblair! I hope you are well. anteaya mentioned something to the affect that you have some thoughts on the recent jeepyb changes.15:59
BobBall(i.e. broken in the python-crypto vs pip pycrypto sense)15:59
mordredBobBall: right. so in the future, it will do-the-right-thing and not break it15:59
mordredBobBall: you can try uninstall/re-installing the yum version to get the system version working16:00
mordredto test that16:00
BobBallyeah - it's just a shame that we can't rely on an isolated system16:00
mordredtotally agree16:00
BobBalli.e. we can't use virtual environments to be confident that it'll work irrespective of how broken the outside world is16:00
mordredI would welcome redhat fixing the build system around libvirt16:00
jeblair_TheDodd_: i don't think so; i think there was some suspicion that there was something wrong with the backwards-compatability, but that turned out to be incorrect on further inspection.16:00
mordredhowever, even if they decided to-I expect that to be at least 6-8 months of work16:00
BobBallwow, that huge16:00
* BobBall thinks that's a rabbit hole he should steer well clear from16:01
_TheDodd_jeblair, I see. Well, I am glad that it has been working! I've been a bit out of the loop these last few weeks, so I've been somewhat concerned about it.16:02
*** hub_cap has left #openstack-infra16:02
_TheDodd_I am still planing on writing up some test code for a few of the major aspects of update_bug. At some point I would like to code up a mock object representing an lp bug test which we can automate our testing against.16:03
fungi_TheDodd_: the few backwards compatibility concerns which surfaced mainly just highlighted the broad variety of different and often overly-wordy ways people had gotten used to referencing fixed bugs in their commit messages16:03
_TheDodd_Some of that stuff just seems far to risky to be deploying without some good test code.16:03
fungii am inclined to consider no longer supporting most of the references i saw as a feature, not a drawback16:04
_TheDodd_fungi, yea. I was stressing about that big time when I first wrote up the changes.16:04
_TheDodd_I was concerned that I may have left some important words out, but I didn't know how far I should go with it.16:05
fungi_TheDodd_: it's interesting how quickly people will accept changes in workflow as long as there's a good reason for it ;)16:05
_TheDodd_Ha. Indeed.16:05
fungii didn't really see anyone get upset about it. just confused until it was explained and then, "ah! okay, i should start using the new header format anyway--thanks!"16:05
_TheDodd_Nice16:06
_TheDodd_Glad to hear that.16:06
clarkbmorning16:06
*** vogxn has joined #openstack-infra16:06
_TheDodd_It's always nice when peace prevails in the community.16:06
fungiit mostly caught people unawares because even though they'd seen the announcement they already had outstanding commits using non-forward-compatible phrasing16:06
_TheDodd_Morning, clarkb!16:06
fungii think they just assumed their existing commits would get "grandfathered in" somehow, but there wasn't a great way to skin that without a lengthy transition period and a fair amount of extra work16:08
*** pabelanger has joined #openstack-infra16:08
jeblairclarkb: so i refreshed the plugin manager on jenkins-dev, and it doesn't seem to indicate there is an update...16:09
jeblairclarkb: i'm uninstalling it and will restart jenkins16:09
jeblairclarkb: i'm wondering if it may have been installed manually before, so doesn't check the update center or something16:09
clarkbjeblair: I am not sure16:10
clarkbjeblair: I have had to manually tell the upadte manager to update its list16:10
jeblairi did do that already16:10
clarkbjeblair: also check that it shows up on the jenkins-ci.org side16:10
jeblairclarkb: where's that?16:10
clarkbjeblair: http://updates.jenkins-ci.org/download/plugins/zmq-event-publisher/16:11
clarkbjeblair: looks like 0.0.2 is there16:11
jeblairclarkb: yeah, it shows up in the available list after i removed the manually installed version16:12
jeblairclarkb, zaro: so i think the jenkins publishing jobs are all good.  :)16:13
clarkbawesome16:13
*** jfriedly has joined #openstack-infra16:17
*** emagana has joined #openstack-infra16:17
*** gyee has joined #openstack-infra16:18
*** dina_belova has quit IRC16:19
*** vogxn has quit IRC16:19
*** pcrews has quit IRC16:21
*** dina_belova has joined #openstack-infra16:22
*** markmcclain has left #openstack-infra16:22
*** ^d has joined #openstack-infra16:23
*** ^d has joined #openstack-infra16:23
fungiSpamapS: i have a few minutes to trigger your release now... what was the project name and tag number?16:23
openstackgerritRyan Petrello proposed a change to openstack-infra/config: Configure Pecan to re-publish docs through RTFD on release.  https://review.openstack.org/4196916:24
*** _TheDodd_ has quit IRC16:24
*** SergeyLukjanov has quit IRC16:26
*** dina_belova has quit IRC16:26
*** jjmb has quit IRC16:27
*** _TheDodd_ has joined #openstack-infra16:27
SpamapSfungi: os-apply-config , 0.1.016:28
SpamapSfungi: and thanks (hopefully you still have a minute :)16:28
fungiSpamapS: thanks. working on it16:28
*** odyssey4me has quit IRC16:29
fungiSpamapS: okay, so looks like i need to trigger os-apply-config-tarball and then once that succeeds trigger os-apply-config-pypi-upload16:31
*** morganfainberg_a is now known as morganfainberg16:32
*** markmcclain has joined #openstack-infra16:32
fungii have the first running now16:34
fungiSpamapS: i think we may want to hold off on the pypi upload? it looks like your generated tarball is unversioned... http://tarballs.openstack.org/os-apply-config/os-apply-config-60b1928.tar.gz16:40
clarkbfungi: pbr should apply a version if it is tagged. that version happens when there is no tag16:40
fungiclarkb: hmmm... maybe i ran the job wrong... i used the --refname refs/tags/0.1.0 (it does exist) and the output of git show-ref 0.1.0 for the --newrev value16:41
fungi /opt/zuul/tools/trigger-job.py --job os-apply-config-tarball --pro16:42
fungiject stackforge/os-apply-config --pipeline release --newrev 60b1928075033ef03966773c1d851407770ead0d --refname refs/tags/0.1.016:42
fungigah, stray newline there16:42
SpamapS?16:42
fungiSpamapS: pbr isn't finding the tag when doing setup.py sdist it seems16:43
fungibut i do see the tag in the repo16:43
* fungi checks the jenkins log for the job16:43
SpamapSdid I tag the wrong commit?16:43
*** dkliban is now known as dkliban_afk16:44
fungiSpamapS: clarkb: https://jenkins01.openstack.org/job/os-apply-config-tarball/1/console16:45
*** nati_ueno has joined #openstack-infra16:46
mtreinishjeblair: so I've got: https://tinyurl.com/pdfz93l16:46
fungii wonder if trigger-job.py needs to be modernized16:46
mtreinishis there a way to scale one of the plots to make it bigger16:46
*** jjmb has joined #openstack-infra16:47
SpamapSfungi: I am pbr stupid, so I don't really know what that shows except "not a tarball with a version"16:49
*** fbo is now known as fbo_away16:49
*** ^demon has joined #openstack-infra16:49
SpamapSfungi: I can confirm that sdist locally does not produce a versioned tarball16:49
fungiSpamapS: yeah, i'm right there with you... still trying to figure it out myself16:49
*** ^d has quit IRC16:51
clarkbmtreinish: look at the graphs on the zuul status page16:52
*** jjmb has quit IRC16:52
fungiSpamapS: i too get dist/os-apply-config-60b1928.tar.gz when running git checkout 0.1.0 && python setup.py sdist16:52
SpamapShm16:52
SpamapSgit describe doesn't show the tag16:52
fungiSpamapS: aha!16:52
SpamapSunsigned16:52
SpamapS_DOH_16:52
clarkbmtreinish: you should be able to construct a graph that way and scale it16:52
*** saper has quit IRC16:52
fungiSpamapS: yup16:52
*** saper has joined #openstack-infra16:52
clarkbmtreinish: you can right click on one, copy url and open in a new tab16:52
SpamapSfungi: will delete 0.1.0 and re-issue with a signature16:52
jeblairmtreinish: it looks like if you click and drag a box it zooms in16:53
*** dina_belova has joined #openstack-infra16:53
fungijeblair: mordred: clarkb: what was the proper approach we decided on for replacing unsigned release tags with signed ones? don't?16:53
SpamapSoh16:53
* SpamapS waits16:53
*** wenlock has joined #openstack-infra16:53
fungii think without --fetch tags the build slave may not see the signed tag, if my memory is correct16:53
fungibecause it's already gotten the unsigned one into its refs16:54
SpamapSok so I can do 0.1.1 signed16:54
fungiSpamapS: that will work as long as your team is cool with it16:55
SpamapSI really don't mind if 0.1.0 was "the release that never was"16:55
mtreinishjeblair: ok cool thanks16:55
mtreinishclarkb: ok, I'll take a look16:55
fungiSpamapS: and should automagically worm its way through zuul-land without need of manual attention16:55
mtreinishclarkb: do you think graphing the failures that way is useful (the greater the negative amplitude on the red the more failures on parallel that weren't on serial)16:56
*** boris-42 has quit IRC16:57
*** markmcclain has quit IRC16:58
*** SergeyLukjanov has joined #openstack-infra16:58
fungiSpamapS: i highly recommend following the exact commands on https://wiki.openstack.org/wiki/GerritJenkinsGithub#Tagging_a_Release16:58
fungiSpamapS: modulo the branch/commit you're releasing from and the tag name itself of course16:59
ryanpetrellocan anybody shed some light on the difference between 'release' and 'pre-release': http://ci.openstack.org/zuul.html#overview ?16:59
fungiryanpetrello: it's based on a regexp match on the tag17:00
*** dina_belova has quit IRC17:01
fungiryanpetrello: https://git.openstack.org/cgit/openstack-infra/config/tree/modules/openstack_project/files/zuul/layout.yaml#n4817:01
SpamapSfungi: ok, 0.1.1 wending its way through the system17:01
fungiSpamapS: great! let's see how far it gets this time17:02
* SpamapS feels like he just set off a rube goldberg machine17:02
*** jpich has quit IRC17:03
fungiSpamapS: it does often feel just like that, i agree17:03
mordredSpamapS: w00t!17:03
SpamapShttps://jenkins01.openstack.org/job/os-apply-config-tarball/2/console17:03
SpamapSyaaay17:03
mordredwoot17:03
mordredof course, I just got a varnish error from pypi17:03
mordreddstufft: ^^17:04
SpamapShttps://jenkins01.openstack.org/view/All/job/os-apply-config-pypi-upload/ <-- shouldn't that go next?17:04
clarkbSpamapS: oui, but not on that master17:05
SpamapSoh duh17:05
clarkbSpamapS: iirc only jenkins.o.o is hooked up to slaves that can talk to pypi17:05
*** rcleere has joined #openstack-infra17:05
SpamapShttps://jenkins.openstack.org/view/All/job/os-apply-config-pypi-upload/17:05
SpamapSso that one?17:06
*** BobBall is now known as BobBall_Away17:06
clarkbyes, that is where I expect it to have run17:06
mordredSpamapS: you like finding all the problems don't you?17:06
*** markmcclain has joined #openstack-infra17:07
SpamapSmordred: its why you love to hate me and hate to love me.17:07
* mordred hate loves SpamapS17:07
* SpamapS is the Charlie Sheen of OpenStack17:07
SpamapS#winning17:07
*** sarob has joined #openstack-infra17:07
clarkbthere is a two and a half men joke here somewhere17:08
clarkbI am not sure why that job did not run17:08
clarkbis the zuul config not correct?17:09
* clarkb AFKs to dock laptop17:09
*** yolanda has quit IRC17:09
BobBall_Awaymordred: Next problem - /usr/bin/glance-api is invoked through /usr/bin/python rather than .venv/bin/python, so it breaks out of the venv and doesn't have the stuff it needs (e.g. the right version of python-crypto).  Thoughts?17:09
*** chuckieb has joined #openstack-infra17:10
mordredBobBall_Away: awesome! why is it doing that?17:10
mordredah17:10
BobBall_Awaymordred: #!/usr/bin/python :)17:10
mordred$GLANCE_BIN_DIR/glance-api17:10
mordredwe've got some explicit BIN_DIR settings we shoudl fix17:11
mordredlemme take a stab17:11
*** nayward has quit IRC17:11
*** beagles has quit IRC17:11
mordredget_python_exec_prefix17:11
mordredBobBall_Away: http://paste.openstack.org/show/4414117:13
mordredbut I'm going to amend my patch - did you make fixes to it already?17:14
mordredor - feel free to fix and reupload, btw17:14
BobBall_Awaymordred: only locally to move the PIP_CACHE_DIR17:14
BobBall_Away(or whatever it was)17:14
mordredok. I've made that change locally here too17:15
BobBall_Awaymordred: but it's not working yet for me - and my day is almost over so I have to leave! If you haven't had a chance to fix it tonight I'll look at a new change tomorrow if I get it working17:16
mordredBobBall_Away: cool. well, the glance hint was a good one17:16
*** beagles has joined #openstack-infra17:16
BobBall_Awayglad I'm useful for something ;)17:17
BobBall_Away*gone*17:17
*** pcrews has joined #openstack-infra17:17
clarkbSpamapS: fungi: so pypi upload did not run?17:18
fungiclarkb: i think i see why17:18
*** _TheDodd_ has quit IRC17:18
clarkboh good I can go find caffeine then17:19
*** sarob has quit IRC17:19
*** sarob has joined #openstack-infra17:19
fungiwell, no17:21
fungiclarkb: http://paste.openstack.org/show/44142/ "handle: None name: build:os-apply-config-pypi-upload unique: 9d3f4315d0304687926c164b5578e238> is not registered with Gearman"17:22
*** markmcclain has quit IRC17:23
*** beagles has quit IRC17:23
fungibut /var/lib/jenkins/jobs/os-apply-config-pypi-upload/config.xml exists on jenkins.o.o (which should be the one to farm it out, right?)17:23
*** beagles has joined #openstack-infra17:23
*** sarob has quit IRC17:24
*** gyee has quit IRC17:25
dstufftmordred: still happening?17:25
openstackgerritJames E. Blair proposed a change to openstack-infra/nodepool: Initial commit  https://review.openstack.org/4180517:25
jeblairclarkb, fungi, mordred: ^ that is ripe.17:26
mordreddstufft: it seems to be back17:26
mordredjeblair: I will look at that for real once I have coffee17:27
dstufftmordred: probably a temporary blip then17:27
mordredclarkb: did you see the pile of exciting new patches I uploaded this morning?17:27
mordreddstufft: yeah. agree17:27
openstackgerritJames E. Blair proposed a change to openstack-infra/nodepool: Initial commit  https://review.openstack.org/4180517:27
mordredthe openstack project is excellent early-warning monitoring :)17:27
mordreddstufft: oh - btw - I think jeblair wrote the hard part of the code that needs to be written for me to be able to trigger openstack builds on changes to the pip repo and let you know if you're going to break us17:28
*** cthulhup has joined #openstack-infra17:28
dstufftmordred: I never bothered to get the guy with the keys to add my info to pingdom for pypi, becasue twitter lets me know faster than pingdom does17:28
jeblairclarkb, mordred, fungi: the jenkins queue is managable now; so i'm going to rolling upgrade zmq and gearman plugins17:28
dstufftmy info == cell phone, it does get sent to my email17:29
mordredjeblair: ++17:29
mordreddstufft: we have on more than one occiasion alerted gys at rax and hp about an issue they were about to start seeing ni ntheir clouds :)17:29
jeblairjenkins02 is in shutdown mode17:30
mordreda chorus of yelling developers is the new pingdom17:30
dstufftmordred: +117:30
dstufftbuild thing lots of people use, never need monitoring again17:30
* fungi needs to run an errand... brb17:31
* jeblair imagines a world where twitter is pingdom's only user17:31
*** danger_fo_away is now known as danger_fo17:32
mgagnecgit is not well conceived to be easily skinnable... =(17:34
openstackgerritJason Meridth proposed a change to openstack-dev/hacking: Adds ability to ignore H231, python3x except compatability check  https://review.openstack.org/4171317:34
* jeblair -> afk for a bit17:35
*** rnirmal has quit IRC17:40
clarkbmordred: I did not17:42
clarkbI am still catching up this morning17:42
*** _TheDodd_ has joined #openstack-infra17:42
mordredclarkb: I may have done things we've been wanting for a bit17:42
clarkbjeblair: fungi: is that a bug in the gearman plugin? potentially fixed by the upgrade jeblair is about to do17:42
clarkbon my walk to the office this morning I was thinking about a useful first real use case for logstash/elasticsearch17:44
clarkbI am thinking a daily job that searches the last days devstack screen logs for ERROR level messages, and collates them into a reasonable format for humans and further consumption would be a good place to start17:45
clarkbthen we can start by handing a thing to openstack-qa and eventually feed that into a thing that deals with bugs17:45
*** derekh has quit IRC17:45
mordred++17:46
*** ArxCruz_ has joined #openstack-infra17:47
clarkbneat cgit shows you change refs in the git log tree17:47
*** sarob has joined #openstack-infra17:47
*** nayward has joined #openstack-infra17:47
*** ArxCruz has quit IRC17:48
clarkbI think we may need to give git.o.o more horsepower though17:49
* fungi is back17:49
clarkbmordred: can you look at https://review.openstack.org/#/c/41790/ ? this is the start of our mysql backup stuff17:50
clarkbmordred: and the child change of that shows you how I intend on using it17:50
clarkbmordred: I hope to test it on etherpad-dev today17:50
mordredclarkb: cool. you know you don't have to use $defaults_file = '/etc/mysql/debian.cnf' if ythe mysql was set up by puppet, yeah?17:51
clarkbmordred: right, but not all of our mysql is setup by puppet iirc17:51
mordredindeed.17:51
clarkbmordred: and I don't like the puppetlabs mysql backup class17:52
mordredjust pointing out - as debian.cnf is debian specific17:52
mordredno - I don't think you should use their backup class17:52
clarkbmordred: right that is why it is a parameter17:52
clarkbdoes centos not create a defaults file that lets root in?17:52
mordreddunno17:52
fungiyeah, debian.cnf is convenient on debian systems, but i always feel sort of guilty for using it17:52
mordredgreat. also - there may be a time when our databases are in a cloud trove somewhere17:52
fungilike i really should set up separate backup credentials instead17:52
clarkbmordred: we can use a non debian "defaults" file when we make that switch17:53
mordredso we may want to just be able to pass the hostname, username, and password itself in as a parameter to the backup class and let it manage what it does with it17:53
mordredactually, ^^ is more my concern17:53
clarkbwouldn't that first require managing all of your mysql servers with puppet?17:53
mordredwhy?17:54
clarkbotherwise we won't know what the credentials are17:54
mordredif we create a database in the cloud17:54
mordredwe will get credentials back from that action17:54
mordredthen we put those creds into heira17:54
clarkbright, but we aren't there today17:54
mordredrigh. I know17:54
clarkbtoday we need a thing that can backup databases on ubuntu that may or may not be configured by puppet17:54
mordredI'm just saying that is a thing we are going to want to be able to do in the future17:54
clarkbdefinitely17:55
fungido we have a mysql database for pbx.o.o?17:55
mordredI am fine refactoring the backup module later to deal with that17:55
clarkb(I don't disagree with what you are saying, but think that the needs today are different than the needs tomorrow)17:55
clarkbmordred: and it might be easist to capture that with a second define. backup-trove-db vs backup-local-db or somesuch17:56
clarkbfungi: I don't think so17:56
fungiokay, then all debuntu things17:56
*** Ryan_Lane has quit IRC17:57
clarkbbtw cloning nova from git://git.o.o is a full minute faster than cloning from github using https17:57
fungithat is thrilling, truly17:57
clarkbfungi: grep on pbx says no mysql17:57
clarkber17:57
clarkbpgrep17:57
*** Ryan_Lane has joined #openstack-infra17:58
* fungi is switching gears to build a temporary system to build a precise cacti security backport, because ubuntu17:58
mordredfungi: lovely17:59
mordredfungi: I'm going to grab a coffee - when I get back do you want to talk about apt repos?17:59
fungiyeah, i want cacti back up before our calls friday, and i also want to be able to see if git.o.o could stand upgrading18:00
fungimordred: i can talk, sure18:00
fungiget coffee18:00
clarkbmtreinish: tempest testr seems to potentially be unhappy noq18:00
clarkb*now18:00
fungianybody know if there's a trick to running novaclient out of a virtualenv? i pip installed it into one but get "ERROR: 'NoneType' object has no attribute 'authenticate'"18:01
*** dina_belova has joined #openstack-infra18:01
fungihen trying to use it (installing it works just fine)18:02
openstackgerritMonty Taylor proposed a change to openstack-infra/config: Use cgit server instead of github for everything  https://review.openstack.org/3817718:02
*** Ryan_Lane has quit IRC18:02
mordredspeaking of that ^^18:02
*** dina_belova has quit IRC18:02
*** dina_bel_ has joined #openstack-infra18:02
*** Ryan_Lane has joined #openstack-infra18:03
clarkbfungi: no clue. is that the most recent release?18:03
* clarkb tries18:03
fungiclarkb: most recent release on pypi, though i am running it on a debian/jessie (testing) vm18:03
*** jerryz has joined #openstack-infra18:04
fungiprobably roughly equivalent to running on raring18:04
*** Ryan_Lane has quit IRC18:04
*** ladquin_afk is now known as ladquin18:04
clarkbfungi: nova list works on precise out of a venv18:05
fungiclarkb: ha... bug 119774518:05
uvirtbotLaunchpad bug 1197745 in python-novaclient "Rackspace authentication no longer supported" [Wishlist,Confirmed] https://launchpad.net/bugs/119774518:05
clarkbah, I am was talking to hpcloud18:06
fungireported on 2013-07-0418:06
fungiafter also installing rackspace-auth-openstack into the venv and setting the new OS_AUTH_SYSTEM=rackspace var, it works18:08
fungii guess we'll eventually want to do similar things on our systems which launch servers or which are used by us to do so (d-l.slave, ci-puppetmaster)18:10
anteayamordred: when you are back from coffee, this file disappeared from patchset 3: https://review.openstack.org/#/c/38177/2/modules/openstack_project/files/git/cgitrc18:12
jeblairfungi: i believe we switched to using passwords rather than rax api keys18:12
anteayamordred: I think it should be in there but the only change is git:// for https://18:12
anteayathough I could be wrong18:12
SpamapSfungi: so, what came of the pypi upload not running?18:13
fungiSpamapS: jenkins-gearman plugin bug is what clarkb suggested. we should probably wait until jeblair finishes the plugin rolling upgrades and manually retrigger it18:14
SpamapSI am so glad to ferret out all of your bugs :)18:14
jeblairfungi: who what?18:14
*** mrmartin has joined #openstack-infra18:14
fungiSpamapS: if only those really were all of our bugs18:14
fungijeblair: http://paste.openstack.org/show/44142/18:15
fungijeblair: zuul claims that the job is not registered, but it clearly exists on jenkins.o.o18:16
*** nayward has quit IRC18:16
clarkbjeblair: I think possible related to executor management which the new verison of the plugin should handle much better18:16
*** luisg has quit IRC18:16
*** luisg has joined #openstack-infra18:16
SpamapSfungi: ah, so something has to be HUP'd or restarted maybe?18:16
*** _TheDodd_ has quit IRC18:18
*** _TheDodd_ has joined #openstack-infra18:18
fungiSpamapS: well, clarkb's assertion is that it may be due to a bug which may be fixed by jenkins plugin upgrades jeblair is in the middle of applying right now. if so, then trying after he's finished may work out18:19
*** _TheDodd_ has quit IRC18:19
jeblairi'll upgrade jenkins.o.o now18:19
*** _TheDodd_ has joined #openstack-infra18:19
jeblairi also restarted puppet because it had a zombie jenkins-jobs process18:22
*** afazekas has quit IRC18:25
*** melwitt has joined #openstack-infra18:27
*** chuckieb has quit IRC18:27
*** lifeless has quit IRC18:28
*** hartsocks has joined #openstack-infra18:28
jeblairokay, jenkins.o.o is back up.  i had to start it twic; it seems to have hung the first time.18:29
*** psedlak__ has quit IRC18:29
jeblairfungi, SpamapS: the job is registered now18:29
fungijeblair: awesome. retriggering it now18:29
jeblairrestarting jenkins0218:29
fungiwell, awesome about the job now being registered. not so awesome about jenkins getting itself into a sorry state when starting18:30
fungiSpamapS: https://pypi.python.org/pypi/os-apply-config/0.1.118:33
SpamapS\o/18:33
SpamapSnow if I can just figure out why neutron is crashing...18:34
nati_uenoHi Could you guys review this one? https://review.openstack.org/#/c/41799/ This is needed to identify gating issues18:34
*** emagana has quit IRC18:35
mrmartinhi18:37
jeblairi'm seeing the same deadlock on jenkins02; i'm getting stacktraces18:38
mordredclarkb: mind taking a loot at https://review.openstack.org/#/c/41283 ? or dhellmann ?18:38
mordred(pbr is broken for the windows folks)18:38
*** markmcclain has joined #openstack-infra18:39
clarkbwoo shrews just helped me find a testr bug18:40
clarkbmordred: ya, let me file this bug against testrepository first18:40
mordredclarkb: kk18:40
*** chuckieb has joined #openstack-infra18:40
*** thomasbiege has joined #openstack-infra18:41
*** dkliban_afk is now known as dkliban18:42
clarkbhmm no lifeless on the freenodes18:46
clarkbhttps://bugs.launchpad.net/testrepository/+bug/1212390 is the bug18:46
uvirtbotLaunchpad bug 1212390 in testrepository "Testr load cannot handle subunit v1." [Undecided,New]18:46
jeblairclarkb, zaro: so i think some of those methods i changed to synchronized need to go back to a finer grained explit synchronization on the gewtHandles object18:47
clarkbjeblair: you think that is causing the deadlock?18:47
mordredjeblair: poop. I had liked the sync methods approach18:48
dhellmannmordred: why not just make _run_shell_command() take a list of args?18:48
*** thomasbiege has quit IRC18:48
clarkbI have not started any of the owrk that I wanted to start yet.18:48
mordreddhellmann: cause it's ugly to read at the calling location? I dunno. it's just what we've always done :)18:48
dhellmannmordred: uglier than escaping quotes to make shlex work?18:49
mordreddhellmann: you do make a good point18:49
*** rscottcoyle has joined #openstack-infra18:49
mordredthere are times when I miss Java multi-methods18:49
dhellmannmordred: ah, I thought this was your patch, I'll add a comment18:50
*** emagana has joined #openstack-infra18:50
mordreddhellmann: nope, it's alex from hyperv18:50
* dhellmann nods18:51
dhellmanndo we have any examples of jenkins jobs that take a multiline string as a named parameter?18:52
*** psedlak__ has joined #openstack-infra18:53
clarkbdhellmann: I don't think so18:53
dhellmannclarkb: :-/ I want to pass file contents to a builder to write a little temp file. I'm passing it through sed to convert spaces to newlines right now, but that feels hackish.18:54
NobodyCamdhellmann: do you have a free minute to to take a look at the Fix Driver loading Ironic patch? (https://review.openstack.org/#/c/39617/)18:56
dhellmannNobodyCam: looking18:56
NobodyCam:)18:56
NobodyCamTY18:56
*** ^demon has quit IRC18:59
*** psedlak__ has quit IRC18:59
mrmartinjeblair, I added a missing .gitreview to the groups project. Do I need to be a member of core reviewers for this project? https://review.openstack.org/#/c/41988/19:01
*** cthulhup has quit IRC19:03
*** ArxCruz_ has quit IRC19:03
fungijeblair: i can add mrmartin to groups-core if desired19:04
fungimrmartin: taking a look at your patch now19:04
jeblairfungi: please, thanks19:04
mrmartinfungi: thanks19:04
fungimrmartin: you're in the core group for it now19:04
mrmartinit is perfect patch19:04
*** ArxCruz has joined #openstack-infra19:05
jeblairi'm going to downgrade to 0.0.3.1 on jenkins02 and restart19:05
mordredjeblair: k19:05
mrmartinok I have a few questions, I made the puppet manifests to create the drupal environment for groups-staging.openstack.org, and it runs well in my local dev environment.19:05
fungijeblair: do we want openstack-ci-core included in groups-core too?19:06
mrmartinI needed to add a pear puppet module due drush cli support: rafaelfc-pear (v1.0.3)19:06
mrmartinwhat is the proper way to add it to openstack-ci/config repo?19:06
jeblairfungi: yeah, it's under openstack-infra19:07
mordredmrmartin: you'll see a list of modules ...19:07
mrmartinDoes it enough if I add it to install_modules.sh? How will this populated after a commit?19:07
mordredyes19:07
mordredour puppet cron stuff runs install_modules19:08
mrmartinoh great19:08
*** gyee has joined #openstack-infra19:08
mrmartinthe other question is, that we'll have a running staging site at groups-staging.openstack.org. Currently I have a bash build script that populates the drupal site under virtualhost directory, it runs nicely when I launching a new node with drupal manifest.19:09
NobodyCamTY dhellmann :)19:10
mrmartinIf I like to update this environment after every commit, what is the proper way to do that? Can I trigger some notification from gating, and execute this script on this node somehow?19:11
mordreddhellmann: alexpilotti was wondering if we could do the run_shell_command-takes-list refactor next when he's past not being able to install anything19:11
dhellmannmordred: sure19:11
*** alexpilotti has joined #openstack-infra19:11
*** emagana has quit IRC19:11
*** mjfork has quit IRC19:11
mrmartinhi Alessandro19:11
fungimrmartin: we'd have the vcsrepo module watch that repository and then make an exec for that script in puppet and subscribe the exec to the vcsrepo19:12
mordredalexpilotti: dhellmann said 'sure'19:12
dhellmannalexpilotti, mordred : +219:12
mrmartinfungi: thanks, I'll check it19:12
*** emagana has joined #openstack-infra19:13
fungimrmartin: that should cause the script to run each time vcsrepo pulls the latest commit from the remote branch19:13
mordredalexpilotti: but you have to promise to do the refacto :)19:13
alexpilottithanks dhellmann !19:13
* alexpilotti hides19:13
clarkbmrmartin: fungi: would the vhost need to be updated each time? or do we simply need to update the code behind it?19:13
mrmartinfungi: ok, this is the last step missing from auto-update process of staging19:13
* dhellmann wonders if yaml even honors multiline strings in jjb params19:13
alexpilottikidding, I'm on it19:13
mrmartinclarkb: I mean we need just update the code behind it, not the entire vhost (vhost = apache vhost here)19:14
clarkbmrmartin: fungi: it almost sounds to me like the current situation depends on the script to update the code which is why it is run whereas the new sitaution can have puppet do that19:14
alexpilottiWe have an issue on hooks.py on Neutron on Windows: https://bugs.launchpad.net/neutron/+bug/121238519:14
uvirtbotLaunchpad bug 1212385 in neutron "Setup fails on Windows due to changes in neutron/hooks.py" [Undecided,New]19:14
fungiclarkb: i took "under virtualhost directory" to mean that the repository updates get pulled into the document root corresponding to that apache vhost19:15
alexpilottibasically, on Windows we have to remove some requirements and add some others19:15
alexpilottihttps://github.com/openstack/neutron/blob/ee3fe4e836ca1c81e50a8324a9b5f982de4fa97f/neutron/hooks.py#L2519:15
mordredalexpilotti: ah - you need to _remove_ some of them19:15
fungiclarkb: or s/pulled into/generated into based on the git repo content/19:15
mrmartinclarkb: I have a working bash script for that, I'll check whether I could puppetize it. This could be a more elegant solution.19:16
alexpilottinow as requires_dist is empty, I cannot remove them (actually it's only pyudev)19:16
mordredyeah. I have a n idea19:16
*** mjfork has joined #openstack-infra19:16
alexpilottiis there a different way to handle it now?19:16
mordredalexpilotti: for now, put in an else after the win32, add pyudev there, and remove it from the reuqirements.txt list19:17
mordredalexpilotti: we have a todo list item to let people put markerlib strings in requirements.txt - but I have to sell dstufft on pip support for that first19:17
alexpilottioki, so requires_dist is still used in the latest pbr builds, correct?19:17
mordredyup19:18
mordredit's what pbr injects things that are in requirements.txt into19:18
alexpilottioki, sounds good!19:18
clarkbmordred: I left a comment on your experimental pipeline change19:19
mordredclarkb: yay!19:19
clarkbmordred: would be curious to see what you have to say about what I have to say19:19
mordredclarkb: so - the outstanding question with that is what happens with the voting19:20
mordredclarkb: the difference is that the experimental pipeline does not run by default19:20
mordredit only runs when you request it19:20
*** hartsocks has left #openstack-infra19:20
mordredso we don't have to run cells 1000 times a day so that devs can ignore the red color and still know that cells is broken19:20
mordredbut the guys working on cells can easily request a run of the cells job19:20
*** rnirmal has joined #openstack-infra19:23
*** ruhe has joined #openstack-infra19:24
*** vipul is now known as vipul-away19:24
*** thomasbiege has joined #openstack-infra19:25
*** nicedice_ has joined #openstack-infra19:25
*** vipul-away is now known as vipul19:28
*** emagana has quit IRC19:28
*** vipul is now known as vipul-away19:32
*** thomasbiege has quit IRC19:32
*** lifeless has joined #openstack-infra19:39
*** jbjohnso has joined #openstack-infra19:39
*** ruhe has quit IRC19:39
jbjohnsoquestion in this whole gerrit workflow, the way I usually push tags in git doesn't work, how to push tags?19:39
mgagnejbjohnso: which project?19:41
fungijbjohnso: https://wiki.openstack.org/wiki/GerritJenkinsGithub#Tagging_a_Release19:41
*** afazekas has joined #openstack-infra19:41
mgagnejbjohnso: what fungi said, otherwise it could be an ACL issue in gerrit for this specific project19:43
mordredjeblair: you're not on the twitter, but I figured you'd like this: http://www.slate.com/blogs/business_insider/2013/08/14/gmail_security_google_says_users_have_no_legitimate_expectation_of_privacy.html19:43
mordredjbjohnso: yeah. we just have to set you as being a person who can push tags for a project19:44
*** vipul-away is now known as vipul19:45
*** pabelanger has quit IRC19:45
*** wenlock has quit IRC19:49
*** chuckieb has quit IRC19:50
*** hartsocks has joined #openstack-infra19:54
jbjohnsothanks, that worked19:54
mtreinishclarkb: sorry I was in a really long meeting were the tests failing?19:55
hartsocksSo I have a question about a patch I'm trying to get Jenkins to recheck. Is there something going on today?19:56
mordredhartsocks: yeah. there were some issues earlier with race conditions inside of jenkins19:57
mordredwe're trying to track them down19:57
hartsocksmordred: thanks19:58
*** SergeyLukjanov has quit IRC19:58
* fungi needs to disappear again for a bit... bbiaw19:58
clarkbmtreinish: they were failing, but seem to be happy again19:59
clarkbmtreinish: I may have overreacted19:59
clarkbmordred: thats the difference. I completely missed that for some reason20:00
clarkbmordred: now that I know that I love the idea20:00
clarkbbecause cells failing always and neutron-full failing always is getting old20:01
*** rscottcoyle has quit IRC20:02
*** afazekas has quit IRC20:02
*** rcleere has quit IRC20:03
mgagnefirst attempt at skinning cgit for openstack: http://imgur.com/Xw7CIy920:04
pleia2mgagne: that looks great20:05
pleia2I still have my test cgit instance up, so if you want to toss in review I can test20:06
mtreinishclarkb: ok, yeah I'm looking at the trend graph it looks to be about the same there were a couple of failures that happened around the same time20:06
mtreinishbut overall it looks pretty good20:06
pleia2oh, I need to set up a static place for files20:07
openstackgerritJames E. Blair proposed a change to openstack-infra/gearman-plugin: Use more fine-grained synchronization in GearmanProxy  https://review.openstack.org/4200320:07
mtreinishbut definitely not as good as serial20:07
jeblairclarkb, mordred, zaro: ^20:07
jeblairmgagne: NICE!20:07
mgagnepleia2: I'm not ready for a review, I'm copy/pasting my css in the developer tool of chrome, my setup is ghettho20:07
*** pcrews has quit IRC20:08
*** emagana has joined #openstack-infra20:08
jeblairpleia2, mgagne: can we disable the "owner" column in the display?20:08
mgagnepleia2: I can send you the css if you want to work on it and improve it. I used duct tape. Otherwise I'll check later this week20:08
*** pcrews has joined #openstack-infra20:08
mgagnejeblair: sure!20:08
mgagnejeblair: in my "todo" list20:08
mordredjeblair: exciting, looking20:08
pleia2mgagne: sure20:08
mgagnejeblair: enable-index-owner: 020:09
mgagnepleia2: don't laugh: http://paste.openstack.org/show/44161/20:09
mgagnepleia2: I'm mostly taking css from the gerrit theme20:10
mgagnepleia2: I did not test other pages as my setup is limited in that aspect. I would have to pop a cgit install to test and I'm lazy20:10
pleia2mgagne: thanks! which openstack icon are you using, the one from gerrit?20:11
mgagnepleia2: yes, check the url =)20:12
jeblairi've put jenkins02 back in shutdown mode, hopefully we can upgrade the gearman plugin again there.20:12
mgagnepleia2: there is already a copy of the logo in the openstack_project module20:12
pleia2mgagne: saw bg, not os icon20:12
pleia2cool, I'll make sure I install that one20:12
mgagnepleia2: it's only a matter of installing static files to the right folder20:12
* pleia2 nods20:12
pleia2halfway through my basic static files patch now (logo and favicon are config options, so those are easy to do quickly)20:13
pleia2...but my lunch just arrived! be back soon20:13
mgagnepleia2: modules/openstack_project/files/openstack.png?20:13
clarkbmgagne: if I have a puppet module with a define it it as module::foo do I need an init.pp for that module?20:14
mgagneclarkb: no20:14
openstackgerritJames E. Blair proposed a change to openstack-infra/nodepool: Initial commit  https://review.openstack.org/4180520:14
clarkbmgagne: thanks20:14
openstackgerritClark Boylan proposed a change to openstack-infra/config: Switch etherpad_lite backups to mysql_backup.  https://review.openstack.org/4179120:16
openstackgerritClark Boylan proposed a change to openstack-infra/config: Add new mysql_backup module.  https://review.openstack.org/4179020:16
*** whayutin_ has joined #openstack-infra20:16
openstackgerritMonty Taylor proposed a change to openstack-infra/config: Add job to propose tag merges  https://review.openstack.org/4192720:17
*** _TheDodd_ has quit IRC20:17
*** _TheDodd_ has joined #openstack-infra20:18
mordredclarkb: lifeless is back20:20
*** weshay has quit IRC20:20
*** ^d has joined #openstack-infra20:22
*** whayutin_ is now known as weshay20:23
*** adalbas has quit IRC20:23
*** ftcjeff has joined #openstack-infra20:26
openstackgerritClark Boylan proposed a change to openstack-infra/config: Switch etherpad_lite backups to mysql_backup.  https://review.openstack.org/4179120:27
lifelessmordred: clarkb: yes, apparently my server didn't want to be on overnight. So whatever you asked... I don't know.20:28
mordredlifeless: clarkb made you a new bug present20:28
*** sandywalsh has quit IRC20:28
mordredlifeless: https://bugs.launchpad.net/testrepository/+bug/121239020:28
uvirtbotLaunchpad bug 1212390 in testrepository "Testr load cannot handle subunit v1." [Undecided,New]20:28
*** ftcjeff_ has joined #openstack-infra20:30
clarkbmordred: jeblair: fungi 41791 and its parent have been applied to etherpad-dev and look to be good20:31
*** jtzl has joined #openstack-infra20:31
jeblairclarkb, zaro: are either of you interested in reviewing https://review.openstack.org/#/c/42003/  or should i let production jenkins review it? :)20:31
clarkbjeblair: I am reviewing it now20:31
jeblairok20:31
lifelessmordred: clarkb: ah - wontfix.20:32
openstackgerritJason Meridth proposed a change to openstack-dev/hacking: Adds ability to ignore H231, python3x except compatability check  https://review.openstack.org/4171320:32
clarkblifeless: why not?20:32
zarojeblair: me too, was reviewing clarks puppet backup.20:32
*** ftcjeff has quit IRC20:32
clarkblifeless: you are outputting content in a format you cannot consume20:32
lifelessclarkb: no, we're not outputting that content at all20:33
clarkblifeless: also I now know why testr run --analyze-isolation hasn't been working for anyone20:33
clarkbbecause testr load is loading an empty test log20:33
clarkbjeblair: is that change basically a revert on that one file?20:33
jeblairclarkb: i very much doubt it, but have not diffed the two versions20:33
jeblairclarkb: there should still be substantial changes to method bodies in both this and the previous change20:34
lifelessclarkb: huh, where from  ?20:35
clarkblifeless: testr load of a v1 subunit file doesn't load anything20:35
clarkblifeless: so when I tell people to grab the subunit log fron jenkins, load it and run analyze-isolation it is a noop20:35
clarkbeither testr can handle both or I have to also tell people to do a conversion first20:35
clarkband the fact that it isn't a failure to load the old stuff makes it silently break20:36
lifelessclarkb: oh, I thought you were saying analyze-isolation was internally broken.20:36
*** thomasbiege has joined #openstack-infra20:36
*** briancli1e is now known as briancline20:36
lifelessclarkb: so you may remember extensive discussions about auto probing back oh 8 months20:36
*** thomasbiege has quit IRC20:36
clarkbwell it might also be since it has to know bout the last run20:36
lifelessclarkb: it's hard to get /right/, the failure modes are subtle20:36
clarkbbut testr can't read the last run apparently20:36
clarkbI actually did not check if testr last works properly after testr run20:37
lifelessbadfile | subunit-1to2 | testr load ; should be enough20:37
lifelessclarkb: v1 needs to go far far away as soon as possible20:38
jeblairclarkb, fungi, mordred: quick question: are you okay with a nodepool.openstack.org host?  if so, i will spin one up and use it to develop puppet manifests (for later review)20:38
lifelessclarkb: The last thing I want to do is add more support for it anywhere20:38
*** dkliban has quit IRC20:38
*** dina_bel_ has quit IRC20:39
lifelessclarkb: if you want to avoid education, we could do 1to2 when capturing the file, so users don't need to know that the current store is v120:39
lifelessclarkb: by capturing, I mean when you copy it to storage20:39
*** adalbas has joined #openstack-infra20:40
clarkbtestr last does work correctly, so I think analyize-isolation works in the general case20:40
clarkblifeless: education is fine. I think my biggest concern right now is that there is no indication that something went wrong20:41
*** sandywalsh has joined #openstack-infra20:41
clarkbinstead it says PASS20:41
*** dprince has quit IRC20:41
mordredjeblair: yes20:42
*** jjmb has joined #openstack-infra20:42
clarkbjeblair: I left a question in that review20:42
clarkbjeblair: I am okay with nodepool.o.o20:43
mordredlifeless, clarkb why aren't we capturing in v2 anyway?20:44
mtreinishmordred: I think it's for the html results output20:45
clarkbmtreinish: that can actually handle either version20:46
mtreinishoh, ok20:46
clarkbI think it may have to do with v2 being ugly to look at as a human maybe?20:46
clarkbI do like the v1 is the default log format. It is easier on us humans20:46
clarkbbut v2 isn't so bad that I can't see switching to it everywhere20:46
mgagnewhat OS/version is running on git.o.o ?20:49
lifelessI just haven't inished the internal migration sufficiently to move the backend to 220:49
lifelessouch, HTF did I do that.20:49
clarkbmgagne: CentOS 6.420:49
mgagneclarkb: thanks20:49
mordredpleia2: do you know if there is a way to make 'tree' the default think I git when I go to https://git.openstack.org/cgit/openstack/keystone ?20:52
mrmartinguys: I have this review: https://review.openstack.org/#/c/42007/ but no email notification was arrived to my inbox. Do I need to setup something else in the project to receive notifications about new patches?20:53
jeblairmrmartin: check out https://review.openstack.org/#/settings/projects20:53
clarkband by default you don't get mail that would be generated by yourself20:53
clarkbthere is a check box somewhere to change that under settings20:54
mrmartinclarkb: ok, thanks20:54
clarkbjeblair: did you see my comments on 42003?20:54
*** jtzl has quit IRC20:54
jeblairclarkb: yes, am about to respond20:54
mrmartinand when I commit a new patch, do I need to always add myself as a reviewer?20:54
clarkbmrmartin: you do not need to add yourself as a reviewer if you watch the project20:55
mgagnemordred: what would be the link to go back to summary if that link is tree by default?20:55
mordredmgagne: hrm. I'm not sure20:55
clarkbmrmartin: and I think you are automatically added to the list of people hwne it is your own change20:55
*** jtzl has joined #openstack-infra20:55
mrmartinclarkb: yeah, I thought the same, but not happened20:55
mordredmgagne: I should probably just get used to it I guess20:56
mrmartinclarkb: I try to tune the project watch settings20:56
mgagnemordred: it's not that I don't agree with you =)20:56
mordredmgagne: yeah - I think it's funny - pretty much everyone decides to show you something other than the files as the primary view20:56
mordredlaunchpad, bitbucket, gitorious, cgit20:57
mordredgithub is like the only one that starts from a tree view20:57
mgagnemordred: tell me about it, add gitlab to the list20:57
*** ArxCruz has quit IRC20:57
mordredexcept, almost without exception, the _only_ reason I go to a repo in a web browser is to, you guessed it, browse the files20:57
mgagnemordred: they feel "activities" are most important than files themselves20:57
jeblairclarkb: responded; thanks.20:58
*** rfolco has quit IRC20:58
*** briancline has quit IRC20:58
mordredmgagne: yup. except there is no workflow in cgit - it's just a browser - and "what tags are there" is a less frequent question than "what's in the requirements.txt of that project"20:58
*** jjmb has quit IRC20:59
mordredthey've already got a branch dropdown - if they'd add a tag dropdown, I believe the summary page could actually just go away20:59
*** dkliban has joined #openstack-infra20:59
mgagnemordred: top feedback for gitlab: http://feedback.gitlab.com/forums/176466-general/suggestions/3907476-add-readme-to-project-home-view-or-make-files-t "we think the activity feed is the most important view for frequent visitors to the project"20:59
mordredmgagne: funny. none of the visitors to the project seem to agree21:00
mgagnemordred: IMO, he is wrong and should open his eyes to the reality of the users21:00
mgagnemordred: tell me about it, I got totally turned off by this answer and moved to an other git repo manager21:01
mordredmgagne:21:01
mordred:)21:01
mordredthat's ok - we asked github a question back in the early days, they told us they didnt' care, we went elsewhere21:02
mgagnemordred: =)21:02
*** woodspa has quit IRC21:03
openstackgerritJames E. Blair proposed a change to openstack-infra/gearman-plugin: Use more fine-grained synchronization in GearmanProxy  https://review.openstack.org/4200321:04
jeblairclarkb, mordred: ^21:04
clarkblooking21:05
jeblairi guess the thread member should have the same kind of synch around it, huh?21:06
jeblairclarkb: yeah, let me refine that a little more21:08
openstackgerritJames E. Blair proposed a change to openstack-infra/gearman-plugin: Use more fine-grained synchronization in GearmanProxy  https://review.openstack.org/4200321:11
jeblairclarkb: ok, so if we combine what i just did with your idea, then i think we have protection for .thread and .worker  ^21:11
*** changbl has quit IRC21:12
mtreinishclarkb, jeblair: is there a good way to pull stats from zuul. Like if I wanted to know how many runs of a certain job succeed on the gate pipeline in an interval.21:13
jeblairmtreinish: i think those are the graphite keys you were looking at earlier?21:14
mtreinishjeblair: but is there a way to pull the raw number from graphite?21:14
jeblairmtreinish: oh, yeah, i think you can form a json graphite url...21:15
jeblairmtreinish: can you paste the graph url you were looking at earlier?21:15
mtreinishjeblair: this one: https://tinyurl.com/pdfz93l21:15
mtreinish?21:15
jeblairmtreinish: http://graphite.openstack.org/render/?from=-24hour&until=-0hour&target=stats.zuul.pipeline.gate.job.gate-tempest-devstack-vm-testr-full.SUCCESS&format=json21:16
jeblairmtreinish: http://graphite.openstack.org/render/?from=-24hour&until=-0hour&target=summarize%28stats.zuul.pipeline.gate.job.gate-tempest-devstack-vm-testr-full.SUCCESS,%20%2724h%27%29&format=json21:17
mtreinishjeblair: ok cool thanks21:18
mgagnewith cgit, do you think we should "care" (show) about how many files/lines are modified by a commit?21:18
jeblairmgagne: tentatively, yes? unless there's a good reason not to?21:19
jeblairmgagne: are you thinking about the Lines column in the log view?21:19
mgagnejeblair: yes21:19
mgagnejeblair: mostly motivating by the desire to unclutter the UI21:19
*** pcm__ has quit IRC21:20
*** thomasbiege has joined #openstack-infra21:20
jeblairmgagne: ok, yeah, i could be convinced that's not useful.  it seems rare that you'd chose to look at a commit because of the number of lines changed.21:21
jeblair(and if that's what you are doing, perhaps a more specialized tool is appropriate)21:21
mtreinishjeblair: do you know how it is counting? because it goes from ~.0333 to ~.91666 which shows the increase in successful jobs but not how many more (or least not in a raw count)?21:21
*** thomasbiege has quit IRC21:23
jeblairmtreinish: http://graphite.openstack.org/render/?from=-24hour&until=-0hour&target=hitcount%28stats.zuul.pipeline.gate.job.gate-tempest-devstack-vm-testr-full.SUCCESS,%20%2724h%27%29&format=json21:24
jeblairmtreinish: does that do what you want?  you probably want to double check that.21:24
mtreinishjeblair: yeah that's it. I really need to read the graphite docs now21:25
mtreinishjeblair: it seems like a reasonable number21:25
*** alexpilotti_ has joined #openstack-infra21:26
*** fbo_away is now known as fbo21:27
*** alexpilotti has quit IRC21:29
*** alexpilotti_ is now known as alexpilotti21:29
mordredjeblair: in stopAll() - what's the point of doing stopHandles = new ArrayList<AbstractWorkerThread>(); right before the sync block where you do stopHandles = new ArrayList<AbstractWorkerThread>(gmwtHandles); ?21:30
*** thomasbiege has joined #openstack-infra21:31
clarkbjeblair: and with thread.start() within the synchronized block should the stops move into the synchronized blocks as well?21:31
jeblairmtreinish: i changed it to include all pipelines for the past 1350 minutes, and got 279 runs; the current zuul log says 274 runs; that's fairly close (there could still be a little time skew i'm not accounting for)21:31
jeblairmtreinish: (the zuul log doesn't make grepping by pipeline easy)21:31
jeblairmordred: that does seem pointless.21:32
mordredjeblair: also probably harmless21:33
*** alexpilotti has quit IRC21:34
jeblairclarkb: so i'm counting on ewt.start not actually doing any work (it just spawns a Thread); but having it in the sync block means you can't stop it until run has been set and a thread object exists21:34
jeblairclarkb: (you can't stop it because you can't retrieve it from gewthandles)21:35
jeblairclarkb: but stop could take a while and actually execute real code, so i'd rather not have it in the sync block21:35
*** alexpilotti has joined #openstack-infra21:35
jeblairclarkb: (but i think we should also probably move the management worker start into its sync block)21:36
* fungi returns21:37
fungiahh, scrollback21:37
clarkbjeblair: gotcha that makes sense to me21:37
clarkbfungi: hahahaha21:37
mordredwoot21:37
*** sarob has quit IRC21:37
*** sarob has joined #openstack-infra21:38
clarkbjeblair: however tests do not pass with patchset 321:38
clarkbI wonder if the tests have bad assumptions about the order of things now that the locking is slightly changed21:38
* fungi so far... likes mgagne's openstack cgit skin!21:38
mordredfungi, clarkb: if you're bored, you could look at https://review.openstack.org/#/c/41215/21:39
*** rcleere has joined #openstack-infra21:39
clarkbI am super bord /sarcasm :) I did get the current iteration of the mysql backup stuff working on etherpad-dev thouhg21:39
*** dina_belova has joined #openstack-infra21:40
clarkbif folks want to review those changes I can apply to them to etherpad.o.o as well then we can start looking at backing up all of the other mysql servers21:40
mordredclarkb: oh yeah - I'll go review them now21:40
openstackgerritMathieu Gagné proposed a change to openstack-infra/config: Cleanup cgit interface  https://review.openstack.org/4201621:40
fungiclarkb: third half. nice21:41
*** sarob has quit IRC21:42
*** mriedem has quit IRC21:42
mordredclarkb: +221:43
*** dina_belova has quit IRC21:44
clarkbfungi: I didn't realize the pie had that many slices, but it was too late to give up on halves :)21:44
*** jhesketh has joined #openstack-infra21:44
*** thomasbiege has quit IRC21:46
*** pabelanger has joined #openstack-infra21:47
openstackgerritJames E. Blair proposed a change to openstack-infra/gearman-plugin: Use more fine-grained synchronization in GearmanProxy  https://review.openstack.org/4200321:50
*** dina_belova has joined #openstack-infra21:50
jeblairclarkb, mordred: ^ with the change i mentioned and passing tests21:50
mordredjeblair: I think passing tests are an overrated luxury21:50
mordredholy crap - that's many more files21:51
mgagnewould people be interested in source highlight in cgit?21:52
mordredmgagne: I think so - I think they're used to it everywhere else21:52
*** rcleere has quit IRC21:52
lifelesswhere to pip bugs go?21:52
lifelessbah21:52
*** sarob has joined #openstack-infra21:52
lifelesswhere do pip bugs go ? I ended up looking into pip cache safety, and it's not concurrency safe.21:52
lifelesswould like to capture that for upstream.21:52
lifelessdstufft: ^21:52
dstufftgithub.com/pypa/pip21:53
lifelessthanks21:53
mgagnemordred: highlight seems to be the "default" proposed tool to do highlight. I will propose pygments instead which is used by github and support more languages21:53
mordredmgagne: yah. we use pygments for paste.o.o too21:54
openstackgerritA change was merged to openstack-dev/pbr: Fixes issue with command escaping on Windows  https://review.openstack.org/4128321:54
openstackgerritA change was merged to openstack-dev/pbr: Stop checking periods in commit messages  https://review.openstack.org/4083821:54
mordredalexpilotti: ^^21:54
mordredalexpilotti: as soon as the next two land, I will cut a new release for you21:54
alexpilottimordred: sorry, I just got reconnected21:55
*** dina_belova has quit IRC21:55
*** rnirmal has quit IRC21:56
openstackgerritA change was merged to openstack-dev/pbr: Fix python-ldap mirroring.  https://review.openstack.org/4073221:57
mordredcome on baby. you can do one more21:57
fungijeblair: still churning through scrollback, but a nodepool.o.o fqdn seems fime21:57
fungifine21:57
mordredI think it seems fime too21:57
mtreinishjeblair: now I'm not so sure of those numbers. It shows 65 successes and 27 failures for parallel and 64 successes and 14 failures for serial.21:59
mtreinishshouldn't they be about the same21:59
jeblairmtreinish: it may have aborted some21:59
mtreinishoh ok21:59
*** anteaya has quit IRC22:00
*** alexpilotti_ has joined #openstack-infra22:01
*** alexpilotti has quit IRC22:02
*** vipul is now known as vipul-away22:03
*** emagana has quit IRC22:03
marunI'm curious - are some projects simply not configured to update launchpad bug status from gerrit events?22:03
*** datsun180b has quit IRC22:04
clarkbmarun: yes22:04
clarkbhowever that is mostly stackforge projects. all openstack/* projects should work just fine22:05
clarkbthough we occasionally find one that doesn't have the correct user in the bug driver group22:05
marunclarkb: Is devstack an exception?22:05
clarkbmarun: do you have a specific example?22:05
*** alexpilotti has joined #openstack-infra22:05
*** alexpilotti_ has quit IRC22:05
*** burt has quit IRC22:05
clarkbmarun: devstack shouldn't be. can you link to a change that isn't doing the right bug stuff?22:05
marunwill do22:05
marunhttps://review.openstack.org/#/c/41270/22:05
marunThis was submitted on sunday and merged yesterday.22:06
*** dkliban has quit IRC22:06
marunNo automatic updates to the bug status that I can see.22:06
marunhttps://bugs.launchpad.net/devstack/+bug/121066422:06
uvirtbotLaunchpad bug 1210664 in devstack "neutron can't setup basic network connnectivity in gate jobs" [Undecided,Fix released]22:06
*** mrmartin has quit IRC22:06
clarkbmarun: that commit message is using the old format22:07
marunclarkb: ah, I'm doing it wrong?22:07
openstackgerritMathieu Gagné proposed a change to openstack-infra/config: Cleanup cgit interface  https://review.openstack.org/4201622:07
clarkbmarun: yeah, I am trying to find a link to the email thread that explains it all22:07
clarkbmarun: http://lists.openstack.org/pipermail/openstack-dev/2013-August/012945.html is the thread that announced the changes22:08
clarkbmarun: http://lists.openstack.org/pipermail/openstack-dev/2013-August/013424.html is a thread asking a similar question to yours22:08
Alex_Gaynorwowa, are we really out of devstack nodes, not sure I've seen that before22:09
*** alexpilotti has quit IRC22:09
*** vipul-away is now known as vipul22:09
*** weshay has quit IRC22:09
clarkbjeblair: are we running on one jenkins right now?22:09
marunclarkb: not that it's your responsibility, but this new implementation is a usability fail.22:09
*** wannatest has joined #openstack-infra22:10
clarkbmarun: how so? this was proposed back in san diego as a usability win22:10
clarkband it was brought up again in portland iirc22:10
marunclarkb: all he had to do was allow 'bug xyz' as well as 'bug #xyz' and the old functionality would have continued to work22:10
fungimarun: mostly, it's the fact that "fixes" doesn't come at the beginning of a line and is preceded by * so the backwards-compat regex in the new matching doesn't catch it, but yeah use the new style headers in the future and rejoice22:10
*** acabrera has joined #openstack-infra22:10
*** acabrera has left #openstack-infra22:10
marunfungi: fair enough22:11
*** jerryz has quit IRC22:12
zarojeblair: not sure if this related to the latest patch, but i'm seeing lost jobs.22:12
jeblairzaro: where?22:12
fungii am pleased enough that we can now differentiate complete, partial and related bug references in commit messages that i can personally cope with the minor change in workflow22:13
jeblairclarkb: yes22:13
*** mkirk_ has joined #openstack-infra22:13
jeblairzaro: the word "LOST" does not appear on the zuul status page22:14
zarojeblair: when i run i see all of the jobs i submitted go on the gearman queue but not all of them get run by jenkins.22:14
*** alexpilotti has joined #openstack-infra22:14
*** mrodden has quit IRC22:14
zarojeblair: it seems like gearman will passes out number of jobs equal to the number of available workers to run them.  then it doesn't run anymore jobs that are on the queue.22:15
zarojeblair: i am still using the C gearman server ver 1.1.7, could that be the problem?22:16
*** alexpilotti has quit IRC22:16
*** alexpilotti has joined #openstack-infra22:16
openstackgerritA change was merged to openstack-infra/gearman-plugin: Use more fine-grained synchronization in GearmanProxy  https://review.openstack.org/4200322:16
*** alexpilotti has quit IRC22:19
*** sarob_ has joined #openstack-infra22:20
jeblairzaro: i am unable to replicate that.  can you be more specific about how many jobs you are running, when, and how may executors are available to run them?22:20
jeblairzaro: or try again with geard?22:20
*** gyee has quit IRC22:21
zarojeblair: sorry about that. i have a problem with the way i was submitting jobs in my client.22:22
jeblairzaro: https://jenkins01.openstack.org/job/gearman-plugin-hpi-artifact/3/console22:23
*** sarob has quit IRC22:24
fungidstufft: now you're taunting rubygems people on oss-security. you know they're new to this whole internet thing... be gentle ;)22:24
* Alex_Gaynor goes to find oss-security and popcorn22:24
jeblairzaro: 2013-08-14 22:19:28.323 | [EnvInject] - Unset unresolved 'PROJECT_VER' variable.22:24
*** sarob_ has quit IRC22:24
jeblairzaro: that doesn't make much sense to me.22:25
*** blamar has quit IRC22:25
dstufftfungi: oh I wasn't actually :] I was just trying to say that pip has a CVE for the same thing so it probably makes sense to assign one, and making sure that they actually verify TLS and don't just use HTTPS w/o verifying since that's barely better than HTTP22:25
fungiAlex_Gaynor: though network security news of the week is that windows ping-of-death has returned wearing a cloak of ipv622:25
zarojeblair: looking into it.22:26
Alex_Gaynordstufft: can we have cert pinning for pip and pypi?22:26
fungidstufft: yes, i agree that their fix is almost certainly too premature to be useful to their community22:26
dstufftAlex_Gaynor: It's on my list22:26
Alex_Gaynordstufft: <322:26
mordreddstufft: what about pnies. can we have pnies?22:26
Alex_Gaynormordred: I have a pony on my desk22:27
fungiAlex_Gaynor: dstufft: definitely. i don't want to trust joe ca, bait and tackle with verifying my pypi downloads any longer than needed22:27
dstufftAlex_Gaynor: Ideally I want to see if there's something that can be done generically so people can pin certs other than PyPI too. But worst case we'll just hardcode in the CA or something22:27
dstufftI need to talk to Noah and probably fastly to make sure we can count on them using digicert22:27
openstackgerritClark Boylan proposed a change to openstack-infra/config: Switch etherpad_lite backups to mysql_backup.  https://review.openstack.org/4179122:28
openstackgerritClark Boylan proposed a change to openstack-infra/config: Add new mysql_backup module.  https://review.openstack.org/4179022:28
clarkbfungi: ^ addressed your comments, thanks22:28
*** _TheDodd_ has quit IRC22:29
fungidstufft: something in .pip/pip.conf which overrides the verification ca directory or cert would be great22:29
dstufftfungi: you can already use your own ca bundle22:29
fungidstufft: wfm then22:29
mordreddstufft: also, can I use pip to install ruby gems?22:30
*** ^d has quit IRC22:30
mordredwhat about dbs?22:30
mordreddebs22:30
mordreddamn keyboard22:30
clarkbmordred: so I am about to say something that I may regret. I think the tools around gems are better than pip22:30
dstufftI forget the exact command for it, but it should be settable via cli flag, env var, or conf file22:30
jeblairrestarting jenkins0222:30
clarkbbut virtualenv is better than whatever they use22:30
fungidstufft: though also being able to treat a single public cert as the ca bundle to match a remote server would be great22:30
clarkbnow I need to go wash my mouth out or otherwise punish myself22:30
fungidstufft: meaning, "signed by or actually being the same as this cert"22:31
* mordred admonishes clarkb22:31
clarkbmordred: because they get dependency resolution correct22:31
mordredclarkb: dstufft is working on that22:31
dstufftfungi: should be able to make a single cert bundle, we just pass that shit into OpenSSL22:31
dstufftclarkb: I'm learning how to write  SAT solver22:31
fungidstufft: then what else is needed for pinning?22:31
*** vipul is now known as vipul-away22:31
dstufftfungi: to handle it for random people automatically22:31
mordreddstufft: I hear lifeless may have spent some time in a former life thinking about dependency graphs, btw...22:32
mordreddstufft: in python22:32
fungidstufft: ahh, so providing a default which is neither "all the ca certs you have in /etc/ssl" nor "whatever i find on the server"22:32
Alex_Gaynorformer lives are the best lives22:32
fungiAlex_Gaynor: none of my former lives are better than this one22:33
clarkbmordred: there is a dependency graph solver thin in testr/testools/subunit I forget which22:33
clarkbbut it doesn't deal with ranges which is where SAT comes in iirc22:33
mordredyah22:33
mordreddstufft: also, I keep forgetting - what's the story with markerlib and pip?22:33
mordreddstufft: is it that there is no story if I do pip install -r requirements.txt - but there is a way to make it consume the information if it's in install_requires?22:34
dstufftfungi: basically pip is used for sites other than PyPI itself so we want to encourage people to use TLS and making that easier by shipping with a sane ca bundle is a generally good thing, but to make PyPI more secure we want to pin PyPI's cert. But we need to make sure we can trust that it will be digicert for the foreseable future, and that we don't lock out other servers from using other certs22:34
dstufftmordred: requirements.txt doesn't support anything like markerlib correct22:35
fungidstufft: ahh, digicert better live up to your expectations then ;)22:35
jeblairthis is a job for dnssec22:35
openstackgerritClark Boylan proposed a change to openstack-infra/config: Switch etherpad_lite backups to mysql_backup.  https://review.openstack.org/4179122:35
fungijeblair: i couldn't agree more22:35
dstufftDNSSEC you just trust someone different than the CA's22:35
clarkb^ last one assuming that doesn't do anything crazy22:35
uvirtbotclarkb: (last [--{from,in,on,with,without,regexp} <value>] [--nolimit]) -- Returns the last message matching the given criteria. --from requires a nick from whom the message came; --in requires a channel the message was sent to; --on requires a network the message was sent on; --with requires some string that had to be in the message; --regexp requires a regular expression the message must match; --nolimit returns (1 more message)22:35
clarkbsorry uvirtbot22:35
*** markmcclain has quit IRC22:36
fungijeblair: i will trust the isc farther than i can kick any commercial ca22:36
dstufftit just moves the problem, doesn't actually solve it :V22:36
*** markmcclain has joined #openstack-infra22:36
jeblair^ last sorry22:37
uvirtbotjeblair: (last [--{from,in,on,with,without,regexp} <value>] [--nolimit]) -- Returns the last message matching the given criteria. --from requires a nick from whom the message came; --in requires a channel the message was sent to; --on requires a network the message was sent on; --with requires some string that had to be in the message; --regexp requires a regular expression the message must match; --nolimit returns (1 more message)22:37
clarkbjeblair: you did it too :)22:37
jeblair^ last --with sorry22:37
uvirtbotjeblair: [22:37:12] <jeblair> ^ last sorry22:37
fungijeblair: soren won't like you hacking his 'bot22:38
jeblairi'm excited.  i actually learned a uvirtbot command22:38
mordredwiw22:38
mordredyeah22:38
fungiheh22:38
mordredI like that a lot22:38
jeblairit might even be useful22:38
dstufftfungi: jeblair We use DynEct at PSF so we should have DNSSEC capabilities, need to figure out a way to get it into pip when the network stack pip is running on might not support it22:38
mordred^ last from soren22:38
uvirtbotmordred: (last [--{from,in,on,with,without,regexp} <value>] [--nolimit]) -- Returns the last message matching the given criteria. --from requires a nick from whom the message came; --in requires a channel the message was sent to; --on requires a network the message was sent on; --with requires some string that had to be in the message; --regexp requires a regular expression the message must match; --nolimit returns (1 more message)22:38
jeblair^ last --from soren22:39
uvirtbotjeblair: Error: I couldn't find a message matching that criteria in my history of 1000 messages.22:39
jeblairaww that is sad22:39
mordredit is sad22:39
clarkbonly 1000 messages. I talk to much for that buffer22:39
mordredyah22:39
fungidstufft: that is a problem for the future. everyone should be supporting dnssec recursion by the time you have a good answer, right?22:39
zarojeblair: i think build problem is a intermittent bug with the jenkins plugin.22:39
zarojeblair: for the same patch 4200322:39
jeblairzaro: what?22:40
zarojeblair: jenkins run for patch #1 did not set env correctly, #3 worked correctly, then last one didn't work.22:40
fungianyway, i trust the former bsd greybeards at isc way more than netsol/verisign/symantec, so hedging my bets on dnssec22:40
*** vipul-away is now known as vipul22:41
jeblairzaro: ah, you mean it shows up in the gate-build job too. i agree22:41
zarojeblair: actually the good and bad runs are on different precise slaves.  so it might be puppet not getting updated?22:42
jeblairzaro: very possible; can you give me a good and bad slave?22:42
*** pentameter has quit IRC22:43
zarojeblair: bad one was precise5, good one is precise1522:43
jeblairzaro: /usr/local/jenkins/slave_scripts/maven-properties.sh is the same on both22:45
*** ryanpetrello has quit IRC22:45
zarojeblair: can we manually run same build on precise5?22:45
lifelessdstufft: mordred: I have spent a ridiculous amount of time with dependency graphs22:46
jeblairzaro: not easily.  do you think that the first build on a host fails?22:47
zarojeblair: don't think so because it failed to set the env twice on precise15.22:48
*** changbl has joined #openstack-infra22:48
jeblairzaro: how are the variables supposed to be injected?  i only see that that script is called; but that's not supposed to set variables.22:48
zarojeblair: the jenkins run on patch set 3 and #4 both ran on precise1522:49
zarojeblair: vars injected with wrapper22:49
jeblairzaro: perhaps only the first one succeeds?22:49
zarojeblair: vars injected with wrapper '-inject'22:49
zarojeblair: it's in jenkins-plugin-jobs.yaml22:49
zarojeblair: first one?22:50
*** prad_ has quit IRC22:50
dstufftlifeless: heh, my current thoughts are using a SAT solver, but I'm learning about them first :]22:50
*** dina_belova has joined #openstack-infra22:50
marunlifeless: for tempest, tox now uses testtools instead of nose, but on rhel64 (py26) testtools complains that without py27 the discover module must be installed.22:50
marunlifeless: is there any reason not to add discovery to tempest's list of dependencies so py26 'just works'?22:51
clarkbmarun: add discover to the test-requirements or requirements22:51
clarkbmarun: there isn't we should be doing this for all of the othe rprojects too22:51
mordredmarun: yeah. we have discover in the test-requirements.txt in several projects22:51
clarkbhowever22:51
mordredI do not fully understand why it is needed but anecdotally, it is22:51
jeblairzaro: when i look in the web interface, i only see the script file path, not the prorperties file path.22:51
clarkbtempest + testr + py26 won't get along in all causes due to setUpClass aiui22:52
marunclarkb: are you telling me testr is now broken on rhel64?!?!?!22:52
clarkbmarun: yes22:52
marun<unprintable>22:52
clarkband not now, always has been22:52
zarojeblair: which web ui?22:52
jeblairzaro: jenkins22:52
marunclarkb: Was anyone from redhat cognizant of this fact?22:53
mordredclarkb: didn't mtreinish fix that?22:53
marunclarkb: because that seems like a pretty huge foobar.22:53
clarkbmarun: we have avoided this issue by not using setUpClass because setUpClass is extremely broken22:53
jeblairzaro: can you look into fixing this?  you may want to set up a jenkins server, with a slave, and use jjb.22:53
clarkbmarun: its not a fubar22:53
zarojeblair: ohh yes, it's because there are two instacnes of '-inject' in the jjb job.22:53
clarkbmarun: setUpClass is bad bad bad, don't use it22:53
zarojeblair: only one will appear on the UI.22:53
*** jerryz has joined #openstack-infra22:53
marunclarkb: I'm confused.22:53
*** ^d has joined #openstack-infra22:53
jeblairzaro: pretty sure that means it's broken22:53
clarkbmarun: it doesn't work properly with nose either, so nose was also broken22:53
marunclarkb: is or is tempest not broken right now?22:53
*** ^d has quit IRC22:53
*** ^d has joined #openstack-infra22:53
marun(on py26)22:54
clarkbtempest + testr + py26 does not quite work right22:54
clarkbin theory tempest + nose + py26 mostly works but the issue is around setUpClass which nose does not do properly22:54
clarkbso the same bits of code were always broken, the severity of brokeness is changing22:54
marunclarkb: Tempest was working fine with nose as of 2 weeks ago, but I don't run the full suite.22:54
*** dina_belova has quit IRC22:55
jeblairzaro: that could be why it didn't work.22:55
marunclarkb: What symptoms can I expect trying py26 + testr?22:55
clarkbmarun: nose + setUpClass breaks around failures22:55
zarojeblair: ok. i thought that maybe we could set multiple instances of a jenkins plugin in jjb. but i guess it's not reliable.22:55
Alex_Gaynormtreinish: FWIW the numbers might be slightly off about testr parallel stuff right now, there's some horizon/tempest issues which is causing a ton of failures :(22:55
jeblairzaro: i would not do anything that the web ui doesn't let you do.22:55
clarkbmarun: anything that depends on a setUpClass to prep things will probably fail22:55
clarkbmarun: because testr will not run setUpClass under py2622:55
zarojeblair: dangit! will fix.22:56
marunclarkb: *sigh*22:56
jeblairzaro: if there's no other way to deal with it, i'd consider making the job a freestyle job and run maven directly22:56
clarkbso instead of seeing brokeness occasionally you will get it 100% of the time22:56
marunclarkb: well, I appreciate the insight22:56
mordredclarkb, marun: I believe the suggestion for fixing that was "put code in the setupClass into a fixture, but have the setupclass load the fixture"22:56
mtreinishAlex_Gaynor: yeah I noticed that I'm working on a way to get accurate stats right now.22:56
clarkbmordred: that won't fix it22:56
zarojeblair: cool.  i suggested that to clarkb but he was resistant.22:56
mordredclarkb, marun: then add a testresources for the class, which only testr will run22:57
lifelessmarun: you should add discover yes, but it's not a complete answer22:57
mordredand not nose22:57
clarkbmordred: you need something else to load the fixture because setUpClass is not run by py26 unittest22:57
Alex_Gaynormtreinish: I would have suggseted yelling at horizon people people as a solution, but I guess better stats is a reasonable approach22:57
mtreinishAlex_Gaynor: it's hard to filter out a random failure that's not parallel specific but occurs randomly on a parallel run22:57
clarkbmordred: or that22:57
mtreinishAlex_Gaynor: the yelling will come tomorrow22:57
marunlifeless: I'm mainly wanting to keep the quantum smoke test running.  Sounds like I need to update to testfixture asap.22:57
clarkbbut we erally need to get off ot he setUpClass crutch and stop acting like it wasn't already broken22:57
mordredright. and _then_ we can start pulling the setupcalsses out22:57
mtreinishAlex_Gaynor: right now I'm going to go home for the day22:57
Alex_Gaynormtreinish: night, enjoy22:58
jeblairputting jenkins01 in shutdown mode22:58
clarkbmtreinish: ftr nose + setUpClass is broken in some cases where setUpClass will throw and exception, nose will then skip all tests in that class and report success22:58
clarkbmarun: ^22:58
jeblairand jenkins.o.o22:58
marunclarkb: Sure, that's easy to fix though.22:58
clarkbmarun: it should report failure but doesn't22:58
clarkbmarun: it is?22:58
marunclarkb: add error handling to setupClass22:58
marunclarkb: No thrown exception, nose doesn't lose it's shit.22:59
mordredor stop using setupclass :)22:59
clarkbmarun: but then no tests run and you report success22:59
clarkbmarun: you need some way of getting nose to die gracefully and report failure22:59
clarkbthere doesn't seem to be a way to do that22:59
clarkbwithout fixing nose because their setUpClass stuff is a hack22:59
dstufftpytest!22:59
dstufft:]23:00
dstufft(because the solution to a problem in tool a is switch to tool b you see)23:00
mordredmarun: https://pypi.python.org/pypi/fixtures + https://pypi.python.org/pypi/testresources23:00
marunclarkb: From one hack to another, merrily we go...23:00
clarkbdstufft: when tool a is no longer maintained...23:00
clarkbmarun: there is no hack in the new stuff :) it just properly doesn't work23:00
mordreddstufft: or - just actually finish the current migration :)23:00
mordreddstufft: :)23:00
marunclarkb: sure, keep telling yourself ;)23:00
mordredgah23:00
clarkbmarun: all that said, fixtures + testresources is so much better23:01
mordredLAG LAG LAG NETWORK23:01
dstufftmordred: :D23:01
marunclarkb: I like it, don't get me wrong.  but it's not free.  It is necessarily more complicated.23:01
marunThe price of progress.23:01
clarkbis it more complicated?23:01
marunOne more api to learn23:01
clarkbI ported all of nova's unittests without any prior nova unittest knowledge.23:02
marun*sigh*23:02
marunI'm just getting worn out keeping up with all these infra changes and it makes it hard to get real work done.23:02
marun /rant23:02
lifelessdstufft: what problem are you solving ?23:02
marunbad choice of words, though.  real == stuff i have to do.23:03
*** danger_fo is now known as danger_fo_away23:03
clarkbmarun: it is fair that it is a new api and that requires some amount of learning. My experience learning them has been that you get better tests because the tools are simpler not more complicated23:03
dstufftlifeless: Given a set of version constraints and a set of available versions find out which versions can be installed to satisfy all the constraints23:04
clarkbthe cost is >023:04
clarkbbut the long term cost is far less than dragging along the brokeness that we have/had23:04
dstufftlifeless: trivially written is a boolean expression afaict23:04
dstufftas a*23:04
marunclarkb: i just wear too many hats (neutron, tempest, rh) and do all of them poorly as you can tell.23:04
pleia2goes through massive patch and leaves comments on wrong set \o/23:04
dstufftlifeless: https://gist.github.com/dstufft/86ee27f147e53e19fc6623:04
clarkbpleia2: the worst part is when new patchset is pushed just before you leave your comments ;)23:05
pleia2clarkb: yeah23:05
mordredmarun: you wear them great23:05
lifelessdstufft: ok, so 'what to install' :>23:05
jeblairjenkins, jenkins-dev, and jenkins02 have all been upgraded to ${project-version} of gearman-plugin23:05
jeblairyay.23:05
clarkbjeblair: woot23:06
lifelessdstufft: have you thought about how that interacts with incremental discovery ?23:06
mordredjeblair: yay!23:06
mordredjeblair: my favorite version!23:06
lifelessdstufft: by which I mean pip's basically recursing at the moment to build an egg etc23:07
dstufftlifeless: the paper i'm reading is for an incremental SAT solver, so as more version specs are found I can add additional constraints efficiently resolve the problem, and see if there are new things I need to download23:08
dstufftso it'd still do recursing for right now, until the new API is done on PyPI which allows querying that info23:09
dstufft(and new packaging formats)23:09
lifelessdstufft: I'm thinking about 'install version A, then find A is blacklisted'23:09
dstufftlifeless: pip doesn't install anything until after all the dependencies are resolved23:09
dstufftit jsut downloads them and runs egg-info23:09
lifelessdstufft: oh23:09
lifelessdstufft: so setup_requires isn't pip managed23:09
marunlifeless: how best to conditionally skip a test class using testr?  The standard nose-centric way in tempest is to use a check in setupClass.23:10
mordredyeah. setup_requires is a little bitch23:10
dstufftlifeless: correct. Although I have plans to make it pip managed, but setup_requires aren't globally installed they are installed only for that invocation and I want to make it pip controlled and available only to the package that setup_require'd it23:10
*** dhellmann is now known as dhellmann_23:10
lifelessmarun: put a check at the top of setUp if you want it to affect every test23:11
marunlifeless: so instead of per-class it becomes per-method?23:11
dstufftI was talking with jaraco (Setuptools maintainer) the other day about making a sort of setup.py.py egg-info --setup-requires which will just give you the setup requires and won't install anything23:11
lifelessmarun: it always is per method23:11
lifelessmarun: the shim that makes it look per class in nose is a lie23:12
dstufftso pip can go get them23:12
lifelessdstufft: please god please23:12
mordreddstufft: O M G +100023:12
marunlifeless: Fair enough.  And if the check is expensive (check if neutron is reachable), would you suggest a way to cache that result for future checks?23:12
lifelessdstufft: I /so/ want run-mirror to not have to install stuff to build a targeted mirror23:12
lifelessmarun: you can stash a variable on the class trivially23:13
marunlifeless: ok23:13
lifelessmarun: or use a TestResource23:13
mordreddstufft: what can I do to to help that?23:13
*** dnavale has joined #openstack-infra23:13
dstufftlifeless: pip will still need to sort of install stuff (because the point of setup_requires is that they can change how setup.py is interpreted), but it will just install it to a temporary directory which is only made available to the setup.py that requested it23:13
lifelessdstufft: so yes incremental SAT sounds like a good approach23:14
dstufftmordred: I need to make a patch against setuptools and pip to verify it will work, but jaraco seemed amiable to adding it23:14
jeblairmordred: have you reviewed 38177 yet?23:14
lifelessmordred: something odd with https://review.openstack.org/#/q/status:open+project:openstack-dev/pbr,n,z23:15
mordredlifeless: what?23:15
dstufftAlso amiable to pulling pkg_resources out of setuptools so projects that use entry points can jsut depend on pkg_resources, which is one of the major blockers to making setuptools not a required dependency of pip23:15
mordredjeblair: I wrote 3817723:16
jeblairmordred: i know.23:16
lifelessmordred: oh, I loaded it at the wrong time; its fine :)23:16
jeblairmordred: it looks like the output of a search and replace.  several people have pointed out obivous errors in it already.  i started reviewing it and found some as well.23:16
jeblairmordred: i just want to know if you've reviewed it yourself.23:16
jeblairit's a big patch and a lot of work to review.23:17
mordredjeblair: locally via git diff - but  good point - let me walk through it ttw real quick23:17
jeblairmordred: k, thx23:17
dstufftmordred: so I don't want to get anyones hopes up, but if this all works in the future we can have a pip that won't requier setuptools (so none of this setuptools breaks pip nonesense), where ``pip install`` never uses setuptools except as a build tool to actually prefer the install (like it does today) but pip always does the downloading and dependency resolver, and an actual resolver instead of "first specifier is the only specifier"23:18
dstuffts/prefer/preform/23:18
jeblairmordred: it looks like pleia2 actually just finished what i started.23:18
mordreddstufft: I would like that a lot23:18
mordredoh neat!23:18
dstufftmordred: oh, and probably pip will be available by default in Python too, possibly only 3.4+ but I'm going to try and get Linux distros and stuff to do it for all versions (if I can get them to do it at all)23:19
dstuffts/in Python/with Python/23:20
mordreddstufft: I don't want it in python by default23:20
dstufftmordred: it'll still be indendepntly upgradeable23:20
dstufftit's not getting added to the stdlib23:20
dstufftit'll just be bundled with Python (or in Linux land python and pip will depend on each other)23:20
dstufftso that if you have Python you also have pip23:20
mordreddstufft: that's how shit gets broke23:20
mordredbecause you can never fix it23:20
*** nati_ueno has quit IRC23:21
dstufftmordred: the outcome will be exactly the same as if you immediately installed pip after installing Python23:21
dstufftit will just do it for you23:21
dstuffthttps://github.com/dstufft/peps/blob/master/pip-bundling.rst <- in progress23:21
fungidstufft: i have someone asking what tool to use these days to create and update a full private pypi mirror for their company... bandersnatch or is there something better?23:23
*** dnavale has quit IRC23:24
dstufftfungi: bandersnatch will mirror PyPI23:24
dstufftit's the best tool for that ATM23:24
*** nati_ueno has joined #openstack-infra23:24
fungidstufft: perfect. i only skim distutils-sig unfortunately. your reinforcement of my recollection is much appreciated23:24
dstufftfungi: ther'es also dev-pi if they just want a caching mirror that also supports uploading private packages23:24
fungiperhaps. i'll suggest that too23:25
dstufftbandersnatch mirrors everything up front, dev-pi does it on demand23:25
dstufftI think dev-pi also caches things not hosted on PyPI so there's that too23:25
fungiahh23:25
clarkbjeblair: I just remembered. The bug that has us turnning off some compression in jenkins to avoid the runaway threads was fixed in a semi recent jenkins release which we should now be running23:26
dstuffthttps://pypi.python.org/pypi/devpi/0.9.423:26
clarkbjeblair: should we try removing the workaround from the default file?23:26
dstufftfungi: devpi actually works by having multiple indexes inside on install I believe23:26
dstufftso you have one index that's a on demand mirror of PyPI (and external things if I recall), then you have extra indexes for your own personal private repos23:26
dstuffts/repos/packages/23:26
fungihuh, neat23:27
clarkbjaypipes: subnets and networks are different :P23:27
dstufftso it depends on what they want to do exactly, but either of those should work fine23:27
*** jerryz_ has joined #openstack-infra23:27
fungidstufft: thanks again. i passed along the suggestions23:27
dstufftbandersnatch is just a more or less byte for byte copy of what's on PyPI23:27
dstufftfungi: yup np23:27
*** jerryz has quit IRC23:28
fungidstufft: yeah, bandersnatch talks about implementing pep-381 and then in turn pep-381 talks about getting permission/registering your mirror, so it was daunting (tried to explain pep-449 is ripping out the official mirrors anyway)23:28
dstufftfungi: yea 381 has both a mirroring protocol in it, and a method for registering and naming your mirror, 449 removes the latter part23:29
fungi381 shoulda been two peps in my opinion, but hindsight yadda yadda23:30
dstufftyea23:30
dstufftit's ok 449 removes part of 381, and then a future PEP will remove the other part of 38123:30
dstufftwhenever I get around to making a new mirroring protocol23:30
fungis/new/actually secure/23:31
dstufftyea basically23:31
dstufftbasically everything was broken23:31
dstufftand we're trying to inplace fix it all :V23:31
fungii followed that much of the thread. wholeheartedly approve23:31
openstackgerritMonty Taylor proposed a change to openstack-infra/config: Use cgit server instead of github for everything  https://review.openstack.org/3817723:33
*** zehicle has quit IRC23:33
*** ryanpetrello has joined #openstack-infra23:35
mordredpleia2: thanks for finding those! good point on the help blurbs - so I just completely reworked them23:37
lifelessmordred: we're still going to mirror to github right ?23:37
pleia2mordred: yeah, looks great :)23:37
pleia2lifeless: yes23:37
mordredlifeless: yes. apparently some people still think its useful for something23:38
mordredlifeless: but we're going to be able to remove more of our dependnce on it23:38
*** fbo is now known as fbo_away23:38
mordredlifeless: qI've also batted around the idea of also replicating to bitbucket, so as that we're not playing favorites23:39
mordredlifeless: but I don't think we care enough to do that yet :)23:39
lifelessmordred: meh23:40
mgagnemordred: I actually prefer browsing code using the github interface, but it's a matter of personal preference I guess23:40
jeblairclarkb, mordred: regarding mysql backups, wouldn't it be better to back all of the databases on the server rather than specifying the database name?23:41
lifelessmgagne: git clone; vim. :)23:41
mgagnelifeless: sure, when I'm on my laptop which isn't always the case unfortunately23:42
mordredjeblair: I  like the named database approach, because it will map easier to having a single backup host and a bunch of cloud databases in the future23:42
jeblairmordred: i don't see how that affects it...23:42
jeblairmordred: i'm assuming we'd get a different set of credentials for each database, yeah?23:43
mordredjeblair: yeah. good point23:43
fungimgagne: part of the goal, i think, is to get the cgit browsing experience close enough to as usable as github that you don't care so much, and then there's how much faster it runs23:43
*** vipul is now known as vipul-away23:43
*** vipul-away is now known as vipul23:43
mordredjeblair: ok, I'm down with that too23:43
*** UtahDave has quit IRC23:44
mgagnefungi: that's why I'm proposing updating the skin it sucks less =)23:44
jeblairmordred: so yeah, we'd want to say "backup gerrit" and "backup paste", but each of those would back up all of related schemas, (so "all of gerrit" and then "all of paste")23:44
mordredyup. makes sense to me23:44
fungimgagne: no argument123:44
jeblairk, will leave comment to that effect23:44
mordredmgagne: if you're a god, you could update cgit ui to have a slightly better click on line to get highligted line link - and also add support for shift-click ranges23:45
*** vipul is now known as vipul-away23:45
mordredbut you're doing a greatjob so far23:45
mgagnemordred: my C skills are a little rusty =)23:45
mordredmgagne: bah. I'm sure that's html23:45
mgagnemordred: you would be surprised23:45
clarkbjeblair: we can do it that way too23:46
*** zehicle has joined #openstack-infra23:47
jeblairjenkins01 is idle; upgrading plugin there23:47
mordredjeblair, fungi: I'm trying a new method for keeping track of reviews I need to do that clarkb and I talked about yesterday23:50
mordredI think it's super helpful so far23:50
*** dina_belova has joined #openstack-infra23:50
jeblairmordred: good.  have you added nodepool to your watched list? :)23:51
*** pcrews has quit IRC23:51
mordredyes I have - and it's also in my starred list now23:51
clarkbjeblair: for backing up everything, basicaly keep ${name} everywhere it is currently used but remove it from the mysqldump command and use the option to backup everything there?23:51
mordrednew method: use this: https://review.openstack.org/#/q/watchedby:mordred%2540inaugust.com+-label:CodeReview%253C%253D-1+-label:Verified%253C%253D-1+-label:Approved%253E%253D1++-status:workinprogress+-status:draft+-is:starred+-owner:mordred%2540inaugust.com,n,z23:51
fungimordred: using the pretty sparkly stars?23:51
mordredto browse list of things I need to review and star them23:51
fungiindeed23:51
mordredthen use https://review.openstack.org/#/q/is:starred+-label:CodeReview%253C%253D-1+-label:Verified%253C%253D-1,n,z23:52
fungistars >> ponies23:52
mordredto go through the things I need to review, and I can unstar them when I'm done with them23:52
fungii intend to try the same workflow23:52
mordredso that once my star list is depleted, I can re-assess the first list23:52
mordredhelps my ADD not get overwhelmed23:52
fungifirst i intend to finish catching up on e-mail and then fix the other things i broke. how did it get dark already?23:53
jeblairmordred: cool, i have taken notes on that and will try it.23:53
jeblairmordred: (though so far, important changes is still mostly working for me)23:53
mordredjeblair: you may want to replace the email address23:53
mordredjeblair: great!23:53
openstackgerritClark Boylan proposed a change to openstack-infra/config: Switch etherpad_lite backups to mysql_backup.  https://review.openstack.org/4179123:53
openstackgerritClark Boylan proposed a change to openstack-infra/config: Add new mysql_backup module.  https://review.openstack.org/4179023:54
clarkbjeblair: ^ that what you have in mind?23:54
jeblairjenkins01 is back up23:54
fungiyeah, i mostly stick to the important changes dashboard, but also my review throughput it very, very terrible23:54
fungiso anything to improve efficiency there is worth trying23:54
*** tjones has joined #openstack-infra23:55
*** dina_belova has quit IRC23:55
jeblairclarkb: yeah23:56
tjonesis there any way to programmatically write to etherpad or pastebin or wiki?  I want to write a cron job to generate a report which is publicly available.  I could put it in my google drive but thought i'd check here 1st…23:56
clarkbtjones: yes for pastebin. Not sure about wiki or etherpad23:57
fungitjones: mediawiki has an api, etherpad has an import capability though may require pretending to be a browser a little23:57
fungitjones: and pastebinit can deal with paste.o.o23:57
mordredclarkb: I +2d the second change - but left it un approved so you can sheperd it in23:57
jeblairtjones: i've used the mediawiki api for this page: https://wiki.openstack.org/wiki/Infrastructure_Status23:57
clarkbmordred: thanks23:58
tjonesthanks folks!23:58
fungitjones: any time!23:58
clarkbit will run the backups on etherpad dev shortly and if that looks good I will apply it to etherpad.o.o tomorrow most likely23:58
jeblairtjones: i think you would need to talk to Ryan_Lane to get an account for the wiki23:58
jeblairclarkb, fungi, mordred: i'm about to run, but with the new plugins in place (thanks for your help!), i hope to run nodepool for real tomorrow.23:59
mordredjeblair: awesome23:59
clarkb++23:59
tjonesjeblair: thx.  I'll ask him23:59
fungijeblair: i hope to review that still. thanks for all the great work!23:59

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