Wednesday, 2019-12-11

openstackgerritMerged zuul/zuul-jobs master: Fix python3 compat in tox siblings handling  https://review.opendev.org/69833500:00
*** rf0lc0 has quit IRC00:10
*** igordc has quit IRC00:13
*** jamesmcarthur has joined #zuul00:21
openstackgerritMerged zuul/zuul master: Add upgrade note about ansible_python_interpreter  https://review.opendev.org/69831800:31
openstackgerritClark Boylan proposed zuul/zuul-jobs master: DNM test all the things on ansible 2.8 with python3  https://review.opendev.org/69834400:34
clarkbcorvus: pabelanger fungi ^ occurred to me that we can do that too00:34
clarkban extra layer of sanity checking. Not sure how much coverage it will actually give us though00:34
clarkboh wow that is a lot of jobs :)00:35
*** jamesmcarthur has quit IRC00:39
corvusclarkb: ha, that is many jobs01:06
clarkblooks like only gentoo multinode failed. Probably good to proceed with the plan01:30
*** bhavikdbavishi has joined #zuul01:35
*** bhavikdbavishi1 has joined #zuul01:38
*** bhavikdbavishi has quit IRC01:40
*** bhavikdbavishi1 is now known as bhavikdbavishi01:40
*** rlandy|bbl has quit IRC01:49
*** sgw has joined #zuul01:50
*** sgw has quit IRC01:58
*** sgw has joined #zuul02:26
*** Petar_T has quit IRC02:29
*** sgw has quit IRC02:58
*** ianychoi has joined #zuul05:32
*** pcaruana has joined #zuul06:09
*** raukadah is now known as chkumar|ruck06:10
*** ianychoi_ has joined #zuul07:08
*** tosky has joined #zuul07:09
*** ianychoi has quit IRC07:11
*** jcapitao has joined #zuul07:50
*** hashar has joined #zuul07:51
*** sanjayu__ has joined #zuul07:57
*** pcaruana has quit IRC08:22
*** wznoinsk has quit IRC08:28
*** Petar_T has joined #zuul08:36
*** jpena|off is now known as jpena08:53
*** themroc has joined #zuul08:53
*** jangutter has quit IRC09:03
*** jangutter has joined #zuul09:04
openstackgerritIan Wienand proposed zuul/nodepool master: Dockerfile: create APP_DIR  https://review.opendev.org/69364609:20
openstackgerritIan Wienand proposed zuul/nodepool master: Dockerfile: install sudo for nodepool-builder  https://review.opendev.org/69470909:20
openstackgerritIan Wienand proposed zuul/nodepool master: Dockerfile: add DEBUG environment flag  https://review.opendev.org/69484509:20
openstackgerritIan Wienand proposed zuul/nodepool master: Also build sibling container images  https://review.opendev.org/69739309:20
openstackgerritIan Wienand proposed zuul/nodepool master: [wip] move openstack testing to use containerised daemon  https://review.opendev.org/69346409:20
*** jangutter_ has joined #zuul09:36
*** avass has joined #zuul09:37
*** jangutter has quit IRC09:39
*** ianychoi_ has quit IRC09:56
*** hashar has quit IRC10:15
*** arxcruz is now known as arxcruz|pto11:32
*** pcaruana has joined #zuul11:36
*** ianychoi has joined #zuul11:49
*** sshnaidm|afk is now known as sshnaidm11:52
*** jcapitao is now known as jcapitao|afk12:00
*** avass has quit IRC12:03
*** spsurya has joined #zuul12:05
*** rfolco has joined #zuul12:05
*** jpena is now known as jpena|lunch12:29
*** jangutter_ is now known as jangutter12:41
*** rlandy has joined #zuul13:19
openstackgerritSimon Westphahl proposed zuul/zuul master: Add optional support for circular dependencies  https://review.opendev.org/68535413:20
*** jcapitao|afk is now known as jcapitao13:20
*** jpena|lunch is now known as jpena13:30
openstackgerritSimon Westphahl proposed zuul/zuul master: Add optional support for circular dependencies  https://review.opendev.org/68535413:33
pabelangerzuul-maint: https://review.opendev.org/698324/ is a trivial reno update, hopefully help others13:35
*** sgw has joined #zuul14:02
*** sanjayu__ has quit IRC14:24
*** bhavikdbavishi has quit IRC14:28
*** bhavikdbavishi has joined #zuul14:29
*** jamesmcarthur has joined #zuul14:31
*** jamesmcarthur has quit IRC14:36
*** sanjayu__ has joined #zuul14:36
*** avass has joined #zuul14:38
*** jamesmcarthur has joined #zuul14:44
*** jlk has quit IRC14:52
*** jlk has joined #zuul14:52
*** jamesmcarthur has quit IRC15:06
*** Goneri has joined #zuul15:11
*** swest has quit IRC15:21
*** jamesmcarthur has joined #zuul15:25
*** sanjayu__ has quit IRC15:27
*** jamesmcarthur_ has joined #zuul15:27
*** jamesmcarthur has quit IRC15:31
*** bhavikdbavishi has quit IRC15:35
*** panda is now known as panda|bbl15:44
*** chkumar|ruck is now known as raukadah15:47
*** themroc has quit IRC16:20
clarkbI've double checked that the jobs we were testing yesterday ran with ansible 2.8 and auto python interpreter16:27
clarkbI don't think I've got anything else to check, should be good to revert the 2.7 pin in !zuul and then tag release16:27
*** jcapitao is now known as jcapitao|afk16:29
zbris there a way to use a single github pipeline that triggers some jobs on all PRs+comments but some jobs are triggered only by comments?16:39
zbror the only solution is to split the pipeline in two?16:39
zbrcurrent one looks like https://review.rdoproject.org/r/#/c/24032/2/zuul.d/github.yaml16:39
zbrand I want to enable triggering on PRs for some repos, but problably not for all.16:39
corvuszbr: yeah, 2 pipelines16:43
zbrcorvus: ok, thanks. wanted to be sure i am not doing something stupid.16:46
openstackgerritMerged zuul/zuul master: Add additional info for executor.merge_jobs release note  https://review.opendev.org/69832416:46
*** avass has quit IRC17:12
*** panda|bbl is now known as panda17:20
*** rlandy is now known as rlandy|brb17:26
clarkbcorvus: let me know if I can help do anything else to make zuul release stuff go smoothly17:36
corvusclarkb: is there a change to unpin 2.7?17:37
SpamapSzbr: one trick I've used, btw, is to have a label that triggers each, and on success/fail use those labels to have one trigger the other.17:38
clarkbcorvus: looking17:38
clarkbcorvus: doesn't look like it. Let me push it up17:39
SpamapSI don't do this today, but I did play with a thing that would add the 'run-deep-checks' label to any PR that failed check, so that the dev would have more data when responding to the fails.17:39
clarkbcorvus: do you think we should set the pin to 2.8 or just rely on zuul defaults?17:40
corvusclarkb: default17:40
corvusclarkb: can remove zuul 2.8 pin too17:40
*** igordc has joined #zuul17:42
*** hashar has joined #zuul17:43
*** rlandy|brb is now known as rlandy17:50
*** jpena is now known as jpena|off18:06
*** reiterative has quit IRC18:13
*** igordc has quit IRC18:13
*** igordc has joined #zuul18:14
*** rlandy is now known as rlandy|brb18:18
*** igordc has quit IRC18:25
*** jamesmcarthur_ has quit IRC18:30
openstackgerritMatthieu Huin proposed zuul/zuul master: admin REST API: zuul-web integration  https://review.opendev.org/64353618:35
*** mhu has joined #zuul18:35
clarkbstill waiting on ansible unpin to apply in production18:39
clarkbbut I've been watching jobs going through waiting for that18:39
*** tosky has quit IRC18:44
corvusmordred, Shrews: the googlecloudapi client is not thread-safe, plus we sort of have this idea in nodepool that maybe we would like to serialize requests to be nice to providers.  i feel like we should implement the taskmanager we once did with the openstack provider for the google provider.  and moreover, why not for aws and azure and ...18:44
corvusmordred, Shrews: the obvious implecation of that is that openstack would be the odd one out since it's the only one with its own taskmanager18:46
corvusmordred, Shrews: do either of you have ideas on how to approach this?  do you have any thoughts about how other drivers should handle this issue?18:46
clarkbthe openstack driver could use a nodepool level taskmanager if we wanted to be like the others (as sdk/shade operate not taskmanaged by default iirc)18:47
corvusclarkb: yeah; i thought there was some benefit to handing that off to sdk though18:48
fungii guess the discrepancy is that we abstracted the task management out into shade and eventually openstacksdk when all that logic was forklifted from nodepool? but that other providers don't have similar features in the sdks we use (or does nodepool just talk directly to rest apis for them?)18:49
corvusfungi: for both aws and google, there are sdks that are helpful (but probably not required)18:49
tristanCcorvus: I'm not sure to understand the difference between threads and task manager18:49
corvusin particular, there's a bunch of auth+discovery stuff it does18:50
corvustristanC: a taskmanager is a single thread which performs tasks on behalf of other threads.  so 100 launch threads can submit a task saying "create an instance" and the single taskmanager thread executes those serially.18:50
fungiwith caching18:50
fungier, in the list of things shade's providing on the auth/discovery front i mean18:51
corvustristanC: it solves both the problem of thread-safety in client libraries (if there is one) and the problem of rate-limiting to a single api endpoint across threads.18:51
mordredcorvus: so - there's a tricky-ish part here18:51
AJaegerhttps://review.opendev.org/#/c/691114/ adds some go jobs and roles to zuul-jobs, anybody interested to review it besides mordred , please?18:51
AJaegerand https://review.opendev.org/695594 " replace /home/zuul by ansible_user_dir" needs a review as well, please18:52
mordredcorvus: one of the reasons we kept pushing the taskmanager down into the sdk/ksa layers is to catch the rate-limiting requests for the actions that are ancillary18:52
tristanCcorvus: i see, makes sense. thus could this be abstracted away? e.g. launch thread submit operations as lambda to a generic task manager?18:52
corvustristanC: yes, that's more or less how it was implemented.18:53
mordredso, from nodepool, our action is "create_server" - but that involves one or more calls to keystone, one or more to nova and possibly some to cinder and neutron and glance - all abstracted away from the caller18:53
mordredso a high level taskmanager helps with the coordination of actions across threads - but not being in there there's holes in the rate limiting18:54
corvusmordred: yes, though i can think of some technical solutions to that problem18:54
corvus(which, i mean, would likely be necessary for client libraries which we don't plan to expand with this support)18:55
mordredyah18:55
tristanCmordred: for kubernetes, or more generally for rest, should an action be (verb, endpoint, data, callback)?18:55
clarkbfwiw I think many of the nodepool drivers are already distinct enough that havin different taskmanagement is probably not the end of the world18:55
corvusclarkb: i don't think they need to be that distinct18:55
clarkbthat is fair18:56
corvusthe framework is pretty close to "implement create; implement list; implement delete; you're done"18:56
corvusi'm basically there, after 2 hours of work, for the google api client.  but then i run into thread safety issues.18:56
tristanCmordred: oh nevermind, create/list/delete sounds more formal18:56
corvusso i'm thinking, i like the idea that one can implement a basic driver in 2 hours.  we did a pretty good job there.  but the thread-safety/rate-limit aspect of it is not genericised.  so i'm thinking, maybe we should do that, and end up still with the idea that it takes about 2 hours to implement a driver.18:57
mordredcorvus: if we moved back to a nodepool level taskmanager - it might then also make sense to have list/filter be in the nodepool layer too, yes?18:57
corvusmordred: instances or other things?18:58
AJaegercorvus: left a comment on https://review.opendev.org/#/c/696939/14 - want to fix with a followup? Then I change my -1 to a +2A18:58
mordredcorvus: instances18:59
mordredcorvus: like - that seems like a pattern that you'd want in the generic parts18:59
corvusAJaeger: replied18:59
mordredfrom the sdk side - the task management is pretty easy for nodepool to just stop using if it added its own taskmanager back19:00
AJaegercorvus: thanks, I'm convinced ;)19:00
corvusmordred, clarkb, fungi, tristanC: okay, i'll dig deeper into this.  i'll see if i can quickly come up with a reasonable proposal for a driver-generic taskmanager.  if not, i'll do something quick for the google driver and we can come back later and refactor.19:03
corvus(but in any case, it sounds like the answer is not "do not make a taskmanager for the google driver" :)19:03
tristanCcorvus: thanks, that sounds like a good thing to have. i'd be happy to review it19:03
mordredcorvus: ++19:04
tristanCcorvus: one things that is also difficult to manage is the quota and respecting max-servers... would be nice if the manager could do that too19:04
corvustristanC: agreed19:05
clarkbI thought max-servers was already handled in a single thread19:07
clarkbthe provider manager that spawns the launch threads does that accounting iirc19:07
clarkb(I might have the names wrong)19:07
mordredmax-servers is - but requests-per-second is handled down in the ksa Adapter layer (in sdk)19:10
*** rlandy|brb is now known as rlandy19:11
clarkbmordred: ya just responding to tristanC's feature request. I think that feature is already complete (though maybe needs improving?)19:11
mordredyah19:11
Shrewsi just returned from my last ever doc appt for my shoulder (yay \o/), but i agree with the things mordred said19:13
fungilast ever? are you hanging up the snowboard? ;)19:13
Shrewsfungi: yup. sold my equipment a few weeks ago19:13
fungiwow19:14
mordredhttps://opendev.org/openstack/keystoneauth/src/branch/master/keystoneauth1/session.py#L1002-L1007 <-- that's the current state of rate limit support in the ksa layer  - along with https://opendev.org/openstack/keystoneauth/src/branch/master/keystoneauth1/adapter.py#L171-L17819:14
clarkbShrews: wow19:14
mordredShrews: \o/19:14
*** spsurya has quit IRC19:14
corvusShrews: yay!19:14
Shrewsi figure 2 injuries requiring 3 surgeries is enough19:14
fungiyou can come out here and take up kitesurfing19:14
Shrewsimma chase turtles with mordred19:15
fungior that, sure19:15
mordredShrews: it's much less likely to injure your shoulder for sure19:15
fungiworst case you'll need your shoulder treated for sharkbites19:15
fungijust bring a harpoon and you'll be safe19:16
clarkbcoral is harder than snow though19:17
openstackgerritMerged zuul/zuul-jobs master: openshift speculative containers  https://review.opendev.org/69693919:17
mordredclarkb: yes. but you're not supposed to touch the coral19:17
Shrewsi'm assuming "harpoon" is the beer19:17
Shrewsnot the pointy stick thing19:17
mordredalso - sharks really aren't interested in biting scuba divers - we're big and scary with all of our super loud bubbles19:18
clarkbmordred: ya be nice to the coral. But wave and current conditions can be terrible sometimes19:18
mordredit's the silly surface swimmers who look like tasty tasty morsels backlit against teh sun19:18
tristanCclarkb: i meant the other max- limit, for openshift it is done by the handler, and when multiple threads are creating pods, then the provider may go over the limit19:18
mordredclarkb: this is true19:18
clarkb(probably avoid getting in the water in the first place)19:18
mordredyeah19:18
mordredlike - just don't dive when it's like that19:18
clarkbtristanC: seems like a bug in that provider?19:18
clarkbtristanC: I think we can fix that the same way openstack handles it?19:18
*** jamesmcarthur has joined #zuul19:20
tristanCclarkb: probably yes, a bug that can be fixed. but if there is a generic manager, then perhaps this can be done automagically?19:20
clarkbtristanC: maybe. I guess my point is that the proposed task manager isn't necessary and avoiding adding extra functionality into the task manager might make the abstraction simpler19:21
tristanCwell i don't know how the existing task manager operate, but if it could do such thing (handle over-quota issue) it would further reduce the complexcity of driver implementation19:25
*** themroc has joined #zuul19:27
tristanCe.g., https://opendev.org/zuul/nodepool/src/branch/master/nodepool/driver/openstack/handler.py#L247-L265 and https://opendev.org/zuul/nodepool/src/branch/master/nodepool/driver/openshift/handler.py#L59-L80 are handling quotas19:27
clarkbtristanC: to me quota handling in particular is going to be driver specific19:27
clarkbbecause there are many axis on which you can apply quotas19:27
tristanCopenstack invalidate it's cache, and openshift just keep on retrying19:27
tristanCaws and kubernetes doesn't check for quota issue19:28
clarkbya19:28
tristanCand they all have that while attemp <= retry loop.19:28
*** mhu has quit IRC19:29
ianwmordred / corvus : https://zuul.opendev.org/t/zuul/build/0aebe58151d245ad835506d716c6f28a <- sibling-ised, containerised nodepool+nodepool-builder+nodepool-launcher functional test that worked19:29
clarkbthough I guess if we don't actually care about the axes in the taskmanager and simply a boolean flag returned by the driver that may be simple enough19:29
ianwneed to get it reviewable, but the basics are there19:29
mordredianw: zomg! that's so awesome19:30
tristanCclarkb: yes, e.g. the taskmanager could have a 'is_exception_a_quota_exceeded_error' callback, then perhaps it could delay all create request until the exception is gone?19:32
*** jamesmcarthur has quit IRC19:34
*** jamesmcarthur has joined #zuul19:34
tristanCor the otherway around, e.g. driver.create can raise quota issue19:35
tristanCas this "while attempts <= retries" loop is implemented by all the drivers (except static)...19:37
Shrewswe have API calls for the driver to report quota issues since the driver is the only source of knowing its quota. I don't feel like we could (or should) make that generic19:38
clarkbfwiw ansible 2.8 seems to be running stable on opendev after unpinning now19:39
Shrewsif there's a deficiency around the existing api's, we should fix that19:39
clarkball of the job failures I've looked at were failures in the job unrelated to ansible version19:39
*** mhu has joined #zuul19:41
Shrewscorvus: oh, also, 2 hours for the gce driver is awesome. i looked at possibly implementing that a few weeks back (just on a whim) but didn't like the trial period stuff (and the resulting sales calls that I'm sure would have occurred)19:42
corvusShrews: i used my redhat account and redhat office address19:43
corvusit doesn't seem like a terrible api19:44
*** themroc has quit IRC20:49
*** hashar has quit IRC21:19
*** hashar has joined #zuul21:22
*** mattw4 has joined #zuul21:36
*** pcaruana has quit IRC21:38
jamesmcarthurHi y'all. I've been working on a Zuul page for wikipedia.  I basically copied what was on the wikimedia page21:40
jamesmcarthurBut there is a ton of stuff that's WMF specific. Plus, we have an opportunity here to put our keywords into the page (like open source CI)21:41
jamesmcarthurIf you have a chance, could you all take a look: https://en.wikipedia.org/wiki/Draft:Zuul_CI21:41
jamesmcarthurThe page isn't scheduled to be reviewed for several months, so we have some time to get it right21:41
jamesmcarthurHowever, I'd love to get a jump on it.  Please feel free to suggest edits directly or just email them to me directly (jimmy@openstack.org)21:42
*** sgw has quit IRC21:50
jamesmcarthurThere is some stuff that I'm pretty sure is off/old - like the references to Jenkins ( It listens to Gerrit stream-events feed and trigger jobs function registered by Jenkins using the Jenkins Gearman plugin.)21:50
jamesmcarthurSo not only should we update this stuff, but also the wikimedia page as well21:51
jamesmcarthurAny/all help appreciated21:51
corvusjamesmcarthur: thanks!  yeah, most of the info on that page is outdated or is very specific to wmf, so i think it'll be a good chunk of work.  it's a good outline though, to make sure we answer all those questions.21:52
corvusi'm not sure the wmf page itself needs updating though; they may still be running on a fork of zuul v2.21:52
jamesmcarthurcorvus: ok - got it21:52
jamesmcarthurSo it turns our Robert Cathey can actually publish it for us.21:53
jamesmcarthurSo basically, as soon as we get it ready we can get it live.  This will be a huge SEO boost for us.21:53
*** jamesmcarthur has quit IRC21:56
*** jamesmcarthur has joined #zuul21:58
corvusi will try to give it some significant time by the end of the week; hopefully someone else will have time before then :)21:58
jamesmcarthurcorvus: Happy to post this to the ML as well, if you think that's appropriate?21:59
jamesmcarthurI know it's just before the holidays, so no worries.21:59
corvusalso, should the title be something like "Zuul (something to disambiguate)" ?21:59
corvus"Zuul (Project Gating System)" "Zuul (CI/CD Software)" "Zuul (CI Software)"...22:00
jamesmcarthurI did Zuul CI since that's basically our URL22:00
corvusit's our url, but not our name22:00
jamesmcarthurExcellent point22:00
corvus[and that only because we can't afford our name as a url :( ]22:01
jamesmcarthurlol22:01
corvuscourse, with the .org thing, maybe nobody will be able to22:01
jamesmcarthurErgh. That irritates me so much.22:02
jamesmcarthurRe: the name - why don't you put some thought into it. I think we have to make a new entry, which is just fine.22:02
jamesmcarthurB/c you can't change the name after you've suggested it.22:02
jamesmcarthurPersonally, I would go with Zuul (Open source CI) if we're really looking to get maximum SEO juice22:03
jamesmcarthurOtherwise (CI/CD software)22:03
jamesmcarthurI don't think the term "project gating" is easily or widely understood.  HOWEVER, it's an amazing opportunity to define the term22:04
corvusi don't know enough about wikipedia norms to know what the best disambiguator would be; i'm open to about anything, but i do think it would be good to indicate that the name is Zuul22:04
jamesmcarthurAnd in fact, we could also put together a Project Gating page22:04
jamesmcarthurto explain the concept22:04
corvusjamesmcarthur: there's this page, all of whose citations post-date the creation of zuul: https://en.wikipedia.org/wiki/Gated_commit22:05
corvusonce the zuul page exists, we should update that page to link to it, and dig up earlier citations22:05
*** sgw has joined #zuul22:05
jamesmcarthurok - it looks like these guys (https://en.wikipedia.org/wiki/TeamCity) basically created that page for the same reason22:06
clarkbtypically it would be Zuul (Software) I think. But there is multiple zuul softwarews22:07
clarkbjamesmcarthur: I think we should remove operational and configuration details and add history/evolution?22:07
jamesmcarthurInteresting that it's from JetBrains.  I used to use a lot of their SQL analysis tools for MS SQL.22:07
clarkband a bit on gating22:08
jamesmcarthurclarkb: Agreed. History, evolution, versions/release info, maybe plugins?22:08
clarkbjamesmcarthur: ya supported plugins/drivers is another good one22:09
jamesmcarthurIf you all want to create a github account, you can just edit the page.22:09
jamesmcarthurOnce we're all in agreement, I can create a new one with the correct page name22:09
clarkbgithub?22:09
jamesmcarthurand voila22:09
clarkbor wikipedia22:09
jamesmcarthuruhh22:09
jamesmcarthurwikipedia22:09
fungii'm also working on an article about zuul for opensource.com (i'll seek some editors from this crowd once i have the draft ready) which could serve as another citation in the wiki article22:10
ianwjamesmcarthur: i agree that "project gating" isn't really an understood term ... i wrote https://review.opendev.org/#/c/683085/1 (which has a lot of great comments from Jan i should get back to) when i thought about this very thing22:11
fungibut i think we should feel free to cite recorded conference talks and things like that too22:12
jamesmcarthuroh - this is great ianw :)22:12
jamesmcarthurfungi: absolutely - the more citations we can do the better22:12
clarkbianw: jamesmcarthur there is actually a wikipedia article on project gating22:12
clarkbhttps://en.wikipedia.org/wiki/Gated_commit22:13
corvusi don't think it's recorded, but here's a slide presentation from 2011 about gated commits: https://docs.openstack.org/infra/publications/2011-uds_p-launchpad/#(3)22:14
corvushere's a recorded talk from 2012: https://www.youtube.com/watch?v=1uzTKKxnYHs  slides https://docs.openstack.org/infra/publications/2012-lca-overview/#(9)22:15
*** tosky has joined #zuul22:15
corvusplease don't watch that22:15
corvusyou can tell it's old because the aspect ratio is 4:322:16
clarkbwow this is really difficult22:20
clarkbhttps://etherpad.openstack.org/p/zuul-wikipedia22:20
clarkbit is easier for me to start putting edit ideas in there than make a new account >_>22:20
clarkbcorvus: we good to make those releases?22:21
clarkbits been about 1.5 hours since ansible 2.8 took effect in opendev and there hasn't been any issues that I have seen22:21
corvusclarkb: sounds good, i'll get started22:22
corvuscommit a7fa150e216d3eec9bcba974ef27349a1fd4d742 (HEAD -> master, tag: 3.13.0, origin/master, origin/HEAD)22:23
corvusclarkb: ^ look right?22:23
corvusrelnotes are at https://zuul-ci.org/docs/zuul/releasenotes.html22:23
clarkbyes, that commit looks right. Also the delete 2.5 change hasn't merged yet so we won't accidentally tag that one22:24
corvuspushed tag22:25
*** rfolco has quit IRC22:25
*** sshnaidm is now known as sshnaidm|afk22:33
clarkboh heh I've just realized corvus linked to the gated commit url before I did22:37
clarkbalso this is actually really difficult22:38
clarkbwhat I've got on that etherpad is more of a rich outline than article content22:38
clarkbfeel free to stick it in the wikipedia draft or edit it22:39
*** Petar_T has quit IRC22:39
*** rfolco has joined #zuul22:45
*** hashar has quit IRC22:52
*** jcapitao|afk has quit IRC22:56
*** jamesmcarthur has quit IRC22:56
*** jamesmcarthur has joined #zuul23:03
*** jamesmcarthur has quit IRC23:03
corvussent the 3.13.0 announcement23:12
*** rlandy is now known as rlandy|bbl23:27
*** sgw has quit IRC23:34
*** tosky has quit IRC23:40
openstackgerritJames E. Blair proposed zuul/nodepool master: WIP: Add Google Cloud provider  https://review.opendev.org/69834223:57
corvusclarkb, mordred, Shrews, tristanC: ^ that's actually in worse shape than yesterday, and i hesitate to suggest anyone look at it.  *but* if you want to take a look at drivers/gcloud/adapter.py, you can see what i think a driver impl will look like with this23:59

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