| tristanC | corvus: i haven't, i guess this needs some sort of specs to enable such customization | 00:03 |
|---|---|---|
| tristanC | corvus: simplest solution would be a pipeline.resulst_template blob to be formated with builds (list of job name, log url, build url) | 00:05 |
| tristanC | corvus: or perhaps zuul would provides different template the user can choose from, e.g. results_with_log_urls, or results_with_build_urls | 00:06 |
| corvus | tristanC: oh, maybe we should just do it after we require the sql db. then we're guaranteed it's available. | 00:11 |
| corvus | tristanC: i don't think this needs to be customized; i think when the build page is ready (soon), we just make that the result. users can still set result_url to override it if necessary; but otherwise i don't think having the result link go directly to logs will be desirable. | 00:12 |
| corvus | but, at the moment, since the sql db is still technically optional, it's tricky. so maybe we just make the switch after we move to requiring it. | 00:13 |
| corvus | (or, i guess if we're really eager, we could say, if the sql db is present, use the build page url, otherwise use the log url) | 00:13 |
| corvus | sorry, earlier i said "result_url"; i meant "success_url" | 00:13 |
| tristanC | corvus: but that's not backward compatible, users may have automated system to fetch logs url from zuul comment... shouldn't this be a controlled behavior? | 00:17 |
| corvus | tristanC: we have an api for automated systems to find logs, that would be a great thing for folks to update to. | 00:21 |
| corvus | and i don't think we've promised indefinite backwards compatability for anything in zuul. | 00:22 |
| corvus | it certainly warrants a release note | 00:23 |
| clarkb | we can also advertise the zuul submits job method of processing artifacts that openstack uses if people want ideas for alternate implementations | 00:24 |
| corvus | but in general, our approach in zuul is that you should get the best working system by default; we try to avoid requiring folks opt-in to the good stuff. | 00:24 |
| corvus | clarkb: yeah, that should be fairly robust | 00:26 |
| corvus | if the zuul web app were not entirely client-side js, we could put a <link rel=...> tag in the build page html to point automated systems at the api endpoint for the build; but i'm not sure if we could do that with the hosting structure we have. | 00:28 |
| tristanC | corvus: it seems like many (if not all) releases introduces subtle changes to user facing functionality... it sounds better to make changes optional in the 3.x branch with a deprecation notice, and wait for a major release to force them by default... | 00:28 |
| corvus | i'm not sure why making changes in releases is bad | 00:29 |
| tristanC | corvus: iirc, SpamapS is looking forward upgrading zuul without having to change anything else | 00:29 |
| corvus | why upgrade if you don't want change? | 00:30 |
| tristanC | corvus: to get bug fixe? | 00:30 |
| corvus | i'm not sure we can satisfy everyone all the time here | 00:31 |
| tristanC | anyway, forcing the result comment change makes it easier, so i'm fine with it | 00:31 |
| corvus | i think we've been pretty up-front about the idea that zuul is under heavy development and will change rapidly, and is designed to be continuously deployed. we *do* try to avoid breaking zuul when upgrading, but i don't think we can ever promise not to break external systems that rely on ad-hoc zuul behaviors. | 00:32 |
| SpamapS | I'm not sure what has been ascribed to me? | 00:32 |
| corvus | like, we're not going to change the zuul job syntax in a backwards incompatible way for fun and without notice. but i do think we reserve the right to improve the web interface without making a big deal out of it. | 00:33 |
| tristanC | SpamapS: it was about the react interface, you said "< SpamapS> but.. can.. I just change my version pointer.. just once.. and not have to spend 2 hours mopping up? :-P" | 00:34 |
| SpamapS | Yes, that was regarding deployment tooling. | 00:34 |
| corvus | tristanC: anyway, if you're not in a hurry, i'm sure we can wait until v4, and if you want to put it in v3 with a feature flag, that's fine with me too. as long as, in the end, we end up with the nice thing as the only and default option. :) | 00:34 |
| corvus | (but i would totally just +2 a hard switch in v3 as well :) | 00:35 |
| SpamapS | As in, every time I have upgraded, I've had to move files, deploment rules, etc. etc. | 00:35 |
| corvus | i have to run now | 00:35 |
| tristanC | SpamapS: and if you have a script that scrap zuul comments for logs, then this feature is likely to require some mopping up | 00:35 |
| SpamapS | Yeah, I'd be sad if that stopped working suddenly. | 00:37 |
| SpamapS | But I don't have such a thing currently. | 00:37 |
| SpamapS | So I personally am OK this time. ;) | 00:37 |
| SpamapS | And was just thining I'd like the result url to be somewhere that I can use to find the variables set in the build, so I could use that to set an artifact ID/url/etc to go fetch in a post job later. | 00:38 |
| SpamapS | scraping comments isn't exactly something I'd expect to work perfectly, forever. | 00:38 |
| clarkb | ya I think using the api to fetch that data or having jobs trigger followup work as openstack does for log indexing is likely more robust long term | 00:40 |
| SpamapS | Yeah I had actually been thinking of doing a PR# based upload to S3 with a json doc for artifacts, but then I saw the build page and that's really what I want. | 00:47 |
| SpamapS | tobiash: I'm curious, with your GitHub setup, how do you enforce gating with Zuul? Since it's an app, I can't explicitly restrict branch protections to it, but if I don't let people have write access to the repo, they can't use labels on PR's... | 01:02 |
| SpamapS | Kind of feels like we need a way to have Zuul act like a real user so it can have branch protection access, or do something janky like use comment commands to add labels. | 01:03 |
| *** jesusaur has joined #zuul | 01:12 | |
| tristanC | corvus: forgot to mention, but could we also have a "buildset" endpoint to get all the build associated with an event? | 01:37 |
| tristanC | corvus: if so, then we may want to have a buildset page and use this is instead of individual build result, then we could have a dashboard similar to travis-ci | 01:38 |
| tristanC | corvus: it might also be better, as we could display in a single page, the job-output failure of all the jobs | 01:39 |
| SpamapS | tristanC: yes please, a buildset endpoint would be fantastic. | 01:39 |
| SpamapS | That would let us set buildset on the github status. | 01:39 |
| SpamapS | (I'd also like to see if we could get github checks API results in for each build) | 01:40 |
| tristanC | SpamapS: it seems like we should get those individual build result register with the new check api, then we could make the final zuul result comment a single link to the buildset page | 01:41 |
| SpamapS | ya that would be cool | 01:42 |
| *** spsurya has joined #zuul | 03:46 | |
| *** rlandy|rover|bbl is now known as rlandy|rover | 03:54 | |
| *** rlandy|rover has quit IRC | 04:17 | |
| *** bhavikdbavishi has joined #zuul | 04:22 | |
| *** rf0lc0 has joined #zuul | 04:53 | |
| *** jesusaur has quit IRC | 05:02 | |
| *** rfolco has quit IRC | 05:02 | |
| *** sshnaidm has quit IRC | 05:02 | |
| *** rcarrillocruz has quit IRC | 05:02 | |
| *** sshnaidm has joined #zuul | 05:09 | |
| *** rcarrillocruz has joined #zuul | 05:09 | |
| *** jesusaur has joined #zuul | 05:10 | |
| *** jpena|off has quit IRC | 05:22 | |
| *** jpena|off has joined #zuul | 05:23 | |
| *** bhavikdbavishi has quit IRC | 05:26 | |
| *** bhavikdbavishi has joined #zuul | 05:27 | |
| openstackgerrit | Merged openstack-infra/nodepool master: Add Fedora 29 testing https://review.openstack.org/618671 | 05:54 |
| *** pcaruana has joined #zuul | 07:06 | |
| *** quiquell|off is now known as quiquelll | 07:09 | |
| *** quiquelll is now known as quiquell | 07:09 | |
| *** hashar has joined #zuul | 07:41 | |
| *** quiquell is now known as quiquell|brb | 08:00 | |
| *** themroc has joined #zuul | 08:14 | |
| *** bhavikdbavishi has quit IRC | 08:21 | |
| *** bhavikdbavishi has joined #zuul | 08:22 | |
| *** hashar has quit IRC | 08:24 | |
| *** quiquell|brb is now known as quiquell | 08:28 | |
| *** gtema has joined #zuul | 08:40 | |
| quiquell | Good morning | 08:41 |
| *** dkehn has quit IRC | 08:46 | |
| *** avass has joined #zuul | 08:51 | |
| *** jpena|off is now known as jpena | 08:52 | |
| *** hashar has joined #zuul | 08:53 | |
| *** quiquell has quit IRC | 08:53 | |
| *** quiquell has joined #zuul | 08:54 | |
| *** quiquell has quit IRC | 08:54 | |
| *** quiquell has joined #zuul | 08:56 | |
| *** rcarrillocruz has quit IRC | 09:01 | |
| *** avass has quit IRC | 09:18 | |
| openstackgerrit | Tobias Henkel proposed openstack-infra/zuul master: WIP: Add spec for scale out scheduler https://review.openstack.org/621479 | 09:46 |
| *** avass has joined #zuul | 09:56 | |
| avass | tobiash: I think you might have made a small mistake with the executor change yesterday. | 09:57 |
| avass | should have been: for key in (node.get('host_keys') , []): not for key in node.get('host_keys', []): no? | 09:58 |
| *** bhavikdbavishi has quit IRC | 10:00 | |
| avass | tobiash: but that would just be a touple wouldn't it? since I got the update and i still get the same exception. Couldn't find the node class to figure out how it works. | 10:09 |
| *** panda|off is now known as panda | 10:18 | |
| *** hashar is now known as hasharAway | 10:46 | |
| *** electrofelix has joined #zuul | 10:58 | |
| *** chandankumar is now known as chkumar|out | 11:39 | |
| *** jpena is now known as jpena|lunch | 12:08 | |
| *** AJaeger has quit IRC | 12:43 | |
| *** rf0lc0 is now known as rfolco | 12:49 | |
| *** AJaeger has joined #zuul | 12:51 | |
| tobiash | avass: node is a dict so that should be correct | 12:52 |
| avass | tobiash: any chance the problem could be in that I am using static driver? | 12:53 |
| tobiash | ah, that's a missing piece of information | 12:53 |
| tobiash | what's your nodepool config? | 12:53 |
| avass | what do you need? | 12:54 |
| *** rlandy has joined #zuul | 12:55 | |
| *** rlandy is now known as rlandy|rover | 12:56 | |
| tobiash | avass: I think I've found the bug: https://git.zuul-ci.org/cgit/nodepool/tree/nodepool/driver/static/provider.py#n52 | 13:00 |
| tobiash | it just returns but is expected to return the list of keys where everywhere else the list of keys explicitly is defaulted to an empty list | 13:00 |
| *** jpena|lunch is now known as jpena | 13:04 | |
| avass | Ah, I see | 13:06 |
| tobiash | avass: but could you post your exception in zuul-executor you mentioned earlier? | 13:10 |
| tobiash | I want to understand why my fix from yesterday didn't fix this in zuul | 13:10 |
| avass | here? | 13:10 |
| tobiash | paste.openstack.org | 13:11 |
| openstackgerrit | Tobias Henkel proposed openstack-infra/nodepool master: Default host_keys to empty list in static driver https://review.openstack.org/629478 | 13:11 |
| avass | http://paste.openstack.org/show/740941/ | 13:11 |
| tobiash | in the meantime this should resolve your issue ^ | 13:11 |
| tobiash | ah now I understand, host_keys is set explicitly to None in nodepool | 13:13 |
| tobiash | and so the default isn't picked | 13:13 |
| avass | ah | 13:13 |
| tobiash | so the correct fix is https://review.openstack.org/629478 | 13:14 |
| tobiash | Shrews: ^ | 13:14 |
| tobiash | and this also explains why it works for me because I don't have windows static nodes, only dynamic ones | 13:15 |
| avass | thanks for the help | 13:21 |
| tobiash | no problem | 13:23 |
| Shrews | tobiash: +A'd | 13:34 |
| tobiash | \o/ | 13:34 |
| *** dkehn has joined #zuul | 13:49 | |
| dmsimard | thanks for charting the territory for building and publishing draft zuul-web builds during code review | 14:06 |
| dmsimard | managed to finally land it for ara as well and it's largely inspired from your work :) | 14:07 |
| *** hasharAway is now known as hashar | 14:15 | |
| mordred | dmsimard: woot! | 14:19 |
| mordred | tristanC: looking at the openapi patch - it occurs to me that it'll be wrong for whitelabeled installs. I don't think we need to block on that necessarily, but it's a thing we should ponder | 14:31 |
| mordred | tristanC: nevermind. you have, in fact, already thought about this :) | 14:33 |
| openstackgerrit | Merged openstack-infra/nodepool master: Default host_keys to empty list in static driver https://review.openstack.org/629478 | 14:34 |
| openstackgerrit | Merged openstack-infra/zuul master: Clean up command sockets on stop https://review.openstack.org/628990 | 14:40 |
| mordred | Shrews: TIL about super() in python3 and am much pleased | 14:42 |
| openstackgerrit | Merged openstack-infra/zuul master: Ensure command_socket is last thing to close https://review.openstack.org/628995 | 14:43 |
| AJaeger | mordred, pabelanger : on https://review.openstack.org/#/c/511853/ is a -1 by pabelanger from July 2018. pabelanger is that still valid? Could you two discuss the way forward, please? | 14:54 |
| mordred | AJaeger: I believe, based ona different patch, that we agreed to move forward with the single version for now and come back to refactoring into multiple later | 15:01 |
| mordred | AJaeger: although I'm starting to think that working through the pabelanger rework of the base job into base minimal first might make it easier to test some of the later portions of this stack | 15:02 |
| *** arxcruz is now known as arxcruz|ruck | 15:03 | |
| *** rlandy|rover is now known as rlandy | 15:04 | |
| Shrews | mordred: is there more context to that statement? | 15:04 |
| tobiash | mordred probably meant that you don't need to write super(Foo, this) | 15:06 |
| Shrews | i'm going to chalk it up to Random Musing Wednesdays | 15:06 |
| mordred | Shrews: I was reading your config refactor patches and yes, as tobiash says, learned that super(Foo, this) isn't needed in python3 any longer | 15:08 |
| Shrews | ah ha | 15:09 |
| Shrews | i liked my theory better | 15:09 |
| *** ssbarnea has quit IRC | 15:10 | |
| *** ssbarnea|rover has joined #zuul | 15:10 | |
| *** hashar has quit IRC | 15:31 | |
| openstackgerrit | Merged openstack-infra/zuul master: Document missing executor stats https://review.openstack.org/626749 | 15:41 |
| openstackgerrit | Tobias Henkel proposed openstack-infra/zuul master: Enforce max-job-timeout for jobs without configured timeout https://review.openstack.org/629552 | 15:42 |
| openstackgerrit | David Moreau Simard proposed openstack-infra/zuul-jobs master: Add support for CentOS and RHEL for the install-nodejs role https://review.openstack.org/629554 | 15:45 |
| *** quiquell is now known as quiquell|off | 15:45 | |
| Shrews | oh that's interesting. i've never seen nodepool never be able to acquire a lock | 15:47 |
| openstackgerrit | Merged openstack-infra/zuul master: Fix skipped job counted as failed https://review.openstack.org/625910 | 15:49 |
| fungi | where's the source code for the github app? or is that even an actual software thing which would have source code? | 15:51 |
| *** bhavikdbavishi has joined #zuul | 15:54 | |
| tobiash | fungi: in github speech a github app is not necessary a software but more or less a set of settings for webhook urls, auth mechanism | 15:56 |
| fungi | tobiash: thanks, i suspected that might be the case as i couldn't find anything which seemed like source code | 15:56 |
| tobiash | you can define a github app and 'install' it on repos. Installing means that you allow the owner of that github app to access your repo | 15:57 |
| tobiash | the owner of the github app has a private key that can be used to generate api keys to access these repos | 15:57 |
| tobiash | most github apps however have some source code | 15:57 |
| tobiash | e.g. zuul itself is the according software part | 15:58 |
| tobiash | that gets webhooks and can access the api with that private key | 15:58 |
| *** avass has quit IRC | 15:58 | |
| mordred | dmsimard: I think you're going to add a test to that nodejs patch - when you do, maybe also do the include: trick based on os_family like we do other places | 16:03 |
| *** pcaruana has quit IRC | 16:03 | |
| *** bhavikdbavishi has quit IRC | 16:04 | |
| *** bhavikdbavishi has joined #zuul | 16:04 | |
| *** chkumar|out is now known as chandankumar | 16:27 | |
| fungi | thanks tobiash! | 16:33 |
| *** jpena_ has joined #zuul | 16:36 | |
| *** mhu has quit IRC | 16:38 | |
| *** fbo has quit IRC | 16:39 | |
| *** nhicher has quit IRC | 16:39 | |
| openstackgerrit | Paul Belanger proposed openstack-infra/zuul-jobs master: Add validate-dco-license role https://review.openstack.org/629565 | 16:39 |
| *** pabelanger has quit IRC | 16:39 | |
| *** jpena has quit IRC | 16:39 | |
| *** pabelanger has joined #zuul | 16:40 | |
| pabelanger | fungi: https://review.openstack.org/629565 is a follow up from yesterday dco request | 16:42 |
| pabelanger | err, dco license check request | 16:42 |
| fungi | thanks pabelanger! | 16:42 |
| *** rlandy is now known as rlandy|brb | 16:46 | |
| fungi | pabelanger: does that need a node, or just checks the commit on the executor? | 16:47 |
| pabelanger | fungi: nope, you can save yourself one from nodepool and just use executor | 16:52 |
| pabelanger | I wonder if we should also add the job into zuul-jobs too | 16:53 |
| fungi | okay, so empty nodeset, got it | 16:53 |
| pabelanger | eg: https://github.com/ansible-network/zuul-config/blob/master/zuul.d/jobs.yaml#L70 | 16:53 |
| dmsimard | mordred: I started doing the include distro thing | 16:54 |
| dmsimard | But then realized it's just an additional block | 16:54 |
| dmsimard | I didn't really want to fan out in like 5 different files for adding a new block | 16:54 |
| *** jkt has joined #zuul | 16:55 | |
| jkt | hi, I'm trying to deply zuul v3 on centos 7 via ansible. I wonder if someone tested the redhat recipes from ansible-role-zuul? | 16:55 |
| jkt | because there's apparently no python3-devel on centos+epel, but there's python34-devel etc | 16:56 |
| pabelanger | jkt: no, since centos-7 doesn't have python3 by default. Fedora will work | 16:56 |
| pabelanger | hopefully once centos-8 lands, I'll update the role to suppport it | 16:56 |
| pabelanger | support* | 16:56 |
| jkt | pabelanger: ah, so it's only targetting fedora ATM | 16:56 |
| jkt | pabelanger: are you interested in patches which make this work on el7? | 16:57 |
| jkt | I used to work in Puppet, and this is my first attempt at ansible to learn some new bits | 16:57 |
| pabelanger | jkt: I'd much rather hold off until centos-8 | 16:57 |
| pabelanger | that will be python3 by default | 16:57 |
| jkt | pabelanger: but that's like six months in future at least, isn't it | 16:58 |
| pabelanger | jkt: not sure if timeline public TBH. there is RHEL 8 beta, so we could start targeting that | 16:58 |
| pabelanger | jkt: fwiw: fedora works fine, I use it locally for testing | 16:59 |
| pabelanger | and we gate on it | 16:59 |
| jkt | pabelanger: don't get me wrong, I would love to get my hands on el8 too, but my existing zuul-v2 + turbo-hipster setup is slowly but steadily going to explode, eventually | 17:00 |
| jkt | and waiting for el8 is, well, a nice excuse for me of course, but... | 17:00 |
| fungi | would the containerized deployments work on centos 7? | 17:02 |
| openstackgerrit | Monty Taylor proposed openstack-infra/zuul-jobs master: Add role to move docs and artifacts to log root https://review.openstack.org/629571 | 17:04 |
| mordred | corvus: how's that look? ^^ | 17:04 |
| mordred | pabelanger: aren't the software factory folks pulling in a software collection or something for centos support? | 17:05 |
| clarkb | note zuul needs python 3.5 or greater | 17:06 |
| clarkb | the type annotation stuff isnt valid in 3.4 | 17:06 |
| jkt | there's 3.6 in EPEL as well | 17:07 |
| corvus | mordred: lgtm with suggested improvements | 17:07 |
| *** rlandy|brb is now known as rlandy | 17:09 | |
| openstackgerrit | Monty Taylor proposed openstack-infra/zuul-jobs master: Add role to move docs and artifacts to log root https://review.openstack.org/629571 | 17:16 |
| mordred | corvus: I have applied your suggested improvements | 17:16 |
| mordred | oh - you know what - one more change | 17:16 |
| openstackgerrit | Monty Taylor proposed openstack-infra/zuul-jobs master: Add role to move docs and artifacts to log root https://review.openstack.org/629571 | 17:17 |
| mordred | there. that's simplier | 17:17 |
| pabelanger | mordred: yah, software collections. However, I think python gets installed into an odd place /opt maybe? | 17:18 |
| mordred | jkt: 3.6 totally works - I think the majority of deployers are actually running 3.6 | 17:19 |
| jlk | Off topic, but GitHub has a new hire, VP of Engineering, who's first name is Dana. Her GitHub handle is 'danaiszuul' | 17:23 |
| dmsimard | jkt: for what it's worth, software factory provides packages for zuul on centos 7 but they are built against software collections | 17:24 |
| pabelanger | jlk: nice | 17:25 |
| *** themroc has quit IRC | 17:25 | |
| SpamapS | jlk: April Fools idea: she announces they're replacing all github CI apps with Zuul. "Dana says there is no CI...." | 17:31 |
| jlk | lol | 17:31 |
| openstackgerrit | Monty Taylor proposed openstack-infra/zuul-jobs master: Add role to move docs and artifacts to log root https://review.openstack.org/629571 | 17:33 |
| mordred | SpamapS: ++ | 17:33 |
| pabelanger | q: are we on track for a release of zuul / nodepool this week? | 17:35 |
| clarkb | openstack infra is running fairly up to date versions of zuul and nodepool both | 17:36 |
| clarkb | I haven't noticed any issues with them after corvus fixed the github reconfigure bug and the window scaling node request bug | 17:37 |
| pabelanger | cool, I wouldn't mind one to get the new executor zone stuff | 17:38 |
| mordred | tobiash, pabelanger: since you've reviewed the log output stuff before, wanna take a look at 629571? new (simpler) idea is just to have a role that moves things into the logs dir on the executor and not to modify the upload-logs role | 17:39 |
| mordred | that way the interface is the dirs on the remote node, openstack can apply the new role to upload interim artifacts to logs, but other deployers can choose to deal with interim artifacts in some other way | 17:40 |
| pabelanger | mordred: sure, I'll look after I grab some food | 17:40 |
| mordred | pabelanger: sweet - thanks! I think it should make your concern about making upload-logs do to much go away | 17:41 |
| *** chandankumar is now known as chkumar|out | 17:42 | |
| pabelanger | ++ | 17:44 |
| tobiash | mordred: you're aware that this role will only work within a trusted playbook? | 17:48 |
| openstackgerrit | Monty Taylor proposed openstack-infra/zuul-base-jobs master: Add fetch-output to base jobs https://review.openstack.org/628975 | 17:51 |
| openstackgerrit | Monty Taylor proposed openstack-infra/zuul-base-jobs master: Ignore errors on ssh key removal https://review.openstack.org/628976 | 17:51 |
| openstackgerrit | Monty Taylor proposed openstack-infra/zuul-base-jobs master: Add merge-output-to-logs to base job https://review.openstack.org/629604 | 17:51 |
| mordred | tobiash: yah. it's intended to be used in a base job's post playbook | 17:51 |
| tobiash | mordred: commented | 17:51 |
| mordred | tobiash: ++ will fix | 17:52 |
| openstackgerrit | Monty Taylor proposed openstack-infra/zuul-jobs master: Add role to move docs and artifacts to log root https://review.openstack.org/629571 | 17:52 |
| mordred | tobiash: how's that look? | 17:53 |
| tobiash | mordred: lgtm | 17:53 |
| mordred | \o/ | 17:53 |
| *** sshnaidm is now known as sshnaidm|afk | 18:01 | |
| fungi | pabelanger: when you say the ansible/awx repo is using that dco check job, poking around recently merged pull requests for that repo i'm not seeing that job being run on them | 18:04 |
| fungi | for that matter, it doesn't look like anyone's adding signed-off-by to their commit messages in that repo at all | 18:06 |
| openstackgerrit | Monty Taylor proposed openstack-infra/zuul-base-jobs master: Add merge-output-to-logs to base job https://review.openstack.org/629604 | 18:07 |
| *** gtema has quit IRC | 18:07 | |
| fungi | or was mordred just saying that ansible/awx is using zuul to gate changes, and you were saying that ansible-network is using that dco check job? | 18:07 |
| mordred | fungi: I think that's maybe what the thing is | 18:08 |
| fungi | yeah, making sense now. sorrt for the confusion! | 18:09 |
| fungi | mordred != pabelanger ;) | 18:09 |
| *** jpena_ is now known as jpena|off | 18:12 | |
| openstackgerrit | Merged openstack-infra/nodepool master: Extract out common config parsing for ConfigPool https://review.openstack.org/621642 | 18:14 |
| *** bhavikdbavishi1 has joined #zuul | 18:15 | |
| *** bhavikdbavishi has quit IRC | 18:16 | |
| *** bhavikdbavishi1 is now known as bhavikdbavishi | 18:16 | |
| mordred | fungi: wait - really? I kind of thought pabelanger and I were the same person | 18:16 |
| fungi | shocking, yes | 18:17 |
| ssbarnea|rover | does zuul have a mechanism where it can trigger a job when another one is finishing (and passing some metadata)? like job chaining? | 18:17 |
| fungi | it has job dependencies and the ability to return information ni variables which are supplied in those dependent jobs | 18:18 |
| fungi | ssbarnea|rover: https://zuul-ci.org/docs/zuul/user/jobs.html#return-values | 18:19 |
| ssbarnea|rover | fungi: any example? i can explain what I want to do and you can tell me if this would be a good/bad idea. | 18:19 |
| ssbarnea|rover | as part of our jobs we produce the reproducer-quickstart.sh script, which is supposed to reproduce the same job execution on a dev machine. This script is currently not tested by CI. | 18:20 |
| *** bhavikdbavishi has quit IRC | 18:20 | |
| fungi | i see where you're going with this ;) | 18:20 |
| mordred | yeah - I think that has the potential to be a great idea | 18:21 |
| ssbarnea|rover | I want to start a test-repro job that runs at least one of these, so we would now that the reproducer is ... reproducable :D | 18:21 |
| fungi | ssbarnea|rover: if the reproducer-quickstart.sh script is archived with the job logs, then you could indeed have a child job which retrieved that from the supplied log url of the parent job and ran it | 18:21 |
| ssbarnea|rover | fungi: this is collected. as long I know the parent job, i should be able to find the file on logs server. time to make a POC test. | 18:23 |
| fungi | ssbarnea|rover: yeah, you shouldn't even need to "know" the parent job build, better to just return the log url as part of the zuul_return and then have the child job use the returned url | 18:24 |
| ssbarnea|rover | on the same logic we could delay fat jobs to run after linting is passing in order to lower the load, right? | 18:24 |
| ssbarnea|rover | i clearly need to deploy zuul locally to play with it more | 18:24 |
| fungi | ssbarnea|rover: yes, also possible, even zuul v2 could do that. we've experimented with it in the past, and some projects do it to a limited degree now, but it's not without its downsides | 18:24 |
| fungi | in particular, 1. the time it takes to return results from the "fatter" jobs is increased by the time to run the "slimmer" ones, 2. it can increase the number of change iterations i the (common) case where you have linting issues but also some deeper functional or integration problem in your patch | 18:26 |
| fungi | ssbarnea|rover: as for deploying zuul locally, we have container images and a quickstart walkthrough for deploying a fully-integrated zuul+nodepool+gerrit | 18:27 |
| fungi | ssbarnea|rover: https://zuul-ci.org/start | 18:29 |
| fungi | corvus: did a live demo of that in berlin | 18:30 |
| pabelanger | fungi: ansible-network does, not sure about awx | 18:30 |
| pabelanger | fungi: https://github.com/ansible-network/cloud_vpn/pull/60 for PR for example | 18:30 |
| fungi | yep, figured it out. thanks! | 18:31 |
| fungi | that's actually the precise example pr i passed along ;) | 18:31 |
| pabelanger | ha, nice | 18:31 |
| fungi | most recent merged pr for the first pinned repo in your org, so it was an obvious choice | 18:31 |
| * fungi is nothing if not lazy | 18:31 | |
| jkt | dmsimard: thanks, but I think I'm OK with installing via pip; I was just wondering if the ansible playbooks are known to work on el7 at all | 18:33 |
| ssbarnea|rover | i found a bug: WARNING: The http_proxy variable is not set. Defaulting to a blank string. | 18:36 |
| ssbarnea|rover | this was a lie, the http_proxy variable was defined. | 18:36 |
| pabelanger | jkt: at one time yes, when it was zuul v2.5. But once zuulv3 came along and python3 requirement, testing was removed | 18:36 |
| ssbarnea|rover | something very weird is happening with gerrit first account creation dialog, probably related to my 1pasword or some other firefox extension: once start typing the Full Name field, the 2nd field (suername) vanishes from the screen! very weird ... | 18:43 |
| ssbarnea|rover | nope, is not browser. i tried with Safari/Firefox/Chrome even in incognito: the username disapears. | 18:45 |
| fungi | looks like it's just referencing whatever the latest gerritcodereview/gerrit image is on dockerhub | 18:51 |
| fungi | https://hub.docker.com/r/gerritcodereview/gerrit | 18:51 |
| fungi | Updated 21 days ago | 18:52 |
| fungi | so guessing it's gerrit 2.16.2 | 18:52 |
| fungi | might be a new gerrit bug you're encountering? | 18:52 |
| *** electrofelix has quit IRC | 18:55 | |
| ssbarnea|rover | fungi: maybe https://youtu.be/1Ni_r7lOLS4 | 18:58 |
| fungi | wow, yeah that's strange | 19:00 |
| fungi | you could probably edit the docker compose file to refer to a specific (older) gerrit image and see if it's any better | 19:00 |
| *** panda has quit IRC | 19:19 | |
| *** panda has joined #zuul | 19:21 | |
| openstackgerrit | Tobias Henkel proposed openstack-infra/zuul master: Enforce max-job-timeout for jobs without configured timeout https://review.openstack.org/629552 | 19:29 |
| openstackgerrit | Merged openstack-infra/zuul master: Add cgroup support to ram sensor https://review.openstack.org/549506 | 19:32 |
| *** hashar has joined #zuul | 19:43 | |
| ssbarnea|rover | fungi: interesting discovery, "sudo docker-compose..." did trigger the error about environment variable but if I removed sudo, it worked. this means sudo is hiding it (even you are already root). this means the docs are misleading. We should write "sudo -i docker-compose..." which is ok. | 19:47 |
| fungi | yeah, sudo likely filters out the proxy envvar | 19:47 |
| fungi | you could configure sudo not to do that, or explicitly copy the value into the sudo environment for that run, or... | 19:48 |
| fungi | by default sudo only carries over a very limited whitelist of envvars from the calling environment | 19:48 |
| clarkb | sudo is used because docker is a privileged process | 19:49 |
| fungi | at least if env_reset is set anyway | 19:49 |
| clarkb | maybe have a note that sudo will work for many, but if you have special needs (like proxies) then execute it as root or something | 19:49 |
| fungi | according to the sudoers(5) manpage, by default the only envvars preserved are TERM, PATH, HOME, MAIL, SHELL, LOGNAME, USER and SUDO_* | 19:50 |
| openstackgerrit | Sorin Sbarnea proposed openstack-infra/zuul master: docs: Added missing -i on docker-compose up command https://review.openstack.org/629652 | 19:52 |
| ssbarnea|rover | i was tempted to add a Makefile there that so you could easily run it "make run", but i am not sure if people like that. | 19:53 |
| ssbarnea|rover | i was tempted to adopt docker (gerrit) use for git-review testing which now has the vary bad habbit to leave you with a big number of gerrit servers running even after finishing the tests. CPU and memory hog. | 19:55 |
| ssbarnea|rover | clarkb: fungi : i do love the ease of docker testing approach with zuul! thanks. | 20:04 |
| ssbarnea|rover | i found another issue now but I will narrow it down myself, OSError: [Errno 97] Address family not supported by protocol | 20:05 |
| ssbarnea|rover | i probably need to find the right mix of container tags to use, using latest is probably not going to provide a fully working mix. | 20:06 |
| fungi | ssbarnea|rover: i can't take credit for the docker quickstart. i think it was mostly (or perhaps entirely) corvus who put that together | 20:08 |
| ssbarnea|rover | kudos to all invoved! | 20:08 |
| ssbarnea|rover | the problem with vanishing username happens even with the 2.14.3 gerrit container | 20:18 |
| SpamapS | Normally you don't need sudo to docker if you are in a group that can access the docker socket | 20:21 |
| clarkb | SpamapS: ya but that isn't recommened aiui as it gives that user fulltime root access ability | 20:21 |
| clarkb | (though not any worse than passwordless sudo) | 20:22 |
| SpamapS | Correct | 20:30 |
| ssbarnea|rover | i am on mac and docker works very well without sudo, so we could consider removing the sudo from docker-compose command. | 20:32 |
| ssbarnea|rover | i started with gerrit 2.15.7 and the behavior of create account dialog is different now, the username is not disapearing anymore but I am still unable to click save button. | 20:33 |
| ssbarnea|rover | probably that for testing purposes we should automate the creation of first user account and avoid these bugs. | 20:34 |
| ssbarnea|rover | not sure if they are bugs in gerrit or only on the way we setup it initially | 20:34 |
| ssbarnea|rover | good news: switching to old ui allowed me to create the first account | 20:36 |
| openstackgerrit | Merged openstack-infra/zuul master: docs: Added missing -i on docker-compose up command https://review.openstack.org/629652 | 20:43 |
| fungi | ssbarnea|rover: the zuul integration test jobs do automate gerrit admin user account creation i believe | 20:59 |
| fungi | looks like the username is "admin" and the password is "secret" | 21:08 |
| openstackgerrit | Merged openstack-infra/nodepool master: Extract common config parsing for ProviderConfig https://review.openstack.org/625094 | 21:41 |
| *** hashar has quit IRC | 21:57 | |
| *** rlandy has quit IRC | 23:25 | |
| tristanC | pabelanger: note that scl are available and provided by CentOS, e.g.: http://mirror.centos.org/centos/7/sclo/x86_64/rh/rh-python36/ | 23:48 |
| tristanC | it may not be as easy to use as a system wide python, but python3 is available | 23:48 |
| openstackgerrit | John Studarus proposed openstack-infra/nodepool master: Work in Progress https://review.openstack.org/629688 | 23:57 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!