Thursday, 2019-01-10

fungi was featured in an lwn article earlier this week. looks like an interesting effort similar to what we're working on15:16
fungialso some similar philosophies and design goals15:17
fungithough they seem to be taking the approach of implementing everything from scratch rather than integrating available free software15:19
fungii have a feeling much of that approach is driven by their desire to make browser-interfaced applications without javascript15:22
Shrewscorvus: the sound on the walkthrough is not working for me. "Error" is displayed next to the play button. No more info than that15:23
Shrewsthat working for anyone else?15:23
* Shrews tries a different 'puter15:23
corvusShrews: hrm, it's an ogg vorbis file... you can try downloading it directly at and play it with a local player15:25
Shrewsok, works on my work laptop15:25
fricklerfungi: interesting, but looks like the free-alpha trial of a soon-to-be-paid-for service by a single person according to
fungifrickler: oh neat, i missed that, as did the lwn article author i think15:33
fricklerI do particularly like the "w/o js" part, that's the single most thing I don't like about gitea15:34
fungianyway, aside from the funding model for the as-a-service part, it does seem all the source code for it is being published along with installation instructions15:35
frickleryeah, I don't object to the funding model per se, I was more wondering about your "they" vs. "him". seems one can also deploy all the things locally if one doesn't want to pay15:37
fricklerI was going to praise that the registration confirmation mail was pgp signed, sadly the signature is invalid ... :-/15:42
fricklerthis may be interesting for folks who don't have a lwn subscription (like me ;)
*** openstackgerrit has joined #opendev20:52
openstackgerritMerged openstack-infra/zuul-base-jobs master: Add ensure-output-dirs to base jobs
openstackgerritMerged openstack-infra/zuul-base-jobs master: Add fetch-output to base jobs
openstackgerritMerged openstack-infra/zuul-base-jobs master: Ignore errors on ssh key removal
clarkbit works20:58
corvusclarkb: can i trick you into reviewing and ?20:59
corvusthose should be ready to land, and we can build images21:00
corvusmordred: manilla just got a stable/rocky update, and the default branch is still master:
corvusmordred: so i think we can say that the default branch problem only shows up on initial replication21:02
corvusmordred: have you restarted pods with the new image?21:03
mordredcorvus: I am not sure21:03
mordredcorvus: I have 2 issues I'm unsure about right now21:03
mordredcorvus: first is - I ran the ansible and it showed nothing changed on the deployment, so I ran kubectl directly and then describe on the deployment and it still showed the gitea-templates configmap present, which was confusing21:04
mordredso I tried doing an edit - which worked and resulted in k8s redeploying the containers21:05
mordredso I'd like to get to the bottom of why the kubectl apply didn't do that21:05
mordredbut also -I'm not sure it pulled new images21:05
clarkbcorvus: ya I'll look at those in a moment21:06
mordredcorvus: dockerhub also seems to think jeblair/gitea was last updated 21 days ago21:06
mordredcorvus: so I'm thinking I did something wrong in all of thise21:06
corvusmordred: nope! i did not docker correctly!21:06
mordredcorvus: however, woot on manilla21:06
mordredcorvus: oh good21:07
clarkbmordred: re kubectl apply not doing what you expected could that be related to the three way diff preservation of existing stuff thing it does?21:07
mordredclarkb: perhaps?21:08
clarkblike if it was originally created directly and not via an apply21:08
clarkbI think the intent is that it would preserve that through21:08
corvusmordred: how about i try editing the deployment to add an env var and running the ansible again, now that i have actually docker pushed?21:08
mordredcorvus: works for me21:09
mordredclarkb: seems like a thing we might want to learn for our git-driven workflow21:09
clarkbmordred: ++21:10
corvusreplicaset.apps/gitea-769d46c966   3         3         1       29s21:12
corvusreplicaset.apps/gitea-9c5cd6bb4    2         2         2       22h21:12
corvusreplicaset.apps/gitea-ccc54cf54    0         0         0       4h21:12
corvusi think that's the deployment scaling down and up two replicasets21:13
mordredI think you're right21:13
corvussorry omitted headers21:13
corvusNAME                               DESIRED   CURRENT   READY   AGE21:13
mordredwoot. that seems to have worked21:13
corvusNAME                               DESIRED   CURRENT   READY   AGE21:13
corvusreplicaset.apps/gitea-769d46c966   4         4         3       1m21:13
corvusreplicaset.apps/gitea-9c5cd6bb4    0         0         0       22h21:13
corvusreplicaset.apps/gitea-ccc54cf54    0         0         0       4h21:13
mordredhttp:// is nice and clean21:13
corvusso that was just the dummy env var trick21:13
clarkbwhy are there 3 of them with 2 having no desired instances?21:14
corvusi ran ansible with -v and saw that it used the patch http method21:14
clarkbare they the old sets that will be removed?21:14
corvusclarkb: i don't know what the 22h old one is21:14
corvuswhy don't i do it again and see what happens21:14
mordredcorvus: there's a good deal of senseless vertical whitespace now21:15
corvusmordred: i think you removed too much21:15
corvusi don't see issues or code tab21:16
mordredoh - yeah - those tabs do seem to be missing21:16
corvusclarkb: now we're up to 421:17
corvusclarkb: so it doesn't seem to be deleting old replicasets21:17
clarkbcorvus: huh I guess it keeps track of the historical list?21:17
corvusso yeah, assuming we did things "correctly" and used versioned configuration and images, then you can roll-back to previous replicasets21:18
corvusi don't think that's our style (gitops and all) so maybe we should zero that21:18
corvusor set to 1 in case we want to look at changes or something21:19
clarkbcorvus: couple of questions on the ones in the dockerfile may just be improvements before production21:23
mordredcorvus: I do not understand why the tabs have gone21:27
mordredI did not actually delete the chunks that would produce it, nor change them21:27
corvusclarkb: replied21:29
mordredcorvus: and I see the wrapping div21:29
clarkbcorvus: similar types of questions on I don't think any of this prevents us from merging the changes but we may want to clean things up as followups21:30
mordred                        {{if .Permission.CanRead $.UnitTypeCode}}21:30
mordredis the template language construct wrapping the code tab21:30
mordredbut that didn't change21:30
mordredcorvus: aha!21:31
mordredcorvus: I pulled the template from the wrong version of gitea21:31
mordredcorvus: we seem to now be running based on 1.6.021:32
corvusneat i guess we upgraded just now :)21:32
mordredoh - well - no, I think I pulled from too new21:32
corvusoh yeah, our dockerfile pins 16021:33
mordredalthough there is a 1.6.3 out21:33
corvusclarkb: can you elaborate on "Clark Boylan: Since /data is shared we probably want to guard the mkdirs and chowns against them existing?"21:34
openstackgerritMonty Taylor proposed openstack-infra/system-config master: Use the v1.6.0 template instead of master
mordredcorvus: ^^21:35
clarkbcorvus: /data is mounted off of ceph and persists beyond the lifespan of a pod, but the jinja-init container is run whenever a new pod is started (this is my understanding at least)21:35
clarkbcorvus: was thinking we only want to mkdir and chown if those dirs do not yet exist (the first ever pod started)21:36
clarkbas is its probably fine, just extr awork we don't need to do21:36
corvusclarkb: ah... ok.  the mkdirs are "-p" and should be safe, but i agree, the chowns are redundant21:36
clarkb(and mkdir -p is actually a noop if it exists but the chowns might not be)21:36
clarkbcorvus: fwiw I think you can approve those as is, just wanted to point that stuff out while I was doing reviews21:39
clarkband we can cleanup password and simplify chowns later21:39
clarkbbut didn't approve in case you wanted to just fix it now21:39
corvusclarkb: cool; replied to 2nd set of comments21:39
corvusclarkb: i'll approve and roll forward21:40
corvusi've approved the first 2 image build changes; let's let those go through and see if the machinery works, then approve the next changes to get new builds and start exercising this21:41
mordredcorvus: ++ that's exciting21:41
mordredcorvus: incidentally, triggering a deploy when the image has changed and we're tracking :latest - is the same as the restart21:45
mordredcorvus: update a meaningless env var21:45
mordredthe things I've found include people saying things about how you'd obviously NEVER want to deploy 'latest' in production21:47
mordredI guess those people don't have good gating systems21:47
corvusspeaking of which -- we might be able to do some amount of gating on whether the k8s deployment works, however, we'll probably want a dev server so we can work out things like "update the repo header template when gitea changes all the variable names in a new version"21:48
corvuswe can probably run that in the same k8s cluster; we could probably just use sqlite and emptydir volumes to make it self-contained21:49
mordredcorvus: yeah.21:49
corvusthough if we decided we wanted to use rook, but didn't want to have a second rook cluster, i believe we could mount a subdir of the cepffs.  so we'd have "/prod" and "/dev" on the cephfs.21:50
corvus(but i like sqlite+emptydir for simplicity)21:51
clarkbcorvus: re gating the k8s deployment I think this is part of the struggle magnum and mnaser have21:51
clarkbwe can deploy a devstack an dmagnum and then k8s21:52
clarkbbut to run workload and hcekc that requires nested virt21:52
corvusclarkb: well, it's a little better for us, we can deploy a k8s (see nodepool func testing)21:52
mnaserSo I think an interesting weekend project would be a magnum nodepool provider for example21:53
mordredcorvus: fwiw - spamaps says he tags the image for every commit based on zuul.newrev21:53
clarkbcorvus: ya, it just won't test all the openstack integration points I guess, but maybe we don't care about that21:53
corvusclarkb: oh that, yes.  i'd be happy to assume those work for this purpose :)21:53
mordredcorvus: and then sets explicit tags in the deployment yaml - which can of course be also templated by ansible21:53
corvusmnaser: ++21:54
mnaserRight. I wouldn’t recommend doing nested virt to test these workloads. The reason I did for magnum is we have to test the deployment tool which happens to deploy VMs. It would be an overkill, having said that though, maybe it would be good to have a multinode test that runs the playbooks mordred wrote21:54
mnaserAnd then runs the workloads on top of those21:54
mnaserThat way you don’t have 2 different environments which are deployed differently, test and “prod”21:55
corvusmordred: yeah, if we're explicit about images in the deployment, then we can easily work on image updates for staging and then move to prod.21:55
clarkbseems like staging would be the gate though?21:56
corvusclarkb: i don't anticipate us being able to write a gate test that would fail on this page missing the code/issues tabs:
clarkbselenium could do it, but point taken21:57
corvusclarkb: maybe we would write that eventually, but at any rate, i was mostly puzzling over having an environment where we could say "let's upgrade to gitea 1.6.3 and see if it hoses our custom templates"21:57
corvus(side note: i will be happy when system-config doesn't run 13 puppet jobs on dockerfile changes)21:59
mordredcorvus: ++22:00
openstackgerritMerged openstack-infra/system-config master: Add gitea dockerfile
openstackgerritMerged openstack-infra/system-config master: Add jinja-init Dockerfile
openstackgerritJames E. Blair proposed openstack-infra/system-config master: Set APP_NAME for gitea
openstackgerritJames E. Blair proposed openstack-infra/system-config master: Set APP_NAME for gitea
mordredcorvus: zuul did not seem to run the system-config-build-image-gitea in post22:17
mordredcorvus: is that because if has a file matcher on it, so it didn't trigger in post?22:17
corvusmordred: yeah, i'm suddenly reminded of the recent report that file matchers don't work in post22:17
mordredcorvus: yeah22:17
mordredcorvus: this might be an example of that22:17
corvusthis also makes me think that the right answer to that is not "ignore file matchers" but rather "add files to the post event"22:19
corvuscause i really don't want to build all the docker images on every change to system-config22:19
corvusof course, what i really want to do is use promote22:20
corvusbut that entails uploading something to logs.o.o22:20
corvuswe could *really* abuse dockerhub and upload everything in gate with per-change tags and then have promote re-tag them...22:21
corvushow bad of an idea is that? :)22:21
corvusi mean, *most* changes in gate should end up being real publications... it just might be nice to clean up the ones that don't.22:22
mordredcorvus: I think it's a great idea - at least for the time being22:22
mordredand especially for this particular set of stuff22:22
corvusyou know, maybe promote could clear out all gate uploads *older* than the one it's promoting22:22
mordredmaybe it's even fine for zuul master - which is about as break-neck of a project as we're working from typically22:23
corvus(new ones may have shown up and are about to be promoted)22:23
corvusi actually think if we do that, it'll be a pretty reasonable use of the system22:23
corvusis there a "docker" command to list cremote images?22:27
corvusoh, maybe i just use the api22:27
openstackgerritMonty Taylor proposed openstack-infra/system-config master: Update to gitea v1.6.3
openstackgerritMonty Taylor proposed openstack-infra/zuul-jobs master: Add role to move docs and artifacts to log root
corvusgood news: i can totally find all the old change tags to delete23:24
corvusbad news: dockerhub doesn't support deleting tags23:24
corvus(you can delete manifests, but i think if you do that, you delete all the data for it, so... basically, we can't ever "un-tag" something)23:24
corvuswhat i'm taking from this is that dockerhub doesn't like to have things deleted and will be perfectly happy for us to send them a constant stream of change tags and never delete them.23:25
corvusso i think that's what i'll do.  :)23:25
mordredI am in favor of this approach23:32
corvusif you send an incorrect request to the dockerhub api, it responds by sending an enormous base64 encoded image23:35
corvusnot, as you might expect, a helpful error message23:36
mordredcorvus: do they expect you to save the image to a file and boot it in docker - and then run docker logs on the resulting container to get the error message text?23:38
corvussorry, i meant "picture"23:39
mordredthat doesnm't really make anything less ridiculous23:39
mordredwhy do they send a picture?23:39
mordredwait - is it a fail whale?23:39
corvusit's their 40423:40
openstackgerritMerged openstack-infra/project-config master: Added Vitrage specs
openstackgerritMerged openstack-infra/project-config master: Consolidate Cinder repo ACL settings
openstackgerritMerged openstack-infra/project-config master: Remove Cinder CI Verified label
openstackgerritMerged openstack-infra/project-config master: Add Review Priority column to glance repos
openstackgerritMerged openstack-infra/project-config master: Retire murano-deployment
openstackgerritMerged openstack-infra/project-config master: Run openstackid docs jobs on bionic

Generated by 2.15.3 by Marius Gedminas - find it at!