| jamielennox | is there a reason to expose an executor-only host to the public internet? | 00:29 |
|---|---|---|
| jamielennox | (incoming) | 00:30 |
| jamielennox | log streaming is via the proxy | 00:30 |
| jamielennox | i don't see a reason a regular user would hit an executor directly | 00:31 |
| mordred | jamielennox: well - finger-protocol streaming if people want that doesn't have a central proxy yet - but I think you could certainly skip public internet on executor if you wanted at this point | 00:46 |
| jamielennox | mordred: is a central proxy for that coming? | 00:47 |
| mordred | and there is an intent to have a central finger proxy/gateway too | 00:47 |
| mordred | yah | 00:47 |
| jamielennox | mordred: ok, great. i think it's easiest to set it up with that assumption and see if there are any problems | 00:48 |
| jamielennox | just wanted to make sure i wasn't going to do something obviously wrong | 00:48 |
| mordred | nope - I think that should totally work | 00:48 |
| dmsimard|off | jamielennox: fyi https://review.openstack.org/#/c/495561/ | 01:05 |
| jamielennox | dmsimard|off: oh - cool, i saw your tweet but mostly just saw a bunch of cache variables i wasn't sure were public | 01:06 |
| jamielennox | if that works i'm happy | 01:07 |
| dmsimard|off | reverse engineering power | 01:07 |
| jamielennox | it was always a hack that seemed unnecessary | 01:07 |
| dmsimard|off | asked upstream about it, they said they don't feel callbacks should "need" access to the inventory | 01:08 |
| dmsimard|off | so there's no proper way to access it and thus is very awkward | 01:08 |
| jamielennox | i'd probably agree with them in most cases, but zuul.. | 01:09 |
| dmsimard|off | ¯\_(ツ)_/¯ | 01:09 |
| dmsimard|off | I ran into the same issue for ara and was going to run with your hack (which I had also found) but though there *had* to be a better way | 01:09 |
| dmsimard|off | and only came up with something slightly better :/ | 01:10 |
| jamielennox | i'd say way better, but 'all' is special cased in a number of places so it's not that weird here | 01:11 |
| *** dkranz has quit IRC | 01:19 | |
| jlk | If you mentioned me in the past week, I've lost it to the scrollback gods. | 03:24 |
| *** bhavik1 has joined #zuul | 04:56 | |
| *** bhavik1 has quit IRC | 05:03 | |
| *** isaacb has joined #zuul | 07:16 | |
| *** amoralej|off is now known as amoralej | 07:20 | |
| *** pbelamge has joined #zuul | 07:43 | |
| *** xinliang has joined #zuul | 07:45 | |
| *** xinliang has quit IRC | 07:45 | |
| *** xinliang has joined #zuul | 07:45 | |
| *** isaacb has quit IRC | 08:13 | |
| *** isaacb has joined #zuul | 08:22 | |
| *** electrofelix has joined #zuul | 09:19 | |
| *** isaacb has quit IRC | 10:27 | |
| *** jkilpatr has quit IRC | 10:41 | |
| *** pbelamge has quit IRC | 10:47 | |
| *** jkilpatr has joined #zuul | 11:01 | |
| *** openstackgerrit has quit IRC | 11:17 | |
| *** dkranz has joined #zuul | 11:59 | |
| *** isaacb has joined #zuul | 12:16 | |
| *** amoralej is now known as amoralej|lunch | 12:27 | |
| *** amoralej|lunch is now known as amoralej | 13:11 | |
| *** dmsimard|off is now known as dmsimard | 13:59 | |
| *** isaacb has quit IRC | 14:57 | |
| jeblair | dmsimard: i think having more of the playbook path and having the entries be in chronological order would be a huge ux win in the zuul context (at least -- as a sysadmin, i would also like the same for my plays). what do you think of this mockup as a solution to the problem of displaying the long names? http://imgur.com/jetBnYC | 15:02 |
| jeblair | mordred, pabelanger: ^ what do you think of that? | 15:02 |
| pabelanger | jeblair: ++ Ya, that would be perfect I think | 15:04 |
| dmsimard | jeblair: hey o/ | 15:05 |
| pabelanger | really shows nicely to users the order of playbook execution | 15:05 |
| jeblair | dmsimard: welcome back! :) | 15:05 |
| dmsimard | jeblair: that mockup looks good, I was at the very least going to prefix the basedir of the playbook based on pabelanger's feedback | 15:06 |
| dmsimard | from your comment it looks like you read the backlog | 15:06 |
| dmsimard | for chronological order, the only problem is that it makes sense so long as you don't have a number of playbooks that exceeds pagination | 15:06 |
| dmsimard | i.e, your latest playbooks ends up on page 50 | 15:07 |
| jeblair | dmsimard: note that the paths to our playbooks are even longer than those in my mockup -- but they have lots of useless stuff at the beginning /var/lib/zuul/builds/blahblahblahblah/ which i stripped out. that actually suggests an idea for implementation -- what if we supplied a variable to ara to indicate what the playbook "display name" should be? | 15:07 |
| dmsimard | I can add a configuration toggle to control the order in which things are displayed | 15:07 |
| dmsimard | jeblair: oh, wait, my brain might be asleep still -- did you mean the *playbook* ordering or the *tasks* ordering ? | 15:08 |
| jeblair | dmsimard: i'm only looking at the index page now, so playbook ordering | 15:08 |
| jeblair | dmsimard: does static generation use pagination? | 15:09 |
| dmsimard | jeblair: ok, I'll add a new toggle to my todo, pabelanger also asked to reverse the sorting order for tasks (which is consistent with the playbook order, last task first) | 15:09 |
| jeblair | dmsimard: it probably makes sense to keep those the same, so if you reverse one, the other is reversed as well, yeah? | 15:10 |
| dmsimard | jeblair: static generation is 100% parity with dynamic webapp, so yes, it has pagination if required. Default is 10 playbooks in a page but is configurable -- you can see an example in ARA's own integration tests where I force a 3 report pagination: http://logs.openstack.org/74/495474/3/check/gate-ara-integration-py27-latest-centos-7/afc1db6/logs/build/ | 15:10 |
| pabelanger | dmsimard: sorry, playbooks like jeblair listed in his mock. That is what I was looking for yesterday | 15:10 |
| pabelanger | task order is correct now | 15:11 |
| dmsimard | pabelanger: you wanted task order in the other direction no ? | 15:11 |
| pabelanger | dmsimard: I'd want what jeblair mock up does | 15:11 |
| dmsimard | jeblair: ah actually the task order is inconsistent with the playbook order right now, tasks are in chronological order while playbooks are reversed | 15:11 |
| dmsimard | jeblair: I'll add two configuration toggles for each ordering -- not hard at all and can't please everyone with a single setting :D | 15:13 |
| *** isaacb has joined #zuul | 15:13 | |
| jeblair | dmsimard: that'll be great. :) | 15:13 |
| dmsimard | for the path, there is the problem of overly long paths but I found that the max path is usually 255 characters long (longer is unsupported by most filesystem implementations) | 15:14 |
| dmsimard | so it can be long but we can fairly assume that there is a limit | 15:14 |
| jeblair | dmsimard: it's 4096 on linux | 15:14 |
| dmsimard | jeblair: It's not a linux filesystem limit though, is it ? It's a filesystem one iirc | 15:14 |
| dmsimard | er, not a linux limit* | 15:15 |
| dmsimard | ah, unless it's about any single filename, not necessarily it's path -- but I did run into errors relatively recently where files ended up nested deep and would error out | 15:16 |
| dmsimard | https://en.wikipedia.org/wiki/Comparison_of_file_systems#Limits | 15:16 |
| dmsimard | yup, looks like there's a distinction between file and path names | 15:17 |
| jeblair | dmsimard: i believe 4096 is a linux limit; some filesystems may be shorter... i'm not sure. one interesting thing is that shebang (#!/bin/...) paths are capped at 128. in practice i think planning for a max of 255 seems reasonable for most non-critical applications. | 15:17 |
| dmsimard | jeblair: so, in a previous implementation of the UI, the compromise that we had was to truncate the file path (from the beginning) if it was too long and prefix "..." | 15:17 |
| jeblair | dmsimard: that seems reasonable. i'd say doing that at even 128 would be fine. though also, playing with my mockup, it seems to fold the path nicely too. | 15:18 |
| jeblair | dmsimard: our paths from zuul are very long, and it would be useful to have, more than just the base dir, but less than the whole path. what do you think about the idea of a playbook path display name variable? so we can have "git.openstack.org/openstack-infra/project-config/playbooks/base-test/pre.yaml" ? | 15:19 |
| jeblair | (the full path is /var/lib/zuul/builds/ff8cbf919ab847b3ba6afb6b0cd134ac/trusted/project_0/git.openstack.org/openstack-infra/project-config/playbooks/base-test/pre.yaml">git.openstack.org/openstack-infra/project-config/playbooks/base-test/pre.yaml which only zuul admins can love) | 15:20 |
| jeblair | er sorry | 15:20 |
| jeblair | /var/lib/zuul/builds/ff8cbf919ab847b3ba6afb6b0cd134ac/trusted/project_0/git.openstack.org/openstack-infra/project-config/playbooks/base-test/pre.yaml | 15:20 |
| dmsimard | how would you see that variable working ? | 15:21 |
| dmsimard | I think we can strike a good (simple) middle ground by giving more room to the playbook path and truncate from the beginning if it's too long, the length before truncating could be made configurable and default to a sane, "good enough" value | 15:21 |
| jeblair | dmsimard: we currently do something similar for the zuul_stream callback... lemme get a link | 15:22 |
| jeblair | dmsimard: http://git.openstack.org/cgit/openstack-infra/zuul/tree/zuul/executor/server.py?h=feature/zuulv3#n1602 | 15:22 |
| jeblair | dmsimard: see the "zuul_execution_phase" variable we add -- that's specifically for zuul_stream to include extra info in its output | 15:23 |
| jeblair | dmsimard: so we could add something similar (ara_playbook_name?) and if ara sees that variable, it uses it instead of the filename | 15:23 |
| jeblair | at least as the display name | 15:23 |
| dmsimard | jeblair: oh, I see what you mean now | 15:23 |
| dmsimard | jeblair: that's interesting. | 15:24 |
| dmsimard | I believe harlowja asked for that before but in a way I didn't understand back at the time | 15:24 |
| dmsimard | That's a good idea, let me add that to the todo. | 15:24 |
| jeblair | dmsimard: here's where it's used: http://git.openstack.org/cgit/openstack-infra/zuul/tree/zuul/ansible/callback/zuul_stream.py?h=feature/zuulv3#n173 | 15:25 |
| dmsimard | yep, I totally get what you mean | 15:25 |
| dmsimard | there would be nothing preventing you from naming your playbook "dancing banana" :D | 15:26 |
| jeblair | i would run that playbook :) | 15:26 |
| dmsimard | peanut_butter_jelly_time.gif | 15:26 |
| jeblair | dmsimard: but yeah, so i'd keep the mouseover with the actual full path (don't want to lose any data, this should just be about preseting the most useful form of the data) | 15:27 |
| jeblair | s/preseting/presenting/ | 15:28 |
| dmsimard | jeblair: yup, and the full paths will always be available when a) clicking on the file b) looking at the file tab | 15:30 |
| jeblair | ++ | 15:30 |
| dmsimard | jeblair: that's great feedback, thanks :) | 15:31 |
| jeblair | dmsimard: yay! thank you! this is going to be really sweet. :) | 15:31 |
| pabelanger | Yay | 15:36 |
| dmsimard | I'm still making good progress towards 1.0, I'm confident to have something in shape for a beta by the PTG | 15:40 |
| dmsimard | If you've missed it, I've highlighted what's coming recently in https://dmsimard.com/2017/08/16/whats-coming-in-ara-1.0/ | 15:41 |
| dmsimard | Which reminds me, I've been meaning to ask -- now that ARA is a default in zuul, I'd like to have a v3 gate job in ARA's gate to make sure I don't break things. | 15:42 |
| dmsimard | A *LOT* of code is being merged and while I'm happy with the extent of the coverage we already have, I'd hate to break something that could've been prevented | 15:44 |
| dmsimard | I mean, the testing matrix is fairly exhaustive already.. Spanning unit and integration tests, we're testing py2, py3, ansible 2.2, ansible 2.3, ansible 2.4, fedora, centos, ubuntu and have an implementation of openstack-ansible jobs as well. | 15:45 |
| * dmsimard should probably document that test matrix | 15:45 | |
| jeblair | dmsimard: we don't have any tests which exercise ara yet, so we'll need to add those, but we should be able to add a job like that pretty soon | 15:46 |
| dmsimard | jeblair: the roles aren't integration tested themselves ? | 15:47 |
| jeblair | dmsimard: the ara generation role is in a base job which means it doesn't get run speculatively -- mordred added it to the base-test job (which isn't normally used) so that it could be tested specially before being merged. short version: it's a bit low-level to be tested in the normal way for zuul jobs. there are likely ways for us to live-test changes to ara in zuulv3 (though that will require some care), or we can look at adding zuul ... | 15:51 |
| jeblair | ... integration tests. | 15:51 |
| *** isaacb has quit IRC | 16:08 | |
| jeblair | SpamapS, clarkb: interested in reviewing 495439 and 495449 -- secrets on tmpfs? | 16:21 |
| SpamapS | jeblair: I'll start with those in a few minutes. | 16:21 |
| jeblair | SpamapS: thanks! | 16:21 |
| jeblair | pabelanger, mordred: anything i should review for upload/publish jobs? | 16:21 |
| clarkb | uh the moon has begun to cover the sun, you should be outside :P though now sure how apparently it is in california yet | 16:22 |
| pabelanger | jeblair: mordred: 494672 is our patch that needs reviewed and testing | 16:22 |
| pabelanger | Ya, I'll likely be outside for the next few hours with kids looking at science | 16:23 |
| jeblair | clarkb: it's going to look the same no matter what: fog. | 16:23 |
| jeblair | i mean, i could go to the other side of the hills but.... then i'd have to go to the other side of the hills. | 16:24 |
| jeblair | pabelanger: small -1 on that change | 16:24 |
| jeblair | no solar eclipse on the planet krikkit: http://static.lawrencehallofscience.org/scienceview/scienceview.berkeley.edu/html/view/index.php | 16:27 |
| pabelanger | lol, there are 2 storm troopers right line on nasa TV feed | 16:28 |
| pabelanger | jeblair: thanks, I'll upload shortly | 16:28 |
| *** openstackgerrit has joined #zuul | 16:32 | |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Document execution_wrapper setting. https://review.openstack.org/495440 | 16:32 |
| mordred | jeblair: from this weekend's work, I'm fairly sure we want to figure out some sort of integration test for the playbooks in the base job - or at the very least for the post-logs playbook, since it's impossile to debug syntax errors in it without executor debug logs - and sometimes wihtout keep turned on | 16:38 |
| mordred | jeblair: I've noodled on HOW to do that a little, but don't have an answer I'm super excited abotyet -it's also not URGENT since that's unlikely to change frequently - but I think long-term it'll be valuable | 16:39 |
| jeblair | mordred: that's fair. i think pabelanger had a proposal to run ansible-lint on project-config. that seems like something easy we can do now. but since we don't expect the post playbook to change much between now and ptg, maybe we can tackle that later; possibly in conjuction with the ara job dmsimard requested. (indeed, this seems like a great conversation to have *at* the ptg) | 16:40 |
| mordred | yup. totally | 16:40 |
| mordred | I _think_ even some synthetic and specific jobs - that actually just set up avars file witha fileserver variable pointing at a second node and then run ansible-playbook on a couple of playbooks would give us enough to be able to test theplaybooks/roles themselves, ansible versions and ara versions - but I totally agree it's a great PTG conversation | 16:42 |
| mordred | "hey everybody, look at how this hangs together - what test jobs can we write now to avoid foot-gun?" | 16:42 |
| jeblair | yup | 16:43 |
| mordred | speaking of - I'd like to restart zuul to pick up the secret naming patch - anything else we should make sure lands first? | 16:43 |
| jeblair | mordred: nah, go for it | 16:44 |
| mordred | jeblair: I think that only needs scheduler restart, yeah? | 16:44 |
| jeblair | mordred: i think that's correct | 16:45 |
| mordred | ok. scheduler restarted | 16:47 |
| dmsimard | mordred, jeblair: I'd be happy to help/contribute to such integration jobs :) | 16:57 |
| jeblair | dmsimard: thanks! :) | 16:57 |
| jeblair | mordred, pabelanger: i have 2 things on my plate today -- 1) add the ssh key without it hitting disk, and then 2) start working on the devstack-gate localconf module | 16:58 |
| mordred | jeblair: ++ | 17:00 |
| mordred | jeblair: I noodled just a bit over the weekend at splitting out / reworking a couple of d-g things as playbooks - lemme push that stack up real quick | 17:02 |
| openstackgerrit | James E. Blair proposed openstack-infra/zuul-jobs master: Add TODO about improving key security https://review.openstack.org/495931 | 17:05 |
| jeblair | mordred: er actually, i'm going to leave task #1 as a TODO ^ since that gets a lot better in ansible 2.4 | 17:06 |
| mordred | jeblair: cool | 17:06 |
| Shrews | jeblair: just curious... when a job inherits from another job in a different project, what's the expected format for referencing that job? <tenant>.<project>.<job>? | 17:10 |
| dmsimard | did someone mention that the concept of pipeline precedence is going away in v3 ? or is my brain playing tricks on me ? | 17:10 |
| mordred | Shrews: <job> - it's a flat namespace | 17:11 |
| jeblair | dmsimard: nope, precedence stays | 17:11 |
| dmsimard | jeblair: okay, so I was trying to understand what precedence (or priority, if you will?) translated to in practice. For example, would jobs in a low precedence remain queued for as long as there are no jobs queued in pipelines with normal and high precedence ? | 17:12 |
| jeblair | dmsimard: that's correct | 17:13 |
| jeblair | dmsimard: we put check at normal, gate and publish at high, post and periodic at low. | 17:13 |
| Shrews | mordred: ok. i think we may have conflicting info in https://docs.openstack.org/infra/manual/drivers.html#v3-naming | 17:14 |
| dmsimard | jeblair: so I find it hard to believe that post and periodic jobs run at all ? | 17:14 |
| jeblair | dmsimard: that way things people tend to wait around for get handled first | 17:14 |
| dmsimard | jeblair: I mean, at least in the openstack zuul, there's always stuff in the check and gate queue | 17:14 |
| Shrews | "There is in general no need to give the name of the repository as part of the job as it was done with Zuul v2." ...and then a bit below that... "If you define a job in a specific repo, the name of the job should use the repository name as prefix or as first part of it." | 17:15 |
| mordred | Shrews: right. that's a recommendation for openstack jobs so that people don't step on each other | 17:15 |
| Shrews | mordred: it just feels like that first sentence needs a "however" portion to it | 17:16 |
| mordred | so shade could define a 'shade-devstack-nodepool' job and not worry aboutotherprojects maybe truing to define a job of the same name | 17:16 |
| Shrews | because we're saying "you don't need to, but you really need to" | 17:17 |
| mordred | yah- and I think there is a distinction between use and define here that likely needs captured | 17:17 |
| mordred | Shrews: like - in v2 you needed to define (using a template) a job called gate-{project}-python27,then use gate-shade-python27 in the zuul config | 17:18 |
| mordred | whereas in v3 there is already a job called tox-py27 andyou don't need to define anything to use it | 17:18 |
| mordred | there's also possibly two different audiences here (that we never had before) | 17:19 |
| jeblair | Shrews, mordred: yeah, i think what's attempting to be conveyed is: not all jobs need to have the project name now (eg, tox-py27). but if you make a project-specific job, it *should* have the project name. | 17:19 |
| Shrews | jeblair: yes, exactly. that wording is much more clearerer | 17:19 |
| jeblair | dmsimard: yes, though precedence affects when jobs start (it doesn't wait until they finish). so once all the jobs in check have *started* then jobs in post begin to start (in the order they were enqueued). if new jobs show up in check, the ones in post which haven't started yet will sit a bit longer. | 17:26 |
| jeblair | dmsimard: with our current constrained resources, post jobs do indeed wait for a long time (sometimes all day) | 17:27 |
| *** harlowja has joined #zuul | 17:29 | |
| dmsimard | jeblair: okay, so I'm trying to figure out something tangentially related where we have a batch of periodic jobs that we might not want to trigger all at once | 17:33 |
| dmsimard | say the schedule is every 24hrs, like upstream, does that mean they will all queue at the same time -- or is it possible to space them out in a way that they still run once every 24hrs but with some randomness | 17:34 |
| dmsimard | I'd hate to have to artificially space jobs out into different pipelines to make sure they are somewhat spaced out | 17:35 |
| dmsimard | s/artificially space jobs out/artificially split jobs out/ | 17:35 |
| *** amoralej is now known as amoralej|off | 17:45 | |
| jlk | o/ | 17:47 |
| jeblair | dmsimard: there isn't an easy facility to do that. why do you want them spaced out though? | 17:57 |
| dmsimard | jeblair: mostly the amount of jobs involved | 17:57 |
| jeblair | dmsimard: right, but if they're at the bottom of the precedence list, does it matter? or did you want them at a higher precedence? | 17:58 |
| dmsimard | jeblair: in jenkins, you can set the schedule of a periodic job with a "shuffle", like "H H(0-7) * * *" | 17:59 |
| dmsimard | jeblair: they'd likely be at a higher precedence, yes, these would be important periodic jobs | 17:59 |
| jeblair | dmsimard: what's less important than them? | 17:59 |
| dmsimard | It's not so much about the periodic jobs being triggered before another kind of job in terms of priority. It's more about, given a set of jobs in the same periodic pipeline, don't necessarily trigger all of them at once and potentially generate a temporary resource shortage | 18:01 |
| dmsimard | Basically. I'm more interested in "make this job run once a day" than "make this job run at 8AM every morning" | 18:02 |
| dmsimard | It's a subtle nuance | 18:02 |
| jeblair | dmsimard: right; it's just that when faced with this problem, we found that scheduling things by time wasn't the most direct solution to the problem. a schedule can't adapt to the current resource situation, but queue precedence can. our daily jobs get scheduled at some arbitrary time, and then they end up running whetever there is spare capacity. if the goal is to avoid resource constraints, then prioritizing periodic jobs at the bottom ... | 18:03 |
| jeblair | ... seems like the best approach. | 18:03 |
| jeblair | dmsimard: if, after doing that, those jobs don't ever run, then the system just plain doesn't have enough resources -- no time of day shuffling will solve that. :) | 18:04 |
| jeblair | s/running whetever/running whenever/ | 18:04 |
| dmsimard | jeblair: so do things potentially overlap if they don't get started within the time window ? I'm assuming 24hrs is not so problematic but I'm looking at other frequencies (every 4, 6 or 8 hours, for example) | 18:05 |
| jeblair | dmsimard: duplicate entries shouldn't end up in the same pipeline, so if a periodic job is still in the pipeline 24h later, a second one should not be enqueued. i think. :) | 18:06 |
| jeblair | or, X hours later, as it were | 18:07 |
| dmsimard | Ok! | 18:07 |
| jeblair | dmsimard: tangentially related -- i'm proposing a new kind of pipeline manager that allows for at most 2 of the same project items in a pipeline. this is to be used in the post pipeline so that we publish the branch tip tarball/docs/etc after a change, but if 5 more changes land while it sits in the queue, we skip the intervening changes and the next publish run will be for the latest change. | 18:08 |
| jeblair | dmsimard: but i'm being a team player and not writing that until after ptg. :) | 18:09 |
| jeblair | dmsimard: but it may be interesting to explore the interactions with that and periodic pipelines | 18:09 |
| jlk | I got travel approval for PTG. Time to book some flights. | 18:09 |
| dmsimard | jlk: yay! | 18:09 |
| dmsimard | jeblair: makes sense for some kind of jobs, yeah | 18:10 |
| jlk | the plan is still to cut over that week, right? Nothing caught on fire last week? | 18:10 |
| dmsimard | Otherwise, I'm basically helping with the process of migrating some "legacy" workloads from Jenkins to Zuul and a lot of those are based on that periodic shuffle trigger I mentioned. It's an interesting experiment -- I have to admit that periodic jobs are probably a weakness of Zuul right now, both in terms of scheduling and in reporting, at least when compared to the defacto Jenkins. So hopefully we can | 18:12 |
| jeblair | jlk: so far, yes. i'm nervous about whether we will have everything ready in time, but that's not a new feeling, and no plans have changed. | 18:12 |
| dmsimard | improve that. | 18:12 |
| jlk | jeblair: is there a high value target punch list somewhere, that somebody like me could chip away at this week? | 18:12 |
| dmsimard | I think the upcoming job dashboard will improve the periodic job visibility a lot, so there's that | 18:13 |
| *** electrofelix has quit IRC | 18:13 | |
| jeblair | jlk: this is the root etherpad with links to children: https://etherpad.openstack.org/p/zuulv3-pre-ptg | 18:13 |
| jeblair | speaking of which | 18:13 |
| jeblair | jlk, mordred, pabelanger, SpamapS, Shrews: can everyone attend the meeting today? | 18:14 |
| jlk | signs point to yes. | 18:14 |
| * Shrews shakes jlk vigorously for an answer | 18:15 | |
| jlk | your answer appears to be vomit. | 18:15 |
| Shrews | I think that means "It is certain" | 18:16 |
| dmsimard | what time is the meeting? I'll add it to my agenda | 18:16 |
| * Shrews walks out to gaze at the sun | 18:17 | |
| jeblair | dmsimard: 2200 utc | 18:17 |
| dmsimard | oh, yeah, the eclipse is in like 10 minutes here. | 18:17 |
| jlk | just finished watching the 94% here. | 18:18 |
| SpamapS | jeblair: I'll be there. | 18:20 |
| jeblair | it got darker here. then it got brighter. | 18:20 |
| * SpamapS spent the morning running a science experiment. :) | 18:21 | |
| SpamapS | https://twitter.com/spamaps/status/899687679704539136 | 18:21 |
| SpamapS | jeblair: reviewing now. | 18:22 |
| jeblair | SpamapS: science! | 18:27 |
| dmsimard | jeblair: lol, are you like the guy in this comic? http://i0.kym-cdn.com/photos/images/newsfeed/000/915/770/e6c.jpg :p | 18:28 |
| pabelanger | jeblair: yes | 18:34 |
| openstackgerrit | Merged openstack-infra/zuul-jobs master: Add fetch-stestr-output role https://review.openstack.org/491559 | 18:45 |
| pabelanger | jeblair: mordred: https://review.openstack.org/495463/ as ansible-lint to project-config. However, i think we might need to create a shared ansible-lint job between all 4 project (zuul, zuul-jobs, project-config, openstack-zuul-jobs) and zuul-clone each to ensure we have all the right playbooks / roles. As you can see in 495463, it is failing because of a role issue in another project | 18:53 |
| jeblair | pabelanger: maybe add that to zuulv3? | 18:54 |
| pabelanger | jeblair: yes, I think that would be a great idea | 18:55 |
| *** weshay has joined #zuul | 19:01 | |
| weshay | howdy | 19:02 |
| SpamapS | jeblair: tmpfs secrets should merge shortly | 19:35 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Add wrapper driver execution context https://review.openstack.org/495439 | 19:35 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Write secrets to tmpfs https://review.openstack.org/495449 | 19:37 |
| openstackgerrit | Paul Belanger proposed openstack-infra/zuul-jobs master: WIP: Add upload-twine role https://review.openstack.org/495972 | 19:54 |
| Shrews | jeblair: mordred: first pass at a quickstart guide: https://review.openstack.org/495971 | 19:54 |
| Shrews | and anyone else interested in it, really | 19:55 |
| leifmadsen | *yoink* | 20:02 |
| mordred | Shrews: looks great! comments within | 20:13 |
| Shrews | mordred: thx | 20:21 |
| *** jkilpatr has quit IRC | 20:35 | |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Retrieve filtered list of hosts for a task, not all hosts https://review.openstack.org/495561 | 20:45 |
| openstackgerrit | Merged openstack-infra/zuul feature/zuulv3: Fix documentation nits https://review.openstack.org/494310 | 21:13 |
| *** dkranz has quit IRC | 21:37 | |
| *** jkilpatr has joined #zuul | 21:53 | |
| jeblair | it's zuul meeting time in #openstack-meeting-alt | 22:01 |
| jeblair | jlk: ^ | 22:01 |
| jlk | oh hi | 22:01 |
| leifmadsen | o/ | 22:47 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!
