| opendevreview | Merged opendev/infra-openafs-deb jammy: Update Jammy to 1.8.13 https://review.opendev.org/c/opendev/infra-openafs-deb/+/935025 | 00:41 |
|---|---|---|
| opendevreview | Merged openstack/diskimage-builder master: Reapply "Make sure dnf won't autoremove packages that we explicitly installed" https://review.opendev.org/c/openstack/diskimage-builder/+/934992 | 01:48 |
| tonyb | clarkb: Yeah it's for Noble, I thought I had something workable, but then I discovered that docker-compose (v1 written in python), dosn't work with python >= 3.12 so we'd really need to consider using v2 on distros > jammy (Possible >= jammy) | 01:49 |
| opendevreview | Doug Goldstein proposed zuul/zuul-jobs master: add roles to install helm-docs https://review.opendev.org/c/zuul/zuul-jobs/+/935030 | 01:50 |
| jcapitao[m] | hello folks, we are currently trying to add CS10 support in DIB https://review.opendev.org/c/openstack/diskimage-builder/+/934045 | 09:07 |
| jcapitao[m] | but looks like the worker CPUs does not support x86-64-v3 microarch level | 09:08 |
| jcapitao[m] | is there a way in Zuul/Nodepool to request a node that support it ? | 09:09 |
| jcapitao[m] | apevec: ^ FYI | 09:09 |
| tonyb | jcapitao[m]: Not that I'm aware of. IMO it was a problematic decision to make that the minimum | 09:11 |
| apevec | uhoh which cloud is that? | 09:12 |
| tonyb | jcapitao[m]: the only ones that might work are onmetal, and raxflex. | 09:13 |
| tonyb | apevec: most of them | 09:13 |
| jcapitao[m] | yeah, it's a bit disruptive even though x86-64-v3 was designed back in ~2013 with Haswell, many CPUs still don't support all the features (e.g AVX) :/ | 09:20 |
| apevec | RAX with Xen is older :) | 09:25 |
| apevec | tonyb: could we get a label which is restricted to the providers with do have CPU v3 ? | 09:26 |
| tonyb | there's also a complication around the kernel/KVM version of the hypervisor. | 09:27 |
| tonyb | apevec: yes RAX is, but raxflex is more recent | 09:27 |
| tonyb | apevec: I expect we can | 09:28 |
| jcapitao[m] | tonyb: should we formally request the labels somewhere to track the topic ? | 09:49 |
| tonyb | no it's okay I'll look at it tomorrow. | 10:38 |
| tonyb | I'll firstly verify which providers if any will work. | 10:39 |
| frickler | infra-root: release-team has noticed multiple gitea failures like https://zuul.opendev.org/t/openstack/build/f8ebe67a160847d29610c150b6812d06 GnuTLS recv error (-110): The TLS connection was non-properly terminated. | 11:26 |
| frickler | checked all gitea instances and they seem fine in general, so likely some kind of sporadic issue | 11:42 |
| *** darmach688 is now known as darmach68 | 11:59 | |
| opendevreview | Tae Park proposed openstack/project-config master: Add repo app-openbao for starlingx https://review.opendev.org/c/openstack/project-config/+/935154 | 14:49 |
| frickler | another issue I saw when checking logs, not sure if it is a kolla thing, might usually not be noticed since it is getting retried, could be related to raxflex being different https://zuul.opendev.org/t/openstack/build/d7a108adc1c8491a92362bcb40b37670 | 14:57 |
| frickler | I checked a couple of similar rechecks and they all were on raxflex. will put that onto the kolla agenda | 15:09 |
| fungi | looks like mkfs isn't actually setting the requested label, or it's not showing up in the device scan afterward | 15:16 |
| fungi | might be something related to virtio | 15:17 |
| fungi | i know we had some initial wierdness with virtio causing the block device mapping to get swizzled around | 15:18 |
| fungi | swap and ephemeral were switched with each other, i think | 15:18 |
| Clark[m] | jcapitao apevec tonyb the closest thing we have today is going to be the nested virt labels. I don't know for sure if they have all the cpu flags you need but the machines are generally more capable and modern. But you limit where your jobs can run pretty substantially | 15:35 |
| Clark[m] | My suse machines mix in the extra CPU capabilities which I feel like is a nice compromise between not working at all and getting the desired performance improvements. It's unfortunate that this approach isn't more common | 15:37 |
| *** artom_ is now known as artom | 15:54 | |
| Clark[m] | frickler: I wonder if the gitea issues can be traced back to the memory leak | 15:58 |
| opendevreview | Mohammed Naser proposed zuul/zuul-jobs master: Add buildset registry image override https://review.opendev.org/c/zuul/zuul-jobs/+/935168 | 15:59 |
| Clark[m] | It seems what happens is we end up swapping and things slow down quite a bit before an OOM occurs. Maybe that is enough to make TLS sad. I think it fits noonedeadpunk's connection timeout problems better but could fit here too | 15:59 |
| opendevreview | Mohammed Naser proposed zuul/zuul-jobs master: Add buildset registry image override https://review.opendev.org/c/zuul/zuul-jobs/+/935168 | 16:03 |
| opendevreview | Mohammed Naser proposed zuul/zuul-jobs master: Add buildset registry image override https://review.opendev.org/c/zuul/zuul-jobs/+/935168 | 16:04 |
| opendevreview | Mohammed Naser proposed zuul/zuul-jobs master: Allow overriding the buildset registry image https://review.opendev.org/c/zuul/zuul-jobs/+/849989 | 16:06 |
| opendevreview | Mohammed Naser proposed zuul/zuul-jobs master: Allow overriding the buildset registry image https://review.opendev.org/c/zuul/zuul-jobs/+/849989 | 16:07 |
| opendevreview | Merged openstack/project-config master: Use 2024.2 constraints in master translation jobs https://review.opendev.org/c/openstack/project-config/+/934402 | 16:13 |
| opendevreview | Merged openstack/project-config master: Add separate acl group for watcher-tempest-plugin https://review.opendev.org/c/openstack/project-config/+/934357 | 16:13 |
| opendevreview | Merged openstack/project-config master: Update more ironic project ACLs for editHashtags https://review.opendev.org/c/openstack/project-config/+/935022 | 16:13 |
| fungi | slittle1: is https://review.opendev.org/935154 (Add repo app-openbao for starlingx) expected? | 16:15 |
| clarkb | one thing I want to try and get done today after parent teacher conferences is prepping a fallback swift container for insecure-ci-registry pruning tomorrow | 16:59 |
| clarkb | if anyone recalls any special setup for that please let me know otherwise I'll probably just login and manually inspect things and see what I can see | 17:00 |
| slittle | please review https://review.opendev.org/c/openstack/project-config/+/935154 ... Set myself up as the initial core. I'll take care of he rest. Thanks | 17:05 |
| fungi | slittle: thanks! i asked you in here earlier if that change was on your radar. will approve it now | 17:06 |
| slittle | Ha. Hazard of working from two sites. Left my hexchat running on the other location | 17:08 |
| opendevreview | Merged openstack/project-config master: Add repo app-openbao for starlingx https://review.opendev.org/c/openstack/project-config/+/935154 | 17:10 |
| fungi | once that ^ deploys i'll add you to starlingx-app-openbao-core | 17:10 |
| slittle | Thanks fungi | 17:14 |
| corvus | clarkb: fungi it's looking like x-delete-after doesn't work in rax-flex. i just tried it with SLO objects as well as normal objects, and they're not being deleted. | 17:25 |
| corvus | that has implicatons for using it for log storage in addition to the image uploads. | 17:26 |
| fungi | i wonder if there's some background process in swift that they should be running but aren't | 17:27 |
| corvus | yeah, i believe that's how it's implemented. i'll send off an email to rax folks in a bit. | 17:28 |
| fungi | slittle: done! | 17:30 |
| fungi | corvus: swift docs mention "the swift-object-expirer daemon" so maybe that's missing | 17:30 |
| clarkb | oh interesting. That feels like something that falls under "its good we're testing it and can provide feedback" category of things | 17:30 |
| corvus | oh wait, it does work -- but the objects are not removed from the listing. they still appear to be present... | 18:18 |
| fungi | https://docs.openstack.org/swift/latest/overview_expiring_objects.html#accessing-objects-after-expiration | 18:38 |
| fungi | that i guess | 18:38 |
| corvus | fungi: perhaps? but it's been a month for some of these objects and they still appear in the listing as if they were present | 18:43 |
| corvus | but yeah, perhaps it's only done the "expiration" step and still hasn't actually deleted them after a month | 18:44 |
| corvus | (but in the configuration that we can't HEAD or GET them after expiration) | 18:44 |
| corvus | interestingly, DELETE-ing them returns a 404 but does actually delete them from the listing. | 18:45 |
| fungi | "eventually consistent" (for possibly very long definitions of "eventually") | 18:46 |
| clarkb | looks like we're using rax dfw swift for the intermediate registry with a dedicated user | 18:56 |
| clarkb | I'll dig into creating a new container there and give that user access | 18:57 |
| clarkb | I actually wonder if I can just create a container as that user and then problem solved | 18:57 |
| * clarkb attempts this | 18:57 | |
| clarkb | infra-root python3 -m venv failed on insecure-ci-registry because we don't have the python3-venv package installed. Would it be ok for me to install that to make an openstackclient venv or would you prefer I use an openstackclient docker image or interact with that clouds.yaml on say bridge instead? | 18:59 |
| corvus | i'm happy to have venv installed on that host for easy tool usage | 19:04 |
| clarkb | ok I'll go ahead and quickly install that package | 19:05 |
| corvus | and i'm not worried about that being out of sync with system-config; i think our testing keeps that from being a problem | 19:05 |
| clarkb | do you want me to also push up a change to get it back into sync? | 19:06 |
| clarkb | arg you can't pip install python-openstackclient without a full buildchain because of netifaces | 19:09 |
| clarkb | why does the openstackclient need to care about netifaces? | 19:10 |
| mordred | clarkb: openstacksdk uses netifaces | 19:25 |
| mordred | clarkb: https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/cloud/_utils.py#L191 | 19:27 |
| clarkb | ya but why does the client care? | 19:27 |
| clarkb | you do name lookups and if you get back ipv6 you use those addresses | 19:27 |
| clarkb | otherwise you use ipv4 | 19:27 |
| clarkb | separately I'm having a wonderful time tracking down whatever happened to being able to specify the clouds.yaml path | 19:28 |
| clarkb | it looks like os-client-config's config loader actually gets implented in openstacksdk? | 19:28 |
| mordred | clarkb: you'd THINK that would be how you would do things - but to provide interface_ip (since servers launched do not default to having anything dns related) - you have to look at the ip's on the server object, and then determine which of those are usable from the calling client | 19:29 |
| mordred | you know, because we can't have nice things | 19:29 |
| mordred | and yes - os-client-config is just a compat shim layer- the relevant code was merged in to openstacksdk long ago | 19:30 |
| clarkb | mordred: the problem with ^ is that its pure spaghetti. I've gone though python-opnstackclient, keystoneauth, os-client-config, and now openstacksdk just to dtermine if I can set a path to clouds.yaml (whcih I'm 99% certain was possible before) | 19:31 |
| clarkb | and I still haven't answered that qusetion | 19:31 |
| fungi | installing python3-venv on any server seems fine to me | 19:31 |
| fungi | or on every server, sure | 19:31 |
| mordred | clarkb: fair enough. I was not quite done deprecating old things, sorry about that. :) | 19:32 |
| clarkb | config_file_override = self._get_envvar('OS_CLIENT_CONFIG_FILE') | 19:32 |
| clarkb | ok you can still do this but its not documented | 19:32 |
| clarkb | or at least I don't think it is. Checking that is next up | 19:33 |
| mordred | yup | 19:33 |
| mordred | https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/config/loader.py#L199 | 19:33 |
| clarkb | it is documented in openstacksdk and os-client-config but not in python-openstackclient's documentation/manpage/helpoutput | 19:34 |
| fungi | part of the problem with the config belonging to a library rather than the application, it's not always clear where to document it | 19:34 |
| mordred | yeah - that's a good point. osc should really flow-through some relevant sdk docs so that an osc user doesn't have to know about sdk itself | 19:35 |
| clarkb | ya I think linking from osc docs to sdk docs on auth setup would be good in the online docs. Its more painful to do that with manpages and help output though | 19:35 |
| mordred | we need exportable documentation chunks that the consuming app can include :) | 19:35 |
| opendevreview | James E. Blair proposed opendev/zuul-jobs master: Switch to using openstacksdk for image uploads https://review.opendev.org/c/opendev/zuul-jobs/+/935218 | 19:36 |
| clarkb | I'm going to put this clouds.yaml file on bridge and then run commands from there I think that is the most straightforwad thign at this point (doable because I can override the clouds.yaml path now) | 19:38 |
| clarkb | container list results in a forbidden response | 19:45 |
| clarkb | I half expected that but I was hoping this would be easy mode. So I think I need to create the container and then delegate it to this user somehow /me pulls up rax swift docs | 19:45 |
| opendevreview | Jeremy Stanley proposed opendev/infra-openafs-deb focal: Update Focal to 1.8.13 https://review.opendev.org/c/opendev/infra-openafs-deb/+/935220 | 19:46 |
| fungi | clarkb: are you trying to delete objects? if so, i'm not sure the unified openstacksdk plumbs through the bulk delete operation | 19:47 |
| clarkb | fungi: no I'm trying to set up a new fallback container that the dedicated registry swift user can read and write to | 19:48 |
| fungi | ah | 19:48 |
| clarkb | fungi: in case things go poorly with registry pruning tomorrow. I want the backup container ready to go and just update the config file on the registry to switch over | 19:49 |
| fungi | yep, makes sense | 19:49 |
| clarkb | I thought maybe just maybe the special user could list and create new containers with implicit perms in place for it but doesn't appear to be the case | 19:49 |
| clarkb | I think ti was a good exercise though | 19:49 |
| corvus | clarkb: fungi https://review.opendev.org/935218 is a switch *back* to using sdk for the image uploads. i believe this has workarounds for all known problems, so we should end up actually deleting images after 3 days. | 19:57 |
| fungi | yay! | 20:00 |
| clarkb | any idea what properties | Access-Log-Delivery='false' this property on the existing registry container means? I've created a new container and it doesn't have that | 20:00 |
| clarkb | but also it looks like there is no way to set acls via headers in opesntaclient? | 20:01 |
| fungi | love the carried-over copyright lines, reminds me how much i miss jhesketh | 20:01 |
| clarkb | there is container set but that seems to set property values liek the one I pasted above | 20:02 |
| corvus | fungi: yeah, i think there's like a line or two that goes all the way back :) | 20:02 |
| clarkb | I'm not seeing an obvious way to set X-Container-Read/X-Container-Write | 20:02 |
| corvus | clarkb: that property does not ring a bell for me | 20:02 |
| clarkb | corvus: since you've been poking at this a bit recently do you know if openstackclient can set those X-Container-* header values somehow? | 20:02 |
| fungi | clarkb: seems likely to have been in the default properties and then configured out between when that was created and now | 20:03 |
| clarkb | fungi: ya that could be | 20:03 |
| corvus | clarkb: i'm pretty sure we had to use curl for that | 20:03 |
| fungi | probably has no impact on our use either way | 20:03 |
| clarkb | ok I skipped breakfast so I'm starving for lunch. I'll pick this back up again after I eat somethign (I'll also review those changes yall pushed) | 20:05 |
| clarkb | corvus: ya even in openstackclient tests they just do a raw HEAD request against the conatiner to set the values then check they come back out again on a container show | 20:06 |
| clarkb | timburke: ^ this probably isn't your highest priority, but as a user I find this particularly frustrating. I should be able to do straightfowrard tasks like this through the default tool | 20:07 |
| clarkb | timburke: tl;dr is it doesn't appear that openstackclient is capable of setting read or write acls on swift containers | 20:07 |
| clarkb | oh the test is in a mock so its not even that sophisticated | 20:07 |
| clarkb | timburke: a semi related thing is that I almost never want to use project specific client tools because they very rarely support clouds.yaml, but maybe this has changed. I would say as a user having tasks like this through the main client is super helpful and so is having clouds.yaml support in the project specific clients | 20:12 |
| clarkb | ok lunch now. Back in a bit | 20:13 |
| mordred | clarkb: we started slowly adding clouds.yaml support to project specific clients back in the day, but only got through a few of them | 20:19 |
| clarkb | api operations require tokens. I think by default those tokens have a relatively short lifespan. But I see that osc also has a token revoke command but no token listing. I guess that makes me wonder if tokens are as ephemeral as I thought they may be. DO they last forever? | 20:57 |
| clarkb | oh maybe if I issue one the response will tell me when it expires | 20:58 |
| clarkb | reading https://docs.rackspace.com/docs/set-up-cloud-files-and-acls there is an additional complication where all of the curl examples are actually against clouddrive and not swift apis? | 21:00 |
| clarkb | ok I got ^ to work except that it created the container in the wrong region | 21:10 |
| clarkb | because it wasn't already created and I set the read acl so it helpfully created the conatiner too | 21:10 |
| * clarkb tries again | 21:10 | |
| clarkb | specifying --os-region-name doesn't seem to work (I ended up installing swift client and i have that almost working except for the region so maybe the -A auth url is wrong?) | 21:12 |
| clarkb | I now have a container that should work in the wrong region (its the wrong region bceause its not the same region as the service using swift | 21:14 |
| clarkb | so I think you can't use -A/-U/-K with --os-auth-url/--os-region-name/--os-username/--os-password. Its one of the other. Problem is I think I cannot auth with swiftclient using the openstack stuff because that requires special rax key auth | 21:21 |
| clarkb | it works when you use -A/-U/-K because that is the special key auth stuff but then I can't select the region | 21:22 |
| mordred | clarkb: the rax key auth is *very* similar to username/password auth, iirc it's structurally the same, just with a word replaced. I feel like at one point we had a ksa plugin that would do it, but then there were concerns about landing it in ksa itself since it was "non-standard" | 21:28 |
| clarkb | mordred: ya we're using the ksa plugin for not swift | 21:28 |
| clarkb | but that is driven by clouds.yaml and I don't see any way to drive this via swiftclient other than using -A | 21:28 |
| clarkb | so its either you use swiftclient and get the default region or you use openstacksdk and don't get full functionality or you do everything "bit by bit" with curl or nc | 21:30 |
| mordred | and that's because you need to do a thing that OSC doesn't have exposed, right? | 21:30 |
| clarkb | yes, I want ot set read and write acls | 21:30 |
| mordred | are you trying to do this in base with osc? or in python with sdk? | 21:30 |
| mordred | s/base/bash/ | 21:31 |
| clarkb | with osc not the sdk. But the sdk doesn't directly expose it either | 21:31 |
| clarkb | you can probably manipulate the sdk to do a "raw" post with headers set though | 21:31 |
| clarkb | my frustration is more along the linse of "this should work the first time with the default client everytime" | 21:31 |
| clarkb | I'm a special case of user that is going to bang their head against this until something works. Most people are not | 21:31 |
| mordred | well - yeah - believe me, of all the people I totally hear you and agree with you | 21:32 |
| mordred | it looks to me like this is directly supported in SDK though | 21:33 |
| mordred | https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/object_store/v1/container.py#L78 | 21:33 |
| clarkb | the sdk and osc will read the acls back | 21:33 |
| clarkb | but I haven't found any where where they will write them | 21:33 |
| clarkb | oh I see in the docs now so maybe that is my best path forward | 21:34 |
| clarkb | write a script taht gets the cloud then gets the container then sets the metadata | 21:34 |
| mordred | yeah - that should work. I agree, this should be exposed in OSC for sure | 21:35 |
| clarkb | ok I'm going to take a deep breath and then tackle it that way | 21:35 |
| clarkb | I may post up a draft of the script here in a few just to sanity check before I try to run it | 21:35 |
| timburke | clarkb, as far as expired objects appearing in listings, i remember the rackspace folks always complaining about their expirers running behind. i know we at nvidia have had to tune things a lot to handle hundreds of millions of queue entries | 21:38 |
| timburke | unfortunately, the overlap of osc and swift developers is basically nil; even worse, the same could be said of the set of swift developers that actively push forward client development | 21:40 |
| clarkb | mordred: https://paste.opendev.org/show/bawRwIdnWn7lm1iBq44W/ does this look good? | 21:42 |
| clarkb | timburke: ya I also think this is a common issue and not limited to swift. I'm just hitting it with swift dueto particular circumstances | 21:42 |
| mordred | clarkb: yes - that seems reasonable - assuming those acls are correct, which I have no idea about | 21:43 |
| clarkb | mordred: yup mostly looking for structural correctness | 21:43 |
| clarkb | thanks | 21:43 |
| clarkb | well that ran and didn't raise an exception but it doesn't seem to have set the acls either | 21:47 |
| clarkb | time for more debugging | 21:47 |
| clarkb | looks like maybe I have to explicitly state which metadata key values I want to write back (the example for this doesn't do so but the method docs imply this is necessary) | 21:51 |
| clarkb | problem is it says "key value pairs" so now I'm like wat | 21:53 |
| clarkb | ok after 3 hours I have successfully managed to set the acls | 21:58 |
| clarkb | mordred: thanks for the pointer this wasn't as easy as I would've liked but it was workable | 21:58 |
| clarkb | I'm going to push up a little script into system-config so that its captured somewhere and then also push an sdk docs update | 21:58 |
| clarkb | I need to cleanup the container that was auto created for me in the wrong region too /me starts chipping away at athat | 22:00 |
| fungi | i wonder how far the code distance is from that script to an osc implementation. i guess mostly arguing about what the ui should be | 22:03 |
| clarkb | ORD conatiner has been deleted | 22:03 |
| clarkb | looks like the container name is set in private vars so I won't push any chagnes to WIP before we do the pruning tomorrow. We'll just have to edit the name tomorrow | 22:04 |
| clarkb | assuming we do fallback | 22:04 |
| opendevreview | Clark Boylan proposed opendev/system-config master: Add a rax swift acl setting script https://review.opendev.org/c/opendev/system-config/+/935228 | 22:14 |
| clarkb | mordred: et al ^ the final result | 22:14 |
| clarkb | I wrote a summary of the problems and why this is a solution in that file too | 22:15 |
| mordred | fungi: looking at it briefly, it would not be hard. you're absolutely right, deciding what the cli should be will be the hardest part. like "openstack container set acl" perhaps? | 22:17 |
| opendevreview | Jay Faulkner proposed openstack/diskimage-builder master: [gentoo] Fix+Update CI for 23.0 profile https://review.opendev.org/c/openstack/diskimage-builder/+/923985 | 22:20 |
| fungi | and figuring out whether swift folks need to weigh in on the syntax | 22:21 |
| fungi | (since as timburke said there are approximately zero swift team members with interest in the unified openstack cli or sdk) | 22:21 |
| opendevreview | Jay Faulkner proposed openstack/diskimage-builder master: [gentoo] Fix+Update CI for 23.0 profile https://review.opendev.org/c/openstack/diskimage-builder/+/923985 | 22:22 |
| mordred | typically service teams have not cared about such syntax discusisons | 22:22 |
| clarkb | remote: https://review.opendev.org/c/openstack/openstacksdk/+/935229 Fix swift metadata setting documentation | 22:24 |
| clarkb | I also updated the sdk docs | 22:24 |
| mordred | of course, looking further, I'm now reminded that cli on the backend is just using the REST adapter out of SDK and not the higher level service objects, because it has its own "higher level" internal API. So - still not hard, but mildly annoying | 22:24 |
| clarkb | ok I promosed peopel code reviews off to do that now | 22:27 |
| clarkb | corvus: fungi fyi left a -1 on https://review.opendev.org/c/opendev/zuul-jobs/+/935218 mostly concerned about ansible logging of secrets | 22:38 |
| clarkb | please review and let me know if I've got something wrong there | 22:39 |
| clarkb | corvus: fwiw I have a feeling my little openstacksdk script would work for raxflex too if we want to test that. Probably on a new container when we're not already distracted though | 22:49 |
| opendevreview | Merged opendev/infra-openafs-deb focal: Update Focal to 1.8.13 https://review.opendev.org/c/opendev/infra-openafs-deb/+/935220 | 22:55 |
| opendevreview | Jay Faulkner proposed openstack/diskimage-builder master: [gentoo] Fix+Update CI for 23.0 profile https://review.opendev.org/c/openstack/diskimage-builder/+/923985 | 23:31 |
| opendevreview | James E. Blair proposed opendev/zuul-jobs master: Switch to using openstacksdk for image uploads https://review.opendev.org/c/opendev/zuul-jobs/+/935218 | 23:54 |
| corvus | clarkb: ^ fixed and replied | 23:55 |
| corvus | clarkb: do you want to? i'm switching to a new container with that patchset because of the detritus in the current container which i can't delete. now would be a good time to change the acls, etc, if we want. however, tbh, i'm sort of over it and think we should just use the more normal credentials. | 23:56 |
| clarkb | corvus: ya I mean I feel like the three hours of investigation make me not want to use it either. But the end result seems usable | 23:58 |
| clarkb | (until the next round of cloud updates and client changes and it breaks again I guess) | 23:58 |
| clarkb | corvus: oh I didn't realize that prune was explicitly to work around the behavior issue | 23:58 |
| corvus | clarkb: it would also be an experiment to see if that works with flex | 23:59 |
| clarkb | for some reason I had in my head it was to handle the lack of pruning on the objects you already uploaded | 23:59 |
| clarkb | but you're swapping containers for that | 23:59 |
| corvus | oh nope, they actually did get deleted | 23:59 |
| corvus | but their entries are somehow stuck and i can't even delete them through the web | 23:59 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!