| === E_Eickmeyer is now known as Eickmeyer | ||
| juliank | queues are empty :D | 07:56 |
|---|---|---|
| juliank | I see failures "Could not connect to ftpmaster.internal:80 (91.189.89.100), connection timed out" again, will investigate :/ | 07:57 |
| cjwatson | juliank: see ~is-outage on mattermost | 08:01 |
| cjwatson | you will get that when ftpmaster is actually down ... | 08:01 |
| juliank | cjwatson: oh, well, I can't see that from ~is-outage :D | 08:03 |
| laney | heh, yeah, not going to get very far if ftpmaster.itself is not available | 08:05 |
| laney | juliank: did you see that the error rate dropped off, what's up with that? | 08:09 |
| laney | if you go to 7 days and select arm64 normal/abnormal only | 08:09 |
| juliank | laney: it's an absolute number and we finished the queue | 08:10 |
| laney | I mean it dropped off at like the start of Saturday | 08:11 |
| laney | like something about the later tests didn't cause so many errors | 08:11 |
| laney | maybe when we finished the SRUs? | 08:11 |
| juliank | or less load on the cloud from builders? | 08:12 |
| laney | hmm | 08:13 |
| juliank | typing sever instead of server when typing server delete kind of makes sense | 08:15 |
| laney | juliank: wdyt about the shim bug dann pointed out on devel@, does that seem feasible to you? | 08:50 |
| juliank | laney: I replied to him | 08:52 |
| juliank | laney: maybe in the wrong email | 08:52 |
| juliank | laney: the shim bug is waiting for review | 08:53 |
| juliank | I cannot comment on whether they are related | 08:54 |
| juliank | doesn't _seem_ like it | 08:54 |
| juliank | the shim one is null pointer dereferencing at exit boot services; we crash _after_ that | 08:55 |
| juliank | also we crash in older releases without the broken shim :D | 08:55 |
| juliank | so I could comment after all | 08:55 |
| laney | ah yeah, just saw it after I asked you :D | 09:00 |
| === utkarsh210225 is now known as utkarsh2102 | ||
| laney | sil2100: heya, to deploy your private branch to staging... | 11:32 |
| laney | do we need to get swift users created? | 11:32 |
| laney | shouldn't the X-Auth-Token config be a dict user -> token? | 11:33 |
| laney | sorry, maybe I forgot some details | 11:33 |
| sil2100 | laney: let me get back to you in a few minutes! | 12:20 |
| laney | sil2100: ack, going for lunch now anyway | 12:23 |
| sil2100 | laney: ok, so regarding this: so from the POV of the workers and the ADT infra, the only thing that's should be needed credential-wise is the X-Auth-Token, since that's enough to get access to the results (user not needed here) | 12:25 |
| sil2100 | laney: a separate user might be needed indeed as this is passed for instance via the 'swiftuser' request parameter, to decide which user to add read access to the results | 12:26 |
| sil2100 | laney: that being said, I think we could temporarily just use X-Auth-Token of the staging main swift user | 12:27 |
| sil2100 | laney: it can be a separate user for security, in case the token somehow leaks out or something and such a separate-user token will in theory have much less powers over the whole database | 12:28 |
| utkarsh2102 | sil2100: hello, I am another hints MP whenever you have time? | 12:28 |
| utkarsh2102 | no rush, though. | 12:29 |
| utkarsh2102 | (cf: https://code.launchpad.net/~utkarsh/britney/+git/britney/+merge/404113) | 12:29 |
| utkarsh2102 | ugh, s/I am/I have/g :) | 12:29 |
| sil2100 | utkarsh2102: hey! Reviewed o/ | 12:32 |
| utkarsh2102 | sil2100: awesome, thank you! though I added "all" intentionally because it's gonna be a problem for all architectures, at least until ruby3.0 transition, which is waiting on the Debian archive. | 12:34 |
| utkarsh2102 | I suspect, someone will need to add the hints again for the next versions for s390x. So I just wanted to save the time others might spend because it's going to be unrelated. | 12:35 |
| utkarsh2102 | anyhow, would you still want me to change to specific version instead? I'd be happy to! :) | 12:35 |
| utkarsh2102 | s/all architectures/all versions on s390x/g | 12:38 |
| sil2100 | I'd prefer us bumping it knowingly than risking us forgetting about it and just missing out real failures on this architecture | 12:43 |
| utkarsh2102 | sil2100: gotcha, +1 then, fixed the MP! \o/ | 12:48 |
| sil2100 | Merging! | 12:48 |
| utkarsh2102 | thanks a bunch! :D | 12:48 |
| laney | sil2100: I was trying to make it fit in with what you do in the worker, when uploading a private result - you grant access to the named swiftuser there | 13:46 |
| laney | so we should be using the X-Auth-Token for that user on the reading side I guess | 13:46 |
| laney | we don't need to make one for staging, fair enough, but it does probably need the ability to take multiple users | 13:47 |
| laney | shouldn't be too hard to modify that, I can do it if you want | 13:50 |
| laney | I guess just container -> token should be fine | 13:51 |
| === blue_penquin[m] is now known as Guest7585 | ||
| sil2100 | laney: hm, that can be a good idea I suppose! | 14:13 |
| sil2100 | laney: I mean, right now the X-Auth-Token can be simply the one from the main swift users that the workers use to upload results, as it should have read access to all the containers | 14:14 |
| sil2100 | (as the owner) | 14:14 |
| sil2100 | The swiftuser parameter is more so that the X-Auth-Token from the britney side of ESM or any other users (so outside of the ADT infra) can access it with their own X-Auth-Token | 14:15 |
| * laney nods | 14:17 | |
| -queuebot:#ubuntu-release- Unapproved: lvm2 (groovy-backports/main) [2.03.07-1ubuntu3 => 2.03.11-2ubuntu4~ubuntu20.10.1] (core, i386-whitelist) | 14:21 | |
| === Guest7585 is now known as blue_penquin[m] | ||
| laney | sil2100: crap, I just read that X-Auth-Tokens are valid for 24 hours typically | 14:25 |
| sil2100 | Wait, but you can't set the date? | 14:27 |
| laney | I didn't find something that says you can | 14:27 |
| laney | did you? | 14:27 |
| sil2100 | Since when I created test ones they were only valid for an hour, but it felt like something that's configurable (forgot to check) | 14:27 |
| laney | I just read https://docs.openstack.org/zaqar/queens/user/authentication_tokens.html and it says "Applications should be designed to re-authenticate after receiving a 401 (Unauthorized) response from a service endpoint" | 14:28 |
| -queuebot:#ubuntu-release- Unapproved: sanlock (groovy-backports/universe) [3.6.0-4build1 => 3.8.2-2~ubuntu20.10.1] (i386-whitelist) | 14:28 | |
| sil2100 | Oooookaay | 14:29 |
| laney | hmmmmm | 14:30 |
| sil2100 | "Authentication tokens expire after a time period that the authentication service defines. When a token expires, use of the token causes requests to fail with a 401 Unauthorized response. To continue, you must obtain a new token." | 14:30 |
| sil2100 | eh | 14:30 |
| sil2100 | This was such a good idea, too bad I didn't actually dive into the expliration time last week | 14:31 |
| laney | I didn't notice either /o\ | 14:33 |
| laney | thinking about if there's a way round this | 14:33 |
| -queuebot:#ubuntu-release- Packageset: Removed libclc from i386-whitelist in impish | 14:51 | |
| -queuebot:#ubuntu-release- Packageset: Removed nvidia-graphics-drivers-340 from i386-whitelist in impish | 14:51 | |
| -queuebot:#ubuntu-release- Packageset: Removed nvidia-graphics-drivers-418-server from i386-whitelist in impish | 14:51 | |
| -queuebot:#ubuntu-release- Packageset: Removed nvidia-graphics-drivers-435 from i386-whitelist in impish | 14:51 | |
| -queuebot:#ubuntu-release- Packageset: Removed nvidia-graphics-drivers-tesla-460 from i386-whitelist in impish | 14:51 | |
| -queuebot:#ubuntu-release- Packageset: Added libreoffice to i386-whitelist in impish | 14:51 | |
| sil2100 | I think we just need to switch to the full-credentials approach | 14:51 |
| laney | not very thrilled by that | 14:54 |
| laney | we could probably try to get a read-only user, and grant to 'swiftuser' and that one | 14:55 |
| laney | or the swiftuser can go away in that case maybe | 14:58 |
| * laney is asking IS for input | 14:58 | |
| -queuebot:#ubuntu-release- Unapproved: apt (hirsute-proposed/main) [2.2.3 => 2.2.4ubuntu0.1] (core, i386-whitelist) | 15:06 | |
| -queuebot:#ubuntu-release- Unapproved: python3.8 (focal-proposed/main) [3.8.5-1~20.04.3 => 3.8.10-0ubuntu1~20.04] (i386-whitelist) (sync) | 15:20 | |
| sil2100 | As said, the swiftuser part was just to make sure that the ESM britney instance doesn't have to host like the main ADT SWIFT credentials, since that has all write and read access to everywhere | 15:28 |
| sil2100 | This way the ESM britney has a swiftuser user that has read rights to the given container and is all fine. On the ADT side we can use the main creds as those are there anyway | 15:29 |
| sil2100 | (for the workers) | 15:29 |
| laney | yeah for uploading that's what'll happen | 15:34 |
| -queuebot:#ubuntu-release- Unapproved: gcc-10 (focal-proposed/main) [10.2.0-5ubuntu1~20.04 => 10.3.0-1ubuntu1~20.04] (i386-whitelist) (sync) | 15:35 | |
| -queuebot:#ubuntu-release- Unapproved: gcc-10-cross (focal-proposed/main) [6ubuntu3 => 6ubuntu4] (i386-whitelist) (sync) | 15:36 | |
| -queuebot:#ubuntu-release- Unapproved: gcc-10-cross-ports (focal-proposed/universe) [5ubuntu2 => 5ubuntu3] (i386-whitelist) (sync) | 15:38 | |
| laney | sil2100: have you got a sketch of the proposed-migration side? | 15:40 |
| laney | I'm worried that it'll need access to keystone | 15:40 |
| -queuebot:#ubuntu-release- Unapproved: gcc-10-cross-mipsen (focal-proposed/universe) [2+c1ubuntu1.1 => 2+c1ubuntu1.2] (no packageset) (sync) | 15:47 | |
| sil2100 | laney: you mean sketch of using the whole SWIFT credentials instead of X-Auth-Token? | 15:51 |
| laney | sil2100: yeahhhhhhhhhhhhhh | 15:53 |
| laney | like I don't know how you can pass those from a random external server | 15:53 |
| laney | I wonder if you tried it already and it worked | 15:53 |
| laney | I think maybe you *have* to use the X-Auth-Token there ... | 15:54 |
| laney | hopefully I'm not right 😬 | 15:54 |
| sil2100 | hm, well, so I was using swiftclient and was only testing it against canonistack locally, via VPN | 15:54 |
| sil2100 | And it worked fine with my local config, so I assumed we could do the same if we're on the same network? | 15:54 |
| laney | I think they fw will block access to keystone | 15:55 |
| laney | the* | 15:55 |
| laney | let me check from snakefruit | 15:55 |
| sil2100 | Can't we modify the fw rules in that case? Man, I really liked the idea of X-Auth-Token, I don't feel like getting back to full creds :< | 15:55 |
| laney | huh ok it works from there, whyyyYYYYY | 15:55 |
| sil2100 | laney: as for the branch, I can revert the X-Auth-Token changes and push that to a separate branch for review/test if anything | 15:58 |
| laney | ack | 15:58 |
| laney | you can do a 'git revert' and push it on top if you want | 15:58 |
| laney | we can rebase them both away later on | 15:59 |
| rbalint | sil2100, i'm trying to queue https://bileto.ubuntu.com/#/ticket/4583 , but it seems there is a token error https://bileto.ubuntu.com/static/britney/ust_log_2021-06-14_16:30:01.txt | 16:49 |
| rbalint | sil2100, could you please check it? | 16:49 |
| === plars_ is now known as plars | ||
| sil2100 | Oh no, hmm | 17:50 |
| sil2100 | rbalint: oh, so you want to trigger ust for that silo, yes? | 17:52 |
| -queuebot:#ubuntu-release- Unapproved: accepted gcc-10 [sync] (focal-proposed) [10.3.0-1ubuntu1~20.04] | 19:24 | |
| -queuebot:#ubuntu-release- Unapproved: accepted gcc-10-cross [sync] (focal-proposed) [6ubuntu4] | 19:29 | |
| === sarnold_ is now known as sarnold | ||
| -queuebot:#ubuntu-release- Unapproved: accepted gcc-10-cross-ports [sync] (focal-proposed) [5ubuntu3] | 19:32 | |
| -queuebot:#ubuntu-release- Unapproved: accepted gcc-10-cross-mipsen [sync] (focal-proposed) [2+c1ubuntu1.2] | 19:33 | |
| === mfo_ is now known as mfo | ||
| -queuebot:#ubuntu-release- New binary: acorn [amd64] (impish-proposed/universe) [8.0.5+ds+~cs19.19.27-2] (no packageset) | 23:19 | |
| -queuebot:#ubuntu-release- New binary: libfplus [arm64] (impish-proposed/none) [0.2.13-1] (no packageset) | 23:19 | |
| -queuebot:#ubuntu-release- New binary: libfplus [ppc64el] (impish-proposed/none) [0.2.13-1] (no packageset) | 23:19 | |
| -queuebot:#ubuntu-release- New binary: node-token-types [amd64] (impish-proposed/none) [2.1.1+~cs0.2.0-2] (no packageset) | 23:19 | |
| -queuebot:#ubuntu-release- New binary: ntcard [arm64] (impish-proposed/none) [1.2.2+dfsg-2] (no packageset) | 23:19 | |
| -queuebot:#ubuntu-release- New binary: ntcard [s390x] (impish-proposed/none) [1.2.2+dfsg-2] (no packageset) | 23:19 | |
| -queuebot:#ubuntu-release- New binary: libfplus [amd64] (impish-proposed/none) [0.2.13-1] (no packageset) | 23:19 | |
| -queuebot:#ubuntu-release- New binary: libfplus [s390x] (impish-proposed/none) [0.2.13-1] (no packageset) | 23:19 | |
| -queuebot:#ubuntu-release- New binary: ntcard [ppc64el] (impish-proposed/none) [1.2.2+dfsg-2] (no packageset) | 23:19 | |
| -queuebot:#ubuntu-release- New binary: libfplus [armhf] (impish-proposed/none) [0.2.13-1] (no packageset) | 23:19 | |
| -queuebot:#ubuntu-release- New binary: r-bioc-ballgown [amd64] (impish-proposed/none) [2.22.0+dfsg-2] (no packageset) | 23:20 | |
| -queuebot:#ubuntu-release- New binary: ntcard [amd64] (impish-proposed/none) [1.2.2+dfsg-2] (no packageset) | 23:20 | |
| -queuebot:#ubuntu-release- New binary: r-bioc-ioniser [amd64] (impish-proposed/none) [2.14.0+dfsg-2] (no packageset) | 23:24 | |
| -queuebot:#ubuntu-release- New binary: ogre-1.12 [s390x] (impish-proposed/universe) [1.12.10+dfsg2-1.1] (no packageset) | 23:27 | |
| -queuebot:#ubuntu-release- New binary: ogre-1.12 [amd64] (impish-proposed/universe) [1.12.10+dfsg2-1.1] (no packageset) | 23:30 | |
| -queuebot:#ubuntu-release- New binary: libfplus [riscv64] (impish-proposed/universe) [0.2.13-1] (no packageset) | 23:33 | |
| -queuebot:#ubuntu-release- New binary: ogre-1.12 [ppc64el] (impish-proposed/universe) [1.12.10+dfsg2-1.1] (no packageset) | 23:33 | |
| -queuebot:#ubuntu-release- New binary: ntcard [riscv64] (impish-proposed/universe) [1.2.2+dfsg-2] (no packageset) | 23:33 | |
| -queuebot:#ubuntu-release- New binary: ogre-1.12 [arm64] (impish-proposed/universe) [1.12.10+dfsg2-1.1] (no packageset) | 23:41 | |
| -queuebot:#ubuntu-release- New binary: ogre-1.12 [armhf] (impish-proposed/universe) [1.12.10+dfsg2-1.1] (no packageset) | 23:42 | |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!