| clarkb | I've now spent a lot of time drafting docs and remember that I haven't sent an infra meeting agenda yet. I think I'll just have to send that first thing tomorrow | 01:07 |
|---|---|---|
| clarkb | The first draft of the zuul document is up though | 01:10 |
| *** tobias-urdin-pto is now known as tobias-urdin | 11:15 | |
| *** elodilles is now known as elodilles_pto | 11:21 | |
| n0ob | is some one here having experience with developing the sushy emulator? | 14:06 |
| fungi | n0ob: you should ask in the #openstack-ironic channel | 14:14 |
| fungi | pretty sure that's the team who maintains sushy | 14:15 |
| n0ob | thx fungi! | 14:15 |
| fungi | yep, confirmed: https://governance.openstack.org/tc/reference/projects/ironic.html | 14:15 |
| frickler | fungi: seems gmail is now rejecting mail via lists.o.o due to missing dkim/spf | 14:17 |
| frickler | 550-5.7.26 Gmail requires all senders to authenticate with either SPF or DKIM. | 14:17 |
| fungi | i'm going to try not to say something harsh about how people should have already ditched gmail and all of google's other services too, but i suppose adding an spf ~all record for our lists domains only makes me vomit into my mouth a little bit | 14:19 |
| fungi | frickler: want to add that to the meeting agenda? clarkb hasn't sent it out yet anyway | 14:21 |
| frickler | I'm still in other meetings, just checked this when it was mentioned in the neutron meeting | 14:22 |
| fungi | i'll put it on the wiki | 14:23 |
| fungi | actually, i wonder if they'd accept a policy that contained +all (http://www.open-spf.org/SPF_Record_Syntax/ includes that in an example described as "The domain owner thinks that SPF is useless and/or doesn't care.") | 14:29 |
| fungi | but if we actually want it to be an accurate policy, we can i think do "v=spf1 a -all" or "v=spf1 a ~all" or maybe "v=spf1 a ?all" if we're really worried about it | 14:30 |
| frickler | if you check exim logs they also respond with a link to look at, but it might contain PII so not sharing here | 14:31 |
| fungi | in theory, only our listserv should mail-from those domains anyway | 14:31 |
| fungi | frickler: the good news is that they seem to currently only be rate-limiting our deliveries and deferring | 14:34 |
| opendevreview | Jeremy Stanley proposed opendev/zone-opendev.org master: Add an SPF record for the listserv https://review.opendev.org/c/opendev/zone-opendev.org/+/902689 | 14:48 |
| opendevreview | Jeremy Stanley proposed opendev/zone-zuul-ci.org master: Add an SPF record for the listserv https://review.opendev.org/c/opendev/zone-zuul-ci.org/+/902690 | 14:48 |
| fungi | for discussion ^ | 14:48 |
| fungi | similar additions for the other domains will have to be made manually in rackspace and cloudflare depending on the domain | 14:49 |
| clarkb | I'll have to refresh on spf rules | 14:58 |
| clarkb | and ya I'm hoping to get the agenda out as soon as the board meeting concludes | 14:58 |
| * SvenKieske has flashbacks about being a mail admin | 15:01 | |
| clarkb | so basically a means match the A/AAAA records for lists.zuul-ci.org in this case as valid senders and ?all means neutral stance on any other sender? | 15:03 |
| fungi | correct | 15:03 |
| fungi | we could make it tighter with ~all or even -all if we wanted to tell receiving mtas to reject messages outright when they come from another server | 15:04 |
| clarkb | I think ?all is fine to start | 15:04 |
| clarkb | easier to get more restrictive as we go than to start that way | 15:04 |
| clarkb | fungi: I did leave one suggestion about using shorter TTLs in case we need to iterate on the rules. FWIW I don't think this change should negatively impact our mailing lists so we should probably go ahead with it? | 15:05 |
| clarkb | if we were doing -all then I'd be more cautious but ?all should be pretty safe and if it makes other mail servers happier... | 15:05 |
| fungi | yes, i can set a shorter ttl on these for now | 15:06 |
| opendevreview | Jeremy Stanley proposed opendev/zone-opendev.org master: Add an SPF record for the listserv https://review.opendev.org/c/opendev/zone-opendev.org/+/902689 | 15:09 |
| opendevreview | Jeremy Stanley proposed opendev/zone-zuul-ci.org master: Add an SPF record for the listserv https://review.opendev.org/c/opendev/zone-zuul-ci.org/+/902690 | 15:09 |
| clarkb | I made some small edits to the meeting agenda. I'll send that out around 1600 or whenever the board meeting kicks out the public membership | 15:21 |
| *** dmellado206 is now known as dmellado | 15:54 | |
| clarkb | fungi: frickler: any comments on https://review.opendev.org/c/opendev/system-config/+/902436 ? This will affect all ansible runs on bridge (by default at least since it updates the ansible config) | 16:02 |
| clarkb | also if you have time https://review.opendev.org/c/opendev/system-config/+/901469 and its parent should be safe to land at this point. Just adds Gerrit 3.9 image builds and tests but we don't push that into production | 16:03 |
| frickler | oh, that could have been the cause for the sporadic LE failures, too? I remember wondering where the -13 came about | 16:05 |
| jrosser | i have had to patch the same thing a long time ago here https://review.opendev.org/c/openstack/openstack-ansible/+/851426 | 16:07 |
| jrosser | i made a reproducer in the linked bug report | 16:07 |
| frickler | ha, I was just thinking why we shouldn't directly go to 300 instead of 120 ;) | 16:08 |
| clarkb | frickler: yup it was tonyb's investigation of that that led us to the ansible issue | 16:08 |
| clarkb | frickler: I think the main reason to not go to 300 is simply to avoid "leaking" a bunch of ssh processes if we can get away with less | 16:08 |
| clarkb | Its actually a bit surprising to me that this isn't a drop the world and fix it type of bug for ansible | 16:09 |
| clarkb | its been happening for a while now and seems to affect many users and is fatal due to default configuration with no other interaction from the user | 16:09 |
| frickler | my idea is that 120 is still a possible runtime for an LE run, 300 would be much less likely I think | 16:10 |
| clarkb | frickler: its specific to the time between two tasks. 120 and 300 seconds are both possible dependingon the playbook | 16:10 |
| clarkb | its just that as the time increases we believe statistically there are fewer incidences of that time delta | 16:10 |
| clarkb | so ya fewer 300s than 120s | 16:10 |
| clarkb | but every single ansible run will have an ssh process hanging around for 5 times as long at 300 seconds | 16:11 |
| clarkb | and then that is multiplied by the numebr of hosts | 16:11 |
| frickler | but only while the playbook is running, not afterwards? | 16:11 |
| clarkb | I want to say I've seen them live beyond the playbook process' life. But now that you ask I'm not 100% sure of that | 16:13 |
| frickler | then let's say we use 180 as a compromise? | 16:14 |
| clarkb | sure I can update to 180s | 16:15 |
| opendevreview | Clark Boylan proposed opendev/system-config master: Increase bridge's ansible ssh controlpersist timeout to 180s https://review.opendev.org/c/opendev/system-config/+/902436 | 16:17 |
| clarkb | I've got an hvac person doing annual cleaning/inspection/maintenance type stuff in about half an hour. Shouldn't interfere with the meeting | 16:59 |
| clarkb | tonyb: I think your mirror CNAME update changes are in merge conflict due to the serial updating for other changes. Do you think we are ready to proceed with those. Mostly thinking A) we should keep making progress on that (sorry I've been distracted the last few days with gerrit/gitea stuff) and B) we'll need to coordinate those updates with any spf record updates we do | 17:00 |
| clarkb | tonyb: for validation things are working prior to updating the CNAME records I generally just browse the afs filesystem tree via the webbrowser hitting the main host dns record and if that shows records we know afs is working | 17:01 |
| tonyb | Okay, I'll rebase them on top of the SPF updates | 17:01 |
| tonyb | Okay I'll do that. I had done similar via the officsal hostname but I can also do it via the new CNAME | 17:02 |
| tonyb | clarkb: you have absolutly nothing to appologise for. | 17:02 |
| fungi | i wouldn't worry too much about rebasing other dns changes onto the spf change. whichever doesn't merge first can just be revised for a new serial as needed | 17:04 |
| fungi | i set the changes for spf addition to wip until we have a chance to discuss them in the meeting, but that's still a couple of hours out | 17:04 |
| clarkb | we need a merge hook that updates the serial automatically for us | 17:09 |
| clarkb | that seems like more pain that it is owrth though as you won't get matching commit shas | 17:09 |
| tonyb | clarkb, fungi: https://review.opendev.org/c/opendev/zone-opendev.org/+/902100 looks good to me. I think the "merge conflict" was related to it being set WIP? As it sems fine to me after I removed WIP | 17:19 |
| clarkb | oh yes gerrit treats wip changes as merge conflicts | 17:20 |
| clarkb | because merge conflict really means "not mergeable" | 17:20 |
| tonyb | Okay that matches my guess based on observed behaviour | 17:21 |
| clarkb | +2 from me. i also verified I can browse the afs hosted stuff | 17:23 |
| clarkb | I think we can land that whenever we get a second reviewer to double check it | 17:23 |
| tonyb | Thanks | 17:23 |
| clarkb | 2fa will be permanently required on github accounts starting January 11, 2024 | 17:31 |
| clarkb | not an issue for my personal account, but I do wonder if that will impact the accoutns used by projects to replicate to github (I'm guessing they may not have 2fa setup already) | 17:31 |
| clarkb | also maybe the zuul account? Something to watch I guess | 17:32 |
| fungi | clarkb: tonyb: i approved 902100 just now | 17:41 |
| tonyb | Thanks | 17:42 |
| tonyb | clarkb: I'd say the github 2fa change will impact those accounts: https://docs.github.com/en/organizations/keeping-your-organization-secure/managing-two-factor-authentication-for-your-organization/managing-bots-and-service-accounts-with-two-factor-authentication | 17:44 |
| opendevreview | Merged opendev/zone-opendev.org master: Switch CNAME records to new mirrors https://review.opendev.org/c/opendev/zone-opendev.org/+/902100 | 17:49 |
| clarkb | tonyb: but it isn't clear if the account will stop working until that is done or if we just need ot update it on next login | 17:49 |
| tonyb | Ah okay | 17:50 |
| fungi | also we did, long ago, set up 2fa for our shared github admin account | 17:51 |
| fungi | no idea if that was done for any of the replication accounts | 17:51 |
| clarkb | ya and I think I would recommend a similar setup for any bot account needing similar. Basically use a software totp generator | 17:52 |
| fungi | "we" (opendev sysadmins) don't control most/any of those so i don't think we even have a way to find out | 17:52 |
| fungi | the approach we've taken is that we don't want to be responsible or know about github, the individual org owners create replication accounts and corresponding zuul secrets for their credentials | 17:53 |
| fungi | so it will be up to them to make any necessary updates | 17:53 |
| clarkb | ya for opendev I think there are two things we care about. The old admin account which is largely unused now and already using 2fa. And whatever the zuul token is generated with | 17:54 |
| clarkb | those might be the same underlying account with scoped permissions or something | 17:54 |
| opendevreview | Jeremy Stanley proposed opendev/zone-opendev.org master: Add an SPF record for the listserv https://review.opendev.org/c/opendev/zone-opendev.org/+/902689 | 18:10 |
| tonyb | In looking at cleaning up the 4 older mirror nodes I cam across: https://opendev.org/opendev/system-config/src/branch/master/hiera/common.yaml#L45-L49 ... Should I update these to use the un-numbered mirror names ? | 18:10 |
| fungi | rebased ^ fpr the serial update | 18:10 |
| clarkb | tonyb: for simplicity of maintenance I think we should consider that. One reason to make it extra specific is if we need to measure performance between servers. I don't think that is likely for mirror nodes and we can always add an explicit host to achieve that | 18:11 |
| tonyb | Will do | 18:18 |
| opendevreview | Tony Breeds proposed opendev/system-config master: Add a helper script for doing the LVM setup on mirror nodes. https://review.opendev.org/c/opendev/system-config/+/901504 | 18:35 |
| opendevreview | Tony Breeds proposed opendev/system-config master: Update cacti_hosts to more generic names. https://review.opendev.org/c/opendev/system-config/+/902714 | 18:35 |
| opendevreview | Tony Breeds proposed opendev/system-config master: Remove Ansible configuration and inventory entries for old mirror servers https://review.opendev.org/c/opendev/system-config/+/902715 | 18:35 |
| opendevreview | Tony Breeds proposed opendev/zone-opendev.org master: Remove old mirror nodes from DNS https://review.opendev.org/c/opendev/zone-opendev.org/+/902716 | 18:38 |
| fungi | clarkb: did you happen to see https://review.opendev.org/899219 ? | 18:43 |
| clarkb | I did not | 18:44 |
| clarkb | I don't really rely on the reviewer list stuff much beacuse people add me to random changes | 18:44 |
| fungi | yeah, that's why i brought it up. it's been waiting a while, seems reasonably straightforward. it's not a small change but it comes with tests and should have basically no runtime impact except on a platform that isn't supported without that change | 18:45 |
| clarkb | I can try to review it but it probably won't be until late today at the earliest | 18:46 |
| fungi | i'm trusting the ironic developers understand tinycore's expectations | 18:46 |
| clarkb | I still need to do some edits to annual report things and have a zuul change or two to review | 18:46 |
| fungi | but didn't want to single-core approve it | 18:46 |
| clarkb | and am hoping we can merge the ansible controlpersist change update | 18:46 |
| tonyb | I think the latter is ready. | 18:47 |
| fungi | yep, i think we should go ahead and approve the controlpersist change. three reviewers gave +2, and the one who weighed in asking for an adjustment is presumably satisfied with it too now that's changed | 18:47 |
| tonyb | I didn't +W it as I wanted to double check it was safe during "peak hours". | 18:48 |
| fungi | i'm going to go ahead and approve 902481 so that we can take the gerrit server back out of the emergency disable list before we forget | 18:49 |
| tonyb | fungi: sounds good to me | 18:50 |
| clarkb | ++ | 18:51 |
| clarkb | and ya i think the controlpersist change is fine to merge whenever. If it breaks we manually update the ansible config and revert it | 18:52 |
| clarkb | I'm definitely trying to clean up my own backlog before year end so want to help others do that too and will do my best to get to that glean chnage | 18:52 |
| clarkb | https://zuul.opendev.org/t/openstack/build/c7060e07d77148eab826f3feba913c5d I think this change should more or less self test the ansible config update? But I'm not 100% certain of that | 18:53 |
| clarkb | https://zuul.opendev.org/t/openstack/build/c7060e07d77148eab826f3feba913c5d/log/bridge99.opendev.org/etc/ansible/ansible.cfg#31 the config update does show up there and the job runs the base playbook so I think that is a good indication we should be fine | 18:53 |
| clarkb | fungi: maybe lets +W the controlpersist change after you are satisfied with the gerrit update (so that we don't break before we clean u pgerrit) | 18:54 |
| fungi | fair enough | 18:54 |
| opendevreview | Merged openstack/project-config master: Address TODO in acl normalization script https://review.opendev.org/c/openstack/project-config/+/902314 | 19:26 |
| clarkb | I need to pop out and make lunch but when I get back I'm going to do my best to review all those changes I said I would review :) | 19:57 |
| * tonyb needs to go AFK for a bit (about an hour) | 20:00 | |
| opendevreview | Merged opendev/zone-zuul-ci.org master: Add an SPF record for the listserv https://review.opendev.org/c/opendev/zone-zuul-ci.org/+/902690 | 20:03 |
| opendevreview | Merged opendev/zone-opendev.org master: Add an SPF record for the listserv https://review.opendev.org/c/opendev/zone-opendev.org/+/902689 | 20:07 |
| opendevreview | Merged opendev/system-config master: Revert "Switch Gerrit replication to a larger RSA key" https://review.opendev.org/c/opendev/system-config/+/902481 | 20:09 |
| opendevreview | Merged opendev/system-config master: Make bookworm the python Dockerfile parent default image https://review.opendev.org/c/opendev/system-config/+/898755 | 20:09 |
| opendevreview | Merged opendev/system-config master: Add python3.12 bookworm base images https://review.opendev.org/c/opendev/system-config/+/898756 | 20:09 |
| fungi | dns update deploys are queued up waiting for the hourly prod jobs to finish | 20:18 |
| fungi | i've also done the other ones that needed manual processing | 20:19 |
| fungi | getting the expected records back from queries for all of lists.airshipit.org, lists.katacontainers.io, lists.opendev.org, lists.openinfra.dev, lists.openstack.org, lists.starlingx.io, lists.zuul-ci.org | 20:37 |
| fungi | #status log Added (neutral) SPF records for all Mailman sites in order to comply with delivery requirements for some mass mail providers | 20:37 |
| opendevstatus | fungi: finished logging | 20:37 |
| fungi | infra-root: i've removed review02.opendev.org from the emergency disable list now that 902481 has merged | 20:38 |
| fungi | deployment for 898755 (Make bookworm the python Dockerfile parent default image) is failing some bookworm python 3.12 promote image builds | 20:40 |
| Clark[m] | Usually that is due to a race in cleaning up old tags | 20:41 |
| fungi | "promote-docker-image: Get manifest" failed. "the output has been hidden due to the fact that 'no_log: true' was specified for this result" | 20:41 |
| Clark[m] | Oh get manifest wouldn't be that though | 20:41 |
| fungi | https://zuul.opendev.org/t/openstack/build/978f60cbba3048f3bbfa6fc95789c560 | 20:41 |
| Clark[m] | The child change should promote and effectively replace things though so if the child is fine I think we are good | 20:41 |
| fungi | i'll keep an eye on it, should start running momentarily | 20:42 |
| fungi | yeah, the precise builds which failed when run for the parent are what were rerun for the child and are succeeding | 20:43 |
| fungi | probably because the child merged before the parent was enqueued into deploy? | 20:44 |
| fungi | so we ended up running the new jobs one change early | 20:44 |
| fungi | if we'd held up approving the second change until the first one deployed, i guess they wouldn't have been selected for the first deploy | 20:45 |
| Clark[m] | I'm not sure I parse that | 20:45 |
| fungi | the parent and child merged within seconds of each other. the child adds new jobs. because the child was already merged when the parent entered the deploy pipeline, the jobs added by the child got run for the parent | 20:47 |
| Clark[m] | Oh! Yes I see. Fun | 21:00 |
| clarkb | TheJulia: I left some super minor comments on https://review.opendev.org/c/opendev/glean/+/899219 I'm happy to approve that as is but wanted to make sure you saw those comments before it merged just in case any of those items are a bigger concern than I foresee | 21:17 |
| clarkb | tonyb: I approved the cacti update and the inventory removals of the old servers. I'll let you deide if you want to approve https://review.opendev.org/c/opendev/system-config/+/901504/ or address frickler's comments | 21:21 |
| clarkb | and I've also approved the dns update to remove dns records for the old servers just now | 21:23 |
| clarkb | I think all of that should be fine to land in whatever order relative to one another | 21:23 |
| clarkb | the main thing is not removing the actual servers until the inventory updates otherwse we get failures | 21:23 |
| clarkb | *we get failures from LE | 21:23 |
| tonyb | Ahh okay. I misunderstood what you said the time I asked. | 21:26 |
| clarkb | tonyb: I think the order you have is most strictly correct | 21:27 |
| clarkb | and that way we don't accidentally try to update LE certs if the system-config inventory cleanup fails in CI | 21:27 |
| tonyb | got it | 21:29 |
| clarkb | oh heh they don't share a queue so need to recheck that once the dependency merges | 21:32 |
| opendevreview | Merged opendev/system-config master: Update cacti_hosts to more generic names. https://review.opendev.org/c/opendev/system-config/+/902714 | 21:34 |
| tonyb | clarkb: okay | 21:39 |
| clarkb | fungi: since review02 is out of the emergency file now should I approve https://review.opendev.org/c/opendev/system-config/+/902436 ? | 21:46 |
| fungi | clarkb: yes | 21:46 |
| clarkb | double checking things I compared to jrosser's change and that change doesn't have teh s suffix | 21:48 |
| clarkb | so now I'm wondering if this is correct or maybe secondsi s the default. I'm double checking ebfore approving | 21:48 |
| clarkb | "If set to a time in seconds, or a time in any of the formats documented in sshd_config(5)" | 21:49 |
| clarkb | looks like seconds is default and s as a qualifier is acceptable | 21:50 |
| fungi | so fine either way | 21:50 |
| clarkb | yup | 21:50 |
| clarkb | I've approved it | 21:51 |
| tonyb | clarkb: I read over the opendev and zuul annual reports. opendev looks good to me. I think there's a small opportunity for clarification at: https://etherpad.opendev.org/p/2023-zuul-annual-report#L63 | 22:30 |
| tonyb | the ways it's currently worded sounds like there are frequent privilege escalations *in zuul* | 22:31 |
| opendevreview | Merged opendev/system-config master: Remove Ansible configuration and inventory entries for old mirror servers https://review.opendev.org/c/opendev/system-config/+/902715 | 22:42 |
| opendevreview | Merged opendev/system-config master: Increase bridge's ansible ssh controlpersist timeout to 180s https://review.opendev.org/c/opendev/system-config/+/902436 | 22:42 |
| kozhukalov | https://www.irccloud.com/pastebin/6xLS8cSA/ | 22:47 |
| kozhukalov | This is the standard role use-docker-mirror and I often see this error appearing randomly See for example https://37c3b0502f727da81ef7-95e9c5ca80133f8e8d1a12029c605fe6.ssl.cf5.rackcdn.com/902162/2/check/loci-ironic/8c1562c/job-output.txt | 22:48 |
| clarkb | tonyb: thanks I'll see what I can do to make that more claer is a linux issue we're just the victim of :) | 22:49 |
| tonyb | clarkb: That's what I thought. | 22:50 |
| clarkb | kozhukalov: chances are exactly what it says: the disk is full. Do these errors occur in a particular cloud region? Some of them have epehermal drives mounted on /opt that provide additional disk space rather than having all disk available at / | 22:50 |
| tonyb | kozhukalov: I think the error is clear .... the disk is full. I guess the real question is what chewed up all the disk | 22:50 |
| clarkb | if this happens in rax nodes chances are you're filling up the 20GB / (which already has about 11GB dedicated to the OS and caches used up) | 22:51 |
| kozhukalov | yes, the error is clear. However it is not quite clear why it happens. | 22:51 |
| clarkb | and ya need to indentify what in your job is using all the disk and see if it can be migrated to /opt | 22:51 |
| kozhukalov | This is in the very beginning of the job | 22:51 |
| kozhukalov | I'll try to figure out if it happens only in a particular region | 22:52 |
| clarkb | 2023-12-05 19:05:20.612963 | ubuntu-jammy | Setting up swapspace version 1, size = 20 GiB (21474832384 bytes) | 22:52 |
| clarkb | that is almost certainly your problem | 22:52 |
| tonyb | kozhukalov: What change? | 22:52 |
| fungi | zuul should also be collecting info at the start of the job showing what the initial filesystem utilization looks like | 22:52 |
| fungi | in one of the standard zuul_info logs we collect | 22:53 |
| kozhukalov | Will try to set smaller swap allocation. | 22:54 |
| kozhukalov | Thanks @tonyb @clarkb @fungi | 22:54 |
| clarkb | kozhukalov: on rax nodes what should happen is the ephemeral drive should be formatted to include swap | 22:57 |
| tonyb | kozhukalov: FWIW: https://zuul.opendev.org/t/openstack/build/8c1562cc0075408cb33bfdcee7a0a758/log/zuul-info/zuul-info.ubuntu-jammy.txt#123 shows the initial diskspace | 22:57 |
| clarkb | I'm not sure why that particular job is using a swapfile. We only use swapfile outside of rax because we don't get epehermal drives we can repartition and format | 22:57 |
| clarkb | that said I think we suggest at 1GB swap at most | 22:57 |
| clarkb | 20GB is massive and I'm not sure I would recommend it in any setup on our nodes | 22:58 |
| clarkb | so I think there are two bugs here: the first is using a swapfile on rax and the second is the size of the swap file/partition | 22:58 |
| JayF | I have a strange service suggestion, that I feel like might already exist | 23:01 |
| JayF | some kind of link shortener. | 23:01 |
| kozhukalov | This is probably due to the nature of the job. For me it is also unclear why it allocates so huge swap file. it has been the case since 2017. Will try to rework this. | 23:02 |
| clarkb | JayF: its come up in the past but there are plenty that exist out there already. Its a very low return big headache type of service for us | 23:02 |
| JayF | Is there one that you'd trust to put out there? | 23:02 |
| tonyb | kozhukalov: You could try removing the hunk from openstack/loci:playbooks/setup-gate.yaml | 23:03 |
| JayF | I always get skiddish when picking one, you never know when all the sudden short-dot-io is going to turn into a spamhaus | 23:03 |
| tonyb | JayF: I use tiny.cc | 23:03 |
| clarkb | JayF: bitly is a long term resident in the space | 23:03 |
| clarkb | they don't seem to have imploded and created themselves problems yet | 23:04 |
| JayF | bitly now charges | 23:04 |
| clarkb | oh neat | 23:04 |
| JayF | for new ones | 23:04 |
| tonyb | JayF: one nice feature there is that yoy can edit the links for a given short URL | 23:04 |
| JayF | so I am counting the minutes until our old ones go through an ad redirect | 23:04 |
| JayF | the encrappification cycle of url shorteners :/ | 23:04 |
| clarkb | but also I try to avoid shorteners if I can | 23:04 |
| kozhukalov | @tonyb Yes, I am trying to rework this. This was likely to make it faster. It first allocates huge swap file and then deploys docker to use tmpfs. Kinda funny | 23:04 |
| clarkb | I don't like not knowing what the other end is when I click on something | 23:05 |
| JayF | tiny.cc works, thanks tonyb | 23:05 |
| clarkb | it drives me nuts that twitter made shorteners common for everything | 23:05 |
| JayF | clarkb: agreed, but this is for a long link that's going into a youtube video for Openinfra live on Thurs | 23:05 |
| JayF | don't want to make someone type in a 200 character URL in 13 seconds :D | 23:05 |
| fungi | qr code ;) | 23:05 |
| tonyb | JayF: tiny.cc also generates QR codes | 23:05 |
| JayF | fungi: where'd you get the idea that I believe in OR | 23:06 |
| JayF | fungi: AND :D | 23:06 |
| * JayF feels about QR codes the way clark feels about URL shorteners | 23:06 | |
| JayF | except at least with a URL shortener I can curl it | 23:06 |
| fungi | or https://pypi.org/project/qrcode has a convenient command line interface | 23:06 |
| clarkb | JayF: ya I'm somewhat anti qr code too fwiw | 23:08 |
| clarkb | I've gone as far as saying the fcc should stop allowing them on tv but I'm weird like that | 23:09 |
| clarkb | between superbowl ads showing QR codes and restaurants replacing menus with QR codes we've normalized behavior that can only lead to problems in a few yaers when everyone thinks nothing of scanning and following them | 23:09 |
| fungi | i usually try to accompanying them with the actual url for people who want to pause and type | 23:09 |
| JayF | that is exactly what I am doing :) | 23:10 |
| tonyb | kozhukalov: Oh ... that's an interesting setup. I'm sure it made sense when it was implemented | 23:10 |
| opendevreview | Merged openstack/project-config master: [Neutron-lib] Update Grafana Dashboard https://review.opendev.org/c/openstack/project-config/+/902119 | 23:49 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!