| ianw | ++ yeah i can see all that in the logs too | 00:00 |
|---|---|---|
| clarkb | ianw: maybe read through the quay log jus to make sure I didn't do anything obviously dumb :) | 00:01 |
| clarkb | but ya I think this should work | 00:03 |
| clarkb | oh also to be clear the token I created was just for creating repos perms | 00:03 |
| clarkb | I didn't end up needing any additional permissions in that token to get this working | 00:04 |
| fungi | so you can push images as a robot, but precreating the repo requires a token? | 00:04 |
| clarkb | fungi: correct. YOu can also `docker image push` as the robot to create the repo but when you do this its default visibility is private not public | 00:05 |
| clarkb | fungi: this means an alternative approach would be to use the robot to create a private image then use the token to update the visibility to public | 00:05 |
| fungi | interesting that a robot account is able to autocreate a repository but robot credentials can't precreate one | 00:05 |
| clarkb | their api is definitely a little odd. I assume the reason for this is the api has a completely different authentication implemtnation to the docker api part of it? | 00:06 |
| fungi | so we'll need two secrets per org i guess | 00:06 |
| clarkb | yes. | 00:06 |
| clarkb | well no | 00:06 |
| fungi | not including our own accounts | 00:06 |
| clarkb | a single secret with two encrypted attributes | 00:06 |
| fungi | oh, sure that would work | 00:06 |
| clarkb | the API token and then the regular docker robot auth | 00:07 |
| clarkb | also I can look at it with fresh eyes tomorrow and see if I can find a way to do everything with the robot as that is definitely the ideal | 00:07 |
| clarkb | however since repo creation only happens once its not the end ot the owrld to do it the way I describe above | 00:07 |
| clarkb | and now I need to figure out dinner | 00:09 |
| ianw | since we have no private repos on the plan, i wonder how the push works if it doens't make it public? | 00:11 |
| ianw | seems like something i could test :) | 00:11 |
| clarkb | ianw: ya I didn't get that far and just figured out how to make things public. Note you can also toggle them from private to public via the web ui | 00:12 |
| clarkb | but once you do that you cannot toggle it back to private since we don't have perms. I guess the testing would reveal if the image is accessible anyway? | 00:12 |
| ianw | i can see Repository Visibility , which says "you can't make this private" | 00:13 |
| ianw | but not sure i can see one for the image | 00:13 |
| clarkb | ianw: the repository is basically the image I think they are the same concept with the terms we've been using | 00:13 |
| clarkb | they distinguish because a tag in a repo is an image and that may be different than another tag against the same repo name | 00:14 |
| ianw | oh right, yeah it says "repository tags" | 00:14 |
| clarkb | at least that is why I think they do that | 00:14 |
| ianw | so yeah at least i can't see that the repo can be toggled to private, or at least back to private | 00:14 |
| clarkb | ianw: if you want it to start out as private you have to `docker login quay.io #give it your creds when prompted this is a generated password in your user account settings then docker image tag somesourceimage:sometag quay.io/userororg/imagename:sometag then docker image push quay.io/userororg/imagename:sometag | 00:15 |
| clarkb | if you create via the web ui it asks if you want private or public but it won't let you do private without upgrading your account (it chagnes the submit button to upgrade now) | 00:16 |
| ianw | https://access.redhat.com/documentation/en-us/red_hat_quay/3.3/html/use_red_hat_quay/use-quay-manage-repo#allow-robot-access-user-repo | 00:21 |
| ianw | that does say "Identify repositories and images that the robot can push images to or pull images from" | 00:22 |
| ianw | but not "create repositories" | 00:22 |
| ianw | which is i think what you were saying :) | 00:22 |
| Clark[m] | Well I think it has create perms too? But I'm on the phone now and can't check. We/I can test creating with docker image push as the robot tomorrow | 00:25 |
| ianw | well it certainly is true that the repo starts private, you switch it to public and then can't switch it back again | 00:46 |
| ianw | it is intentional -> https://groups.google.com/g/quay-sig/c/zsnYAxv7gtQ/m/8wfa3Pa_AAAJ | 00:55 |
| opendevreview | James E. Blair proposed opendev/zone-zuul-ci.org master: Add registry.zuul-ci.org https://review.opendev.org/c/opendev/zone-zuul-ci.org/+/877727 | 01:25 |
| opendevreview | James E. Blair proposed opendev/system-config master: Add SSL cert for registry.zuul-ci.org https://review.opendev.org/c/opendev/system-config/+/877728 | 01:41 |
| opendevreview | James E. Blair proposed opendev/system-config master: Add static site for registry.zuul-ci.org https://review.opendev.org/c/opendev/system-config/+/877729 | 01:41 |
| corvus | infra-root: 2 years ago, the last time we talked about moving to quay, i did some experiments that suggested that a 301 redirect for container images might be possible. we actually discussed doing registry.zuul-ci.org as a redirector to dockerhub/quay. given the uncertainty around the namespace, and the possibility that we might have to move again in the future, i would like to proceed with that experiment now. | 01:43 |
| corvus | i'd like to create registry.zuul-ci.org in dns, and point it to a static site with a .htaccess file and go ahead and test it redirecting to dockerhub now. if it works, then i'll propose we actually make that the canonical location for zuul images. we could consider doing the same for opendev as well. if it doesn't work, i'll clean it up. | 01:44 |
| corvus | infra-root: i'd like to proceed quickly with that, so if you can go ahead and review those changes, that'd be great. i can +w them and supervise. | 01:45 |
| ianw | corvus: it does feel like we could put the redirect directly in the config file and gate test with a pull ... i presume you're thinking the .htaccess so you can quickly fiddle it? | 01:48 |
| ianw | ok, so i've at least caught up to where everyone else is on the quay situation i think | 01:54 |
| ianw | the robot account can push new repositories/images via docker. confirmed that if it pushes a new repository, then it's private by default | 01:55 |
| ianw | however, the robot account can not access the quay API | 01:55 |
| fungi | i went ahead and approved the dns addition and the ssl cert creation | 01:57 |
| ianw | to access the quay API you need an oauth application. users can then create an oauth token in that application; and then API operations with that token are done by the application "on behalf" of the user that created the token | 01:58 |
| Clark[m] | Yup I linked a thing about that I think and that is why I named my application with my name | 01:59 |
| ianw | so instead of pre-creating the repo, we could also use https://quay.io/api/v1/repository/opendevorg/ianwrepo/changevisibility | 01:59 |
| ianw | to flip it. either way, if it's done by pre-creating a public repository, or flipping the bit on one already pushed, you need the oauth token | 01:59 |
| corvus | ianw: exactly -- and i agree, if it's simple, let's move it into config. if we end up needing a redirect for each repo, probably best to put it in an afs volume for easy project-level maintenance. | 02:00 |
| ianw | ok, i think i'd prefer to see it checked in either way, and ideally a pull or at least a listing or something via testinfra to confirm changes, but for POC sounds good | 02:03 |
| opendevreview | Merged opendev/zone-zuul-ci.org master: Add registry.zuul-ci.org https://review.opendev.org/c/opendev/zone-zuul-ci.org/+/877727 | 02:04 |
| corvus | ianw: absolutely. basically my test 2 years ago was "this looks like it might work based on local testing, but needs validation with a site with a real ssl cert". i promise if it works, the actual redirects will end up in a config managed repo, one way or another. :) | 02:05 |
| fungi | lgtm then. approve at your convenience | 02:07 |
| corvus | just in case you were wondering... chatgpt doesn't know if this will work. but it's pretty sure that we can just proxy image pulls pretty easily! ;) | 02:15 |
| ianw | coruvs: just be sure you blog clearly and explicitly about the results so that it can be fed back into the machine | 02:21 |
| * NeilHanlon has an idea for a (satirical?) blog post about writing for ChatGPT | 02:34 | |
| fungi | try not to taunt it about bingbot's lobotomy | 03:22 |
| fungi | probably a sensitive subject | 03:22 |
| opendevreview | James E. Blair proposed opendev/system-config master: Add static site for registry.zuul-ci.org https://review.opendev.org/c/opendev/system-config/+/877729 | 03:30 |
| corvus | mixed up my - and . | 03:30 |
| opendevreview | Merged opendev/system-config master: Add SSL cert for registry.zuul-ci.org https://review.opendev.org/c/opendev/system-config/+/877728 | 04:04 |
| opendevreview | Merged opendev/system-config master: Add static site for registry.zuul-ci.org https://review.opendev.org/c/opendev/system-config/+/877729 | 04:36 |
| opendevreview | Ian Wienand proposed opendev/system-config master: base: split ssh setup https://review.opendev.org/c/opendev/system-config/+/877735 | 05:11 |
| opendevreview | Ian Wienand proposed opendev/system-config master: base: split ssh setup https://review.opendev.org/c/opendev/system-config/+/877735 | 05:53 |
| *** jpena|off is now known as jpena | 08:24 | |
| dtantsur | someone asked me back at the time for an example of a patch where the gertty crash is reproduced. from today: https://review.opendev.org/c/openstack/ironic/+/877387/ | 10:57 |
| dtantsur | same on https://review.opendev.org/c/openstack/ironic/+/877384/, I wonder what is common between them, is it because they're from one chain? | 10:58 |
| fungi | dtantsur: i just loaded 877387 in gertty (tip of master) and it didn't crash on me. scrolled all the way to the end of the comments and the end of the diff. what actions trigger it for you? | 12:18 |
| fungi | same for 877384 | 12:19 |
| dtantsur | scroll down key | 12:19 |
| fungi | down arrow or pgdn? if it's the latter, i think i narrowed that down to some sort of regression in a newer release of urwid | 12:20 |
| dtantsur | pagedown, yeah | 12:20 |
| fungi | lots of changes crash gertty if i use the pgdn key, something about an element not accepting keypresses | 12:20 |
| fungi | though i'm not getting it to trigger on those changes at the moment | 12:22 |
| fungi | it may be a combination of particular changes at specific terminal geometries. i use gertty in an 80x24 terminal (80x25 minus the tmux status bar) | 12:23 |
| fungi | dtantsur: what gertty version are you using? a release or from git? | 12:26 |
| fungi | i'm also using urwid 2.1.2 with it, under python 3.11.2 currently | 12:28 |
| fungi | trying to see if the behavior has recently gone away for me and maybe i didn't notice | 12:28 |
| fungi | yeah, at the moment no luck, software never crashes when i want it to :/ | 12:31 |
| dtantsur | gertty==1.6.1.dev50, urwid==2.1.2 | 12:38 |
| dtantsur | also 3.11.2 | 12:39 |
| opendevreview | Merged zuul/zuul-jobs master: Remove ignored success-url job attribute https://review.opendev.org/c/zuul/zuul-jobs/+/877700 | 12:39 |
| Stephen_OSA | good morning | 15:21 |
| Stephen_OSA | I have a question about heat container agent, where might the best place to ask that question be? | 15:21 |
| clarkb | Stephen_OSA: this channel is mostly dedicated to the developer tools used to build software like heat. We don't actually know a ton about heat itself as result. Your best bet is probably in #openstack ? | 15:24 |
| clarkb | or in #heat I guess | 15:24 |
| clarkb | (I was expecting it to be #openstack-heat and couldn't find it for a minute) | 15:24 |
| dpawlik | clarkb, fungi: o/ I would like to upgrade the Opensearch cluster in 2 weeks ( 03.04.2023 at 12:00 PM UTC). Are you ok with it? Soon I will send an email | 15:31 |
| dpawlik | normally I see in the AWS console, that the "upgrade" option is available, but I don't know if after clicking it would be working | 15:32 |
| dpawlik | so just small question if you are available at this time, if I don't have permission, you will just click :) | 15:32 |
| clarkb | dpawlik: The openstack release is next week and then the ptg the week after that. I would expect that doing it after those events is a good time. But don't really have a personal opinion beyond that | 15:32 |
| clarkb | dpawlik: to be super clear we were pretty explicit about not being involved in operations like this | 15:33 |
| clarkb | I don't even know how to login | 15:33 |
| dpawlik | I understand | 15:33 |
| dpawlik | oh xD | 15:33 |
| dpawlik | I was thinking that you were logged in into the AWS console | 15:34 |
| dpawlik | allright. So in that case, I will send an email about upgrade | 15:34 |
| clarkb | I think maybe fungi got an account setup? BUt I'm pretty sure I don't have one. | 15:34 |
| dpawlik | if I will not have permission to trigger that, I will just postpone it to later | 15:34 |
| clarkb | dpawlik: is that not something you can check right now? | 15:35 |
| clarkb | Itseems weird to me that this is unknowable | 15:35 |
| dpawlik | not really... So I don't use the AWS API to call the upgrade, I'm doing it via web site and it seems that I got that option "update now" where it shows me when it should be done | 15:36 |
| dpawlik | but when I was starting maintaining the Opensearch, the console look ok, but later I saw that I don't have permissions to check this, this this | 15:37 |
| dpawlik | moreover, there is an info "A new service software release R20221114-P2 is available. The release will be automatically deployed after April 04, 2023, 07:04 (UTC+02:00). Learn more" | 15:37 |
| clarkb | dpawlik: oh you are worried that it will fail after the initiate the process? | 15:38 |
| dpawlik | I never have done it before in AWS | 15:39 |
| clarkb | infra-root: This is fun if you request https://quay.io/opendevorg/doesnotexist/ with a brswer you get a 404. If you do it with curl you get a 403 | 15:39 |
| dpawlik | like...99% of people on that channel :) | 15:39 |
| dpawlik | but I don't expect that it will break anything | 15:40 |
| clarkb | infra-root the next thing I need to test is whether or not calling the repo create on an existing repo is an error. If so I need to do something like ^ to query if the repo exists before creating it | 15:40 |
| clarkb | oh I'm logged in in the browser so it shows me the 404 but I guess if you aren't logged in with perms to kow if the repo exists or not its an unauthorized error? | 15:40 |
| dpawlik | set the repository as "public" not private | 15:43 |
| clarkb | dpawlik: it is | 15:46 |
| clarkb | well I should say the repo we have created it | 15:46 |
| clarkb | but we need to check for uncreated repos which have no visibility status | 15:46 |
| clarkb | basically it seems quay won't let you know if a repo exists or not unless authenticated with sufficient permissions to list all possible repos? Otherwise its an authentication error | 15:47 |
| clarkb | we can probably assume for our purposes that a non 200 return means that the image does not exist, but that is because we will make all of our images public | 15:48 |
| clarkb | looks like attemtping to create a repo that already exists is a 400 errorwith a message indicating the repo already exists. I think we can just try to create things and continue if they are already there. THat seems more reliable than assuming a 403 is a 404 by proxy | 15:49 |
| dpawlik | I have done a tool for maintaining our quay service - https://softwarefactory-project.io/r/plugins/gitiles/software-factory/python-quay-tool . That functionality that you are looking for, probably is missing (I have done it some time ago) | 15:50 |
| clarkb | dpawlik: what I'm doing will end up as a small zuul-jobs ansible role using the uri module. Basically an add on when talking to quay for docker management jobs to precreate the repository (so that we can mark it public) | 15:51 |
| clarkb | after this testing I think it will end up being a single uri task with a couple of followup tasks to error check | 15:51 |
| clarkb | essentially mimicing what you get via docker image push to docker hub | 15:52 |
| dpawlik | ah. Now I got more context | 15:53 |
| NeilHanlon | fwiw clarkb, fungi, others: Rocky was accepted into DSOS this morning | 15:53 |
| dpawlik | the Quay API is pretty cool. Also it works well with swagger | 15:54 |
| * dpawlik need to go in few min | 15:54 | |
| clarkb | dpawlik: I don't like the authentication system. In particular its annoying you need to delete an application to invalidate tokens. At least via the web UI? I also don't like that I can't make a token act on behalf of a robot account | 15:55 |
| NeilHanlon | dpawlik: w.r.t. opensearch upgrades: they have been stable in my experience | 15:55 |
| fungi | clarkb: dpawlik: yeah, i think i logged into the aws console once or twice when things were being set up, but i didn't have administrative control over the environment i don't think. at least not when i was trying to work out the ssl cert renewal situation anyway | 15:56 |
| clarkb | dpawlik: as far as the goal here, I'm mostly just trying to update the existing zuul-jobs support for image creation and pushes for quay and an expectation that repos should be public by default. I wasn't sure what the best way to check if a repo should be created is since we want to precreate via the API before doing the image push (because image push defaults to private) | 15:58 |
| clarkb | also looking at token scopes I think create repo is more limted than the scope necessary to modify repos so a slighty preference for precreating than updating after the fact | 15:59 |
| clarkb | modify perms would allo modification of all repo attributes looks like. But create only allows you to make a new thing once | 16:00 |
| dpawlik | NeilHanlon, fungi: thanks for info | 16:01 |
| dpawlik | clarkb: let me know when you have a PS, I'm interested to check it | 16:02 |
| fungi | it's possible i have opensearch admin perms but not ssl cert admin perms, i suppose | 16:02 |
| dpawlik | fungi: I was reading some time ago about the permissions and policy in AWS that can be applied for user... It's insane how many options they have :D | 16:04 |
| * dpawlik need to go. Enjoy your weekend! | 16:05 | |
| clarkb | you too | 16:05 |
| fungi | thanks! | 16:10 |
| opendevreview | Michael Johnson proposed opendev/meetbot master: Fix white space blocking #startmeeting https://review.opendev.org/c/opendev/meetbot/+/877821 | 16:16 |
| johnsom | A small fix so we don't bug you thinking meetbot is hung. lol | 16:18 |
| fungi | johnsom: oh, right! i remember talking about that | 16:26 |
| johnsom | Yeah, a silly cut/paste error that tricked Greg and I | 16:26 |
| fungi | tricksy, tricksy botses | 16:27 |
| johnsom | Ah, Greg pointed out a bug in my patch, fixing | 16:29 |
| opendevreview | Michael Johnson proposed opendev/meetbot master: Fix white space blocking #startmeeting https://review.opendev.org/c/opendev/meetbot/+/877821 | 16:31 |
| NeilHanlon | random question: any tips/tricks for running your own meetbot? thinking of setting one up for Rocky's various projects | 16:34 |
| clarkb | NeilHanlon: not really. I think we set that up forever ago (I remember addinga feature to it and it existed efore I started owrking on things) and the only thing we've really done to it since is switch to limnoria from supybot | 16:34 |
| NeilHanlon | i see -- any idea why the switch from limnoria? | 16:35 |
| NeilHanlon | in general, besides them being tricksey as fungi mentions... bots are fairly straightforward | 16:35 |
| johnsom | supybot is not maintained anymore | 16:36 |
| clarkb | right supybot was unmaintained and forked off to limnoria and we switched in order to python3 and modernize the deployment | 16:36 |
| NeilHanlon | oh. i misread | 16:41 |
| NeilHanlon | FROM supybot | 16:41 |
| NeilHanlon | yes that makes sense lol | 16:42 |
| clarkb | NeilHanlon: https://opendev.org/opendev/system-config/src/branch/master/docker/ircbot this is where we build our docker image for limnoria. There is some zuul magic there using "sibling" repositories to include meetbot in the install. The local build script hints at what zuul si doing and allows you to replicate it locally | 17:06 |
| clarkb | NeilHanlon: then https://opendev.org/opendev/system-config/src/branch/master/playbooks/roles/limnoria is ansible that deploys the container | 17:07 |
| fungi | NeilHanlon: probably the best advice i have is make sure you give your users an easy-to-find "cheat sheet" with the commands/syntax supported by your bot. especially handy if meetings are an infrequent thing, and people only occasionally need a particular feature of the bot (e.g. to hold a vote or flag specific agreement or action items in the minutes). having to stop and hunt for documentation | 17:10 |
| fungi | can slow down meetings substantially, wasting the time of possibly many attendees | 17:10 |
| fungi | but meetbot is quite useful. i'm on the board of directors for spi and we hold our monthly board meetings in irc using a meetbot (not the same fork as opendev's but shares a common ancestry) | 17:11 |
| *** jpena is now known as jpena|off | 17:24 | |
| NeilHanlon | thank you, appreciate all that. we have other hurdles with people prefering video to chat in some cases.. but, slowly I'll convince them otherwise | 17:25 |
| NeilHanlon | i'll chat with people all day on IRC... i only have so much capacity for voice/video calls | 17:25 |
| fungi | same here | 17:40 |
| fungi | rax-ord utilization doesn't look worse over the past 24 hours, after going back to full capacity. it's not great but seems much better than before the various tuning efforts. still seems like the building line spikes up a lot higher than what i would expect with the the current max-concurrency=5 setting (unless we've got lots of requests for huge nodesets all hitting at once) | 18:48 |
| clarkb | fungi: I wonder if we can query for builds with large nodesets somehow | 18:49 |
| clarkb | maybe through the historical nodepool request logs? | 18:49 |
| clarkb | I think knowing that a bunch of builds are running with 10 nodes is generally useful info too | 18:50 |
| fungi | at the 02:08z sample (just after periodics kicked off), it clocked 178 building nodes | 18:50 |
| fungi | that would imply we averaged 36 nodes per request at that point in time | 18:50 |
| fungi | which i'm pretty sure we have no jobs actually doing | 18:50 |
| fungi | so odds are there's more to that graph than just nodes that are building for a node request that's still in process | 18:51 |
| fungi | but the error node launch attempts graph looks a lot better than a week ago | 18:53 |
| opendevreview | Clark Boylan proposed zuul/zuul-jobs master: Add ensure-quay-repo role https://review.opendev.org/c/zuul/zuul-jobs/+/877834 | 19:34 |
| clarkb | infra-root dpawlik ^ thats where I've ended up with the make quay create repos via api using ansible. I've run that locally using include_tasks and a lot of -e on the command line and I think it is working | 19:35 |
| fungi | needs moar -e | 19:36 |
| clarkb | I'm a bit on the fence for whther or not we should default to public there but I figure since making a private repo is trivial you'd really only use this role if making a public repo so it makes a good default | 19:37 |
| fungi | makes sense to me | 19:39 |
| fungi | did bridge.openstack.org get decommissioned? i can't recall. also did the contents of the root homedir get copied from it to the new bridge? that's where we kept the keychain with the private artifact signing master keys... i'm not finding any of that on the new bridge | 19:54 |
| fungi | specifically the /root/signing.gnupg directory documented in https://docs.opendev.org/opendev/system-config/latest/signing.html | 19:54 |
| Clark[m] | It was shutdown but unsure of deletion | 19:55 |
| fungi | yeah, i'm checking that now | 19:55 |
| fungi | looks like it exists, it's just powered off | 19:56 |
| fungi | infra-root: any objection to me booting the old bridge.openstack.org up briefly so i can copy files we seem to have overlooked from the root homedir on it? | 19:56 |
| fungi | i'm running behind generating the next signing key, and will definitely need to regain access to the previous one so i can sign the new one with it | 19:57 |
| fungi | if booting that server is dangerous, i can work on restoring files from its backup | 19:58 |
| Clark[m] | I don't have an objection. Maybe just be on the lookout for any cronjobs it may run (though I disabled the zuul upgrade one and it won't run for another 4 hours anyway) not sure of others that may trigger if enabled | 19:58 |
| Clark[m] | I think 90% of the danger is just in potentially allowing cron jobs to run since zuul shouldn't talk to it anymore. I guess you can double check zuul has forgotten about the old host too l | 19:58 |
| fungi | okay, i'll have it up just long enough for the new bridge to slurp over a copy of the old ~root, but i'll check crontab and running processes first thing | 20:05 |
| fungi | rax-dns-backup was still configured in the root crontab so i commented it out | 20:07 |
| fungi | okay, i've shut it back down again | 20:20 |
| fungi | managed to use sudo with pipes at both ends of the transfer so that the tarfile i created was never written to disk by a non-root user, even though i authenticated the transfer with my non-root account (fungi@bridge01.opendev.org connecting to fungi@bridge.openstack.org to retrieve it) | 20:22 |
| fungi | basically ssh remote sudo cat file | sudo tee file | 20:23 |
| fungi | gotta love how ssh client avoids mangling binary data streams | 20:24 |
| fungi | anyway, ~root/signing.gnupg is on the new bridge now | 20:25 |
| fungi | and there's a ~root/old-bridge-root-homedir.tar on it if anyone needs anything else out of there in the near term | 20:25 |
| clarkb | thanks | 20:41 |
| opendevreview | Clark Boylan proposed zuul/zuul-jobs master: Add ensure-quay-repo role https://review.opendev.org/c/zuul/zuul-jobs/+/877834 | 20:44 |
| fungi | well, it's become ~root/old-bridge-root-homedir.tar.xz now, to save a bit of space (shrank from 7gib to 2gib) | 21:45 |
| ianw | oh lucky that's still there | 21:59 |
| ianw | i feel like i copied that sorry, but glad we found it | 21:59 |
| ianw | it is a good case for us having a distributed backup, however :) | 22:02 |
| fungi | yep! | 22:08 |
| fungi | my fault for not thinking to check that we had copied it over to begin with, really | 22:09 |
| clarkb | ianw: re flipping the bit after you push I thought about that too but eventually decided doing a create first is better becuase the token scope for that is much smaller | 22:15 |
| clarkb | but agreed both would work | 22:15 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!