Friday, 2018-08-10

*** tflink_ has quit IRC00:55
*** tflink has joined #zuul01:04
tristanCmordred: that rings a bell, i'll have a look01:07
tristanCpabelanger: thanks, i replied that add_host can't be used by untrusted job, and added host doesn't stay between pre, run and post01:08
openstackgerritIan Wienand proposed openstack-infra/zuul-jobs master: Add openafs-client role  https://review.openstack.org/58933401:15
openstackgerritIan Wienand proposed openstack-infra/zuul-jobs master: Add kerberos-client role  https://review.openstack.org/59059101:15
pabelangertristanC: yah, wonder if there is a way to dump in-memory inventory via ansible.  But also thought we'd let add_host be untrusted, or maybe mis-remembering.  I always thought we could add blacklist support of IPs for add_host to block address in control plane, for example01:16
tristanCpabelanger: there is also the difficulty to pass the pods' name from the pre run to the run phase01:20
tristanCpabelanger: but yes, if we can add_host from untrusted, 590092 is not necessary01:21
tristanCdoing ip blacklist sounds tricky though01:22
openstackgerritTristan Cacqueray proposed openstack-infra/zuul master: web: fix job required-projects list  https://review.openstack.org/59059401:31
*** tflink has quit IRC01:41
*** tflink has joined #zuul01:43
*** elyezer has quit IRC02:36
openstackgerritMerged openstack-infra/zuul master: Fix wrong matched project template  https://review.openstack.org/58820102:47
*** elyezer has joined #zuul02:48
openstackgerritIan Wienand proposed openstack-infra/zuul-jobs master: Add kerberos-client role  https://review.openstack.org/59059103:19
openstackgerritIan Wienand proposed openstack-infra/zuul-jobs master: Add openafs-client role  https://review.openstack.org/58933403:19
*** ianychoi has joined #zuul03:56
*** smyers has quit IRC04:53
*** smyers has joined #zuul04:55
*** pcaruana has joined #zuul06:43
*** goern has quit IRC06:57
openstackgerritTobias Henkel proposed openstack-infra/zuul master: Add --check-config option to zuul scheduler  https://review.openstack.org/54216007:17
*** jpena|off is now known as jpena07:55
*** gtema has joined #zuul08:25
openstackgerritTobias Henkel proposed openstack-infra/zuul master: Fix stuck job caused by exception during repo update  https://review.openstack.org/59069708:27
*** ssbarnea has quit IRC08:52
openstackgerritMatthieu Huin proposed openstack-infra/nodepool master: Do not abort node launch if failed node cannot be deleted  https://review.openstack.org/58985408:59
tobiashmhu: responded on ^09:05
mhutobiash thx!09:11
mhutobiash so the minimal info needed for node deletion would be the external id, the ips and the provider right?09:13
mhuam I forgetting smth?09:13
tobiashmhu: I don't think you need the ips but you might need the pool09:14
tobiashbut you can look into the DeletedNodeWorker to see which information it uses09:14
*** ssbarnea has joined #zuul09:31
*** panda|ruck|off is now known as panda|ruck10:33
*** jpena is now known as jpena|lunch11:06
mordredit should only need the external id - from a cloud api perspective11:28
mordredips, if there are any, are deleted as part of the delete_server call11:28
*** jpena|lunch is now known as jpena12:02
tobiashmordred: you're an openstack workflow expert and maybe you have an idea/opinion12:28
mordreduhoh12:28
tobiashmordred: I have many projects that use basically the same image but with different cache content12:28
tobiashso the current workflow is to have many images and each project wants to have a min-ready12:29
tobiash-> bad12:29
tobiashmordred: is it possible to clone-and-attach a volume directly when booting an image?12:29
tobiash(and making it auto-delete)12:29
tobiashhrm, that won;t solve the min-ready12:30
tobiashnevermind12:30
tobiashwe probably would need to boot the images with min-ready and attach a clone of a cache volume on assignment to a node request12:30
pabelangeryah, would be interested in hearing how images are managed for others with cache (git repos) content in them.  Also consider doing something like volume / AFS, but so far learning toward dedicated images for teams12:31
pabelangerbut, min-ready 0 in most cases12:31
tobiashpabelanger: that's our current approach but the teams are not happy with min-ready 012:32
tobiash:/12:32
pabelangerThe other things I started thinking about, is how to stop a user in tenant A use image in tenant B.  thinking the first task in a pre-run job would be to use some regex to validate nodepool.label, based on something like tenantA-centos-7 / tenantB-centos-7.  Then fail the job if they use the wrong one.12:33
pabelangertobiash: yah, if a fast cloud, min-ready 0 isn't an issue12:33
tobiashpabelanger: we discussed a whitelist for labels in the tenant config12:34
tobiasha few months ago12:34
pabelangertobiash: yah, remember, haven't looked into where that landed12:34
tobiashpabelanger: our linux images typically boot in 50-60 seconds, but windows take 5 minutes12:34
openstackgerritTobias Henkel proposed openstack-infra/zuul master: Fix permanently broken git cache  https://review.openstack.org/59076112:45
openstackgerritTobias Henkel proposed openstack-infra/zuul master: Fix permanently broken git cache  https://review.openstack.org/59076112:54
tobiashthat fixes an issue with permanently broken caches we have almost every time a compute node with an executor on it crashes ^12:58
tobiashand this currently happens more often than I want it to happen atm :/13:00
mordredtobiash: well, it IS possible to do what you're looking for with volumes, but I agree it doesn't help with min-ready13:01
mordredtobiash: we've been pondering if it would be better to stop having in-image cache if we could have per-cloud-region git mirrors (oh, pabelanger said that already)13:02
mordredtobiash: but I'm guessing that cloning from your local git infrastructure every time isn't workable for you13:02
tobiashmordred: regarding docker images we definitely want to have in image caching13:03
tobiashmordred: atm we don't do git caching (other than what the executor does)13:03
tobiashbut what would kill us is to not do docker caching13:03
tobiash(we have projects that use 15GB docker images)13:03
mordredtobiash: have you suggested to them that 15G docker images are rather large? :)13:04
tobiashmordred: of course...13:05
mordred:)13:05
tobiashbut the toolchains they use are let's say not optimized for being used in docker13:05
mordredwell - as mentioned above - you could do clone/attach of a cache volume when an node is assigned13:06
tobiashe.g. pull in cuda and you get the compiler + 5gb sdk, ui tools etc13:06
mordredfor you personally that sholnd't be too bad, because IIRC you're using ceph there -so those volume clones should be near-instant COW operations13:06
tobiashyes, that would work13:07
mordredand you can make a volume from an image13:07
tobiashwe would have to reconfigure and restart docker then to use the graph from vdb13:07
mordredoh - yeah. hrm13:07
mordredwel - you could do that in the pre-playbook of your base job13:07
tobiashyes that would be possible13:07
mordredwe could teach nodepool how to do this probably without too much pain13:08
mordredespecially if we let nodepool manage the cache volumes by managing them as images13:08
tobiashthe only problem is that we might need to restructure the nodepool data structure13:08
tobiashthe min-ready nodes would need to have multiple labels attached13:09
mordredyah. it'll take some thought - but from an openstack workflow POV it should be both possible and not terribly inefficient13:09
tobiashcool13:09
tobiashso maybe a friday afternoon project in a few months ;)13:10
pabelangeryah, regional git mirror might also be cool too13:17
*** samccann has joined #zuul13:22
*** dmsimard has quit IRC13:26
*** dmsimard has joined #zuul13:31
mordredpabelanger: ++13:54
openstackgerritMerged openstack-infra/zuul master: web: fix job required-projects list  https://review.openstack.org/59059414:47
corvustobiash: https://review.openstack.org/589975  is ready now -- let me know if it matches your thinking15:00
tobiashcorvus: great, will have a look after dinner15:00
clarkbI can't vouch for tobiash's thinking but the change lgtm15:15
openstackgerritPaul Belanger proposed openstack-infra/zuul-jobs master: Add nodepool info to test-emit-job-header  https://review.openstack.org/55794715:15
pabelangerclarkb: mordred: corvus: could I get a review of the stack at ^, adds nodepool info into job logs now.15:20
pabelangerhttps://logs.rdoproject.org/15/15415/1/check/tox-docs/0478753/job-output.txt.gz#_2018-08-10_15_17_40_255434 shows what the output would be15:20
pabelangerfrom rdoproject15:20
clarkbpabelanger: does that work when running gainst localhost?15:21
clarkboh its a !localhost15:21
pabelangerclarkb: yah, we skip that15:21
clarkbpabelanger: does that role run only against localhost? otherwise I think we will print all that inventory info for each node right? (since its looping overall of them directly)15:23
clarkbpabelanger: looks like the role runs against only localhost then we loop over all hosts in inventory that are not localhost15:26
clarkbthat seems odd, but given our history trying t oget this right also seems to be correct15:26
corvuspabelanger: what if one of those pieces of info is missing?  (ie, is a container?)15:27
pabelangerclarkb: yah, we should only run it against localhost15:29
pabelangercorvus: good point, we'll have checks for fields that will be missing15:30
Shrewsshould we stop using with_* for loops and begin using the recommended 'loop' syntax?15:31
Shrewsper https://docs.ansible.com/ansible/latest/user_guide/playbooks_loops.html#migrating-from-with-x-to-loop15:31
Shrewsi don't know of any planned deprecation, fwiw15:32
pabelangermaybe, that patchset is a little old15:32
pabelangerbut also don't see replacement for with_inventory_hostname on that page15:33
Shrewspabelanger: https://docs.ansible.com/ansible/latest/user_guide/playbooks_loops.html#looping-over-the-inventory15:33
corvusShrews: my understanding is that they are planning the deprecation now :)15:33
pabelangerShrews: ++15:33
mordredyah - I've been using loop: for the new stuff I've been writing for update-cfg-mgmt just to be future proof15:34
mordredwe've got a while yet before we need to, you know, hard-migrate or anything15:34
pabelangercorvus: containers should have a nodepool.provider / nodepool.label right? and interface_ip is likely optional15:44
corvuspabelanger: it was the ip that caught my attention, yes15:45
pabelangerack15:46
openstackgerritPaul Belanger proposed openstack-infra/zuul-jobs master: Add nodepool info to test-emit-job-header  https://review.openstack.org/55794715:46
openstackgerritPaul Belanger proposed openstack-infra/zuul-jobs master: Add nodepool info to test-emit-job-header  https://review.openstack.org/55794715:51
openstackgerritPaul Belanger proposed openstack-infra/zuul-jobs master: Add nodepool info to test-emit-job-header  https://review.openstack.org/55794715:57
pabelangercorvus: mordred: clarkb: Shrews: ^ update for condition check and new loop syntax16:01
pabelangerhttps://logs.rdoproject.org/15/15415/4/check/tox-docs/2ce861f/job-output.txt.gz#_2018-08-10_15_59_21_231353 is output16:01
clarkbTIL there are three different ways to do that lookup that are identical16:03
clarkbactually, 416:04
pabelangerfirst time using query for me16:05
corvuspabelanger: has your base job rework happened yet (is that being dynamically tested)?16:05
pabelangeroh, query is same as lookup, except it will return list16:05
pabelangercorvus: not for zuul.o.o yet, but have done it in rdoproject, how we can test16:06
clarkbwith_inventory_hostnames, lookup('inventory_hostnames', foo, wantlist=True), query('inventory_hostnames' and q('inventory_hostnames'. But now I have learned about ansible loops16:06
pabelangerhttps://review.rdoproject.org/r/15415 was patch in rdo16:06
corvuspabelanger: so that's a live test of the zuul-jobs change in rdo?16:07
pabelangercorvus: yes16:08
corvuspabelanger: (a) that is awesome.  (b) that is sufficient testing for me.  +3  :)16:08
pabelangeryay16:08
tobiashcorvus: I'm +3 with comments on 58997516:17
*** jpena is now known as jpena|off16:22
corvustobiash: okay.  i'd be okay with those changes; i just didn't want to reach beyond my comfort area16:22
tobiashcorvus: I think I can do these changes together with cache update on pr event after my vacation16:24
tobiashcorvus: I'll be officially back on 3rd of september16:30
tobiashbut I might be doing some reviews from time to time16:30
clarkbtobiash: any concern that github could allow a branch to be created as protected?16:31
clarkbas a future change? might be worthwhile being cautious in zuul about that?16:31
tobiashclarkb: I think the api cannot do that16:32
tobiasha git push to a new branch must be unprotected by definition16:32
clarkbtobiash: the git push yes, but as mordred pointed out you can also create them via the web ui?16:32
tobiashthe only method would be to allow branch creates in the ui to be protected from the beginning16:32
tobiashI don't think that fits into githubs usage model as branch protection settings are pretty complex16:34
mordredyah. and even creating through the webui it's a simple "create" button - there's no options on it16:34
tobiashand as long as github doesn't deliver branch protection events our only option to add new protected branches on the fly is to get that information on events related to this branch and update the cache accordingly16:35
tobiashlike pr updated should later check the branch protection and update the cache + eventually trigger a tenant reconfig before delivering the event to the scheduler loop16:36
tobiashclarkb: when we have that it actually doesn't matter if we add a new branch as protected or unprotected to the cache as it gets updated with real information before usage16:37
openstackgerritMerged openstack-infra/zuul master: Cache branches in connections/sources  https://review.openstack.org/58997516:39
clarkbya16:40
*** panda|ruck is now known as panda|ruck|off16:48
*** gtema has quit IRC16:49
openstackgerritTobias Henkel proposed openstack-infra/zuul master: Tolerate missing project  https://review.openstack.org/57987216:52
mordredpabelanger, tristanC, corvus, tobiash: I just left a comment on https://review.openstack.org/#/c/590092 - which just happened to coincide with a thing I was pondering anyway17:31
corvusmordred: does the ssh key stuff described in http://specs.openstack.org/openstack-infra/infra-specs/specs/zuulv3.html#continuous-deployment help?17:36
mordredcorvus: oh - yeah - it does17:37
corvusmordred: though, probably something something config-projects or post-review or something :)17:38
pabelangerreading17:38
mordredcorvus: we could them put the git.openstack.org/openstack-infra/system-config public key into the zuul user on bridge.openstack.org17:38
mordredand simply allowing add_host: to be used by users would complete the circle17:39
mordredcorvus: but yes, also something something config-projects / post-reivew or something :)17:39
corvusmordred: yep.  and as long as that key is only used in a trusted context, that should be safe17:39
mordred++17:39
corvuswhat was the hangup on add_host again?17:39
mordredthere wasn't one17:39
mordredwe just need to unrestrict it17:39
corvusi think pabelanger pointed out an issue in email?17:40
mordredbut I didn't get around to doing that yet because of the ssh key17:40
mordredoh? /me goes to read17:40
pabelangerI completely for got about http://specs.openstack.org/openstack-infra/infra-specs/specs/zuulv3.html#continuous-deployment ++17:40
corvusoh the ssh key issue *was* the hangup?17:40
mordredyup17:40
corvushttp://lists.zuul-ci.org/pipermail/zuul-discuss/2018-June/000458.html17:41
corvusyes that was it :)17:41
mordredso - it seems if we implement that part of the spec, we'll be good to do the thing that that part of the spec was writen to allow us to do17:41
corvusmordred: \o/17:41
corvusi actually don't think it'll be that hard at this point.  the basic patterns for almost all of that have been established (zuul generating and serving keys, trusted contexts, ssh-agent actions)17:42
pabelanger+117:43
*** ianychoi has quit IRC18:10
*** ianychoi has joined #zuul18:11
openstackgerritMerged openstack-infra/zuul-jobs master: Add test-emit-job-header roles  https://review.openstack.org/55794618:16
openstackgerritMerged openstack-infra/zuul-jobs master: Add nodepool info to test-emit-job-header  https://review.openstack.org/55794718:16
*** pcaruana has quit IRC19:19
fungianybody happen to have a foot in the door with https://www.aswf.io/community/ ?20:09
fungiseems very ci/cd focused20:09
fungianother fine product of the linux foundation20:09
fungithe tie-in with the academy of motion picture arts and sciences eludes me20:10
pabelangernever heard of it, seems to have launched today20:16
openstackgerritJames E. Blair proposed openstack-infra/zuul master: Map file comment line numbers (alternate)  https://review.openstack.org/59044220:22
openstackgerritJames E. Blair proposed openstack-infra/zuul master: Map file comment line numbers  https://review.openstack.org/59044220:23
mordredfungi: so - I was confused at first - but I think teh aswf is about open source software associated with motion picture making: https://www.aswf.io/about/20:29
fungiagreed20:30
mordredfungi: and that community page is just indicating that one of the pieces of their dev community is a shared ci infrastruture for their projects20:30
* mordred originally thougth that the aswf was a new CI/CD project and was super confused about the name20:30
fungithey seem quite invested in ci/cd though, which is quite cool20:30
mordred++20:30
*** samccann has quit IRC20:31
openstackgerritJames E. Blair proposed openstack-infra/zuul master: Map file comment line numbers  https://review.openstack.org/59044220:48
openstackgerritMonty Taylor proposed openstack-infra/zuul master: Fix web content copying in multi dashboard job  https://review.openstack.org/59108921:17
mordredclarkb, fungi: ^^ that fixes an issue seen here: https://review.openstack.org/#/c/586552/21:17
mordredthe path exclusions on the change to do file copying caused that change to not be self-testing21:18
openstackgerritJames E. Blair proposed openstack-infra/zuul master: Map file comment line numbers  https://review.openstack.org/59044221:21
corvus"TypeError: expected string or bytes-like object" would be even more helpful if it also included "...but received $something"22:27
openstackgerritJames E. Blair proposed openstack-infra/zuul master: Map file comment line numbers  https://review.openstack.org/59044222:42
openstackgerritJames E. Blair proposed openstack-infra/zuul master: Fix race in test_crd_check_unknown  https://review.openstack.org/59110622:42

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