Wednesday, 2017-04-19

jeblairjhesketh: ^ your comments in that series should be addressed00:29
jheskethjeblair: awesome, thanks... will review today hopefully00:30
*** jkilpatr has quit IRC00:31
*** jkilpatr has joined #zuul00:32
*** leifmadsen has quit IRC00:55
*** leifmadsen has joined #zuul00:57
*** jkilpatr has quit IRC01:13
*** dkranz has quit IRC01:20
*** jkilpatr has joined #zuul01:25
*** yolanda has quit IRC02:26
*** yolanda has joined #zuul02:26
jamielennoxjhesketh: we discussed https://review.openstack.org/#/c/446308/ at the meeting the other day, and decided that both options were useful but we would do the simple one for now and move it to nodepool when there's a concrete case03:09
jamielennoxso [executor] username= would always be available as a default and default to zuul (rather than user ansible is running as)03:10
jamielennoxand in future nodepool information would be taken in preference03:10
jheskethjamielennox: okay, thanks for the update.. not sure if it makes sense for the nodepool information to take precedence though from a users point of view... it does operationally but if a user has set the username and something else is used I would be confused03:18
jamielennoxjhesketh: i'm not sure zuul.conf is really user's point of view - but i guess with only 1 option it has to be a fallback choice03:44
jamielennoxjhesketh: would renaming it default_username or something help?03:44
jheskethjamielennox: by user I meant operator/deployer03:44
jheskethjamielennox: we could have the default_username and maybe use_nodepool_creds boolean?03:45
jamielennoxjhesketh: so there was no timeline on the nodepool creds side03:49
jamielennoxi can't really think of a time where you'd want to override the information provided by nodepool as it's actually creating the images03:50
jheskethsure, I mean when we swing back we can consider something likely only overwriting the set username if the boolean says so (for example)03:50
jheskethyeah, that's true... maybe it's a fallback_username?03:50
jamielennoxjhesketh: personally prefer default_ but will go with consensus, it may also be a long time before anything is capable of overriding the fallback03:55
jamielennoxi have the patches up but deemed unecessary for now03:55
jheskethjamielennox: sure, default works for me :-)03:56
jamielennoxjhesketh: ok, will respin03:56
jamielennoxjhesketh: thanks03:56
jamielennoxjhesketh: do you know if there are any tests that really go into executor server? i can't see anywhere i can really test this03:59
jheskethnot sure off the top of my head sorry04:00
jheskethI don't think there are any unit tests, but there are functional tests afaik04:00
openstackgerritJamie Lennox proposed openstack-infra/zuul feature/zuulv3: Re-add the ability to set username on zuul-executor  https://review.openstack.org/44630804:02
*** pbelamge has joined #zuul06:19
*** isaacb has joined #zuul06:45
*** hashar has joined #zuul07:44
*** yolanda has quit IRC07:54
*** yolanda has joined #zuul08:30
*** yolanda_ has joined #zuul08:59
*** yolanda_ has quit IRC09:01
*** yolanda_ has joined #zuul09:01
*** yolanda has quit IRC09:03
*** bhavik1 has joined #zuul09:08
*** bhavik1 has quit IRC09:46
*** bhavik1 has joined #zuul09:51
*** jkilpatr has quit IRC10:42
tobiashhi, I'm currently working on support for unmanaged images in nodepool10:48
tobiash(on top of https://review.openstack.org/#/c/455464)10:49
tobiashthe providers section also specifies a diskimages list where some provider specific meta data can be set10:49
tobiash(from which I think config-drive makes also sense for unmanaged images)10:50
tobiashdoes it make sense to rename this to images?10:50
tobiashthinking of something like this:10:51
tobiashhttp://paste.openstack.org/show/607134/10:51
*** jkilpatr has joined #zuul11:00
*** isaacb has quit IRC11:04
Shrewstobiash: no. we just renamed it _from_ images in commit dcc3b511:05
tobiashShrews: just saw that it gets diskimages + provider specific stuff11:06
tobiashShrews: would you prefer to add such a section for unmanaged images?11:08
tobiashhttp://paste.openstack.org/show/607137/11:08
tobiashor just don't support customizing config-drive for unmanaged images?11:08
tobiash(which is I think the only option from diskimages which makes sense for unmanaged images)11:09
Shrewsit might make more sense under 'pools' sections because the provider:diskimage is there to tell us which images to build and upload, but the pools:diskimage tells us which to actually use. I will defer to jeblair on that, though11:12
*** bhavik1 has quit IRC11:42
*** yolanda_ has quit IRC12:04
*** yolanda has joined #zuul12:04
*** yolanda has quit IRC12:04
tobiashjust interested, what are you using for debugging zuul/nodepool?12:05
*** yolanda has joined #zuul12:05
openstackgerritTobias Henkel proposed openstack-infra/nodepool feature/zuulv3: Whitelist pydevd debug threads  https://review.openstack.org/45804112:05
mordredhey everybody - so, I _CANNOT_ believe I'm about to say this - like, not even a little bit not even at all now I want to stab myself yukc ... BUT12:49
mordredI was looking at the work sdague as been doing to use systemd for logging in devstack, which is actually cool because you can annotate log messages with a bunch of metadata12:50
mordredand have discovered that python-systemd has a python logging handler: https://github.com/systemd/python-systemd/blob/master/systemd/journal.py12:50
mordredthat you can configure as-normal in a python logging config file12:50
mordredif you do - it automatically annotates log messages with additional information12:51
mordredhttps://github.com/systemd/python-systemd/blob/master/systemd/journal.py#L59412:51
mordredsuch as threadName, processName, pathname, linenum, and funcName - as well as full exception text and information if you're logging an exception12:52
mordredhttps://dague.net/2017/03/30/in-praise-of-systemd/12:52
mordredif you havnet read it yet12:52
*** dkranz has joined #zuul12:59
tobiashmordred: that's cool13:04
tobiashI'm using something similar for direct to json logging where the json can be pushed straight to elasticsearch13:05
mordredyah. it's ... I mean, I still think it's TERRIBLE for this to have been implemented as part of the init system13:17
mordredBUT - I guess I can't fight that any more13:17
openstackgerritJamie Lennox proposed openstack-infra/zuul feature/zuulv3: Don't allow auth definition in job to be a list  https://review.openstack.org/45807213:19
openstackgerritTobias Henkel proposed openstack-infra/nodepool feature/zuulv3: Support externally managed images  https://review.openstack.org/45807313:19
*** yolanda has quit IRC13:20
tobiash^^ first draft for externally managed images13:20
jamielennoxmordred: :)13:20
tobiashprobably needs some beautifying but I hope I'm in the right direction13:21
*** _ari_|gone is now known as _ari_13:28
*** pbelamge has quit IRC13:29
mordredtobiash: looks great! one minor quibble/question in the docs13:29
mordredtobiash: (that is fairly straightforward)13:29
tobiashmordred: wow, that was quick :)13:31
tobiashI would tend to cloudimage13:31
tobiashAnd i'm not yet satisfied with the term unmanagedimages in provider config13:32
tobiashmaybe this also should be renamed to cloudimages?13:32
*** yolanda has joined #zuul13:33
*** yolanda has quit IRC14:08
*** yolanda has joined #zuul14:08
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Don't allow auth definition in job to be a list  https://review.openstack.org/45807214:34
*** yolanda has quit IRC14:38
*** yolanda has joined #zuul14:39
jeblairtobiash, mordred: yeah, i would use the same term under pool and pool-label (because the thing in pool-label refers to the thing in provider).  while i would seriously consider just using "image" for that, "cloud-image" is growing on me, so maybe we should avoid ambiguity and use that.14:40
*** isaacb has joined #zuul14:48
jeblairShrews: you were looking at using daemoncontext to drop privileges; did that go anywhere?14:54
jeblairShrews: (i think if we can create the socket, then drop privs before starting the server, it would be nice)14:54
Shrewsjeblair: starting to look at that. the issue is we have to drop privs AFTER grabbing the fingerd port, so that throws a kink into how the executor current works14:55
jeblairShrews: oh, of course we have the no-daemon option....14:55
jeblairShrews: yeah, the port grabbing would have to be really early14:55
Shrewsjeblair: we could sort of combine both approaches and launch the current finger code i have up within cmd/executor.py (so we'd have two daemon contexts there)14:56
Shrewsbut we'd lose the advantage of accessing internal things14:56
Shrewsbut it does eliminate having two separate processes14:56
Shrewsthat might be a stupid idea14:56
Shrewsbut something that just occurred to me14:57
jeblairwell, i think the only thing we have to do as root is bind the socket14:57
jeblairso we can bind in cmd/executor.py then drop privs, and pass the bound socket into executor.14:57
Shrewsyeah. gonna try that out here in a bit.14:58
jeblaircool14:58
jeblairShrews: if we want this to be compatible with the '-d' (no daemon) option, then we may not be able to use the daemoncontext arguments, and instead may just need to use the change_privs method you wrote but move it up a level.14:59
Shrewsyeah15:00
Shrewsjeblair: that code looks sane-ish enough for you?15:00
Shrewsi wasn't sure if we should do something with umaks15:01
Shrewsumask15:01
Shrewsbrb15:02
jeblairShrews: probably a good idea to add that15:02
jeblairShrews: otherwise, yep.15:02
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Extend test timeout to 120s  https://review.openstack.org/45480615:04
Shrewsjeblair: one thing to note, we'll likely have to use threads instead of processes to handle the requests.15:13
Shrewss/likely/definitely/15:14
pabelangeris it not possible we could use xinetd for some of the port mapping?15:16
clarkbsince mordred seems to be cool ish with systemd now. just going to throw this out there, we could use socket activation/inetd15:17
clarkbpabelanger: jinx15:17
pabelanger:)15:17
jeblairi don't think we should *depend* on systemd.15:19
clarkbjeblair: right but for those without systemd there is inetd and friends. But maybe we don't want to depend on those either?15:20
jeblairShrews: why definitely threads?15:20
jeblairclarkb: i'd rather not15:21
Shrewsjeblair: because once you accept a connection, passing that client socket to a forked process has issues (e.g., i could not get the socket to close). socket sharing across processes is a notoriously difficult problem (that socketserver somehow managed to solve)15:21
jeblairShrews: you can't pass a bound socket into socketserver?15:21
Shrewsthe socketserver lib doesn't work that way, so i'm not sure what you're asking there15:22
Shrewsi don't see how we can use that lib if we integrate directly with executor15:23
*** hashar has quit IRC15:26
*** yolanda has quit IRC15:28
*** yolanda has joined #zuul15:29
jeblairShrews: i guess you could subclass it to accept a bound socket in the constructor and then just have server_bind return that value... but maybe that's not worth it?15:30
jeblairShrews: i think we probably should think more on whether internal data access is important (since that requires threads anyway)15:31
jeblairShrews: if it's not that important, maybe using the forking tcpserver as a separate process started by the executor command is the way to go.15:31
Shrewsjeblair: hrm, that might work, actually15:37
Shrewsbase class sets self.socket in __init__, but looks like we could dump that and replace it safely15:40
Shrewsat least, in the current iteration of that library15:40
* Shrews checks py3 version...15:41
jeblairShrews: i assumed it would be self.socket = self.bind_socket().  so if we saved the socket before calling super's constructor, we could just return it from bind_socket.15:41
Shrewshttps://hg.python.org/cpython/file/2.7/Lib/SocketServer.py#l43115:42
Shrewstrying to find the py3 version15:43
jeblairShrews: yeah, i was suggesting we override server_bind (that's what the docs say to do)15:43
jeblairShrews: oh, i see what you mean15:43
jeblairwell, that's lame.15:44
Shrewspy3 code seems to be identical15:44
Shrewsjeblair: yeah, i mean, we're dumping a socket they've already created if we do that. not sure how future proof that would be15:45
jeblairShrews: what do you think is worth more?  threads+internal data access or forking?15:45
Shrewsjeblair: forking seemed to be advantageous if we have a lot of folks streaming logs. if we go w/ the other option, and now we have a whole lot more threads, i worry how that might affect executor15:47
Shrewsright now, i'm not seeing anything advantageous to accessing internal data. it would eliminate the assumption of where the ansible_log.txt file is stored, but that's the only thing at this point15:48
Shrewsand even that we could migrate to the config. if we need other logs/files to stream, then maybe there's an advantage?15:49
Shrewsand we could directly query ExecutorServer.job_workers for valid job IDs15:50
Shrewsrather than filesytem globbing15:50
jeblairShrews: we do have the idea of requesting specific log files from specific hosts, so this would need to be able to handle the request "get syslog from the host named compute for the build foo", which would basically mean that we need to know the contents of the inventory for the build.  we can either get that from the internal data structure or by reading the inventory file on disk.  that's the only other consideration i can think of.15:51
Shrewsjeblair: so that part of the code i don't think i've explored deeply enough to intelligently say it would be better one way or the other15:52
Shrewsjeblair: which internal data structure has that?15:53
Shrewsis that in AnsibleJob?15:54
jeblairShrews: ExecutorServer.job_workers[uuid] is an AnsibleJob.  and yeah, we'd find it in there somewhere.15:54
jeblair(the inventory isn't saved as an attribute, but we could add it)15:55
Shrewsjeblair: ok. maybe it's worth coding it up to actually see it then15:55
Shrewsjeblair: i might need some assistance from you on getting a local executor running so I can actually test it15:57
Shrewsthat's the most difficult part  :)15:57
*** hashar has joined #zuul15:59
jeblairShrews: that's possible, but it may be easier to incorporate it into the test framework15:59
*** hashar has quit IRC16:02
*** hashar has joined #zuul16:03
*** isaacb has quit IRC16:09
*** hashar has quit IRC16:36
*** bhavik1 has joined #zuul16:41
openstackgerritJames E. Blair proposed openstack-infra/zuul feature/zuulv3: Add simple_layout test decorator  https://review.openstack.org/45816817:10
jeblairSpamapS, clarkb, jlk: ^ that's my idea for reducing the unecessary git repo activity (and also simplifying a lot of test configuration)17:10
jeblaircan you give that a quick look and see if the approach looks good?17:11
clarkbsure, we should also double check test times are reduced?17:11
clarkbtestr should print out the slow tests which we can compare against17:11
*** harlowja_ has quit IRC17:13
jeblairclarkb: this will have 3 effects on test times: the test i applied it to should be much shorter because it only initializes the repos it needs; the other tests that share that general config should be a little shorter because i have removed one extra repo from their initialization, but i will need more changes to repeat this for the other unecessary repos in order for this reduction to accumulate; and overall, once that's applied to as many ...17:14
jeblair... tests as we can, there should generally be less git repo activity which should mean less io/cpu contention for all tests.17:14
jeblairclarkb: the first is easy to measure.  it's down from 3.420s to 1.357s on my local machine.17:15
*** harlowja has joined #zuul17:15
clarkbcool17:15
jeblairthe rest would probably need stasticially significant sampling to determine the effect.17:15
jeblair(and also aren't that interesting until the whole patch series is done)17:16
*** harlowja has quit IRC17:17
*** harlowja has joined #zuul17:17
* jlk looks17:17
SpamapSjeblair: looking now17:20
clarkbjeblair: if I read this correctly, its basicaly a helper that will read the layout to only configure the subset of project repos needed. Rather than setting up the full set every time?17:21
jeblairclarkb: yes.  the other way to do that is to create a config fixture with a bunch of directories that get copied over as git repos.  that works really well for complex scenarios, but is annoying for simple ones (you have to make a bunch of directories), so we ended up with one of those but with a bunch of little repos with their own configs in them.  this makes it simpler not to do that.  :)17:24
clarkbok commented17:25
jeblairclarkb: replied; lmk if that makes sense.17:29
clarkbjeblair: thanks. Basically the end result will be default is simple_layout of "single tenant" equivalent?17:31
clarkbI think thats a good end state. Mostly don't want to have to explicitly opt into using the decorator every time a new test is written as it seems like that would be a good way to end up with really slow tests again17:31
jlkoh yeah a bunch of my tests would benefit from this.17:32
clarkbok zuul test suite and then local reproduction confirms you can't un shutdown an apscheduler backgroundscheduler. Thats unfortunate17:51
SpamapSclarkb: doh17:53
SpamapSclarkb: you could, however, recreate the object I assume?17:53
openstackgerritClark Boylan proposed openstack-infra/zuul feature/zuulv3: Don't run apsched thread when no jobs need scheduling  https://review.openstack.org/45779817:56
clarkbSpamapS: yup ^17:56
clarkbSpamapS: the annoying part is its actually fine untuil the cron trigger triggers. So you don't get an error upfront17:57
*** jkilpatr has quit IRC17:57
openstackgerritJames E. Blair proposed openstack-infra/zuul feature/zuulv3: Add simple_layout test decorator  https://review.openstack.org/45816817:59
*** jkilpatr has joined #zuul18:00
SpamapSclarkb: time's a bitch18:04
*** bhavik1 has quit IRC18:22
*** jkilpatr has quit IRC19:27
*** jkilpatr has joined #zuul19:30
*** jkilpatr has quit IRC19:30
*** jkilpatr has joined #zuul19:30
openstackgerritJames E. Blair proposed openstack-infra/zuul feature/zuulv3: Add playbook support to simple_layout in tests  https://review.openstack.org/45822019:57
jeblairclarkb, SpamapS, jlk: ^ heh, i chose a slightly too simple test for my first move, so i needed to expand simple_layout a bit for the next one.  but hey, this makes for good narrative structure in changes.  so, erm, i totally planned it that way.19:58
jeblairclarkb, SpamapS, jlk: you want the rest of these one test per patch, or should i do some omnibus patches?20:08
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Stop jobs when executor stops  https://review.openstack.org/45775320:09
jlkmaybe set up a hit list for spreading the work out?20:09
jlkI don't think it's great use of your time to iterate through them... :)20:09
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Fix race in test_queue_rate_limiting_dependent  https://review.openstack.org/45779920:10
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Pass source to project instantiations  https://review.openstack.org/45159620:10
jeblairjlk: normally i'd agree, but now that i've started, i think i can knock 'em out pretty quick (the last 2 took me 5m each) -- unless you're dying to get in on the action.20:10
jlkno, not dying per se.20:11
jlkI"d say omnibus it unless there's some that wind up being awkward to handle, and deserve their own change.20:11
jeblairok.  i also only have a few more that are like this, then there's another class of test that needs more thinking.  that may be a good opportunity for a hit list.20:12
jlkguh, it's cold enough today that my fingers are having a hard time typing right.20:12
jeblairsometimes i make a mug of hot water just to hold.20:13
jeblairi understand that other people put other hot liquids in mugs which serve a dual purpose.  i dunno about that.20:14
jlkheh, yeah. my tea this morning helped with that. I need to go see if i have any more caffeine free stuff, since I"m already at my limit for the day20:15
clarkbyes its cold here too. Annoying because yesterday was open windows weather20:15
openstackgerritJames E. Blair proposed openstack-infra/zuul feature/zuulv3: Move tests to use simple_layout  https://review.openstack.org/45823120:43
openstackgerritJames E. Blair proposed openstack-infra/zuul feature/zuulv3: Remove unused repos from repo init  https://review.openstack.org/45823220:43
openstackgerritJames E. Blair proposed openstack-infra/zuul feature/zuulv3: Remove project3  https://review.openstack.org/45823320:43
openstackgerritJames E. Blair proposed openstack-infra/zuul feature/zuulv3: Use 'org/project' for tests which only operate on one project  https://review.openstack.org/45823720:56
* mordred is wearing shorts and the windows are open and the little fountains into the pool accompany the lovely classical music quite nicely20:56
jeblairokay, i think the next phase of this is to identify which of the uses of 'updateConfigLayout' can be replaced by simple_layout.  that will let us remove all of the extra git repos from here, which are all initialized in many of the test runs: http://git.openstack.org/cgit/openstack-infra/zuul/tree/tests/fixtures/config/single-tenant/git?h=feature/zuulv320:57
jeblairthere are 32 of those, so that might be a good opportunity for a hit list20:57
jeblairi will do one now, then make a list20:57
jeblair(basically, it's a candidate if the only use of updateConfigLayout is at the top of the test method.  we're still going to need this for those which change the layout inside of the test method, so we should rework those cases after the easy ones are moved)20:59
SpamapSjeblair: ahhh optimization cycles. so soothing.21:02
openstackgerritJames E. Blair proposed openstack-infra/zuul feature/zuulv3: Move test_tags to simple_layout  https://review.openstack.org/45824021:04
jeblairokay, there's one.  i'll see how many others there are21:04
openstackgerritJames E. Blair proposed openstack-infra/zuul feature/zuulv3: Move test_tags to simple_layout  https://review.openstack.org/45824021:04
jeblairgit add ^ :)21:04
mordredjeblair: silly git add21:10
jeblairmordred: you're a silly git add21:11
SpamapSmy git add brings all the files to the yard21:12
jlkOUT --->21:12
clarkbjeblair: whats the overlap in updateConfigLayout and single-tenant/zuul.yaml?21:12
clarkb(seems like this is also cleaning up triple accounting of a bunch of stuff)21:13
SpamapSadam_g: can you repeat the question you asked earlier about secrets/auth? :)21:15
adam_gwell, it was basically the question of what prevents someone proposing a patch that simply logs the decrypted secrets somehwere visible during/after the test21:17
jeblairclarkb: single-tenant/zuul.yaml is what's initially loaded.  then updateconfiglayout rewrites that file with an alternative.  they shared the same base set because that was backwards compatible with the way tests used to work.  but we really don't want either doing more than necessary.21:17
SpamapSjeblair: ^ My answer to adam_g's question is that config/trusted repos shouldn't have check jobs. Thoughts?21:17
adam_gSpamapS: right, that seems like a sane thing to ask of users21:18
SpamapSOr I wonder if you can have a check job that is only triggered after +2 or something.21:18
jeblairSpamapS: basically -- we added an 'allow-secrets' flag to pipelines, so you can say 'the check pipeline can not use secrets at all'.  that way all the projects can still have check jobs, but just safe ones.21:19
jesusaurSpamapS: well, if there's an additional trigger, it would be a new pipeline; but you could have check and super-check21:19
jeblairSpamapS: then you can add a "safe-check" pipeline, if you want, does allow secrets and which triggers on +2 like you suggest if you want.21:19
jeblairright that :)21:19
jeblairapparently you have to really want it though since i said that twice21:20
SpamapSoh yay there's suspenders on that one. :)21:20
clarkbjeblair: comment on https://review.openstack.org/#/c/458237/1 to sort it out21:20
SpamapSI like the idea of a trusted-check21:20
clarkbjeblair: you'd also need trusted config to not reload its own config on proposal? eg you can add allow-secrets to check in a change and have that magically work?21:22
clarkb(pretty sure this is how it worked at PTG at least so should be fine)21:22
jeblairclarkb: ya.  pipelines can't be dynamically reconfigured, so i think we're good there.21:22
jeblairSpamapS, adam_g: when going back over things recently, i *think* i may have missed one of the safety checks which is "secrets can only be used by jobs defined in the same repo as the secret".  that's a similar situation, in that you don't want to define a secret in the shade repo and then have cloudkitty go and use it (in a job that just prints it out).  that's an easy fix though.  just be aware there's a hole there.  i'll fix that this week (if ...21:24
jeblair... indeed i did miss it).21:24
mordredjeblair: ++21:26
openstackgerritJames E. Blair proposed openstack-infra/zuul feature/zuulv3: Use 'org/project' for tests which only operate on one project  https://review.openstack.org/45823721:29
openstackgerritJames E. Blair proposed openstack-infra/zuul feature/zuulv3: Move test_tags to simple_layout  https://review.openstack.org/45824021:29
jeblairclarkb: thx ^21:29
jeblairhttps://etherpad.openstack.org/p/tYAUpHqZeo21:31
jeblairthose are the easy moves to simple_layout, if anyone wants to grab one, mark it in the etherpad.21:32
mordredI feel like I've reviewed this patch I'm reviewing right now, but it does not show that I ever voted on it21:37
jeblairmordred: gertty or web?21:38
mordredjeblair: web21:38
mordredjeblair: I mostly just recognize the content21:38
jeblairprobably just wrote the same patch twice.  we do that a lot.21:38
mordredhahaha21:39
mordred(it's the first patch of your giant chain)21:39
jeblairmordred: oh, yeah. i noticed you reviewed some of those but not others.  i guess that wasn't on purpose. :|21:41
jlkjeblair: these we're picking off the list, shoudl they be on top of any specific patch?21:44
jeblairjlk: 45824021:46
mordredjeblair: maybe just consider that I left a +2 for all ones I didn't review - since apparently I don't know how to work buttons21:46
jheskethMorning21:49
mordredmorning mr jhesketh21:49
*** jasondotstar_ is now known as jasondotstar21:49
jhesketho/21:51
mordredjhesketh: if you feel like fun, https://review.openstack.org/#/c/451597 is at the base of a big stack and I think you were the last person with a -1 on it21:53
* jeblair takes a short break21:55
jheskethmordred: Yeah I failed to get to that yesterday sorry. Im not sure if I will be able to today so feel free to merge etc without me but I'll do my best to take a look asap21:55
openstackgerritJesse Keating proposed openstack-infra/zuul feature/zuulv3: move test_disable_at to simple_layout  https://review.openstack.org/45825221:56
mordredjhesketh: no worries - was just going through them myself and noticed that22:01
jheskethyeah, thanks for the heads up :-)22:02
* jlk has to step away for a bit.22:04
openstackgerritJesse Keating proposed openstack-infra/zuul feature/zuulv3: Move check_ignore_dependencies to simple_layout  https://review.openstack.org/45825522:04
jlkhopefully I did those two right22:04
mordredjeblair: I have pulled the trigger on the big stack22:16
jeblairmordred: thanks!22:17
mordredjeblair: maybe we'll get to enjoy one of those lovely moments where zuul goes on a merge spree on its own code22:18
jeblairmordred: with our failure rate, probably not :(22:18
mordredjeblair: :(22:21
*** jkilpatr has quit IRC22:21
mordredjeblair: https://review.openstack.org/#/c/436802 looks fine to me, but is one that I would like your ok on - us using http for one thing seems like a conscious choice, but I do not remember it being one specifically22:22
clarkbjeblair: it does seem to be somewhat better towards the tip of your stack of changes. test times down and not seeing as many fails22:22
mordred(it's not urgent, just calling it out because I happened to be looking at it)22:22
mordredclarkb: ++22:23
clarkband the fails I did see were related to the proposed changes which is progress :)22:23
jeblairmordred: thanks; let me cipher on that a bit when i have more brainspace22:25
mordredjeblair: totes22:25
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Add a project index to Tenant  https://review.openstack.org/45159722:35
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Use new tenant project index for config references  https://review.openstack.org/45192822:35
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Remove unused Tenant.getRepo method  https://review.openstack.org/45192922:35
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Add source to project and remove unused tenant attrs  https://review.openstack.org/45196922:37
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Add hostname to TriggerEvent  https://review.openstack.org/45234822:37
jeblairjlk: i think you forgot some git adds22:38
openstackgerritJames E. Blair proposed openstack-infra/zuul feature/zuulv3: Move test_tags to simple_layout  https://review.openstack.org/45824022:38
openstackgerritJames E. Blair proposed openstack-infra/zuul feature/zuulv3: Move some uses of updateConfigLayout to simple_layout  https://review.openstack.org/45826222:38
*** dkranz has quit IRC22:38
openstackgerritJames E. Blair proposed openstack-infra/zuul feature/zuulv3: Remove unused test git repos  https://review.openstack.org/45826322:41
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Fully qualify project configuration names  https://review.openstack.org/45197022:42
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Replace config/project repos with config/untrusted projects  https://review.openstack.org/45334722:42
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Remove source from pipelines (1/2)  https://review.openstack.org/45336222:43
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Remove source from pipelines (2/2)  https://review.openstack.org/45382122:43
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Add simple_layout test decorator  https://review.openstack.org/45816822:43
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Add playbook support to simple_layout in tests  https://review.openstack.org/45822022:43
jlkjeblair: foiled again!22:48
openstackgerritJesse Keating proposed openstack-infra/zuul feature/zuulv3: Move check_ignore_dependencies to simple_layout  https://review.openstack.org/45825522:50
openstackgerritJesse Keating proposed openstack-infra/zuul feature/zuulv3: move test_disable_at to simple_layout  https://review.openstack.org/45825222:51
pabelangerjeblair: I'm going to start work on https://review.openstack.org/#/c/454396/ again tomorrow. Is that something we need to land to bring zuulv3-dev.o.o back online?22:52
*** jkilpatr has joined #zuul22:57
jeblairpabelanger: thanks; i think we can go ahead and bring it online since the actual protection has landed, and that shows us it's generally working.  but finishing that will increase our confidence in it and help prevent regressions.22:58
pabelangerokay cool!22:58
openstackgerritJames E. Blair proposed openstack-infra/zuul feature/zuulv3: move test_disable_at to simple_layout  https://review.openstack.org/45825222:58
openstackgerritJames E. Blair proposed openstack-infra/zuul feature/zuulv3: Move check_ignore_dependencies to simple_layout  https://review.openstack.org/45825522:58
jeblairjlk: ^ rebased on top of mine22:58
*** jkilpatr has quit IRC23:05
jlkthanks23:05
openstackgerritJames E. Blair proposed openstack-infra/zuul feature/zuulv3: Move test_repo_deleted to simple_layout  https://review.openstack.org/45826923:06
jeblairstarting on some of the trickier ones now23:06
openstackgerritJames E. Blair proposed openstack-infra/zuul feature/zuulv3: Remove org_unknown git repo from single-client test config  https://review.openstack.org/45827023:28
clarkbjeblair: can you see comments on https://review.openstack.org/#/c/451597/12 ? its already merged but I am slightly confused by a couple things23:32
jeblair                if secret.source_context != job.source_context:23:36
jeblair                    raise Exception(23:36
jeblair                        "Unable to use secret %s.  Secrets must be "23:36
jeblair                        "defined in the same project in which they "23:36
jeblair                        "are used" % secret_name)23:36
jeblairadam_g, SpamapS: oh look i didn't forget ^ :)23:36
jeblairclarkb: looking23:36
*** jkilpatr has joined #zuul23:38
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Resolve project_name/project confusion for gerrit  https://review.openstack.org/45560423:39
jeblairclarkb: responded23:43
SpamapSjeblair: \o/ ... is there.. a test? ;-)23:44
jeblairSpamapS: i don't think so.  a lot of that is weak on negative test coverage.23:45
clarkbjeblair: I see sothere is only ever a single k:v pair in that second inner dict?23:47
jeblairclarkb: no, you can have a second hostname23:47
clarkbah23:47
jeblairso, {"nova": {"git.openstack.org": <project nova>, "github.com": <project othernova>}} would be a valid structure of two unrelated projects both named "nova", and in that case, we would always have to specify hostnames in the zuul.yaml files for them.23:49
clarkbright23:49
clarkbI think I was mostly thrown off by the value that wasn't used and trying to fit it into what I saw23:49
jeblairsorry that didn't end up in the right change23:50
openstackgerritClark Boylan proposed openstack-infra/zuul master: Update trigger script to handle periodic jobs  https://review.openstack.org/43982123:51
jeblairtobiash: it looks like if you don't define a semaphore, but use it in a job, you get an automatically created mutex by default?23:54
jeblairtobiash: if that's correct, i think we may want to make it required to define a semaphore before using it.  otherwise i think usage across projects is going to get tricky.23:55
openstackgerritMerged openstack-infra/zuul feature/zuulv3: Move tests to use simple_layout  https://review.openstack.org/45823123:57

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