| *** jkilpatr has quit IRC | 00:40 | |
| jlk | holy backscroll | 04:25 |
|---|---|---|
| *** hashar has joined #zuul | 07:48 | |
| *** smyers has quit IRC | 09:04 | |
| *** hashar has quit IRC | 09:13 | |
| *** hashar has joined #zuul | 09:14 | |
| *** smyers has joined #zuul | 09:15 | |
| *** jkilpatr has joined #zuul | 11:06 | |
| mordred | harlowja, Shrews: I mean - we ARE python3 only, so we could just use Barrier if it's the right thing to use | 11:39 |
| openstackgerrit | Merged openstack-infra/nodepool feature/zuulv3: Fix dict key copy operation https://review.openstack.org/476902 | 11:39 |
| Shrews | mordred: nodepool is not | 11:39 |
| Shrews | unless we remove py2 support from nodepool too | 11:40 |
| mordred | Shrews: no reason to keep py2 support for nodepool zuulv3 - especially if there's a useful primitive in python3 that's not in 2 | 11:41 |
| mordred | but with zuulv3 being py3 only, I don't know that there's much value in keeping python2 support in nodepool, right? | 11:41 |
| Shrews | i dunno. people like running nodepool w/o zuul too, or so i hear | 11:42 |
| Shrews | but i'm all for removing py2 | 11:42 |
| mordred | yah - definitely agree about people running nodepool w/o zuul | 11:43 |
| mordred | but I think the logical argument is still the same - nodepool v3 is a whole new thing so we really shouldn't have any 'legacy' installs that would be screwed - might as well do it now before we grow any | 11:43 |
| mordred | we might want to get infra's v3 nodepool running on v3 though - I think we rolled it out on v2 | 11:44 |
| Shrews | mordred: complication with that is we run v3 nodepool-builder in production on py2, so tough to get rid of right now | 12:04 |
| Shrews | i mean we still could, but would require quite a bit of work, i would think | 12:05 |
| mordred | Shrews: yah - I think we need to migrate that to runningin production on py3 first | 12:05 |
| mordred | but I think we should do it, since we're requiring py3 for zuul itself, at least before we officially release v3 - otherwise we'll be in a pretty odd state :) | 12:06 |
| Shrews | mordred: i'll put it on the agenda for discussion | 12:06 |
| mordred | woot | 12:07 |
| *** dkranz has joined #zuul | 12:13 | |
| openstackgerrit | Tristan Cacqueray proposed openstack-infra/nodepool feature/zuulv3: Abstract Nodepool request handling code https://review.openstack.org/468748 | 12:43 |
| openstackgerrit | Tristan Cacqueray proposed openstack-infra/nodepool feature/zuulv3: Abstract Nodepool provider management code https://review.openstack.org/468749 | 12:43 |
| openstackgerrit | Tristan Cacqueray proposed openstack-infra/nodepool feature/zuulv3: Collect request handling implementation in an OpenStack driver https://review.openstack.org/468750 | 12:43 |
| openstackgerrit | Tristan Cacqueray proposed openstack-infra/nodepool feature/zuulv3: Extend Nodepool configuration syntax to support multiple drivers https://review.openstack.org/468751 | 12:43 |
| openstackgerrit | Tristan Cacqueray proposed openstack-infra/nodepool feature/zuulv3: Implement a static driver for Nodepool https://review.openstack.org/468624 | 12:43 |
| *** jkilpatr has quit IRC | 12:54 | |
| tobiash | SpamapS: had another hang | 12:55 |
| tobiash | post mortem strace of ansible-playbook is: | 12:55 |
| tobiash | futex(0x557001244fc0, FUTEX_WAIT_PRIVATE, 4294967295, NULL | 12:55 |
| tobiash | will probably have to install a python debugger in the zuul container to be able to get a python stacktrace | 12:58 |
| openstackgerrit | David Shrewsbury proposed openstack-infra/nodepool feature/zuulv3: Add tox py35 environment https://review.openstack.org/477525 | 12:59 |
| Shrews | ugh, ignore that | 13:03 |
| *** isaacb has joined #zuul | 13:04 | |
| Shrews | harlowja: it would probably make more sense to propose https://review.openstack.org/476683 on the feature/zuulv3 branch rather than master. It would make removing py2 support easier. | 13:08 |
| *** jkilpatr has joined #zuul | 13:08 | |
| mordred | ++ | 13:09 |
| SpamapS | tobiash: ugh that means it's hung on "some pythony thing" :-P | 14:02 |
| mordred | SpamapS, tobiash: maybe the gdb python stuff jeblair did a couple of weeks ago will be useful | 14:18 |
| dmsimard | pretend I want to pass env variables to a ready-script (sorry, not upstream nodepool version), how would you do it ? | 14:51 |
| dmsimard | problem I have is getting configure_mirror.sh ( https://github.com/openstack-infra/project-config/blob/master/nodepool/scripts/configure_mirror.sh ) to pick up a specific NODEPOOL_MIRROR_HOST and can't for the life of me figure it out | 14:52 |
| dmsimard | I tried inserting an element that persists the env var I want in /etc/profile -- I can log in as jenkins and see the env var but nodepool/configure_mirror.sh doesn't seem to pick it up (maybe it runs the script with sudo without -E ?) | 14:53 |
| dmsimard | example error output from nodepool booting the node: http://paste.openstack.org/show/613729/ | 14:53 |
| dmsimard | pabelanger, mordred ^ ? | 14:53 |
| dmsimard | At this point what I'm considering is to add a file to source in configure_mirror.sh (say, /etc/nodepool/extra-vars.sh or something), source it if it exists and then configure an element to write the things I need in that file | 14:55 |
| clarkb | dmsimard: it is supposed to be based on the data coming out of /etc/nodepool. I guess you don't want it to be cloud/region specific but based on some other info? | 14:56 |
| dmsimard | clarkb: yeah, I'm basically trying to build images near-identical to upstream but we don't run mirrors in the region that configure_mirror is expecting. | 14:57 |
| clarkb | I would use a different ready script then | 14:58 |
| mordred | dmsimard: I'd just patch your configure_mirror script (or ready script) to hard-code your mirror | 14:58 |
| dmsimard | mordred, clarkb: we're using pure-upstream elements and scripts from project-config/nodepool so using a different ready script is less than ideal | 14:59 |
| dmsimard | we're not forking project-config, we're replicating it and leveraging it as-is -- the goal being to stay as close to upstream as possible | 15:00 |
| dmsimard | i.e, I don't want to maintain a fork and the people interested in these jobs want the images to be the same-ish as upstream | 15:00 |
| dmsimard | the image definition is here, there are only very subtle differences with the upstream one: https://github.com/rdo-infra/review.rdoproject.org-config/blob/master/nodepool/nodepool.yaml#L12-L34 | 15:02 |
| dmsimard | FWIW the NODEPOOL_MIRROR_HOST env var in that image definition is for test purposes for the time being | 15:03 |
| clarkb | dmsimard: the script should allow each of the vars to be overridden, I would wrap it with your own script that overrides the vars | 15:03 |
| dmsimard | clarkb: ok, I'll try that approach | 15:04 |
| mordred | dmsimard: I know you're not there yet - but just to re-iterate, the issues you're running in to are one of the main drivers behind the v3 work - so when you get free time, I'd love if you could give feedback on whether or not it's still a problem in v3 (not urgent, I know you have a ton of work on your plate - but the earlier we can verify you're good or not the better, right?) | 15:07 |
| dmsimard | mordred: yeah this kind of stuff wasn't obvious to me before -- we're hoping software factory to get closer to upstream asap | 15:10 |
| dmsimard | While perhaps blasphemous in these lands, I'm generally frustrated with DIB. I don't like it at all. :( | 15:11 |
| clarkb | NODEPOOL_MIRROR_HOST=${NODEPOOL_MIRROR_HOST:-mirror.$NODEPOOL_REGION.$NODEPOOL_CLOUD.openstack.org} confirmed, so you just have to set that value in a wrapping script and done | 15:13 |
| dmsimard | clarkb: yeah, that's what I'm trying right now -- I thought that persisting "export NODEPOOL_MIRROR_HOST=mirror" in /etc/profile would work but it doesn't. | 15:14 |
| clarkb | re dib, what is it doing that is problematic? | 15:15 |
| dmsimard | clarkb: oh, probably nothing. I just don't like the tool :) | 15:15 |
| dmsimard | clarkb: likely in part for the same reasons I dislike Dockerfiles, in the end it's just bash -- DIB is *layers* of bash :) | 15:16 |
| dmsimard | I like bash, but I just think it's not the right tool for that kind of job | 15:16 |
| clarkb | dmsimard: its actually layers of whatever you want. Happens that people like bash for interacting with systems | 15:16 |
| dmsimard | clarkb: right, I half forgot about that, there's ansible elements and stuff too now. | 15:17 |
| clarkb | dmsimard: its run parts of executable whatever. Could be emacs lisp for all dib cares | 15:17 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Add configuration documentation https://review.openstack.org/463328 | 15:40 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Reorganize docs into user/admin guide https://review.openstack.org/475928 | 15:40 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Use oslosphinx theme https://review.openstack.org/477585 | 15:40 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Move status_expiry to webapp section https://review.openstack.org/477586 | 15:40 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Move tenant_config option to scheduler section https://review.openstack.org/477587 | 15:40 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Correct sample zuul.conf https://review.openstack.org/477588 | 15:40 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Use executor section of zuul.conf for executor dirs https://review.openstack.org/477589 | 15:40 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Use scheduler-specific log config and pidfile https://review.openstack.org/477590 | 15:40 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Move zookeeper_hosts to zookeeper section https://review.openstack.org/477591 | 15:40 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Add some information about canonical_hostname https://review.openstack.org/477592 | 15:40 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Fix some inconsistent indentation in docs https://review.openstack.org/477593 | 15:40 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Rename git_host to server in github driver https://review.openstack.org/477594 | 15:40 |
| * jeblair deplanes | 15:40 | |
| jeblair | tobiash: do you have information about your non-deterministic setup bug collected somewhere so i can try to understand the issue? | 15:43 |
| *** isaacb has quit IRC | 15:57 | |
| jeblair | tobiash: you said: "the playbook repos don't seem to be part of the repo state the executor gets" and "the playbook repos are also not part of the projects dict" | 16:04 |
| jeblair | tobiash: repo_state holds information on all the projects that are in the dependency chain for an item; so a playbook repo would only show up there if the current change depends on a change to that repo | 16:05 |
| jeblair | tobiash: that is used by the merger to help construct the same state for all of the repos with changes. | 16:09 |
| jeblair | tobiash: the projects key holds all of the projects which the job says that it requires (via job.required_projects). also, all the projects in the dependency chain are added to it as well. to be honest, i'm not sure we need that last part, other than just adding the project for the change being tested. | 16:09 |
| jeblair | tobiash: at any rate, that's used to prepare all of the repos in the work/src directory for the job to use | 16:10 |
| jeblair | tobiash: so if a playbook repo isn't a required-project for a job, and it doesn't show up in a dependency chain for the change, then it won't appear in either of those | 16:11 |
| jeblair | tobiash: in that case, we should just check out the branch-tip of the playbook repo | 16:11 |
| jeblair | tobiash: if the branch-tip changes (ie, a change to the playbook repo merges while running unrelated jobs) then what we check out would be non-deterministic -- we might check out the old version or the new version depending on exactly when the job ran. i'm not certain that's a bug or something that we need to work around. | 16:13 |
| jeblair | tobiash: if, however, you get something different *without* any changes landing in the playbook repo, then we may have a bug such as using an unclean git tree to set up the playbook repo. | 16:14 |
| *** isaacb has joined #zuul | 16:15 | |
| SpamapS | clarkb: to give dmsimard some support.. dib is indeed "whatever you want", except most elements that exist already, are bash. So it ends up being layers of bash to run mostly bash anyway. | 16:23 |
| SpamapS | That said.. I've not seen many build systems that don't end up working mostly the same. | 16:24 |
| SpamapS | once you take runtime concerns out and just want to sequence things and explode when they break.. bash looks pretty good. | 16:24 |
| clarkb | while thats true it is a common misconception that it must be bash and dib itself is rewriting chunks of stuff in python aiui | 16:25 |
| SpamapS | Agreed and that last bit is good to hear. | 16:26 |
| SpamapS | I've found that fretting about the elegance of build-level tooling is a trap. The point of separating build from run is that build is linear and happens in a controlled environment. | 16:27 |
| jeblair | dmsimard: not sure if you got what you needed earlier, but for ready scripts, any environment variable in nodepool's environment that starts with "NODEPOOL_" will be passed through to the ready script | 16:28 |
| jeblair | dmsimard: ie, if you start nodepoold with "NODEPOOL_FOO", NODEPOOL_FOO will be available within the ready script | 16:29 |
| dmsimard | jeblair: oh, I didn't know that -- interesting. | 16:31 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Fix some inconsistent indentation in docs https://review.openstack.org/477593 | 17:00 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Add some information about canonical_hostname https://review.openstack.org/477592 | 17:00 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Rename git_host to server in github driver https://review.openstack.org/477594 | 17:00 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Move tenant_config option to scheduler section https://review.openstack.org/477587 | 17:00 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Use executor section of zuul.conf for executor dirs https://review.openstack.org/477589 | 17:00 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Correct sample zuul.conf https://review.openstack.org/477588 | 17:00 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Move zookeeper_hosts to zookeeper section https://review.openstack.org/477591 | 17:00 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Use scheduler-specific log config and pidfile https://review.openstack.org/477590 | 17:00 |
| *** isaacb has quit IRC | 17:04 | |
| jlk | o/ | 17:31 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Move tenant_config option to scheduler section https://review.openstack.org/477587 | 17:52 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Fix some inconsistent indentation in docs https://review.openstack.org/477593 | 17:53 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Add some information about canonical_hostname https://review.openstack.org/477592 | 17:53 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Rename git_host to server in github driver https://review.openstack.org/477594 | 17:53 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Use executor section of zuul.conf for executor dirs https://review.openstack.org/477589 | 17:53 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Correct sample zuul.conf https://review.openstack.org/477588 | 17:53 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Move zookeeper_hosts to zookeeper section https://review.openstack.org/477591 | 17:53 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Use scheduler-specific log config and pidfile https://review.openstack.org/477590 | 17:53 |
| clarkb | jeblair: https://review.openstack.org/476678 and https://review.openstack.org/476223 are two nodepool related items that came up last week | 18:01 |
| clarkb | I separately merged a fix that shrews had for master as well so we should consider restarting nodepool this week | 18:02 |
| clarkb | mordred: ^ how does that line up with shade releases | 18:02 |
| jeblair | clarkb: i guess a rainy day task would be to make uploads interruptable in shade? would obviously require some significant work thoug.h | 18:03 |
| jeblair | clarkb: what's the master branch change you referred to? | 18:03 |
| clarkb | ya, I don't think it would be very straightforward so probably not worth fixing immediately. Cna't hurt to support it though | 18:04 |
| clarkb | jeblair: you mean why did https://review.openstack.org/476223 come about? | 18:04 |
| jeblair | clarkb: "I separately merged a fix that shrews had for master" <-- that one | 18:05 |
| clarkb | oh let me dig it up | 18:05 |
| clarkb | https://review.openstack.org/#/c/470364/ that one | 18:05 |
| clarkb | sorry shrews one is unrelated to the other two. It is just another fix that came up so makes restarts worthwhile if shade is no longer unhappy | 18:06 |
| jeblair | clarkb: ack, thx | 18:06 |
| SpamapS | I'd have to look but I feel like Shade relies a lot on some specialness in swiftclient if uploading to swift. Dunno about glance direct PUT's. | 18:09 |
| * SpamapS hasn't been tracking the de-client-ification effort very closely either | 18:10 | |
| jeblair | SpamapS: the swiftclient stuff has been removed | 18:10 |
| jeblair | SpamapS: i think ironicclient is the only one left | 18:11 |
| SpamapS | yowza, that's nice | 18:11 |
| jeblair | ya | 18:11 |
| clarkb | jeblair: re 476223 we have a few thousand failed image upload records now because requests decided to stop bundling certs in its repo and instead depends on certifi | 18:13 |
| clarkb | (this lead to running python processes not being able to load the certs file out of the requeists install location at runtime which failed all the ssl checking) | 18:13 |
| jeblair | clarkb: thanks | 18:15 |
| tobiash | jeblair: regarding non-deterministic playbook setup | 18:20 |
| tobiash | my scenario is I have multiple mergers, one executor | 18:20 |
| jeblair | tobiash: aha! i think i see the problem | 18:21 |
| tobiash | I make a change to a config repo, that gets merged (currently with a noop job) so the executor doesn't necessarily update the repo | 18:21 |
| tobiash | when merged, possibly a merger gets the repo update job -> executor has old copy cached | 18:22 |
| jeblair | tobiash: because the playbook repo doesn't appear in 'projects', the executor doesn't tell its internal merger to update that repo, so it doesn't get the new branch tip when you do that ^ | 18:22 |
| tobiash | exactly | 18:22 |
| tobiash | that's why I thought it would be good to freeze the playbook repos also like the dependent changes | 18:23 |
| tobiash | that would also make this independent of concurrent merges and also possibly reduce load on gerrit as the executor doesn;t have to do a fetch on every playbook repo if it has already the correct revision cached | 18:24 |
| tobiash | my current workaround is to stop the mergers and restart the scheduler after a config repo change has landed ;) | 18:25 |
| jeblair | tobiash: it's difficult to put anything other than dependent changes into repo_state -- because we don't actually know what those repos should be until after that merge completes (it could contain configuration changes which add required-projects, or change the job config to alter which playbook repos are involved) | 18:25 |
| tobiash | maybe the repo state could be appended in a second stage | 18:26 |
| jeblair | tobiash: the way to fix that which at least matches the rest of the current behavior would be to alter the executor to run an update task on all the playbook repos (and roles!) in addition to what's in 'projects'. | 18:26 |
| tobiash | yes, that would fix my problem | 18:27 |
| jeblair | tobiash: i think that executor change should be easy to do, so we should probably start there. i think your idea of a second-stage freeze of related repos from the merger is worth considering, however, it could potentially slow operations. we might mitigate it by asking for all of the known playbook and role repos in the first stage, and then we only have to do a second stage if something changes.... | 18:28 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Use executor section of zuul.conf for executor dirs https://review.openstack.org/477589 | 18:29 |
| tobiash | jeblair: sounds like a plan | 18:29 |
| tobiash | jeblair: another issue I discovered today (but had no time yet to debug): | 18:29 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Use scheduler-specific log config and pidfile https://review.openstack.org/477590 | 18:30 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Fix some inconsistent indentation in docs https://review.openstack.org/477593 | 18:31 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Add some information about canonical_hostname https://review.openstack.org/477592 | 18:31 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Rename git_host to server in github driver https://review.openstack.org/477594 | 18:31 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Move zookeeper_hosts to zookeeper section https://review.openstack.org/477591 | 18:31 |
| tobiash | scenario: change A,1 runs a (longer running) job, during that A,2 adding or removing jobs in .zuul.yaml is pushed | 18:31 |
| tobiash | my expectation is that A is restarted with A,2 with the jobs added/removed | 18:32 |
| tobiash | observed behaviour is jobs of A,1 are restarted without honoring added/removed jobs | 18:32 |
| jeblair | tobiash: by 'pushed' do you mean 'proposed'? or directly pushed onto the branch? | 18:32 |
| tobiash | proposed | 18:32 |
| jeblair | tobiash: (or do you mean merged?) | 18:33 |
| tobiash | further reporting is against A,1 | 18:33 |
| tobiash | no merge involved | 18:33 |
| jeblair | tobiash: okay, yeah that sounds like a bug :( | 18:33 |
| jeblair | tobiash: we have no unit tests for that case, but should be easy to add one. | 18:34 |
| tobiash | so this could be one or two bugs: job graph is not recalculated and reporting is against wrong patch version | 18:34 |
| jeblair | agreed | 18:34 |
| tobiash | that was on my task list, but next two days I'm on the german openstack days and after that on a full day workshop | 18:35 |
| tobiash | -> three days off | 18:35 |
| tobiash | and I'll have to debug some occasional freeze of ansible-playbook (see scrollback) | 18:36 |
| jeblair | tobiash: cool, i might be able to take a look at it before then -- not sure how this week is going to go yet :) | 18:36 |
| jeblair | tobiash: that's unfortunate. does zuul at least time out the job and kill the process correctly? | 18:36 |
| tobiash | didn't wait for timeout but I think it would | 18:36 |
| tobiash | ansible-playbook is stuck in some futex (before launching an ssh process) | 18:37 |
| tobiash | it might possibly relate to the modules we inject (log streaming?) as I didn't observe something like that running ansible manually | 18:38 |
| tobiash | last log message before the freeze is "Starting to log 396bf1da93ed43adbfc03274c24a55ee for task..." | 18:40 |
| tobiash | but I have to install gdb in the zuul container and try to get a stack trace next time it happend | 18:40 |
| tobiash | happens in about 1-5% of runs for me | 18:41 |
| tobiash | what's strange about that is if I kill the stuck ansible-playbook process zuul restarts this playbook and continues the job if nothing happened | 18:42 |
| tobiash | (and succeeds the job) | 18:42 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul feature/zuulv3: Make sure playbook and role repos are updated https://review.openstack.org/477627 | 18:46 |
| jeblair | tobiash: ^ there's the fix for the first thing | 18:46 |
| tobiash | jeblair: crazy you're fast | 18:47 |
| jeblair | tobiash: i refreshed my memory of the code this morning :) | 18:48 |
| tobiash | jeblair: lgtm | 18:49 |
| tobiash | jeblair: regarding gerrit 2.13, I think it would be good to change the label matching stuff to case sensitive | 18:51 |
| tobiash | jeblair: gerrit 2.13 breaks the gate with wrong casing as vote+submit doesn't work with one command anymore if the label casing is not correct | 18:52 |
| tobiash | jeblair: https://review.openstack.org/#/c/469946/ that's my proposal | 18:52 |
| jeblair | tobiash: do you know if they did that on purpose? | 18:53 |
| tobiash | (as this breaks *every* fixture the tests are updated in a follow up change for easier review, but would need a rebase) | 18:53 |
| jeblair | (this seems like a bug, if setting the vote works but not submit) | 18:53 |
| tobiash | jeblair: I don't know, we just updated gerrit in march and that broke out gate | 18:53 |
| jlk | SpamapS: you rightly called me out on not having a test case to limit job reporting for push events in github. I implemented the test, and found more bugs. https://review.openstack.org/476400 | 18:55 |
| jeblair | tobiash: in 469946, should we remove the .lower() in normalize_category? | 18:55 |
| tobiash | jeblair: we could to be really correct, but I left this at first as this is just used for internal comparisions | 18:56 |
| tobiash | in this case I think it might be correct to remove the nodmalize_category completely | 18:57 |
| clarkb | re 2.13 we are getting much closer to being able to deploy it on our test box, review-dev.openstack.org so getting those issues fixed will shortly become much more important for us too | 18:57 |
| jeblair | clarkb: is that gerrit 2.13 issue on your radar ^? | 18:58 |
| clarkb | ya I saw it last week I think was just too busy actually sorting out 2.13 and dns problems to pay close attention | 18:58 |
| clarkb | the 2.13 upgrade is :( | 18:59 |
| jeblair | tobiash: well, the intent was that you would be able to say "code-review: 2" in the config file rather than '"Code Reveiew": 2'... if we remove the lower but leave the space/- translation, we can at least still say "Code-Review: 2" | 18:59 |
| clarkb | manual db schema updates and migration from h2 to mysql | 19:00 |
| jeblair | clarkb: 2.11 put some stuff in h2? | 19:00 |
| tobiash | jeblair: ah, ok, but you would then spell the labels in requirements different than in the reporting? | 19:01 |
| clarkb | jeblair: no 2.13 did then in latest release they must've realized that was silly so if you upgrade to 2.13.7 first you have to manually do db things to go to 2.13.8 | 19:01 |
| clarkb | jeblair: so we reverted the 2.13.7 upgrade and will work out how to go straight to 2.13.8 to avoid some of the mess | 19:01 |
| jeblair | clarkb: we upgraded something to 2.13? | 19:01 |
| clarkb | jeblair: review-dev, for about a grand total of 10 minutes | 19:02 |
| jeblair | clarkb: ok -- is that back at its 2.11 state? | 19:02 |
| clarkb | yup we rolled back so that we can do 2.11 -> 2.13.8 testing accurately | 19:03 |
| jeblair | ok cool. | 19:03 |
| tobiash | jeblair: so in case we want to keep normalize_category I would vote for leaving the tolower here as we anyway do a translation for internal comparison | 19:03 |
| tobiash | jeblair: but it's your decision, it should work with both | 19:03 |
| jeblair | tobiash: i think the thing i worry about is that mostly your change is making sure that we don't enqueue something that gerrit won't handle later... | 19:04 |
| tobiash | jeblair: landing such a change will have to be coordinated wisely as it will break *every* change (and also getx broken with every change) | 19:05 |
| tobiash | jeblair: so the part in gerritconnection makes sure gerrit can handle the vote+submit | 19:06 |
| jeblair | tobiash: i think i see why it's okay to leave the .lower() call in there.... it's because it's only the allow_needs that could actually cause a problem | 19:06 |
| jeblair | tobiash: even if we "incorrectly" decide that a change meets a pipeline requirement despite the cases being different, it won't be a problem unless it also shows up in an allow-needs... | 19:07 |
| tobiash | jeblair: yepp | 19:07 |
| jeblair | let's leave it now; i'll think more about changing it later | 19:08 |
| tobiash | ok | 19:08 |
| jeblair | tobiash: we should get some more eyes on that and merge it soon | 19:09 |
| tobiash | jeblair: ok, I'll rebase the test fix follow up once more eyes are happy with this | 19:09 |
| tobiash | rebasing the test fixtures is like hell ;) | 19:10 |
| tobiash | jeblair: I've a question about secrets | 19:11 |
| tobiash | as I've understood secrets are also allowed in untrusted repos | 19:11 |
| tobiash | how are speculative changes to the playbooks handled in that case? | 19:11 |
| jeblair | aha! missing documentation :) | 19:12 |
| tobiash | or is it just a risk to place secrets in untrusted repos? | 19:12 |
| jeblair | tobiash: pipelines have an allow-secrets attribute, so you can ensure that secrets aren't available to jobs running in pipelines which run unreviewed code | 19:13 |
| jeblair | tobiash: allow-secrets is false by default | 19:13 |
| jeblair | tobiash: so you probably only want to enable it for gate, or post, or some pipeline that requires at least a trusted code review before running jobs | 19:14 |
| tobiash | jeblair: I would have a use case as also some jobs in check need to download stuff from (authenticated) artifactory | 19:15 |
| jeblair | tobiash: (for example, we might make a pipeline for running shade jobs against real clouds using real creds which requires a shade-core to +2 the change before jobs run) | 19:15 |
| SpamapS | jlk: \o/ for testing | 19:15 |
| * SpamapS will hit the review queue after lunch | 19:15 | |
| tobiash | the initial job inheritance structure is not retained during job freezing right? | 19:16 |
| tobiash | so currently it would not be possible to have a post playbook in a config repos using a secret for logs, artifacts, etc upload? | 19:17 |
| tobiash | (and hiding the secret from the main playbook) | 19:18 |
| jeblair | tobiash: secrets are available to the entire job. it's starting to look like we may want to think about making them per-playbook, however we hadn't assumed we could maintain security in the executor environment between playbook invocations. with bubblewrap for trusted jobs, it's starting to look like we might be able to do that. | 19:19 |
| jeblair | tobiash: but that's a moderate redesign, so i don't want to block on it right now. | 19:19 |
| tobiash | jeblair: so a task for 3.1? | 19:20 |
| jeblair | tobiash: maybe? possibly still v3.0, but just later, if we decide secrets aren't useful without it. :) | 19:21 |
| jeblair | tobiash: we've already run in to one place where we would like to use secrets but can't because of this issue. we can work around it, but it's not ideal. | 19:21 |
| jeblair | so i'd like to keep an eye on it while we continue to try to get more jobs working to see what works and what doesn't. | 19:22 |
| tobiash | yes, so for my use case I would have to add the secret to artifactory the check pipeline and risk disclosure | 19:22 |
| tobiash | this could be reduced with a dedicated secret for exactly this purpose | 19:23 |
| jeblair | (at least if we make the change, we'd be making the behavior *more* restrictive, rather than less, so it should be okay to make the change in that direction) | 19:23 |
| jeblair | tobiash: but you'd want to put that only in a trusted pre-playbook or something, right? | 19:23 |
| tobiash | jeblair: that was the plan | 19:23 |
| tobiash | trusted pre or post playbook for downloads and uploads | 19:24 |
| jeblair | tobiash: gotcha. that's similar to the thing we ran into as well, where we wanted to use a secret for log publishing. | 19:24 |
| tobiash | that's my second use case | 19:24 |
| jeblair | tobiash: our plan to work around that is to have the log publishing key on the executor, so the trusted post-playbook can use it "out-of-band" so to speak | 19:25 |
| jeblair | tobiash: you may be able to work around your issue similarly | 19:25 |
| tobiash | jeblair: I'm thinking about using eventualley artifactory for log publishing. That way I would remove the need of backups in the ci system itself | 19:25 |
| jeblair | i'll start thinking about per-playbook secrets in the background | 19:26 |
| tobiash | jeblair: ok, that will work as untrusted jobs won't be able to read stuff (other than the workdir) from the executor? | 19:26 |
| jeblair | tobiash: yes -- and even with trusted bubblewrap, we should be able to map in specific directories to trusted playbooks, so you can map in your artifactory creds that way. | 19:27 |
| tobiash | jeblair: I read somewhere that there is an idea of site local variables | 19:27 |
| tobiash | jeblair: maybe that could be enhanced with site local trusted variables | 19:27 |
| jeblair | tobiash: https://review.openstack.org/447734 | 19:28 |
| Shrews | mordred: I'm *this* close to abandoning autobahn | 19:28 |
| tobiash | jeblair: ah, there I saw that :) | 19:29 |
| jeblair | tobiash: could be. though this is looking like a defect in secrets, so if the only reason to do that is this, it may be better to improve secrets. :) | 19:29 |
| tobiash | ;) | 19:29 |
| openstackgerrit | David Shrewsbury proposed openstack-infra/zuul feature/zuulv3: WIP: Add web-based console log streaming https://review.openstack.org/463353 | 19:30 |
| jeblair | tobiash: (i worry that encouraging folks to put sensitive data in site-wide ansible variables might lead to accidentally leaking them through jobs that weren't written with them in mind) | 19:30 |
| tobiash | jeblair: ok, so the workaround is to have a folder with secrets on the executor and having ansible resolving them with lookup (which doesn't work in untrusted jobs) | 19:30 |
| *** ChanServ has quit IRC | 19:30 | |
| jeblair | tobiash: yep | 19:30 |
| jeblair | Shrews: i'm going to grab lunch now, but when i'm back, i'd like to hear more about the issues you're running into if you have a moment | 19:31 |
| tobiash | jeblair: agreed, having them somewhere in a folder is much better than publicly visible (in any trusted job) with a red flag *here are the secrets* on it | 19:32 |
| Shrews | jeblair: i'm constructing a very defeated email :) | 19:32 |
| *** ChanServ has joined #zuul | 19:35 | |
| *** card.freenode.net sets mode: +o ChanServ | 19:35 | |
| tobiash | jeblair: what I noticed in my experiments with job config with zuul managed roles import | 19:36 |
| tobiash | jeblair: I have a repo with a /playbooks folder, some jobs defined in .zuul.yaml and a role in /roles | 19:37 |
| tobiash | these roles are to be used in the same repo as well as in other repos | 19:37 |
| tobiash | is it intended that I also have to define the roles property of jobs in the same repo? | 19:38 |
| mordred | Shrews: yah? | 19:39 |
| tobiash | jeblair: like this: http://paste.openstack.org/show/613752/ | 19:41 |
| *** jkilpatr has quit IRC | 20:00 | |
| openstackgerrit | Tobias Henkel proposed openstack-infra/zuul feature/zuulv3: Fix encrypt_secret for python3 https://review.openstack.org/477168 | 20:01 |
| jeblair | mordred: do you have thoughts on tobiash's issue above? | 20:08 |
| jeblair | tobiash, mordred: should we add every playbook repo to the roles path as well? | 20:08 |
| mordred | jeblair: pondering | 20:09 |
| openstackgerrit | Tobias Henkel proposed openstack-infra/zuul feature/zuulv3: Fix encrypt_secret for python3 https://review.openstack.org/477168 | 20:10 |
| tobiash | jeblair: that would simplify job config | 20:11 |
| tobiash | my use case is to provide some public zuul managed roles and in the same repos having jobs to test them | 20:11 |
| mordred | jeblair: there is a somewhat related question from a couple of weeks ago about | 20:11 |
| mordred | gah | 20:11 |
| tobiash | currently I have to mention the repo itself in the job description which has two drawbacks: first, visual noise, second probably more important, the repo is not relocatable | 20:13 |
| tobiash | (without fixing the jobs referring to its own repo) | 20:13 |
| jeblair | yeah, i feel like "playbook should be able to use roles in its own repo" seems like a fairly normal expectation.... | 20:14 |
| jeblair | tobiash, mordred: if the "roles/" directory were under "playbooks/" would this automatically work? | 20:14 |
| mordred | yah. I'm trying to come up with drawbacks | 20:14 |
| mordred | jeblair: yes | 20:14 |
| tobiash | jeblair: that works | 20:14 |
| mordred | jeblair: but then the dir would be weird for folks consuming it as a source of roles | 20:15 |
| mordred | s/dir/repo/ | 20:15 |
| jeblair | right -- though, having roles as a sibling dir to a playbook is the more normal ansible thing... | 20:15 |
| tobiash | roles in playbooks/roles are repo private currently | 20:15 |
| jeblair | this could also be solved with a symlink, i bet... | 20:16 |
| jeblair | or we could move the playbook up to the root level | 20:16 |
| tobiash | jeblair: right that would also work | 20:16 |
| tobiash | but I like the idea of public roles in /roles and playbook private roles in /playbooks/roles | 20:16 |
| mordred | the thing the repo is providing is the content in roles/ - the playbooks dir, in this case, exists to test the roles | 20:17 |
| tobiash | jepp | 20:17 |
| jeblair | then that leaves us with (a) auto-add playbook repos as roles or (b) symlink | 20:17 |
| mordred | yah | 20:17 |
| mordred | I can't come up with any immediately bad reasons to not do (a) | 20:17 |
| tobiash | I'd vote for a | 20:18 |
| jeblair | (b) is more explicit... it lets you indicate what's going on for this specific repo | 20:18 |
| jeblair | but yeah, (a) may be sort of 'just works' | 20:18 |
| mordred | jeblair: while we're considering this topic ... | 20:19 |
| mordred | jeblair: it might be worth noodling on repos in the 'standard' role layout, such as: http://git.openstack.org/cgit/openstack/openstack-ansible-os_nova/tree/ | 20:20 |
| jeblair | mordred: whatcha mean? | 20:21 |
| tobiash | mordred: isn't that supported (I think it was named bare role in the docs)? | 20:21 |
| mordred | jeblair: which put playbooks to test the role in question in the tests/ dir | 20:21 |
| tobiash | mordred: ah, configurable playbooks dir? | 20:21 |
| tobiash | :) | 20:21 |
| jeblair | mordred, tobiash: yeah that roles layout is supported (yes, we call it a bare-role). and i think we've had a few requests for not assuming playbooks are in playbooks/ | 20:23 |
| mordred | jeblair: ok. cool | 20:23 |
| jeblair | mordred: is that the suggestion? that we make it so that we can have a job run 'tests/test.yml' as the main job playbook? | 20:23 |
| jeblair | mordred: or were you more focused on ensuring that we support bare-roles? | 20:23 |
| jeblair | http://docs-draft.openstack.org/27/477627/1/check/gate-zuul-docs-ubuntu-xenial/2a62ff4//doc/build/html/user/config.html#job | 20:24 |
| jeblair | ^ describes bare-roles; and i just realized we're going to need deep links to the keywords there and we don't have them :| | 20:24 |
| mordred | jeblair: oh - no - I was more focused on making sure that folks with bare-repo ansible roles can test them in an easy manner | 20:24 |
| mordred | jeblair: so I think that would be the playbooks/ topic | 20:25 |
| jeblair | mordred: yeah, so on that, i was thinking we keep the implicit playbook name under playbooks, but then if you set "run:" then we drop the playbooks/ prefix and expect you to pass tho whole path. | 20:26 |
| jeblair | that's like a one-liner. | 20:26 |
| mordred | jeblair: ++ wfm | 20:26 |
| tobiash | ++ | 20:26 |
| mordred | jeblair: for the other, the main drawback I can think of to the symlink approach for the tobiash role thing is that it would prevent him having additional private roles that are just for testing | 20:26 |
| mordred | now - how likely _that_ is is another question | 20:27 |
| jeblair | mordred: on the bare-role topic -- we support either "bare" roles (like your example) or "contained" roles like tobiash's as targets for the "roles" job parameter.... | 20:27 |
| jeblair | mordred: there is a complication if we want to extend that to plan (a) [automatically add playbook repos as roles] | 20:28 |
| mordred | jeblair: how hard would it be to add playbook repos if they have a roles dir? | 20:28 |
| jeblair | mordred: it's easy to add "contained" roles to roles_path. however, we need a name for the "bare" roles case. | 20:28 |
| jeblair | mordred: we can just use the repo name | 20:28 |
| mordred | jeblair: OH - yah - I see the additional issue | 20:29 |
| jeblair | mordred: and then, if someone needs the role to have a different name than the repo, you have to add an explicit "roles" entry for it. | 20:29 |
| jeblair | mordred: (with a roles entry, you can rename the role to something other than the repo name -- eg, "openstack-ansible-os_nova" to "os_nova") | 20:29 |
| mordred | yah, if you look at: http://git.openstack.org/cgit/openstack-infra/ansible-role-puppet/tree/tests | 20:31 |
| mordred | that's an issue :) | 20:31 |
| jeblair | mordred: role: "{{ rolename }}" ? | 20:32 |
| mordred | jeblair: oh - fwiw, there is an ansible "standard" which is that repo names starting with "ansibe-role-foo" install as foo | 20:32 |
| mordred | jeblair: the test job in that case passes in rolename | 20:32 |
| mordred | http://git.openstack.org/cgit/openstack-infra/ansible-role-puppet/tree/run_tests.sh | 20:32 |
| jeblair | mordred: so that would run with rolename=ansible-role-puppet? | 20:33 |
| jeblair | mordred: if so, then adding that playbook repo as a role (plan a) would just work, i think. | 20:34 |
| mordred | jeblair: yes. however, it's always felt a little hacky to me- what I'd prefer is to have the playbook not take a rolename argument and to be written as roles: - puppet (since that's the role name) - but it's harder to run it that way locally since that's not the dir it'll be cloned in to | 20:35 |
| mordred | hang on - reading a thing real quick | 20:36 |
| tobiash | paths: jeblair, mordred: dropping playbooks/ when you set run: could be inconsistent with pre and post playbooks as they are set in any case | 20:37 |
| tobiash | paths: jeblair, mordred: maybe we could distinguish the path if it's an absolute path (starting with /) or not | 20:37 |
| mordred | jeblair, tobiash: this is a role from geerlingguy - and his approach is the top google hit for "testing ansible roles" https://github.com/geerlingguy/ansible-role-java/blob/master/tests/test.yml | 20:37 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Fix parsing of github PR url https://review.openstack.org/476286 | 20:38 |
| mordred | jeblair: I think we can do better than that, tbh | 20:38 |
| jeblair | mordred: we could have the executor be smarter and automatically rename ansible-role-foo to foo for the role install (but not, obviously for the main project checkout). that would make your 'puppet' case work, but break that test as written. maybe that's desirable. :) | 20:39 |
| mordred | jeblair: yah - if I can get zuul testing with that break, I'll take it :) | 20:40 |
| jeblair | tobiash: i think we could drop automatic playbooks/ for pre and post as well. so it's only automatic for the implied job playbook. | 20:40 |
| tobiash | jeblair: so pre/post playbooks must be defined absolute then? | 20:41 |
| mordred | jeblair: I think dealing with ansible-role- prefix would be a nice nod to compat with galaxy | 20:41 |
| jeblair | tobiash: or your suggestion for matching on '/' would work, if we want to try to support both. i guess it would be like being in a shell where cwd is '/playbooks/'. :) | 20:41 |
| mordred | jeblair: and if geerlingguy wanted to do his role but keep it that way, he could always add roles: role_under_test: https://github.com/geerlingguy/ansible-role-java to his job | 20:41 |
| tobiash | jeblair: yes, that was the thought | 20:42 |
| mordred | I'm _less_ crazy about the leading / - because that, to me, implies the root of the filesystem, but we're more likely to be in /home/zuul (or similar) - but I don't feel SUPER strongly about it | 20:42 |
| jeblair | mordred: i'm trying to catch up -- where's geerlingguy's role_under_test ? | 20:42 |
| mordred | https://github.com/geerlingguy/ansible-role-java/blob/master/tests/test.yml#L10 | 20:43 |
| jeblair | mordred: yeah, but where's that role? | 20:43 |
| jlk | making executor do "smart things" with role names and paths makes it harder for people to replicate outside of zuul | 20:43 |
| mordred | he has a wrapper script he wget's into his travis job that puts his role in place and always names it "role_under_test" | 20:43 |
| jeblair | mordred: gotcha. yes. i think that's a substandard experience that we can support in the way you described with the roles: mapping. :) | 20:44 |
| mordred | jeblair: https://gist.githubusercontent.com/geerlingguy/73ef1e5ee45d8694570 | 20:44 |
| tobiash | mordred: so you're in favor of enforcing (repo) absolute paths for pre/post playbooks and default to playbooks/<jobname> for main playbook? | 20:46 |
| mordred | jeblair, jlk: here's another post on dealing with a similar issue- which involves putting a symlink in a roles dir in the tests dir: https://www.ansible.com/blog/testing-ansible-roles-with-docker | 20:47 |
| mordred | scroll down to "A Role Under Test" | 20:47 |
| jeblair | mordred: wow, that symlinks outside of the repo | 20:50 |
| jeblair | (it doesn't have to though, so we can probably just ignore that. just it's an interesting example) | 20:50 |
| mordred | tobiash: yes - I think that's nicer personally- the least amount of magic (the only magic that happens is if you're getting magical implied-run-name magic too) | 20:53 |
| tobiash | mordred: wfm | 20:53 |
| openstackgerrit | Tobias Henkel proposed openstack-infra/zuul feature/zuulv3: wip: support custom playbook locations https://review.openstack.org/477672 | 20:55 |
| tobiash | mordred: like that? ^^ | 20:55 |
| tobiash | tests would have to be fixed (and commit message beautified) | 20:55 |
| jlk | jeblair: reading through doc update, does an executor (if ran without a stand alone merger) not need any of the config entries from the [merger] section of the configuration? | 20:58 |
| tobiash | eod for me now, cya | 20:58 |
| *** dkranz has quit IRC | 21:01 | |
| jeblair | jlk: it uses git_user_name and git_user_email from the merger section | 21:04 |
| jeblair | that's another thing missing from my current docs stack. :) | 21:04 |
| jlk | yeah, I have a pending comment | 21:04 |
| jeblair | i wonder if we should continue doing that, or duplicate the options for executor? | 21:05 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Implement pipeline requirement of github labels https://review.openstack.org/473962 | 21:15 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: config: refactor config get default https://review.openstack.org/474484 | 21:20 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: bubblewrap: adds --die-with-parent option https://review.openstack.org/473164 | 21:25 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: executor: run trusted playbook in a bubblewrap https://review.openstack.org/474460 | 21:25 |
| dmsimard | I'm trying to know where to look (nodepool, zuul, or the disk image), before Zuul 2.5, how did the jenkins slave.jar end up on the nodepool VM and executed so the node connected back ot jenkins ? | 21:32 |
| dmsimard | s/ot/to/ | 21:32 |
| jlk | wouldn't that be a disk image builder element? | 21:32 |
| dmsimard | jlk: I've been grepping 'jar' left and right and nothing's coming up | 21:34 |
| dmsimard | I'm probably not looking in the right places | 21:34 |
| mordred | dmsimard: we had puppet | 21:35 |
| jlk | yeah I would think it's the infra configuration | 21:35 |
| jlk | for dib | 21:35 |
| mordred | dmsimard: that we ran that installed java on the slave | 21:35 |
| mordred | dmsimard: but jenkins itself is responsible for copying the jar as part of teh ssh slave plugin | 21:35 |
| mordred | dmsimard: and jenkins connected to the slave, not the other way around | 21:35 |
| dmsimard | mordred: ah, that's a good hint, thanks | 21:35 |
| mordred | dmsimard: the attach was a REST API call that added the node as an ssh slave - which caused jenkins to connect to the slave | 21:36 |
| jlk | oooh, somebody should go through the github driver code and wire up some statsd metrics. | 21:36 |
| dmsimard | mordred: ok, that's exactly it -- java doesn't end up being installed in the upstream images anymore. Thanks <3 | 21:38 |
| mordred | dmsimard: \o/ | 21:38 |
| mordred | clarkb, fungi: ^^ that may be a thing we want to take note of WRT any 3rd party ci using zuul v2 dib and puppet | 21:39 |
| mordred | and still using jenkins | 21:39 |
| clarkb | oh I ran into that with gerrit build jobs and didn't make the connection to "this will break jenkins" | 21:47 |
| jeblair | zuul meeting time in #openstack-meeting-alt | 22:00 |
| jamielennox | ' | 22:01 |
| *** hashar has quit IRC | 22:41 | |
| mordred | jlk: looks like the PR 'body' isn't even in the comments in https://api.github.com/repos/j2sol/z8s-sandbox/issues/2/comments | 22:43 |
| mordred | jlk: only in the body on https://api.github.com/repos/j2sol/z8s-sandbox/pulls/2 | 22:44 |
| jlk | haha, wtf. | 22:45 |
| jlk | so, that's actually maybe better? | 22:45 |
| jlk | OOOH | 22:46 |
| jlk | so, one flaw in my investigation, when looking at the webhook event that github sends, it doesn't show what TYPE of event. I had assumed it was a comment type event, but in reality it may have been a "pull_request" event, and the action was "edited" | 22:47 |
| jlk | so... that would make more sense. The pull_request was edited, the body was updated. | 22:47 |
| jlk | this is workable | 22:47 |
| jlk | https://developer.github.com/v3/activity/events/types/#pullrequestevent derp. | 22:48 |
| rbergeron | jlk: i uh.... just informed this "maxamillion" character about bonny | 23:37 |
| rbergeron | so um | 23:37 |
| rbergeron | if you hear from him... that's why :D | 23:38 |
| rbergeron | also: jlk -- I have kind of read / experimented with the github api in like, gross ickiness types of detail -- not that i expect to know more than you, but perhaps I can lend the "dumb person who knows enough to be dangerous" aspect while you are playing with it -- between screwing with it for data and also in ELK scenarios and stupid github bigquery | 23:40 |
| rbergeron | i like to think i know... at least something that could be slightly potentially useful momentarily | 23:40 |
| jlk | awesomes! Thanks for the heads up | 23:41 |
| jlk | We are using some searching stuff, and thought we'd need more, but maybe not. | 23:41 |
| jlk | oh, like, I do need to be able to search github for any PRs with "Depends-On" and "org/project/pull/number" as an initial comment. | 23:43 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!