Tuesday, 2019-02-19

openstackgerritIan Wienand proposed openstack-infra/system-config master: [dnm] letsencrypt prototype implementation  https://review.openstack.org/63675900:15
openstackgerritMerged openstack-infra/zuul-jobs master: Fix build-docker-image when using buildset_registry  https://review.openstack.org/63765000:25
openstackgerritIan Wienand proposed openstack-infra/system-config master: [dnm] letsencrypt prototype implementation  https://review.openstack.org/63675900:42
openstackgerritClark Boylan proposed openstack-infra/zuul master: Don't request PR issue data  https://review.openstack.org/63672800:59
openstackgerritJames E. Blair proposed openstack-infra/zuul-preview master: WIP: test docker registry  https://review.openstack.org/63703701:01
openstackgerritJames E. Blair proposed openstack-infra/system-config master: WIP: Run zuul-preview  https://review.openstack.org/63765401:21
openstackgerritTristan Cacqueray proposed openstack-infra/zuul master: amqp: add basic trigger  https://review.openstack.org/63745801:32
openstackgerritTristan Cacqueray proposed openstack-infra/zuul master: amqp: add message informations to the job variables  https://review.openstack.org/63766602:27
openstackgerritTristan Cacqueray proposed openstack-infra/zuul master: amqp: add message informations to the job variables  https://review.openstack.org/63766603:08
openstackgerritIan Wienand proposed openstack-infra/nodepool master: [dnm] testing devstack fix  https://review.openstack.org/63766903:11
openstackgerritTristan Cacqueray proposed openstack-infra/zuul master: web: add triggers information to pipeline list  https://review.openstack.org/63767003:13
openstackgerritTristan Cacqueray proposed openstack-infra/zuul master: webtrigger: add initial driver and event  https://review.openstack.org/55515304:01
openstackgerritTristan Cacqueray proposed openstack-infra/zuul master: webtrigger: add web route and rpclistener  https://review.openstack.org/55483904:01
*** Shrews has quit IRC04:17
*** Shrews has joined #opendev04:19
*** Shrews has quit IRC04:24
*** Shrews has joined #opendev04:25
openstackgerritTristan Cacqueray proposed openstack-infra/zuul master: amqp: add message informations to the job variables  https://review.openstack.org/63766604:57
openstackgerritIan Wienand proposed openstack-infra/system-config master: [dnm] letsencrypt prototype implementation  https://review.openstack.org/63675905:22
openstackgerritIan Wienand proposed openstack/diskimage-builder master: Keep git after ironic-agent post  https://review.openstack.org/63716205:32
openstackgerritTristan Cacqueray proposed openstack-infra/zuul-jobs master: install-kubernetes: fix kube config permission  https://review.openstack.org/63768205:48
openstackgerritTristan Cacqueray proposed openstack-infra/nodepool master: DNM: test install-kubernetes fix  https://review.openstack.org/63768305:49
openstackgerritIan Wienand proposed openstack-infra/system-config master: [dnm] letsencrypt prototype implementation  https://review.openstack.org/63675906:19
openstackgerritIan Wienand proposed openstack-infra/infra-specs master: letsencrypt spec  https://review.openstack.org/58728306:26
*** bgmccollum has quit IRC06:53
*** bgmccollum has joined #opendev07:14
openstackgerritTristan Cacqueray proposed openstack-infra/zuul-jobs master: install-kubernetes: fix minikube config permission  https://review.openstack.org/63768207:32
openstackgerritSorin Sbarnea proposed openstack-infra/project-config master: Add tripleo-ci members as irc ops in oooq  https://review.openstack.org/63443807:42
openstackgerritTristan Cacqueray proposed openstack-infra/zuul-jobs master: install-kubernetes: fix minikube config permission  https://review.openstack.org/63768208:19
openstackgerritzhongshengping proposed openstack/os-testr master: add python 3.7 unit test job  https://review.openstack.org/63774909:06
openstackgerritzhongshengping proposed openstack/os-performance-tools master: add python 3.7 unit test job  https://review.openstack.org/63775909:06
openstackgerritMatthieu Huin proposed openstack-infra/zuul master: CLI: fail if trying to enqueue/dequeue a change for the wrong project  https://review.openstack.org/63666209:57
openstackgerritMerged openstack/diskimage-builder master: Keep git after ironic-agent post  https://review.openstack.org/63716210:08
openstackgerritJan Kundrát proposed openstack-infra/git-review master: Support usernames that contain '@' and ssh Git URLs  https://review.openstack.org/42870010:11
openstackgerritSimon Westphahl proposed openstack-infra/zuul master: Show animated progress bar in preparation phase  https://review.openstack.org/63781010:11
openstackgerritSimon Westphahl proposed openstack-infra/zuul master: Log to job output when running Ansible setup  https://review.openstack.org/63781310:24
openstackgerritTristan Cacqueray proposed openstack-infra/zuul master: web: add jobs list filter  https://review.openstack.org/63365210:25
openstackgerritMatthieu Huin proposed openstack-infra/zuul master: CLI: fail if trying to enqueue/dequeue a change for the wrong project  https://review.openstack.org/63666210:42
openstackgerritTristan Cacqueray proposed openstack-infra/nodepool master: config: add statsd-server config parameter  https://review.openstack.org/53556010:53
openstackgerritMatthieu Huin proposed openstack-infra/zuul master: CLI: fail if trying to enqueue/dequeue a change for the wrong project  https://review.openstack.org/63666211:01
openstackgerritMerged openstack-infra/bindep master: Fix bindep --brief for arch linux  https://review.openstack.org/63742111:01
openstackgerritBrendan proposed openstack-infra/zuul-jobs master: Use zuul_workspace_root variable for Git workspace prep  https://review.openstack.org/63687012:10
openstackgerritNir Magnezi proposed openstack/diskimage-builder master: [wip] rhel8 beta support  https://review.openstack.org/62313713:40
openstackgerritMatthieu Huin proposed openstack-infra/zuul master: CLI: fail if trying to enqueue/dequeue a change for the wrong project  https://review.openstack.org/63666214:32
openstackgerritSean McGinnis proposed openstack-infra/openstack-zuul-jobs master: Add per-cycle Python job templates  https://review.openstack.org/63786614:58
openstackgerritMerged openstack-infra/nodepool master: Properly handle TaskManagerStopped exception  https://review.openstack.org/63639315:26
openstackgerritMiguel Lavalle proposed openstack-infra/irc-meetings master: Propose a new time for L3 subteam meeting  https://review.openstack.org/63790015:34
openstackgerritMerged openstack-infra/zuul-jobs master: install-kubernetes: fix minikube config permission  https://review.openstack.org/63768215:45
openstackgerritQuique Llorente proposed openstack-infra/zuul master: Ignore files at timer trigger  https://review.openstack.org/63791615:51
openstackgerritClark Boylan proposed openstack-infra/zuul master: Rename project to project_name in getPullBySha  https://review.openstack.org/63721815:55
openstackgerritClark Boylan proposed openstack-infra/zuul master: Test GithubShaCache  https://review.openstack.org/63722815:55
openstackgerritClark Boylan proposed openstack-infra/zuul master: Switch to LRU based sha to PR cache  https://review.openstack.org/63761515:55
openstackgerritClark Boylan proposed openstack-infra/zuul master: Switch to LRU based sha to PR cache  https://review.openstack.org/63761516:04
*** dmsimard has joined #opendev16:06
openstackgerritJan Kundrát proposed openstack-infra/nodepool master: Implement a Runc driver  https://review.openstack.org/53555616:16
openstackgerritJames E. Blair proposed openstack-infra/zuul master: Fix typo in build api endpoint  https://review.openstack.org/63622716:28
openstackgerritJan Kundrát proposed openstack-infra/nodepool master: Implement a Runc driver  https://review.openstack.org/53555616:45
* fungi is around17:03
corvusclarkb, mordred: around?17:03
clarkbhello17:03
corvuslet's use https://etherpad.openstack.org/p/ctzZNmV9CE if we need it17:03
corvusso the question at issue is, given https://github.com/go-gitea/gitea/issues/5798 should we continue to plan to deploy on k8s or just use plain docker17:05
* mordred is here17:05
corvusmordred: ooh, nice respnse on your comment there :)17:05
mordred\o/17:05
mordredI think that's an excellent plan17:05
corvusoh, and just to make it clear, my hope is that no matter what, we eventually get to the system that we thought we were about to run -- a shared-everything multi-master running in k8s17:06
corvusso whatever we're talking about here today, i think should be considered temporary until that happens17:06
clarkbif that is the end goal I think I'd slightly prefer shared nothing in k8s17:06
clarkbthen transition to shared everything in k8s17:06
corvusand based on mordred's comment, it looks like there's a roadmap to get there17:06
clarkbas that will give us familiarity with the tooling17:06
fungiyeah, i leaned that direction when we discussed it last week17:06
fungior was that over the weekend?17:07
corvusi didn't do much discussing over the weekend :)17:07
fungiyeah, my notes say that was friday17:08
corvusokay i was about to write some stuff about how it might be easier to transition from shared-nothing docker to shared-everything k8s....but i think the real thing is that, if we did shared-nothing docker, i would like to keep the k8s cluster running17:08
fungiso anyway, shared nothing in kubernetes struck me as the least reinventing if the end goal is shared everything in kubernetes17:08
clarkband I expect the transition will be take one of the shared nothings and turn it into a shared everything and delete the other shared nothings17:08
clarkbwhich in theory k8s makes easier for us when we get there17:09
*** SotK has joined #opendev17:09
corvusso that basically, we would continue to work on the k8s cluster even while using docker17:09
corvusthe big question for me regarding shared-nothing-k8s is -- how do we set up replication?17:09
clarkbcorvus: oh I was thinking the opposite re transition. We'd essentially tack on an elasticsearch then run more pods17:09
clarkbcorvus: I think we can have a load balancer read only frontend for user facing http(s). Then have load balancer do 1:1 to individual ssh pods and set up gerrit to push to each of those17:10
fungiwhat needs replicating under shared-nothing if we start uot just providing read-only repository browsing and searching? just the git repos themselves i guess?17:10
corvusfungi: yeah, in a shared nothing system, we need gerrit to replicate to (let's use our current number) 8 different locations17:11
mordredcorvus: yeah - sort of what clarkb said - I think we'll want to expose port 22 of each individual gitea pod via a non-loadbalancer service17:11
corvusso, does anyone know how to do that in k8s? :)17:11
mordredcorvus: and then put each of those into the gerrit17:11
mordredcorvus: I can put it on my learn-how-to list if that's where we go - I think we just want to add some service objects with a clusterip type17:12
fungioh, so it uses the same ssh port for serving git+ssh as for pushing into, i guess that's the challenge?17:12
corvusmordred: i guess that's a different kind of service, but still something special that's going to cause k8s-on-openstack to get a fip from neutron?17:12
mordredcorvus: yeah. I think so - obviously need to test that theory17:12
clarkbfungi: I don't think we planned to serve git+ssh generally17:13
clarkbfungi: its merely a way to push replicated git repos from gerrit into gitea I think17:13
corvusright17:13
fungioh, i see17:13
corvusin all cases, the ssh port is only for gerrit17:14
fungiokay, so we don't need both lb and non-lb for ssh in that case17:14
corvusin shared-everything, our load balancer has 3 ports, 2 of them public http(s), and one of them is ssh, used only by gerrit.  they all map to any of the pods, because any pod can handle a git push17:14
clarkbexcept as I noted in the etherpad I think the high level concept of a load balancer is how you expose public IPs in k8s even if not really load balancing anything17:14
corvusin shared-nothing, we still have the lb with http(s) to all pods, but each pod needs its own incoming ssh listener for gerrit17:15
mordredclarkb: well - actually, that's concept is the "service" I believe - one of the types of Service is LoadBalancer17:15
clarkbmordred: ya `kubectl expose deployment hello-world --type=LoadBalancer --name=my-service` from docs at https://kubernetes.io/docs/tutorials/stateless-application/expose-external-ip-address/17:16
clarkbbasically our terminology is conflicting here. K8s calls it a load balancer even if you don't load balance anything17:16
clarkbyou just set up that service per singleton deployment17:16
corvusif we have an octavia lb for each pod, that's rather heavyweight, isn't it?17:17
mordredhttp://git.openstack.org/cgit/openstack-infra/system-config/tree/kubernetes/gitea/k8s/service.yaml <-- that's how we do the load balancer17:17
mordredhttp://git.openstack.org/cgit/openstack-infra/system-config/tree/kubernetes/percona-xtradb-cluster/service-percona.yaml is a non-loadbalancer service17:18
clarkbcorvus: yes it is possible we'd want to manage that external to k8s in the k8s shared-nothing setup similar to how we'd do it with the docker only setup17:18
mordredalthough it's just exposing that service locally to the cluster17:18
corvusmordred: right, though that's only internal17:18
clarkbhttps://kubernetes.io/docs/concepts/services-networking/#external-ips may be what we want which is the non load balancer option17:21
mordredreading through things real quick on https://kubernetes.io/docs/concepts/services-networking/service/ - we might just want to have some ansible splat a floating ip on to internal k8s address (I do think spinning up 8 octavia load balancers starts to get a bit silly)17:21
clarkbmordred: ya then expose that via external ips?17:21
mordredyeah. potentially so17:21
corvusi added a second question -- which is whether we can even individually address the pods with a service at all...17:22
clarkbcorvus: I think you can via external-ips and node affinity/pinning17:22
mordredwell - I think what we probably want is a statefulset similar to how the percona xtradb cluster is set up17:23
clarkbcorvus: you'd tell k8s to expose the pods on these external IPs then map pod1 to host1+ip1 and pod2 to host2+ip217:23
mordredso we tell k8s "I want 8 of these, but I want _these_ 8 - and I want them to come back in this shape when they go away and come back"17:23
clarkb++17:23
mordredthen we give the statefulset the pod spec that looks like our current gitea pod17:24
mordrednow - the thing is - this is going to be pretty radically different in shape than our current gitea k8s17:24
mordredand migrating from it to shared disk k8s might not be any easier than migrating from docker-compose17:24
mordredso I think what we'd be getting familiar with is running a something in k8s - but the shape of the something is gonna be pretty different17:25
corvusi suspect that if we started with k8s, we would just migrate to a second k8s cluster when they fix the index issue...17:25
mordredyeah - and maybe take that opportunity to deploy rook with CSI rather than FlexVolume17:26
corvusthere's rook to consider too -- by the time they fix that, the new rook....yeah that17:26
clarkbconsidering rook doesn't do in place upgrades that may be the best approach anyway17:26
corvusthat probably wants a redployment anyway, considering how invasive it is17:26
mordredor CNS ... or whatever17:26
mordredyah17:27
corvusso either way, we're talking about migrating to a new k8s cluster when ES becomes an index option17:27
fungii'm not familiar with what filesystems gitea relies on... does it keep the git repos in a native git disk format or is it keeping them in some sort of gitea-specific format?17:28
corvusfungi: native git17:28
fungioh, but we can't push directly onto the filesystem because it relies on its ssh interface to trigger indexing, right?17:29
mordredyah17:29
corvusfungi: yep17:29
fungiand there's no way to push into just one of them yet have them all share the same index off the filesystem, because they all want to obtain a write lock on the index17:30
openstackgerritMerged openstack-infra/zuul master: Fix typo in build api endpoint  https://review.openstack.org/63622717:30
fungiand presumably wouldn't know when to reread the index into memory i suppose17:30
mordredyah. that's the issue that they're looking to solve by adding optional support for elastic17:30
clarkbfungi: ya if they supported read only instances it would work that way, but tehy don't17:30
corvusthere is one thing we haven't looked into...17:31
clarkb(elasticsearch and multi master is better fix though)17:31
corvusthe idea of still having one git filesystem, but having separate indexes, and somehow getting the triggering event to all of the pods individually17:31
openstackgerritClark Boylan proposed openstack-infra/zuul master: Switch to LRU based sha to PR cache  https://review.openstack.org/63761517:32
corvusi think that would basically mean replacing a gitea component with some kind of shim we write ourselves.17:32
corvusit sounds like a terrible idea to me.  :)17:32
corvusbut it might be possible.17:32
mordredcorvus: yeah. it does. but it is worth mentioning :)17:32
mordredcorvus: becuase I'm pretty sure the indexing event is triggered with a rest payload17:32
clarkbI wonder what would happen if the gitea process flock failed17:32
clarkbmaybe that is our shim, mounting the fs in such a way that they can't lock for writing but maybe if well behaved would read for reading17:33
mordredcorvus: so we could, potentially, put in a git repo hook something something that hit all 8 of them17:33
mordredclarkb: I believe we can configure them to each have different index files17:33
clarkb(I doubt it is that well behaved but it is surprising it worked in the old buggy code given the comments in bleve/boltdb around the dangers of multiwriters)17:33
mordredclarkb: and they would attempt to flock that separate index file17:33
clarkbmordred: ya we can configure that.17:33
corvusmordred: yeah.  i think we'd probably just replace the gitea ssh command with a reimplementiation that hit all of them instead of localhost.17:33
clarkbmordred: btu then we have to replicate the push events17:33
fungioh, an ssh multiplexer?17:33
clarkbmordred: I was thinking maybe theywould just give up on the flock and open for reading if all but one get a read only fs17:34
mordredcorvus: yeah. and we could potentially tempalte that with ansible when we push things out17:34
corvusfungi: no, i think we'd still have one ssh listener, but the ssh "command=" that we run would be our own, and not gitea.17:34
fungiaha17:34
corvuscurrently it's "command=gitea serv --user=1" or something...17:34
corvusso we'd do "command=/usr/local/bin/hit-all-gitea-urls.py" :)17:34
mordredcorvus: I think that woudl take at least as much time to get right as figuring out the right statefulset incantations to get the full shared nothing with 8 ips ... and I don't think any of us would grow super useful knowledge as a result17:35
corvusbut i think that command is doing the git recv-pack stuff as well, so it's not exactly straightforward.17:35
fungiand all that really solves is the kubernetes load-balancing configuration difference and having just one replication destination in gerrit configs17:36
clarkbanother terrible idea: monkeypatch the fix out17:36
mordredhah17:36
clarkbit will probably work until it doesn't :)17:36
corvusclarkb: yeah... like, it may work until we restart :)17:37
mordredI mean - we ARE building our own images - so we _could_ do that ... but oy.17:37
mordredwe coudl also just go back to running 1.6.0 and stay there until a release with elastic17:38
clarkbmordred: 1.7.x includes security fixes17:38
clarkbthey are telling everyone to upgrade17:38
mordredyeah - but are they relevant to our use of gitea17:39
clarkbmordred: that I don't know17:39
corvusmordred: i think i have the same worry about that though -- it works until it doesn't17:39
mordredlike -w e don't let users log in - nobody is using issues or prs or user accounts or ssh uploads17:39
mordredcorvus: fair17:39
clarkbcorvus: ya if the bug is present in 1.6.0 it isn't any better than patching out the fix17:39
clarkbfwiw I think the shared nothing appraoch is likely our best option in the near term17:39
clarkband mostly a decision of whether or not we want ot k8s it. I think if the k8sing isn't too bad for shared nothing we should probably do that given our end goal is to k8s shared everything17:40
corvusalso, we don't even really know how well it was working... did each pod really use a shared index?  or did each pod have its own index, and we just happened not to notice when we did searches.  and were we reindexing the whole system on every startup?17:40
corvusmy gut still says "the docker stuff is simple and ready to go (with testing); the k8s approach means a lot of work to figure out how to make it work like docker".  i'm not at all opposed to it, if someone wants to jump in and figure that stuff out; i'm personally a little less enthused because of the complexity/longevity ratio here.  but i admit, we'd probably be more expert at k8s by the time we're done.17:40
corvus :)17:40
corvusi guess what i'm looking for is someone to say "i will figure out the open questions about shared-nothing k8s".  if someone who isn't me wants to do that, i'm on board and will be happy to help.17:42
clarkbre how it was working: My reading of the code is every process deleted the shared index on start then created a new index which allowed it to get a different file to flock. They were all essentially updating transient indexes. This oprobably means that you could get different search results from different backends17:42
fungibefore this discussion, i didn't realize that switching out the deployment model entirely was easier than adjusting the existing one for a different configuration17:42
openstackgerritMerged openstack-infra/zuul master: Don't request PR issue data  https://review.openstack.org/63672817:42
funginor was i aware/remembering we had docker-based deployment independent from kubernetes17:43
mordredI'm still torn on which is the best - I think doing k8s gets us more k8s knowledge which is good and where we want to be - but otoh compose is ready to go (with testing) so there's no more dev to do17:43
clarkbfungi: the new docker image registry is docker based deployment without k8s17:43
corvusfungi: we have 1 service in production with independent docker already :)17:43
corvusif you haven't seen it, here's the docker patch: https://review.openstack.org/63733017:44
clarkba good compromise is probably to keep the k8s up and running, use it to work on deploying gitea how we want it in k8s, but deploy gitea for near term prod with the docker compose work that is already done17:44
mordredso - in a vacuum I'd vote for shared-nothing-k8s - but compose being ready to go and shared-nothing-k8s needing to be written I think tips me back to "let's just use compose as a temporary"17:44
mordredclarkb: ++17:44
corvusyeah, i'm all for keeping the k8s cluster up, and continuing work on integrating the k8s-on-openstack into our ansible, and figuring out testing :)17:45
mordredyeah17:45
fungiwhat service am i forgetting we're already running in production with docker?17:45
mordredlike - let's keep the ansible going even - maybe turn gitea deployment replicas back down to 1?17:46
corvusfungi: insecure-ci-registry.opendev.org17:46
corvusthe intermediate docker image registry17:46
clarkbmordred: ya thats a good step 0 given what we know about modern gitea17:46
mordredthat way the service will still be running there - and we can poke at it by ip17:46
clarkbmordred: and upgrade it and do all the other things that are still useful without many pods sharing everything17:46
clarkbI like that idea17:46
mordredyah17:47
mordredand keep gerrit replicating to it even17:47
mordredcause why not17:47
corvusfungi: whatcha think ^?17:47
fungimakes sense17:48
fungii'm cool with that plan17:48
corvusokay, i think we have consensus on: proceed with docker, keep k8s running and continue to integrate it, move to k8s when gitea speaks ES.17:48
fungii like that the docker-compose path is already tested17:49
fungi(continuously tested i mean)17:49
mordred++17:49
clarkbthinking out loud about this generally, this is a good real world illustration of how "just put it in k8s" might not actually help solve real problems17:49
corvusnext i'm supposed to make a list of outstanding tasks for opendev-gerrit, but i think i'm going to do that after we get the docker-compose stuff into semi-production (like we thought we had k8s until friday)17:49
clarkbso we probably shouldn't expect all our other services to map into k8s necessarily17:50
clarkbcorvus: wfm17:50
mordredclarkb: ++ I think that's a great thing for everyone to always remember17:50
fungiclarkb: ahh, but "put it in kubernetes" fans assume your services are already "cloud-native" which, i think, means they would also recommend rewriting gitea to not keep its own data or something like that17:50
corvuspesky data17:51
mordredso pesky17:51
mordredotoh - I think the elastic support is going to be a really nice addition to gitea out of this17:51
clarkbwho needs state17:51
corvusokay, https://review.openstack.org/637330 is ready for +3 then.  i can spin up some servers after it lands.17:51
corvusmordred: yeah, and running elastic in k8s sounds like a good idea :)17:51
clarkbcool I'll review once I'm caught up on my zuul changes tobish is kindly reviewing17:51
fungiout of curiosity, why is this xenial instead of bionic?17:53
fungior is the comment in playbooks/roles/gitea/templates/docker-compose.yaml.j2 just copy-paste of staleness?17:54
openstackgerritClark Boylan proposed openstack-infra/zuul master: Clarify project vs repository in getPullBySha  https://review.openstack.org/63795617:54
mordredcorvus: the host-networking patch at the end of that stack has a sad, but +2 on the first 217:55
clarkbfungi: I think our k8s work was all xenial because they don't have bionic packages17:55
clarkbfungi: but this docker compose work could be bionic likely17:55
fungialso, i suspect we're going to get a nonzero number of concerned researchers letting us know about the test credentials they think we accidentally published in playbooks/zuul/templates/group_vars/gitea.yaml.j217:55
mordredfungi: :)17:56
corvusmordred: yes!  it has a sad because i still haven't finished speculative docker containers :(17:58
corvusmordred: until i do that, we'll have to land the patch ahead of it blind, publish the container, recheck and hope for the best17:58
mordredcorvus: ah - nod17:59
corvusfungi: it is bionic.  but i'm still running xenial on my workstation so all my testing is with docker-compose version 2. and we don't need anything later yet.17:59
corvusmordred: but it's still good news that the test is failing as expected.18:00
fungigot it18:00
openstackgerritMerged openstack-infra/zuul master: Add dockerized test setup  https://review.openstack.org/63642418:21
openstackgerritJeremy Stanley proposed openstack-infra/system-config master: Docs addition on decrypting Zuul secrets  https://review.openstack.org/63796918:43
openstackgerritMerged openstack-infra/zuul master: Rename project to project_name in getPullBySha  https://review.openstack.org/63721818:51
openstackgerritMerged openstack-infra/zuul master: Test GithubShaCache  https://review.openstack.org/63722818:51
openstackgerritMerged openstack-infra/zuul master: Switch to LRU based sha to PR cache  https://review.openstack.org/63761518:51
openstackgerritMerged openstack-infra/zuul master: Clarify project vs repository in getPullBySha  https://review.openstack.org/63795618:55
openstackgerritTobias Henkel proposed openstack-infra/zuul master: Remove reference to localhost in zuul_return docs  https://review.openstack.org/63797419:09
openstackgerritMerged openstack-infra/system-config master: Add new openstackid01 host to inventory and cacti  https://review.openstack.org/63763319:22
openstackgerritJames E. Blair proposed openstack-infra/zuul master: Switch artifact return back to list  https://review.openstack.org/63797919:23
openstackgerritJames E. Blair proposed openstack-infra/system-config master: Have gitea sshd listen on 222  https://review.openstack.org/63733319:46
openstackgerritJames E. Blair proposed openstack-infra/system-config master: Use host networking for gitea  https://review.openstack.org/63733419:46
openstackgerritMerged openstack-infra/project-config master: Add cinderlib project  https://review.openstack.org/63761320:00
*** openstackgerrit has quit IRC20:09
*** openstackgerrit has joined #opendev20:27
openstackgerritMerged openstack-infra/system-config master: Deploy gitea with docker-compose  https://review.openstack.org/63733020:27
openstackgerritJan Kundrát proposed openstack-infra/zuul master: More parallelism for git clones and checkouts  https://review.openstack.org/63799620:37
openstackgerritJames E. Blair proposed openstack-infra/zuul master: Combine zuul.artifacts lists in zuul_return  https://review.openstack.org/63800520:55
openstackgerritJames E. Blair proposed openstack-infra/zuul-jobs master: Use list form of zuul artifact return  https://review.openstack.org/63800721:00
openstackgerritIan Wienand proposed openstack-infra/system-config master: Allow nb*.openstack.org to talk to graphite  https://review.openstack.org/63801121:07
openstackgerritMerged openstack-infra/zuul master: Switch artifact return back to list  https://review.openstack.org/63797921:49
openstackgerritMerged openstack-infra/zuul-jobs master: Use list form of zuul artifact return  https://review.openstack.org/63800721:52
openstackgerritMerged openstack-infra/zuul master: Combine zuul.artifacts lists in zuul_return  https://review.openstack.org/63800521:56
mnasermordred, clarkb, corvus: you can use a concept of a 'nodeport' in k8s to export a pod at a specific port on a server21:57
mnaserhttps://kubernetes.io/docs/concepts/services-networking/service/#nodeport21:57
mnaserthe only problem is the port range is not the ideal one to use21:57
mordredmnaser: yeah. I think going half-way with this stuff gets really squirrely21:58
mordredstill - good link thanks21:58
mnasermordred: imho the best approach i've been doing is use docker as a pkg manager21:59
mnaserwhich paves the way because it means you do maybe 80% of the work at containerizing your workload21:59
mnaserand then when you figure out the best k8s strategy (is there any?!) you can leverage teh same work you already did21:59
mnaserive been using a lot of docker_container with ansible to orchestrate all this stuff22:00
mordredmnaser: yah - that's basically where we've gotten to as well22:01
mordredmnaser: docker-as-packaging, ansible to deploy/run22:02
mnaseryep!22:02
mordredmnaser: means you can do a bunch of your work in the build steps22:02
mnaserreally quick, easily repeatable22:02
mordredmnaser: have you seen all the super sexy image promotion stuff corvus has been doing?22:02
mnasera little bit but not too much22:03
mordredmnaser: tl;dr build image in gate, gate test it - then once it lands, push the exact image you used in the gate up to your image registry22:03
mnasermordred: so i assume using artifact passing22:03
mordredmnaser: aka - speculative container images22:03
corvusthis is used currently for zuul images22:03
mnaserbecause different jobs do this, right?22:04
mnaserone in gate and one in post, or is it just one job22:04
corvuswell, the really speculative stuff is still to come, where we can build a container image based one one change, and use it in another change, all in the check pipeline22:04
mordredyeah. that stuff is super cool22:05
corvusmnaser: one job in gate, another in "promote"22:05
corvusmnaser: the next step will be a third job in "check"22:05
mordredbut the stuff we're going now pushes the image to docker hub but with a 'gate_' tag on it - so then the promote pipeline can retag it22:05
mordred++22:05
mnaserok i see22:05
mnaserso passing of the artifacting doesnt happen by say, push to swift22:05
mnaserand then download from swift afterwards22:05
corvussuper simple example: this change https://review.openstack.org/637334 depends on this container image change: https://review.openstack.org/63733322:06
corvusit's failing now, because the container isn't actually built22:06
corvusbut when i finish speculative containers, that first change would be able to pass before the second one lands22:06
mnaseraaaaaah22:06
openstackgerritClark Boylan proposed openstack-infra/infra-specs master: Update priority effort Gerrit topics  https://review.openstack.org/63802422:07
mnaserreally neat.22:07
openstackgerritIan Wienand proposed openstack-infra/project-config master: Enable DIB_SHOW_IMAGE_USAGE for build  https://review.openstack.org/63803122:42
openstackgerritJames E. Blair proposed openstack-infra/system-config master: Run an haproxy load balancer for gitea  https://review.openstack.org/63803322:45
openstackgerritJames E. Blair proposed openstack-infra/zuul master: Allow extra data in artifact schema validation  https://review.openstack.org/63803822:59
openstackgerritJeremy Stanley proposed openstack-infra/puppet-zuul master: Use jemalloc on Zuul v3 executors  https://review.openstack.org/63804423:16
openstackgerritJames E. Blair proposed openstack-infra/system-config master: Run an haproxy load balancer for gitea  https://review.openstack.org/63803323:19
openstackgerritMerged openstack-infra/zuul master: Allow extra data in artifact schema validation  https://review.openstack.org/63803823:33

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