Thursday, 2017-11-02

SpamapShmmmm00:03
SpamapSUnable to freeze job graph: Job syntax-check-ansible does not specify a run playbook00:03
SpamapSI got that in a PR when I didn't touch that job, or its parents.00:03
SpamapSdid something change recently where we have to always specify a run: ?00:23
fungijamielennox: as noted, i'm currently en route. you australians will have to disabuse me of prior cultural misconceptions involving paul hogan and fosters "beer"00:27
jamielennoxwell the fosters we can do, i don't even know where you can buy that here00:28
jamielennoxunfortunately though everyone does look and sound pretty much like paul hogan00:29
fungibush hats and large knives abound?00:31
jlkSpamapS: I didn't think so. I thought there was an assumed run: of a playbook matching the job's name00:34
jeblairSpamapS: yes, that's changing.  always supply a run, and i'd go ahead and stick ".yaml" on it.00:34
jeblairsee "The Bonus Change" section in http://lists.openstack.org/pipermail/openstack-infra/2017-October/005634.html for background00:37
jeblair(we now support extensions, and i'd like to drop implied extensions soon, or at least before release)00:40
jeblair(i submitted 78 changes to openstack to add .yaml extensions; i'm still waiting for 32 of them to merge)00:42
ianwjeblair: i can think of a quick way to get any of the important ones to merge ;)00:51
fungiianw: well, we basically agreed in the last infra meeting (i think?) that we were not above using that "quick way" rather than let individual projects delay progress on such mass transitions01:53
fungis/wre/we're/01:53
*** xinliang has quit IRC02:13
*** xinliang has joined #zuul02:29
*** xinliang has quit IRC02:29
*** xinliang has joined #zuul02:29
*** xinliang has quit IRC02:41
*** xinliang has joined #zuul02:54
*** xinliang has quit IRC02:54
*** xinliang has joined #zuul02:54
openstackgerritAndrea Frittoli proposed openstack-infra/zuul-jobs master: Add a generic stage-output role  https://review.openstack.org/50923307:22
*** xinliang has quit IRC08:39
*** xinliang has joined #zuul08:52
*** xinliang has quit IRC08:52
*** xinliang has joined #zuul08:52
openstackgerritTobias Henkel proposed openstack-infra/nodepool feature/zuulv3: Add cloud quota handling  https://review.openstack.org/50383809:03
openstackgerritTobias Henkel proposed openstack-infra/nodepool feature/zuulv3: Don't fail on quota exceeded  https://review.openstack.org/50305109:03
openstackgerritTobias Henkel proposed openstack-infra/nodepool feature/zuulv3: Make max-servers optional  https://review.openstack.org/50428209:03
openstackgerritTobias Henkel proposed openstack-infra/nodepool feature/zuulv3: Support cores limit per pool  https://review.openstack.org/50428309:03
openstackgerritTobias Henkel proposed openstack-infra/nodepool feature/zuulv3: Support ram limit per pool  https://review.openstack.org/50428409:03
openstackgerritKrzysztof Klimonda proposed openstack-infra/zuul feature/zuulv3: [WIP] Support autoholding nodes for specific changes/refs  https://review.openstack.org/51516909:21
*** electrofelix has joined #zuul09:30
*** hashar has joined #zuul09:42
*** sambetts|afk is now known as sambetts10:20
openstackgerritKrzysztof Klimonda proposed openstack-infra/zuul feature/zuulv3: [WIP] Support autoholding nodes for specific changes/refs  https://review.openstack.org/51516910:32
*** hashar is now known as hasharCooking11:12
*** hasharCooking is now known as hasharEat11:38
*** hasharEat is now known as hashar12:16
*** jkilpatr has joined #zuul12:16
openstackgerritKrzysztof Klimonda proposed openstack-infra/zuul feature/zuulv3: [WIP] Support autoholding nodes for specific changes/refs  https://review.openstack.org/51516912:42
*** bhavik1 has joined #zuul13:03
kklimondajeblair: I've reworked my patch a bit - I'm now converting --change into ref internally and using that for autohold requests. I've not added --oldrev and --newrev yet, both because I'm not sure what they would be useful for, and I'd have to think more how to store them - definitely not as part of the key.13:05
*** bhavik1 has quit IRC13:26
kklimondaAlso, with the regex approach for refs, I can use .* to scope the requests to jobs instead of explicitly handling them.13:47
*** jkilpatr has quit IRC14:06
jlkI have no idea why my change keeps timing out :/14:12
*** jkilpatr has joined #zuul14:24
*** dkranz has joined #zuul15:03
openstackgerritJames E. Blair proposed openstack-infra/zuul feature/zuulv3: Fix gerrit branch creation detection  https://review.openstack.org/51736316:07
jeblairthat's a semi-urgent fix for an issue we're seeing in production -- it could allow folks to land untested zuul configuration changes (which would then break zuul)16:11
* SpamapS now combing through all of his zuul.yaml's adding run:'s16:31
jeblairSpamapS: do you have a lot?  i have a script that could probably be adapted in about 20 minutes.16:38
pabelangerjeblair: +3, left comment about maybe pep8 failure16:38
SpamapSjeblair: no, 15 jobs right now. Inheritance reduced that to maybe 816:38
pabelangerbut zuul hasn't run anything yet16:38
SpamapSit was mostly just that zuul stopped doing anything useful while I fell down that well ;)16:39
jeblairSpamapS: probably easier by hand then.  i'll get the script pushed up eventually anyway -- it just needs to go through one more iteration before it's not a mess16:39
SpamapSNow setting up to run my hoist CI on PR's to my local zuul fork and will stop just pulling in master from git.openstack.org.16:39
SpamapSs,master,feature/zuulv3,16:40
SpamapSthat was lazy anyway16:40
openstackgerritJames E. Blair proposed openstack-infra/zuul feature/zuulv3: Fix gerrit branch creation detection  https://review.openstack.org/51736316:40
SpamapSShould always have been testing things.16:40
jeblairpabelanger: ^ thanks :)16:40
openstackgerritDavid Shrewsbury proposed openstack-infra/nodepool feature/zuulv3: Unpause a declined request  https://review.openstack.org/51706816:42
Shrewsjeblair: change lgtm16:44
SpamapSok I really need to figure out why my zuul is ignoring comment: false16:46
* SpamapS fires up pdb16:46
SpamapSstarting to get spammy with all the success comment emails :-P16:46
Shrewsjeblair: fwiw, 517068 is something we should get in soon, too. i'm not sure what kind of havoc that could cause, but I have seen it in production as recently as yesterday16:47
jeblairShrews: havoc?!  i thought it was only chaos and agony!  you should have said something sooner!  :)16:48
Shrewsjeblair: it has escalated16:48
Shrewsplus, i discovered a thesaurus since yesterday!  :)16:49
jeblairShrews: lgtm.  nice test.  :)16:50
SpamapScry havoc!16:53
*** bhavik has joined #zuul16:58
*** bhavik has quit IRC16:59
*** hashar is now known as hasharAway17:14
openstackgerritJames E. Blair proposed openstack-infra/zuul feature/zuulv3: WIP: normalize daemon process handling  https://review.openstack.org/51738117:25
*** electrofelix has quit IRC17:44
mnaseri think i found a zuul bug?17:48
mnasermy gertty wasnt up to date and i did a recheck on a few merged checks17:48
mnaserand they're sitting in the check queue right now17:48
mnasershouldnt that recheck be ignored?17:48
SpamapSmnaser: yes17:51
mnaserSpamapS: ok cool, example of a merged change in check queue right now - 51498517:51
SpamapSmnaser: actually I think it might be a misconfigured pipeline.17:53
SpamapSmnaser: --> #openstack-infra17:53
mnaserok ill follow17:53
*** sambetts is now known as sambetts|afk17:59
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Fix gerrit branch creation detection  https://review.openstack.org/51736318:00
jlkSpamapS: I'm super duper interested in your rpdb findings.18:07
SpamapSjlk: oh! so I found that I'm a moron. ;)18:10
SpamapSjlk: I had an uncommitted PR and I wasn't looking at project-config master. ;)18:10
jlkohhh?18:10
jlkthat's... funny18:11
SpamapSSaul Goodman now18:11
jlkhowever, I think you've found that we don't have adequate debug logging in that area.18:11
SpamapSjlk: yeah, sorry for the brain draining ;)18:11
SpamapSjlk: well.... I mean... I didn't set comment.. and it wasn't logging comment.. because it was falling through to later defaults.18:11
SpamapSso I think we're OK actually18:12
SpamapSI broke you18:12
SpamapSby saying "here's the config"18:12
SpamapSand me, by believing "here's the config"18:12
SpamapSbut in fact, that was not hte config zuul saqw.18:12
SpamapSnow... on to my current problem18:12
SpamapSUnable to freeze job graph: Pre-review pipeline check does not allow post-review job test-ephemeral-service-account18:12
SpamapSI have a job whose parent uses secrets.18:13
jlkSpamapS: sure, but zuul wasn't adequately displaying what config it saw, and the debug lines weren't informative enough to validate whether it was seeing the correct config18:13
SpamapSand I'm not sure how to make the check queue run that job.18:13
jlkah18:13
jlkso it doesn't by default allow secrets to be used in pre-review pipelines (check)18:13
jlkYou've got to mark the secret as usable in pre-review18:14
SpamapShttp://paste.openstack.org/show/625378/18:14
jlkhttps://docs.openstack.org/infra/zuul/feature/zuulv3/user/config.html#secret18:15
jlkhttps://docs.openstack.org/infra/zuul/feature/zuulv3/user/config.html#attr-pipeline.post-review18:16
jlklooks like you have to define the pipeline itself as post-review18:16
jlkor rather18:16
jlkset hte job.post-review to false18:16
SpamapSI'm wondering if there's a danger there18:17
mnaserSpamapS: depends on your environment18:19
mnaserbut it means i can make a child pre-review job that does "cat $secret"18:19
SpamapSso that sounds wrong18:19
mnaserand see what the value of the secret is18:19
SpamapSsince the first paragraph claims that playbooks which override this job's playbooks don't get access to the secret18:20
SpamapS"Secrets are bound to the playbooks associated with the specific job definition where they were declared."18:20
SpamapSmnaser: I think the reason for defaulting to now allowing this is not that, but the danger that somebody will be able to publish things in a pre-check.18:20
SpamapSSo if you've made a job that uses a secret to provide a resource for any job, you can assert that with post-review: false18:21
SpamapSwhich, in my case, is OK I believe18:21
openstackgerritMerged openstack-infra/nodepool feature/zuulv3: Unpause a declined request  https://review.openstack.org/51706818:21
mnaserSpamapS: yeah you're right18:21
SpamapSbecause I'm using the secret in the pre to make a resource, and handing it to the job18:22
SpamapSand then in the post, I use the secret to delete the resource I made18:22
jlkis the playbook that uses the secret in a trusted repo?18:23
jlkis there any way somebody could propose  change to that playbook, which would in turn cause it to use the speculative future with the secret before a human can read it?18:24
SpamapSjlk: Oh yeah that's the reason the review flag is getting flipped. I need to move the job to my project-config repo.18:25
jlkor, does the use of the secret cost you any real money? Somebody could exhaust your funds by opening up a ton of pull requests that would cause the secret to be used.18:25
SpamapSactually I was going to use a semaphore to prevent it from creating too many resources. :)18:26
jlkthose are good for "too many at once", but I don't think we have anything in place for "too many total"18:26
SpamapSOnce set, the post-review attribute may not be unset18:27
SpamapSZuul isn't letting me do the wrong thing. Good job Zuul. ;)18:27
SpamapSjlk: the post deletes the resource18:27
SpamapSThe trouble I'm having here is that I kind of want to test it in check before I lock it down in project-config. :-/18:28
SpamapSso I have to like, land the code in project-config... then recheck the usage in godaddy-zuul-jobs ... pretty frustrating. I'd like to be able to turn off the safeties while I develop it.18:28
jlkSpamapS: I think I'm still talking past you. I was thinking of the Ansible case, where each job that uses a windows VM costs them a dollar or something like that.18:28
jlkso they'd want both a quota (not too many at once) and a budget (not too many over a set period of time)18:29
SpamapSah yeah18:29
SpamapSthat's a different thing18:29
jlk"may not be unset" ? maybe not live, but certainly with a restart it can be unset :D18:29
SpamapSI can do bazillions of these.18:29
SpamapSI was hoping I could set post-review: false on the job where I declare the secret.18:30
SpamapSbut both are in an untrusted repo18:30
SpamapSso I think I may have to just do the painful thing of landing the code in project-config and rechecking in the untrusted repo.18:31
jlkIt's a valid use case, perhaps we should discuss it more with jeblair, and then document it somewhere.18:33
SpamapSIt's the old "I really really do want to break this. Just for now. Please let me."18:34
SpamapSbut it may be possible18:34
SpamapSjust not obvious to my overloaded brain18:34
jlkright, we might be making an invalid assumption somwhere18:34
tobiashSpamapS: responded on 51706718:53
SpamapStobiash: thanks! I wasn't sure I understood. Sounds like something worth doing.18:54
tobiash:)18:54
SpamapShrm19:08
SpamapSseems like things are working... weirdly with the secrets job as my parent19:08
SpamapShttp://paste.openstack.org/show/625382/19:09
SpamapSthe parent pre/post seem to have run one after the other, with no RUN19:09
SpamapSn/m...  another PBKAC19:21
tobiashjlk: responded on 51712119:27
tobiashs/responded/commented/19:28
jeblairSpamapS: yeah, if you think it's safe enough, you could set post-review on check.  just try to remember to remove it before it causes an incident that makes the evening news.  :)19:28
SpamapS2017-11-02 19:27:39.300980 | testecm | the field 'args' has an invalid value, which appears to include a variable that is undefined. The error was: {{ zuul.secrets.ecm_auth.effort }}: 'dict object' has no attribute 'secrets'19:28
jeblairSpamapS: drop '.secrets'; they just show up as a variable under their name (which can be overridden)19:29
SpamapSOOOOOOOH19:29
SpamapSderpaderp19:29
jeblairSpamapS: also, i documented our procedure for changing our base job; it may be helpful: http://git.openstack.org/cgit/openstack-infra/project-config/tree/zuul.d/jobs.yaml#n719:29
SpamapSjeblair: I went ahead and just landed the job in project-config, and I'm using it in an untrusted repo to iterate.19:30
jeblairSpamapS: cool19:30
SpamapSyeah looks like I got halfway to your solution19:30
SpamapSI like it19:30
SpamapSjeblair: +1 for carefulness :)19:31
jeblair(that's several steps, but once you get going, the "land fix to test job and recheck" iteration cycle can be pretty quick)19:31
SpamapSjeblair: and actually, we have a test auth domain for exactly this19:31
jlkoh cute, seems i Just ran into a bug in the githubconnection driver...19:32
SpamapSso I can have a job that uses the test auth domain without secrets in the check pipeline.19:32
jlkholy cow this is a pretty basic bug :919:33
SpamapSthey all are once you find them19:34
SpamapSit's the finding that isn't always basic :)19:34
jlkalso looks like the github docs are wrong19:35
jlkhttps://developer.github.com/v3/activity/events/types/#pushevent claims a 'pusher' object is in the payload, but it's not19:35
jlkalso claims that the 'ref' key has a full git ref (refs/heads/whatever) but it doesn't. It seems to just be the branch name.19:36
Shrewsjeblair: gah, I missed something on that declined pause change. We need to reset the request to REQUESTED instead of leaving it PENDING so another launcher will try to pick it up.19:36
jlkoh derp, I'm looking at the wrong event. DAMN19:36
openstackgerritDavid Shrewsbury proposed openstack-infra/nodepool feature/zuulv3: Reset state on unpaused, declined request  https://review.openstack.org/51741719:44
Shrewsjeblair: ^^^ that's actually not urgent since our cleanup worker handles it nicely for us19:44
Shrewsonce again, the cleanup thread sweeps my mistakes under the rug  :)19:45
SpamapSspeaking of github bugs19:56
SpamapShttp://paste.openstack.org/show/625387/19:57
jeblairShrews: lgtm20:04
SpamapSThis github delay thing is killing me20:05
SpamapS10s is ok.. sometimes20:05
SpamapSbut some things take 40+s20:05
SpamapSjlk: I wonder if GraphQL would be more up to date :-P20:06
SpamapShrm, debugging some problems..20:24
SpamapSsecrets seem like they get cleaned up even in keep mode?20:24
pabelangerdon't we write them to tmpfs in bwarp, so they don't actually endup on disk20:28
SpamapSah clever20:29
SpamapSI'm getting auth denials from the end point I"m pointed at, so I'm pretty sure my secret content is somehow wrong20:30
SpamapSstruggling to figure out how to debug that20:30
SpamapSI guess I can land a secret that isn't important, debug print it and see what it is, and then adjust accordingly.20:31
pabelangeryah, had a few issues properly testing secrets, most of it was land, test, iterate.20:32
pabelangerbiggest one was using binary data in ansible varibles, took a little bit to figure out that wasn't supported20:33
SpamapShrm, I wonder if I need to trim it20:39
SpamapSpabelanger: I remember the binary fight ;)20:39
SpamapSI think I may have put the \n on the end of a password20:40
*** kmalloc has quit IRC20:40
openstackgerritDavid Shrewsbury proposed openstack-infra/zuul feature/zuulv3: Switch to threading model of socketserver  https://review.openstack.org/51743721:00
*** dkranz has quit IRC21:12
*** hasharAway is now known as hashar21:13
openstackgerritMerged openstack-infra/zuul-jobs master: Add a generic stage-output role  https://review.openstack.org/50923321:49
jlkSpamapS: I wonder if we're suffering from cache invalidation problems.21:55
SpamapSjlk: yeah I have a todo to trace requests usage of the Etag controller to see if it is actually being used21:56
*** hashar has quit IRC22:00
openstackgerritJesse Keating proposed openstack-infra/zuul feature/zuulv3: Prime github app install map on connection load  https://review.openstack.org/51712122:14

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