| mnasiadka | clarkb: regarding Ansible and locale - see https://review.opendev.org/c/openstack/kolla-ansible/+/930975 (I don't know if this is any helpful information) | 09:23 |
|---|---|---|
| mnasiadka | fungi: I'm mainly seeing those logger issues on instances in rax-ord and rax-dfw | 09:42 |
| kevko | +1 | 10:00 |
| kevko | fungi: this is log for ansible -m setup before change https://901249311ab7ecbd3f16-b4ffb63fd72a873cfc8fbd2b6e893a02.ssl.cf2.rackcdn.com/930975/4/check/kolla-ansible-rocky9-kvm/432ae64/primary/logs/ansible/initial-setup and this is after my change mnasiadka mentioned | 10:05 |
| kevko | https://de62b6c8c004e1afcffe-25456b362a22ad76281304acb8641637.ssl.cf2.rackcdn.com/930975/25/check/kolla-ansible-rocky9/2b38a38/primary/logs/ansible/initial-setup ..... check 'ansible_env' key in ansible dictionary ..in failed there is more language variables set ... AND this is normally working ubuntu/debian | 10:05 |
| kevko | https://storage.bhs.cloud.ovh.net/v1/AUTH_dcaab5e32b234d56b626f72581e3644c/zuul_opendev_logs_a5b/909912/50/check/kolla-ansible-ubuntu-kvm/a5b72ec/primary/logs/ansible/initial-setup ...where is only LANG also ..... | 10:05 |
| kevko | so I hope it will help | 10:06 |
| clarkb | mnasiadka: I don't think that change properly fixes the issue because the images are configured to not install C.utf8 content | 14:49 |
| clarkb | mnasiadka: it probably "works" beacuse glibc will afllback to C or similar if it doesn't have the lang that is set | 14:49 |
| clarkb | mnasiadka: I think https://review.opendev.org/c/openstack/diskimage-builder/+/930932 is the proper fix for the missing locale but I am hoping someone with a centos background or interest can help review that and at least confirm it is unlikely to make anything worse | 14:50 |
| clarkb | I don't think it can be broken more than it is now so I suspect that change is safe and if it helps great and if not no big deal. But I'm not certain of that | 14:50 |
| * clarkb is going to pop into the monthly gerrit community meeting in ~5 minutes | 14:55 | |
| clarkb | it has been a while since I attended due to summer activity and summit travel. I can't think of anything to bring up from our end but yu have a couple of minutes to let me know if there is something | 14:56 |
| clarkb | gerrit user summit is next week. I knew that but then forgot. There will be live streaming of sessions via microsoft teams with a link on the docs for the event | 15:07 |
| JayF | :-O how long have I been able to expand files inline in gerrit, without opening them up one by one | 15:55 |
| JayF | I 'misclicked' and learned a cool thing | 15:55 |
| mnasiadka | clarkb: thanks for referencing that patch, looks sane enough | 15:58 |
| clarkb | JayF: since we upgraded to 3.2 | 15:58 |
| JayF | I think that may be the first time in my life I've thought about a gerrit version number :D ... since it's 3.9.6 now that means ... a long time? years? | 15:59 |
| clarkb | yes about 3 years looks like | 15:59 |
| fungi | i need to take a friend to the mainland to pick up their car from the mechanic, so will be disappearing for a few hours, but will check back in once i'm home | 16:06 |
| JayF | o/ | 16:07 |
| clarkb | the openstack release is done so now it is time to think about landing https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/926970 I'll also get a change up to update the default ansible version in the remaining opendev tenants | 16:20 |
| clarkb | we can land both after JayF successfully releases their bugfixes for ironic though | 16:20 |
| opendevreview | Clark Boylan proposed openstack/project-config master: Switch the remaining opendev zuul tenants to ansible 9 by default https://review.opendev.org/c/openstack/project-config/+/931320 | 16:26 |
| corvus | clarkb fungi i'm looking into rax-flex object storage. i believe we set up the old rax containers using this method: https://docs.rackspace.com/docs/set-up-cloud-files-and-acls | 16:56 |
| corvus | i don't know if (a) usernames in the old control panel would exist in the flex world in order to be added to swift. | 16:57 |
| corvus | i also don't know (b) how to get the token that would be needed to do the manual acl step | 16:57 |
| corvus | i feel like i could spend a lot of time trying to solve both of those, and eventually finding out that it just doesn't actually work with that swift | 16:59 |
| corvus | so if we don't have any actual docs that suggest that there's a way to do swift acls with flex, maybe we should assume no for now? | 17:00 |
| clarkb | corvus: thats a good point. I suspect those acls are a rax add on and not in normal swift and since rax flex is more normal openstack wouldn't have support for that? | 17:01 |
| clarkb | https://docs.openstack.org/swift/latest/overview_acl.html but maybe I'm wrong | 17:01 |
| corvus | yeah, i think they are sort of standard | 17:02 |
| corvus | but that still requires a new user in keystone i think | 17:02 |
| clarkb | ya seems likely unless they will automatically lookup that user from keystone to the other old auth system | 17:02 |
| corvus | there is the ability to create an application credential; i don't know if that shows up as a user in keystone? | 17:02 |
| clarkb | jamesdenton: do you know the answer to those question above ^? | 17:03 |
| clarkb | jamespage: basically how automatic is the integration between swift auth in rax flex and the normal rax auth systems. For nova et al we just used the api key as a keystone password and things worked | 17:04 |
| clarkb | jamespage: sorry that message was intended for jamesdenton | 17:04 |
| clarkb | jamesdenton: does the swift integration work in a similar way if we create a new swift specific user in the old backend and then set up acls on containers in swift within rax-flex? | 17:05 |
| corvus | it's getting confusing with all these jameses ;) | 17:05 |
| clarkb | corvus: fwiw I have no objection to setting up a container for nodepool in zuul in an existing working swift setup while we figure out these details for rax flex | 17:05 |
| corvus | clarkb: ack; i'll continue poking at flex for a bit to see what i can learn | 17:07 |
| corvus | okay i uploaded it with ansible and just the top level credentials. that half-worked. the file was uploaded, but the openstack ansible module threw an error: https://paste.opendev.org/show/bz0kgPz2QMXsTZSzuDV0/ | 17:16 |
| clarkb | corvus: I think ansible's openstack moduels have very specific openstacksdk requirements. Might be worth doubl checking what you have installed aligns? | 17:18 |
| clarkb | like maybe that explains why there is a mismatch in type expectations. Otherwise I don't have any great ideas | 17:18 |
| corvus | page says openstacksdk >= 1.0.0 and i have 4.0.0 | 17:18 |
| corvus | https://docs.ansible.com/ansible/latest/collections/openstack/cloud/object_module.html#ansible-collections-openstack-cloud-object-module-requirements | 17:19 |
| clarkb | https://github.com/openstack/ansible-collections-openstack?tab=readme-ov-file#branches-and-non-backward-compatibility-%EF%B8%8F also seems to support that you are good | 17:20 |
| clarkb | oh thats hosted on opendev. | 17:20 |
| clarkb | #openstack-ansible-sig may have more ideas? | 17:21 |
| corvus | https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/object_store/v1/_proxy.py#L472 | 17:26 |
| corvus | the code path where filename is provided and data is not (which is what i'm doing) will return None | 17:26 |
| corvus | https://docs.openstack.org/openstacksdk/latest/user/connection.html | 17:26 |
| corvus | that appears to differ from the docs ^ (search for create_object; i don't see a deep link option sorry) | 17:27 |
| corvus | the docs say it will always return an Object | 17:27 |
| clarkb | I was as far as the object_store create_object method and trying to find the _create def | 17:27 |
| clarkb | but in this case you are dealing with images which go through the other path | 17:28 |
| clarkb | I agree this seems liek a bug in the docs at least and then subsequently in the ansible modules | 17:28 |
| corvus | yeah, i think we want the filename path for this one due to size | 17:28 |
| clarkb | corvus: I think maybe you can return the response of the large object upload | 17:29 |
| clarkb | it ultimately calls https://opendev.org/openstack/openstacksdk/src/branch/master/openstack/object_store/v1/_proxy.py#L720-L726 which may return an object? I'm trying to figure that out | 17:30 |
| clarkb | but now i have to jump over to keystoneauth for that | 17:30 |
| corvus | AttributeError: 'Response' object has no attribute 'metadata | 17:32 |
| corvus | so it's at least more complicated than that | 17:33 |
| clarkb | ya looks like it is a python requests response object | 17:33 |
| clarkb | not an openstack api object | 17:33 |
| corvus | in zuul-jobs swift upload, we just ignore the result | 17:34 |
| corvus | exception=bad, no exception=success | 17:34 |
| clarkb | in this case we are getting an exception though right? | 17:35 |
| corvus | no; the exception is from ansible | 17:35 |
| corvus | sorry -- to be clear, zuul-jobs swift upload does not use the openstack ansible modules | 17:36 |
| corvus | it uses the sdk directly | 17:36 |
| clarkb | oh right the ansible module expects an object not None | 17:36 |
| clarkb | but we could do like zuul jobs logs uploads and upload directly then only care if the sdk generates an exception. That seems reasonable | 17:36 |
| corvus | yeah, so we might need a tiny ansible module for this | 17:36 |
| corvus | or... does flex have an s3 api? :) | 17:37 |
| clarkb | I'm not sure. I believe the swift s3 api support is middleawre you have to add and not built in (so can't be assumed to be present) | 17:37 |
| corvus | and and it's not on the old rax stuff | 17:38 |
| corvus | https://bugs.launchpad.net/ansible-collections-openstack/+bug/2061604 | 17:41 |
| corvus | https://review.opendev.org/c/openstack/ansible-collections-openstack/+/926506 | 17:41 |
| corvus | why are all the jobs dependent on pep8? | 17:42 |
| corvus | clearly that patch has a linter error. i would like to know, as a developer and contributor, whether it actually works regardless of the linter error. | 17:43 |
| clarkb | I've largely given up on trying to convince people that reducing round trips is a good thing | 17:45 |
| clarkb | there is a sense that we're optimizing by running fewer jobs and returning less info to contributors | 17:45 |
| corvus | welp, it worked backwards here. instead of me fixing up this patch for free, i'm moving on to something else. | 17:46 |
| corvus | to anyone else reading this: your time is valuable. it is definitely more valuable than the amount of money it costs to run a virtual machine long enough to run a test job. please let the ci system run as many jobs as possible so that you and other developers don't have to waste time on round trips or running jobs themselves. | 17:51 |
| clarkb | fwiw that code does look correct after reading _find()s implementation. It is a bit excessive in terms of extra api requests but maybe thats the only way to get a complete picture after a multi part upload | 17:51 |
| JayF | pre-commit is useful for these kinda things, ensuring basic quick checks are done before code lands | 17:52 |
| clarkb | JayF: I really dislike precommit... | 17:52 |
| JayF | but even if you have it enabled for a repo, you cannot force someone to have the hook installed | 17:52 |
| corvus | i agree in principle that running some quick checks before upload can save everyone time, and typically do so myself | 17:53 |
| clarkb | there is nothing special that precommit does especially if you are setup with tox or nox already. But the way it manages dependencies breaks a bunch of assumptions in the python world | 17:53 |
| clarkb | its crazy to me that people have created a bunch of meta repos just to make precommit happy isntead of just fixing pre commit | 17:55 |
| JayF | Honestly, that's not entirely true; the first part of that clause | 17:55 |
| clarkb | but the path of least resistance is to just make a git repo with some metadata I guess | 17:55 |
| JayF | pre-commit only runs configured checkers on /changed files/ | 17:55 |
| JayF | which is a significant speed boost vs running pep8, codespell, docs job, and similar jobs that are just a 'sanity check'. Having it happen in <30 seconds on commit is *way* faster than having tox spin up all those tests | 17:56 |
| JayF | I don't know anything about how it manages dependencies tbh, I mainly patterned Ironic's use after using it in Nova and seeing how much it improved my workflow | 17:57 |
| clarkb | JayF: I think most of those tools also support that functionality | 17:57 |
| clarkb | but maybe generating the list of changed files is the issue | 17:57 |
| clarkb | like flake8 can work on the diff | 17:57 |
| clarkb | JayF: precommit only installs things from git repos | 17:57 |
| clarkb | or maybe it does other repos too but only from source not packages. So tools like ruff have a meta repo that says I'm a package that depends on the package in pypi because building ruff from source requires a rust toolchain and is slow | 17:58 |
| clarkb | which breaks constraints and lockfiles and pacakge caching | 17:59 |
| JayF | I don't fully follow tbh | 18:00 |
| JayF | I get 'it only installs from git repos' | 18:00 |
| JayF | I don't understand the meta repo + ruff thing? | 18:00 |
| clarkb | right so if you naively list ruff in precommit as a source repo to install and execute you need to be able to compile ruff from source with a rust toolchain where you are running precommit. This is slow and also requires tools that may not be easy for everyone to get (because rust is bleeding edge and all that) | 18:01 |
| clarkb | instead you tell precommit to use the ruff-precommit source repo and install that. That then has a simple setup.py (or similar) that says I depend on ruff which causes the from source package install to pull down ruff's wheel from pypi and install that | 18:02 |
| clarkb | precommit could be fixed to install pypi packages directly then you don't need meta packages for each tool with slow compiles | 18:02 |
| clarkb | meanwhile you're ignoring any constraints and lockfiles you may have because this is a separate installation (you may still end up using cached packages at least since I think it goes through pip for that redirect) | 18:03 |
| clarkb | https://github.com/astral-sh/ruff-pre-commit/blob/main/pyproject.toml#L5 | 18:03 |
| clarkb | its just a lot of boilerplate which ends up in a less than ideal situation compared to doing the right thing upfront imo | 18:04 |
| JayF | ahh, I see | 18:06 |
| clarkb | it also introduces another potential failure mode for CI systems (because now you're fetching random git repos that the CI system is likely unaware of) | 18:06 |
| JayF | I reallly wonder if some of this is patched outta the gentoo version | 18:06 |
| JayF | and that may be why I didn't have similar experiences | 18:06 |
| clarkb | as an alternative you could just have a pre commit hook that runs ruff with tox | 18:07 |
| JayF | This might be good to bring up in cross-project stuff | 18:08 |
| clarkb | I brought it up in the thread that was started about this stuff on the mailing list recently | 18:09 |
| JayF | because I am extremely unlikely to introduce usage of that tool that's flipped from how other groups, like nova, are using it | 18:09 |
| JayF | and nova has tox run pre-commit aiui | 18:09 |
| clarkb | yes to keep the results in sync | 18:09 |
| clarkb | (otherwise tox and precommit are very likely to use different versions of tools and produce different results) | 18:10 |
| clarkb | side note: still not AAAA record for github.com | 18:12 |
| corvus | i have used an application credential to upload a file | 18:14 |
| corvus | that may not help us much with access control, since i think it's likely to have all the same access | 18:14 |
| corvus | but it at least makes creds easier to rotate | 18:15 |
| clarkb | corvus: so the open question for raxflex is still how to apply acls? | 18:15 |
| corvus | yep | 18:15 |
| clarkb | corvus: I am going to push up a pep8 fixed update to that change since it sounds like you weren't planning to | 18:15 |
| corvus | wfm | 18:16 |
| corvus | you might consider fixing their ppc while you're at it :) | 18:16 |
| clarkb | oh oops just pushed | 18:16 |
| * clarkb looks at that next | 18:17 | |
| corvus | i mean it's probably a good second change :) | 18:17 |
| timburke | ha! we raced, clarkb! i happened to see swift mentioned here, then happened upon ben's patch and though, "hey, i know that guy! i can help him out a little" | 18:19 |
| clarkb | remote: https://review.opendev.org/c/openstack/ansible-collections-openstack/+/931335 Run functional testing regardless of pep8/linter results | 18:20 |
| clarkb | timburke: oh oops | 18:20 |
| timburke | no worries! it all came out the same :-) | 18:21 |
| corvus | i have +2d both of those. | 18:22 |
| corvus | applications credentials have two parts: an id (looks like a uuid) and a secret (long random string) | 18:50 |
| corvus | do we consider the id to be sensitive? (should i encrypt it?) | 18:50 |
| Clark[m] | I want to say id is not secret. But we I think in system config we manage them as secret because it's never been super clear how sensitive that info is? | 18:55 |
| fungi | oof, a lot of scrollback to catch up on | 18:57 |
| corvus | fungi: oh i wouldn't bother :) | 18:57 |
| corvus | just a bunch of humans feeding the llms nonsense | 18:58 |
| corvus | Clark: yeah, my guess is probably fine to have plaintext but why not go ahead and encrypt it since it's not meaningful anyway | 18:59 |
| opendevreview | James E. Blair proposed opendev/zuul-jobs master: Add artifact upload support https://review.opendev.org/c/opendev/zuul-jobs/+/931340 | 19:15 |
| opendevreview | James E. Blair proposed opendev/zuul-jobs master: Add artifact upload support https://review.opendev.org/c/opendev/zuul-jobs/+/931340 | 19:17 |
| corvus | Clark: fungi ^ can you take a look at that and let me know if that looks okay. if it does, i'd like to merge it, and then get the okay to just merge a bunch of followup changes until it actually works (since the secrets involved make it post-review)? | 19:18 |
| corvus | also... should we consider making a trusted-check pipeline for the opendev tenant? | 19:18 |
| clarkb | corvus: looking now. Will haev a couple of comments | 19:24 |
| fungi | i have finally caught up with re-training my meat-based llm on the scrollback and am taking a look at those changes | 19:25 |
| clarkb | corvus: posted | 19:26 |
| fungi | is comparing roles/image-upload-swift/library/image_upload_swift.py to roles/upload-logs-base/library/zuul_swift_upload.py worthwhile? | 19:29 |
| jamesdenton | clarkb sorry for the delay. Are you suggesting creating a new user in the portal and using that user for Flex-Swift? | 19:30 |
| clarkb | jamesdenton: I think we're wondering how well https://docs.rackspace.com/docs/set-up-cloud-files-and-acls maps onto rax flex. One of the steps in there is to create a dedicated user that can have acls applied to it | 19:31 |
| jamesdenton | Good question - let me ask and i will get right back to you | 19:33 |
| corvus | fungi: some of the code comes from there; it's much simpler though | 19:37 |
| fungi | k, thanks. that helps | 19:38 |
| opendevreview | James E. Blair proposed opendev/zuul-jobs master: Add artifact upload support https://review.opendev.org/c/opendev/zuul-jobs/+/931340 | 19:43 |
| corvus | clarkb: ^ replied and addressed | 19:43 |
| clarkb | corvus: +2 from me thanks | 19:44 |
| clarkb | for a little while now I've been noodling some way to communicate how to take advantage of more advanced opendev/zuul features. I'm somewhat committed to making that a reality over the next couple of months so I've started a brainstorm for the topics that I think would be helpful for people basedon misconceptions and misunderstandings I've seen in the past | 19:48 |
| clarkb | https://etherpad.opendev.org/p/advanced-opendev-brainstorm | 19:48 |
| clarkb | happy for people to add notes or questions on tsuff they would like more info for | 19:48 |
| jamesdenton | clarkb i think the answer is... it ought to work but would be helpful to know if it doesn't? :D | 19:49 |
| jamesdenton | but you'd want to use the Flex swift endpoint instead | 19:49 |
| clarkb | right | 19:49 |
| clarkb | jamesdenton: is there a good contact to followup with if we hit problems or want to report an all good? maybe that is you? | 19:49 |
| jamesdenton | That email thread we already have would be perfect. Kevin can nail someone down | 19:50 |
| clarkb | jamesdenton: great thanks you | 19:51 |
| opendevreview | Merged opendev/zuul-jobs master: Add artifact upload support https://review.opendev.org/c/opendev/zuul-jobs/+/931340 | 20:00 |
| opendevreview | James E. Blair proposed opendev/zuul-jobs master: Fix build_diskimage_image_name variable name https://review.opendev.org/c/opendev/zuul-jobs/+/931346 | 20:15 |
| opendevreview | Merged opendev/zuul-jobs master: Fix build_diskimage_image_name variable name https://review.opendev.org/c/opendev/zuul-jobs/+/931346 | 20:18 |
| opendevreview | James E. Blair proposed opendev/zuul-jobs master: WIP: testing https://review.opendev.org/c/opendev/zuul-jobs/+/931347 | 20:32 |
| opendevreview | James E. Blair proposed opendev/zuul-jobs master: WIP: testing https://review.opendev.org/c/opendev/zuul-jobs/+/931347 | 20:33 |
| clarkb | I need to run an errand in like an hour ish. Things seem quiet though so don't expect any problems | 21:09 |
| opendevreview | Julia Kreger proposed openstack/diskimage-builder master: Reduce LVM extent usage https://review.opendev.org/c/openstack/diskimage-builder/+/930950 | 21:14 |
| opendevreview | James E. Blair proposed opendev/zuul-jobs master: WIP: testing https://review.opendev.org/c/opendev/zuul-jobs/+/931347 | 21:27 |
| opendevreview | James E. Blair proposed opendev/zuul-jobs master: WIP: testing https://review.opendev.org/c/opendev/zuul-jobs/+/931347 | 22:06 |
| corvus | https://zuul.opendev.org/t/opendev/build/8cf4e0abcd2f40d8a969072d9ec97929/console#4/0/3/ubuntu-noble | 22:15 |
| corvus | clarkb: fungi ^ i could use another set of eyes on that... i'm not seeing what's wrong... | 22:15 |
| corvus | i'm wondering if it's something about how that complex variable is being created... | 22:16 |
| corvus | hrm yeah... | 22:18 |
| corvus | maybe that's late evaluation happening after the secret freezing stuff | 22:18 |
| opendevreview | James E. Blair proposed opendev/zuul-jobs master: WIP: testing https://review.opendev.org/c/opendev/zuul-jobs/+/931347 | 22:30 |
| corvus | https://zuul.opendev.org/t/opendev/build/0533ca1c11dc4b3e85f7523f5de4967d | 22:34 |
| corvus | apparently "apt-get install python3-openstacksdk" is not sufficient to get a working openstacksdk :( | 22:35 |
| fungi | what is it missing? | 22:38 |
| opendevreview | James E. Blair proposed opendev/zuul-jobs master: WIP: testing https://review.opendev.org/c/opendev/zuul-jobs/+/931347 | 22:38 |
| corvus | python3-oslo.utils apparently | 22:38 |
| fungi | interesting. if i pip install openstacksdk into a venv it also doesn't install oslo.utils | 22:40 |
| fungi | it seems to soft integrate passing in oslo_config objects | 22:44 |
| fungi | without explicitly declaring any dependency on that | 22:44 |
| fungi | but that's the only oslo reference i spot in openstacksdk | 22:44 |
| opendevreview | James E. Blair proposed opendev/zuul-jobs master: WIP: testing https://review.opendev.org/c/opendev/zuul-jobs/+/931347 | 22:46 |
| corvus | woo that worked; now to clean it up | 22:51 |
| opendevreview | James E. Blair proposed opendev/zuul-jobs master: WIP: testing https://review.opendev.org/c/opendev/zuul-jobs/+/931347 | 22:55 |
| opendevreview | James E. Blair proposed opendev/zuul-jobs master: Finish upload job https://review.opendev.org/c/opendev/zuul-jobs/+/931355 | 22:58 |
| fungi | that's an exciting commit title | 22:59 |
| clarkb | errand complete reviewing now | 22:59 |
| corvus | those 2 changes are basically identical; the first one is running now but will intentionally fail in gate; the second one is the "real" change which we can review now and approve once we're happy with the behavior of the first one | 23:00 |
| clarkb | corvus: why do we set pass to parent now? | 23:00 |
| clarkb | we shouldn't need it since we're doing the upload in this job right? | 23:01 |
| corvus | clarkb: it's because we're adding the secret in the project-pipeline variant. this is not something we've done before (normally we have separate build and upload jobs) but on a whim i thought it might be interesting to explore this idea. | 23:01 |
| clarkb | oh I see there is a child job variant | 23:02 |
| corvus | (though, if we had separate build/upload jobs, we still might need the same construct) | 23:02 |
| fungi | yeah, i like the "pass a secret if you want to upload" idea, personally | 23:02 |
| clarkb | +2 from me | 23:03 |
| fungi | but i can see how it might seem slightly magic too | 23:03 |
| corvus | i think to avoid pass-to-parent, we would need to make a lower-level job in a config project that does the uploading | 23:03 |
| clarkb | should that job be protected? I think that is the term | 23:04 |
| clarkb | (to keep it from being reused elsewhere?) | 23:04 |
| corvus | (something like "base-upload-image" in opendev/base-jobs that did the upload and had the secret; then have the "image-build-base" job in opendev/zuul-jobs inherit from it) | 23:04 |
| corvus | clarkb: the current thing? nah, it's fine. no one can inherit the project-pipeline variant with the secret | 23:05 |
| corvus | if we did the base-upload-image in opendev/base-jobs we would need to think about that though | 23:05 |
| clarkb | ack also worst case they would just upload stuff | 23:05 |
| clarkb | I don't think they could influce the actual fetch and reupload to the clouds portion | 23:05 |
| fungi | i think worst case they would just build and not upload stuff? | 23:05 |
| fungi | since they can't inherit the creds | 23:06 |
| clarkb | ya I meant if they could inherit the creds they could upload to the container | 23:06 |
| fungi | oh, that, right | 23:06 |
| clarkb | though maybe they could inject an overlapping image or something but ya seems like a non issue | 23:06 |
| corvus | yeah, that's not possible with this construct, but it is with the base job construct. so if we did that, we would probably want to protect it. | 23:06 |
| fungi | "if they could inherit the creds" i think we'd consider that a severe security vulnerability in zuul and fix it right away | 23:07 |
| fungi | oh, with the separate job. yes | 23:07 |
| fungi | but that doesn't exist (currently anyway) | 23:07 |
| fungi | so still not a concern, just worth remembering | 23:08 |
| corvus | https://zuul.opendev.org/t/opendev/build/2d3e3929d688419bb6d62923e3034bbf is exactly the intentional failure we want, and the artifact looks good -- however -- i think we want to change the artifact file name to include the build uuid :) | 23:08 |
| clarkb | ++ to having a uuid there | 23:11 |
| opendevreview | James E. Blair proposed opendev/zuul-jobs master: WIP: test new upload name https://review.opendev.org/c/opendev/zuul-jobs/+/931356 | 23:11 |
| corvus | i did it like "uuid-imagename.qcow2". since these are short-lived, i'm not too worried about needing a directory hierarchy | 23:12 |
| corvus | but happy to change if others have differing preferences | 23:13 |
| clarkb | a timestamp might also be helpful but I think swift can provide that to us if necessary | 23:13 |
| opendevreview | James E. Blair proposed opendev/zuul-jobs master: Finish upload job https://review.opendev.org/c/opendev/zuul-jobs/+/931355 | 23:14 |
| corvus | yeah; at least, the timestamp shows up in the web ui | 23:14 |
| opendevreview | James E. Blair proposed opendev/zuul-jobs master: WIP: testing https://review.opendev.org/c/opendev/zuul-jobs/+/931347 | 23:15 |
| opendevreview | James E. Blair proposed opendev/zuul-jobs master: Finish upload job https://review.opendev.org/c/opendev/zuul-jobs/+/931355 | 23:18 |
| corvus | okay that looks like it worked; clarkb fungi if you want to re-review https://review.opendev.org/931355 with the name change, i think we're done | 23:22 |
| clarkb | lgtm | 23:28 |
| corvus | well, that did not work for some unknown reason (no_log) | 23:56 |
| corvus | the test change took 2 seconds to upload the 10 byte file, but the real change took 30s to fail | 23:58 |
| corvus | that makes me think that there's something about uploading the actual image file that it didn't like. | 23:59 |
| corvus | probably the way to proceed is to get an autohold, then try running that ansible task manually from the node. | 23:59 |
| Clark[m] | ++ sorry I'm switching to dinner mode so not much help now | 23:59 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!