| fungi | https://sr.ht/ was featured in an lwn article earlier this week. looks like an interesting effort similar to what we're working on | 15:16 |
|---|---|---|
| fungi | also some similar philosophies and design goals | 15:17 |
| fungi | though they seem to be taking the approach of implementing everything from scratch rather than integrating available free software | 15:19 |
| fungi | i have a feeling much of that approach is driven by their desire to make browser-interfaced applications without javascript | 15:22 |
| Shrews | corvus: the sound on the walkthrough is not working for me. "Error" is displayed next to the play button. No more info than that | 15:23 |
| Shrews | that working for anyone else? | 15:23 |
| * Shrews tries a different 'puter | 15:23 | |
| corvus | Shrews: hrm, it's an ogg vorbis file... you can try downloading it directly at opendev.org/walkthrough.ogg and play it with a local player | 15:25 |
| Shrews | ok, works on my work laptop | 15:25 |
| frickler | fungi: interesting, but looks like the free-alpha trial of a soon-to-be-paid-for service by a single person according to https://man.sr.ht/billing-faq.md | 15:31 |
| fungi | frickler: oh neat, i missed that, as did the lwn article author i think | 15:33 |
| frickler | I do particularly like the "w/o js" part, that's the single most thing I don't like about gitea | 15:34 |
| fungi | anyway, 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 instructions | 15:35 |
| frickler | yeah, 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 pay | 15:37 |
| frickler | I was going to praise that the registration confirmation mail was pgp signed, sadly the signature is invalid ... :-/ | 15:42 |
| frickler | this may be interesting for folks who don't have a lwn subscription (like me ;) https://drewdevault.com/2018/11/15/sr.ht-general-availability.html | 15:46 |
| *** openstackgerrit has joined #opendev | 20:52 | |
| openstackgerrit | Merged openstack-infra/zuul-base-jobs master: Add ensure-output-dirs to base jobs https://review.openstack.org/628674 | 20:52 |
| openstackgerrit | Merged openstack-infra/zuul-base-jobs master: Add fetch-output to base jobs https://review.openstack.org/628975 | 20:52 |
| openstackgerrit | Merged openstack-infra/zuul-base-jobs master: Ignore errors on ssh key removal https://review.openstack.org/628976 | 20:52 |
| clarkb | it works | 20:58 |
| corvus | \o/ | 20:58 |
| corvus | clarkb: can i trick you into reviewing https://review.openstack.org/626387 and https://review.openstack.org/626626 ? | 20:59 |
| corvus | those should be ready to land, and we can build images | 21:00 |
| corvus | mordred: manilla just got a stable/rocky update, and the default branch is still master: http://38.108.68.64/openstack/manila | 21:01 |
| corvus | mordred: so i think we can say that the default branch problem only shows up on initial replication | 21:02 |
| corvus | mordred: have you restarted pods with the new image? | 21:03 |
| mordred | corvus: I am not sure | 21:03 |
| mordred | corvus: I have 2 issues I'm unsure about right now | 21:03 |
| mordred | corvus: 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 confusing | 21:04 |
| mordred | so I tried doing an edit - which worked and resulted in k8s redeploying the containers | 21:05 |
| mordred | so I'd like to get to the bottom of why the kubectl apply didn't do that | 21:05 |
| mordred | but also -I'm not sure it pulled new images | 21:05 |
| clarkb | corvus: ya I'll look at those in a moment | 21:06 |
| mordred | corvus: dockerhub also seems to think jeblair/gitea was last updated 21 days ago | 21:06 |
| mordred | corvus: so I'm thinking I did something wrong in all of thise | 21:06 |
| corvus | mordred: nope! i did not docker correctly! | 21:06 |
| mordred | corvus: however, woot on manilla | 21:06 |
| mordred | corvus: oh good | 21:07 |
| clarkb | mordred: 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 |
| mordred | clarkb: perhaps? | 21:08 |
| clarkb | like if it was originally created directly and not via an apply | 21:08 |
| clarkb | I think the intent is that it would preserve that through | 21:08 |
| corvus | mordred: 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 |
| mordred | corvus: works for me | 21:09 |
| mordred | clarkb: seems like a thing we might want to learn for our git-driven workflow | 21:09 |
| clarkb | mordred: ++ | 21:10 |
| corvus | replicaset.apps/gitea-769d46c966 3 3 1 29s | 21:12 |
| corvus | replicaset.apps/gitea-9c5cd6bb4 2 2 2 22h | 21:12 |
| corvus | replicaset.apps/gitea-ccc54cf54 0 0 0 4h | 21:12 |
| corvus | i think that's the deployment scaling down and up two replicasets | 21:13 |
| mordred | I think you're right | 21:13 |
| corvus | sorry omitted headers | 21:13 |
| corvus | NAME DESIRED CURRENT READY AGE | 21:13 |
| mordred | woot. that seems to have worked | 21:13 |
| corvus | now: | 21:13 |
| corvus | NAME DESIRED CURRENT READY AGE | 21:13 |
| corvus | replicaset.apps/gitea-769d46c966 4 4 3 1m | 21:13 |
| corvus | replicaset.apps/gitea-9c5cd6bb4 0 0 0 22h | 21:13 |
| corvus | replicaset.apps/gitea-ccc54cf54 0 0 0 4h | 21:13 |
| mordred | http://38.108.68.64/openstack-infra/zuul-base-jobs is nice and clean | 21:13 |
| corvus | so that was just the dummy env var trick | 21:13 |
| clarkb | why are there 3 of them with 2 having no desired instances? | 21:14 |
| corvus | i ran ansible with -v and saw that it used the patch http method | 21:14 |
| clarkb | are they the old sets that will be removed? | 21:14 |
| corvus | clarkb: i don't know what the 22h old one is | 21:14 |
| corvus | why don't i do it again and see what happens | 21:14 |
| mordred | corvus: there's a good deal of senseless vertical whitespace now | 21:15 |
| corvus | mordred: i think you removed too much | 21:15 |
| corvus | i don't see issues or code tab | 21:16 |
| mordred | oh - yeah - those tabs do seem to be missing | 21:16 |
| corvus | clarkb: now we're up to 4 | 21:17 |
| corvus | clarkb: so it doesn't seem to be deleting old replicasets | 21:17 |
| clarkb | corvus: huh I guess it keeps track of the historical list? | 21:17 |
| corvus | https://kubernetes.io/docs/concepts/workloads/controllers/deployment/#revision-history-limit | 21:17 |
| corvus | so yeah, assuming we did things "correctly" and used versioned configuration and images, then you can roll-back to previous replicasets | 21:18 |
| corvus | i don't think that's our style (gitops and all) so maybe we should zero that | 21:18 |
| corvus | or set to 1 in case we want to look at changes or something | 21:19 |
| clarkb | corvus: couple of questions on https://review.openstack.org/#/c/626387/11 the ones in the dockerfile may just be improvements before production | 21:23 |
| mordred | corvus: I do not understand why the tabs have gone | 21:27 |
| mordred | I did not actually delete the chunks that would produce it, nor change them | 21:27 |
| corvus | clarkb: replied | 21:29 |
| mordred | corvus: and I see the wrapping div | 21:29 |
| clarkb | corvus: similar types of questions on https://review.openstack.org/#/c/626626/4 I don't think any of this prevents us from merging the changes but we may want to clean things up as followups | 21:30 |
| mordred | {{if .Permission.CanRead $.UnitTypeCode}} | 21:30 |
| mordred | is the template language construct wrapping the code tab | 21:30 |
| mordred | but that didn't change | 21:30 |
| mordred | corvus: aha! | 21:31 |
| mordred | corvus: I pulled the template from the wrong version of gitea | 21:31 |
| mordred | corvus: we seem to now be running based on 1.6.0 | 21:32 |
| corvus | neat i guess we upgraded just now :) | 21:32 |
| mordred | oh - well - no, I think I pulled from too new | 21:32 |
| corvus | oh yeah, our dockerfile pins 160 | 21:33 |
| mordred | although there is a 1.6.3 out | 21:33 |
| corvus | clarkb: can you elaborate on "Clark Boylan: Since /data is shared we probably want to guard the mkdirs and chowns against them existing?" | 21:34 |
| openstackgerrit | Monty Taylor proposed openstack-infra/system-config master: Use the v1.6.0 template instead of master https://review.openstack.org/629936 | 21:35 |
| mordred | corvus: ^^ | 21:35 |
| clarkb | corvus: /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 |
| clarkb | corvus: was thinking we only want to mkdir and chown if those dirs do not yet exist (the first ever pod started) | 21:36 |
| clarkb | as is its probably fine, just extr awork we don't need to do | 21:36 |
| corvus | clarkb: ah... ok. the mkdirs are "-p" and should be safe, but i agree, the chowns are redundant | 21:36 |
| clarkb | (and mkdir -p is actually a noop if it exists but the chowns might not be) | 21:36 |
| clarkb | corvus: fwiw I think you can approve those as is, just wanted to point that stuff out while I was doing reviews | 21:39 |
| clarkb | and we can cleanup password and simplify chowns later | 21:39 |
| clarkb | but didn't approve in case you wanted to just fix it now | 21:39 |
| corvus | clarkb: cool; replied to 2nd set of comments | 21:39 |
| corvus | clarkb: i'll approve and roll forward | 21:40 |
| corvus | i'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 this | 21:41 |
| mordred | corvus: ++ that's exciting | 21:41 |
| mordred | corvus: incidentally, triggering a deploy when the image has changed and we're tracking :latest - is the same as the restart | 21:45 |
| mordred | corvus: update a meaningless env var | 21:45 |
| corvus | ack | 21:45 |
| mordred | the things I've found include people saying things about how you'd obviously NEVER want to deploy 'latest' in production | 21:47 |
| mordred | I guess those people don't have good gating systems | 21:47 |
| corvus | speaking 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 |
| corvus | we can probably run that in the same k8s cluster; we could probably just use sqlite and emptydir volumes to make it self-contained | 21:49 |
| mordred | corvus: yeah. | 21:49 |
| corvus | though 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 |
| clarkb | corvus: re gating the k8s deployment I think this is part of the struggle magnum and mnaser have | 21:51 |
| clarkb | we can deploy a devstack an dmagnum and then k8s | 21:52 |
| mnaser | hi | 21:52 |
| clarkb | but to run workload and hcekc that requires nested virt | 21:52 |
| corvus | clarkb: well, it's a little better for us, we can deploy a k8s (see nodepool func testing) | 21:52 |
| mnaser | So I think an interesting weekend project would be a magnum nodepool provider for example | 21:53 |
| mordred | corvus: fwiw - spamaps says he tags the image for every commit based on zuul.newrev | 21:53 |
| clarkb | corvus: ya, it just won't test all the openstack integration points I guess, but maybe we don't care about that | 21:53 |
| corvus | clarkb: oh that, yes. i'd be happy to assume those work for this purpose :) | 21:53 |
| mordred | corvus: and then sets explicit tags in the deployment yaml - which can of course be also templated by ansible | 21:53 |
| corvus | mnaser: ++ | 21:54 |
| mnaser | Right. 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 wrote | 21:54 |
| mnaser | And then runs the workloads on top of those | 21:54 |
| mnaser | That way you don’t have 2 different environments which are deployed differently, test and “prod” | 21:55 |
| corvus | mordred: 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 |
| clarkb | seems like staging would be the gate though? | 21:56 |
| corvus | clarkb: i don't anticipate us being able to write a gate test that would fail on this page missing the code/issues tabs: http://38.108.68.64/openstack-infra/zuul-base-jobs | 21:56 |
| clarkb | selenium could do it, but point taken | 21:57 |
| corvus | clarkb: 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 |
| mordred | corvus: ++ | 22:00 |
| openstackgerrit | Merged openstack-infra/system-config master: Add gitea dockerfile https://review.openstack.org/626387 | 22:07 |
| openstackgerrit | Merged openstack-infra/system-config master: Add jinja-init Dockerfile https://review.openstack.org/626626 | 22:12 |
| openstackgerrit | James E. Blair proposed openstack-infra/system-config master: Set APP_NAME for gitea https://review.openstack.org/629898 | 22:13 |
| openstackgerrit | James E. Blair proposed openstack-infra/system-config master: Set APP_NAME for gitea https://review.openstack.org/629898 | 22:16 |
| mordred | corvus: zuul did not seem to run the system-config-build-image-gitea in post | 22:17 |
| mordred | corvus: is that because if has a file matcher on it, so it didn't trigger in post? | 22:17 |
| corvus | mordred: yeah, i'm suddenly reminded of the recent report that file matchers don't work in post | 22:17 |
| mordred | corvus: yeah | 22:17 |
| mordred | corvus: this might be an example of that | 22:17 |
| corvus | this 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 |
| corvus | cause i really don't want to build all the docker images on every change to system-config | 22:19 |
| corvus | of course, what i really want to do is use promote | 22:20 |
| corvus | but that entails uploading something to logs.o.o | 22:20 |
| corvus | we could *really* abuse dockerhub and upload everything in gate with per-change tags and then have promote re-tag them... | 22:21 |
| corvus | how bad of an idea is that? :) | 22:21 |
| corvus | i 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 |
| mordred | corvus: I think it's a great idea - at least for the time being | 22:22 |
| mordred | and especially for this particular set of stuff | 22:22 |
| corvus | you know, maybe promote could clear out all gate uploads *older* than the one it's promoting | 22:22 |
| mordred | maybe it's even fine for zuul master - which is about as break-neck of a project as we're working from typically | 22:23 |
| corvus | (new ones may have shown up and are about to be promoted) | 22:23 |
| corvus | i actually think if we do that, it'll be a pretty reasonable use of the system | 22:23 |
| corvus | is there a "docker" command to list cremote images? | 22:27 |
| corvus | oh, maybe i just use the api | 22:27 |
| openstackgerrit | Monty Taylor proposed openstack-infra/system-config master: Update to gitea v1.6.3 https://review.openstack.org/629942 | 22:39 |
| openstackgerrit | Monty Taylor proposed openstack-infra/zuul-jobs master: Add role to move docs and artifacts to log root https://review.openstack.org/629571 | 22:48 |
| corvus | good news: i can totally find all the old change tags to delete | 23:24 |
| corvus | bad news: dockerhub doesn't support deleting tags | 23: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 |
| corvus | what 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 |
| corvus | so i think that's what i'll do. :) | 23:25 |
| mordred | I am in favor of this approach | 23:32 |
| corvus | if you send an incorrect request to the dockerhub api, it responds by sending an enormous base64 encoded image | 23:35 |
| corvus | not, as you might expect, a helpful error message | 23:36 |
| mordred | corvus: 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 |
| corvus | sorry, i meant "picture" | 23:39 |
| mordred | that doesnm't really make anything less ridiculous | 23:39 |
| mordred | why do they send a picture? | 23:39 |
| mordred | wait - is it a fail whale? | 23:39 |
| corvus | yeah | 23:40 |
| corvus | it's their 404 | 23:40 |
| mordred | WOW | 23:40 |
| openstackgerrit | Merged openstack-infra/project-config master: Added Vitrage specs https://review.openstack.org/627548 | 23:40 |
| openstackgerrit | Merged openstack-infra/project-config master: Consolidate Cinder repo ACL settings https://review.openstack.org/628407 | 23:42 |
| openstackgerrit | Merged openstack-infra/project-config master: Remove Cinder CI Verified label https://review.openstack.org/628408 | 23:43 |
| openstackgerrit | Merged openstack-infra/project-config master: Add Review Priority column to glance repos https://review.openstack.org/620904 | 23:45 |
| openstackgerrit | Merged openstack-infra/project-config master: Retire murano-deployment https://review.openstack.org/628850 | 23:58 |
| openstackgerrit | Merged openstack-infra/project-config master: Run openstackid docs jobs on bionic https://review.openstack.org/629896 | 23:58 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!