Tuesday, 2020-07-28

*** jamesmcarthur has joined #openstack-infra00:12
*** rlandy|bbl is now known as rlandy00:32
*** Goneri has quit IRC00:39
*** hamalq has quit IRC00:41
*** SpamapS has quit IRC00:44
*** ryohayakawa has joined #openstack-infra00:45
*** portdirect has quit IRC00:51
*** gmann has quit IRC00:51
*** portdirect has joined #openstack-infra00:51
*** gmann has joined #openstack-infra00:51
*** seongsoocho has quit IRC00:52
*** seongsoocho has joined #openstack-infra00:54
*** SpamapS has joined #openstack-infra00:58
*** rfolco has quit IRC00:58
*** ociuhandu has joined #openstack-infra01:01
*** jamesmcarthur has quit IRC01:04
*** ociuhandu has quit IRC01:05
*** tetsuro has joined #openstack-infra01:13
*** ricolin has joined #openstack-infra01:21
*** jamesmcarthur has joined #openstack-infra01:37
*** jamesmcarthur has quit IRC01:48
*** rlandy has quit IRC01:50
*** ramishra has joined #openstack-infra01:53
*** d34dh0r53 has joined #openstack-infra01:55
*** dchen is now known as dchen|away02:04
*** dchen|away is now known as dchen02:27
*** ktsuyuzaki is now known as kota_02:32
*** tetsuro has quit IRC02:45
*** jamesmcarthur has joined #openstack-infra02:51
*** rcernin has quit IRC02:59
*** hongbin has joined #openstack-infra03:00
*** d34dh0r53 has quit IRC03:02
*** rcernin has joined #openstack-infra03:03
*** SpamapS has quit IRC03:06
*** SpamapS has joined #openstack-infra03:09
*** jamesmcarthur has quit IRC03:15
*** SpamapS has quit IRC03:15
*** armax has quit IRC03:33
*** dchen is now known as dchen|away03:42
*** tetsuro has joined #openstack-infra03:51
*** tetsuro has quit IRC04:01
*** tetsuro has joined #openstack-infra04:02
*** tetsuro has quit IRC04:06
*** gyee has quit IRC04:10
*** hongbin has quit IRC04:20
*** vishalmanchanda has joined #openstack-infra04:22
*** ykarel has joined #openstack-infra04:28
*** evrardjp has quit IRC04:33
*** evrardjp has joined #openstack-infra04:33
*** ysandeep|away is now known as ysandeep|rover04:38
*** dchen|away is now known as dchen04:43
*** Lucas_Gray has quit IRC04:49
*** dchen is now known as dchen|away04:57
*** ociuhandu has joined #openstack-infra05:03
*** SpamapS has joined #openstack-infra05:06
*** ociuhandu has quit IRC05:07
*** mtreinish has quit IRC05:08
*** ykarel has quit IRC05:16
*** udesale has joined #openstack-infra05:27
*** ykarel has joined #openstack-infra05:31
*** ykarel is now known as ykarel|mtg05:33
*** ykarel_ has joined #openstack-infra05:36
*** ykarel|mtg has quit IRC05:39
*** dchen|away is now known as dchen05:47
*** lmiccini has joined #openstack-infra05:48
*** mtreinish has joined #openstack-infra05:54
*** lxkong has quit IRC05:55
*** bhagyashris|away is now known as bhagyashris06:01
*** marios has joined #openstack-infra06:03
*** lpetrut has joined #openstack-infra06:04
*** tetsuro has joined #openstack-infra06:06
*** ykarel_ is now known as ykarel06:08
*** tetsuro has quit IRC06:11
*** kevinz has joined #openstack-infra06:28
*** eolivare has joined #openstack-infra06:43
*** slaweq has joined #openstack-infra06:48
*** yolanda has quit IRC06:52
*** yolanda has joined #openstack-infra06:52
*** nightmare_unreal has joined #openstack-infra06:56
*** jcapitao has joined #openstack-infra07:12
*** dklyle has quit IRC07:19
*** dchen is now known as dchen|away07:25
*** andrewbonney has joined #openstack-infra07:29
*** rcernin has quit IRC07:32
*** tosky has joined #openstack-infra07:42
*** ociuhandu has joined #openstack-infra07:52
*** ociuhandu has quit IRC07:52
*** ociuhandu has joined #openstack-infra07:53
*** ralonsoh has joined #openstack-infra07:53
*** jpena|off is now known as jpena07:54
*** dchen|away is now known as dchen07:55
*** lucasagomes has joined #openstack-infra08:06
*** bhagyashris is now known as bhagyashris|lunc08:10
*** ysandeep|rover is now known as ysandeep|lunch08:11
*** xek has joined #openstack-infra08:13
*** hashar has joined #openstack-infra08:25
*** pkopec has joined #openstack-infra08:27
*** dchen is now known as dchen|away08:33
*** derekh has joined #openstack-infra08:41
*** rcernin has joined #openstack-infra08:48
*** priteau has joined #openstack-infra08:49
*** ociuhandu_ has joined #openstack-infra08:53
*** rcernin has quit IRC08:54
*** ociuhandu has quit IRC08:56
*** tetsuro has joined #openstack-infra08:58
*** ysandeep|lunch is now known as ysandeep09:05
*** ricolin has quit IRC09:07
*** ysandeep is now known as ysandeep|rover09:11
*** dtantsur|afk is now known as dtantsur09:12
*** Lucas_Gray has joined #openstack-infra09:14
*** ociuhandu_ has quit IRC09:25
*** ociuhandu has joined #openstack-infra09:31
*** ociuhandu has quit IRC09:31
*** ociuhandu has joined #openstack-infra09:31
*** tetsuro has quit IRC09:32
*** tetsuro has joined #openstack-infra09:40
*** bhagyashris|lunc is now known as bhagyashris09:41
*** tetsuro has quit IRC09:48
*** tetsuro has joined #openstack-infra09:51
*** tetsuro has quit IRC09:53
*** udesale_ has joined #openstack-infra09:58
*** udesale has quit IRC10:01
*** ramishra has quit IRC10:15
*** rcernin has joined #openstack-infra10:19
*** rcernin has quit IRC10:43
*** xek has quit IRC10:49
*** ramishra has joined #openstack-infra10:58
*** dchen|away is now known as dchen11:02
*** jcapitao is now known as jcapitao_lunch11:04
*** bhagyashris is now known as bhagyashris|away11:06
*** lucasagomes has quit IRC11:11
*** lucasagomes has joined #openstack-infra11:12
*** xek has joined #openstack-infra11:24
*** jpena is now known as jpena|lunch11:28
*** bhagyashris|away is now known as bhagyashris11:36
*** lbragstad has quit IRC11:45
*** ricolin has joined #openstack-infra11:47
*** dchen is now known as dchen|away11:50
*** dchen|away is now known as dchen11:50
*** priteau has quit IRC11:55
*** priteau has joined #openstack-infra11:56
*** jcapitao_lunch is now known as jcapitao11:58
*** evrardjp has quit IRC12:00
*** tkajinam has quit IRC12:02
*** rfolco has joined #openstack-infra12:02
*** hashar has quit IRC12:05
*** rlandy has joined #openstack-infra12:10
*** jamesmcarthur has joined #openstack-infra12:16
*** ysandeep|rover is now known as ysandeep|brb12:26
*** ryohayakawa has quit IRC12:26
*** dchen is now known as dchen|away12:29
*** ralonsoh has quit IRC12:34
*** ralonsoh has joined #openstack-infra12:34
*** jpena|lunch is now known as jpena12:34
*** ysandeep|brb is now known as ysandeep|rover12:37
*** xek_ has joined #openstack-infra12:48
*** lbragstad has joined #openstack-infra12:50
*** dchen|away is now known as dchen12:50
*** xek has quit IRC12:51
*** piotrowskim has joined #openstack-infra12:56
*** ociuhandu has quit IRC12:57
*** ociuhandu has joined #openstack-infra12:57
*** rcernin has joined #openstack-infra12:59
*** rcernin has quit IRC13:03
*** dchen is now known as dchen|away13:05
*** dchen|away is now known as dchen13:09
*** dciabrin has quit IRC13:10
*** dciabrin has joined #openstack-infra13:10
*** Goneri has joined #openstack-infra13:13
*** jamesmcarthur has quit IRC13:18
*** zxiiro has joined #openstack-infra13:19
*** Lucas_Gray has quit IRC13:22
*** ramishra has quit IRC13:27
*** Lucas_Gray has joined #openstack-infra13:29
*** dchen is now known as dchen|away13:30
*** dchen|away is now known as dchen13:31
*** ramishra has joined #openstack-infra13:39
*** dchen is now known as dchen|away13:41
*** d34dh0r53 has joined #openstack-infra13:41
*** d34dh0r53 has joined #openstack-infra13:42
*** dchen|away is now known as dchen13:47
*** dciabrin has quit IRC13:48
*** dciabrin has joined #openstack-infra13:49
*** ramishra has quit IRC13:59
*** ramishra has joined #openstack-infra14:00
openstackgerritMonty Taylor proposed zuul/zuul-jobs master: Add a job for publishing a site to netlify  https://review.opendev.org/73904714:04
*** ysandeep|rover is now known as ysandeep|away14:05
*** rlandy is now known as rlandy|training14:07
openstackgerritMonty Taylor proposed zuul/zuul-jobs master: Add a job for publishing a site to netlify  https://review.opendev.org/73904714:09
*** ykarel is now known as ykarel|away14:28
*** hashar has joined #openstack-infra14:28
*** jamesmcarthur has joined #openstack-infra14:30
*** dchen is now known as dchen|away14:33
*** auristor has quit IRC14:34
*** lpetrut has quit IRC14:40
*** auristor has joined #openstack-infra14:41
*** dklyle has joined #openstack-infra14:41
*** armax has joined #openstack-infra14:47
*** auristor has quit IRC15:01
*** jamesmcarthur has quit IRC15:02
*** auristor has joined #openstack-infra15:07
*** ykarel|away has quit IRC15:13
*** auristor has quit IRC15:30
*** udesale_ has quit IRC15:40
*** auristor has joined #openstack-infra15:40
*** marios has quit IRC15:58
*** jcapitao has quit IRC16:04
*** xek_ has quit IRC16:06
*** priteau has quit IRC16:08
*** lmiccini has quit IRC16:09
clarkblogged in docker hub users are not subject to rate limiting16:12
clarkbI expect that authenticating with docker hub and using our mirrors would work but that may affect our ability to cache things?16:13
clarkbthe other aspect to consider is keeping those credentials either safe or sufficiently limited in scope that their exposure in random jobs is a non issue16:14
clarkbweshay|ruck: ^ that may be worth investigating16:14
*** lucasagomes has quit IRC16:18
weshay|rucksec sorry16:26
*** Lucas_Gray has quit IRC16:26
fungiclarkb: yeah, i noticed that as well but wasn't sure how to effectively auth the proxied requests16:29
*** dtantsur is now known as dtantsur|afk16:32
clarkbfungi: I think the protocol requests a token and then supplies that in the requests16:34
clarkbit may be that you need to auth to dockerhub first then use the token with the mirror?16:34
*** rlandy|training is now known as rlandy16:35
clarkbmostly just trying to look at the various options, I haven't tested anything16:39
weshay|ruckclarkb, hrm.. interesting.. zbr FYI ^16:43
*** ociuhandu has quit IRC16:45
*** hashar has quit IRC16:46
*** hamalq has joined #openstack-infra16:46
*** derekh has quit IRC17:00
*** ykarel|away has joined #openstack-infra17:03
*** andrewbonney has quit IRC17:04
*** jpena is now known as jpena|off17:16
*** nightmare_unreal has quit IRC17:33
*** ykarel|away has quit IRC17:41
*** redrobot has quit IRC17:41
*** ralonsoh has quit IRC17:49
*** ociuhandu has joined #openstack-infra17:54
*** ociuhandu has quit IRC17:58
zbrbased on https://docs.docker.com/registry/recipes/mirror/ -- i believe that we need a dual setup, a pull-only mirror and a push-registry for pushes, one that does not use the mirror.18:02
zbrdecoupling pulls from pulls, and we can configure the mirror to use auth, in order to avoid being rate limited18:04
clarkbzbr: we do pushes directly already which is basically the same thing?18:04
clarkbbut also we don't run a proper registry like that because there is no way to prune18:05
fungiyeah, the first half of that suggestion is already done18:18
fungiwe're only talking about read operations here, write operations are completely separate18:19
fungiif we did authenticate the proxy we'd certainly use a different account than the various accounts used for pushing images to various dockerhub namespaces18:19
clarkbwell and I'm suggested we authenticate the client and not change the proxy18:20
clarkbbut yes different accounts for sure18:20
fungiin that case i would be surprised if we could actually cache the downloads18:20
clarkbfungi: we mitm so it should work I think18:20
clarkband we already tell apache to cache even though it shouldn't under its "what is cacheable" rules18:21
fungii guess it depends on whether the request for the file incorporates credentials, and whether that makes it unique in apache mod_proxy's eyes18:22
clarkbI think we'll be ok because it uses headers18:24
clarkband we tell the server that its ok to cache the data anyway18:25
clarkbah we ignore the query string parameters18:25
clarkbnot necessarily headers18:26
*** jamesden_ has joined #openstack-infra18:27
clarkbreading mod_cache docs I think we may be ok because the supplied header is provided by the client and the response either gives you the data or you get a 401 unauthorized18:28
clarkbbut we can also ignore the authentication header with an apache config in case that ends up being used to identify the resources18:30
*** jamesdenton has quit IRC18:30
fungiworth a try, i guess. so projets would encode a dockerhub credential as a zuul secret?18:32
clarkbI think so18:33
clarkbactually this should work becuse iirc you have to do anonymous auth with docker hub already18:34
clarkball we'd be changing is going from a token belonging to anonymous to an actual user18:34
clarkbits possible that the cache may still be scoped by auth token I suppose but I don't think its a consistent token for anonymous either18:37
clarkbpossible that is already an underlying bug in the system if so18:37
*** eolivare has quit IRC18:37
fungijust worried that we're probably hitting this to a great extent because of limited cache space and aggressive expiring leading to frequent cache misses18:44
clarkbthat can be too, but I'm not sure we have much ability to increase disk size. At in some of the clouds we're limited iirc18:44
clarkbwe can possibly make bigger caches in clouds where more cinder quota is available18:44
fungiwell, also htcacheclean speed is limited by i/o bandwidth, so if we make the caches too big we can't prune them as fast as we fill them and the run away from us filling the disk and generating new and even more fun errors18:45
clarkbgood point18:45
clarkboh it will also be proportional to the max-servers count in the clouds since that roughly maps to jobs/time18:49
fungiyep, we hit this issue the most in our largest regions, no surprise there18:50
*** xek_ has joined #openstack-infra18:51
fungiif we had infinite storage and infinitesimal iowait then it would be roughly even across regions, but ultimately there's pressure from new cache additions forcing earlier content out before it expires18:51
fungiand that pressure increases in more active/higher quota regions18:52
clarkbas a sanity check on the dfw mirror the current log file for docker v2 api says 25939 cache hits and 6883 misses18:54
clarkblooking at the log though it seems like the python-requests requests for docker things may not be caching for some reason18:57
clarkbif docker client is used then it will say cache hit vs cache miss etc18:57
fungipython-requests is probably zuul-registry?18:58
fungithat could be worth looking into18:58
clarkbfungi: no its tripleo18:58
fungior skopeo?18:58
fungiahh18:58
clarkbthey've written their own client18:58
clarkband this is why I know about the authentication thing18:59
clarkbit had trouble with that, but if I had to make a hunch here part of the problem is they are bypassing the cache entirely looking at the logs18:59
clarkbI don't understand why though18:59
fungiso basically none of tripleo's requests are actually being served from the cache?18:59
fungithat could explain this recently becoming an issue18:59
clarkbat least on a quick glance any from their python client seem to lack cache hit or miss indications18:59
clarkbfungi: yup that is what I'm thinking now18:59
clarkbbut I need to context switch to the meeting18:59
fungibut now, infra meeting19:00
*** hashar has joined #openstack-infra19:17
*** tosky has quit IRC19:25
*** hashar has quit IRC19:50
openstackgerritIan Wienand proposed openstack/project-config master: Add pyca/project-config  https://review.opendev.org/74314319:54
openstackgerritIan Wienand proposed openstack/project-config master: Add pyca 3rd-party CI tenant  https://review.opendev.org/74314419:54
*** mordred has quit IRC20:05
clarkbweshay|ruck: EmilienM zbr ^ see scrollback but tldr is I think tripleo's python client may be doing something that prevents apache from caching things. And that could lead to more upstream requests and being rate limited. Whereas the docker client does not have these problems based on apache logs20:08
EmilienMmwhahaha: ^ fyi20:08
clarkbI don't know why this is happening and the logs between the two look very similar exept for the user agent strings20:09
clarkbthat maybe points to headers? since they aren't all recorded20:09
EmilienMwe use "podman_image" ansible module to pull / pre-fetch container images20:09
EmilienMbut the tripleo container image prepare step is indeed in pure python on our side20:09
clarkb"python-requests/2.22.0" is the user agent when we don't cache20:10
mwhahahafetching tags/metadata aren't cachable20:10
mwhahahaand have a short life token (5misn)20:10
clarkbthats getting things like /cloudflare/registry-v2/docker/registry/v2/blobs/sha256/99/9984f3dc6de930df9464afc6fed39d9be3c1331ed07f4cd2395ce2eddc0986fc/data20:10
clarkbwhich is not metadata but the actual layer info aiui20:10
mwhahahait's likely having header issues then20:11
mwhahahawe don't specify any no-cache stuff20:11
mwhahahalet me go look in the code20:11
fungiwe also try to ignore no-cache pragma and cache busting stuff where we can20:11
mwhahahawe've been doing this for years now tho20:12
clarkbmwhahaha: sure I'm just reporting what I see in the logs today20:12
fungibut maybe we can improve on that too20:12
clarkb"docker/19.03.12 go/go1.13.10 git-commit/48a66213fe kernel/4.15.0-112-generic os/linux arch/amd64 UpstreamClient(docker-sdk-python/4.2.2)" UA triggers caching just fine20:12
clarkband is used by kolla20:12
clarkbbut the tripleo urls seem to be hit by python-requests and do not trigger caching20:12
mwhahahamaybe we need to add allow caching to our code or something20:14
mwhahahanot certain what the defaults are with python-requests20:14
weshay|ruck0/20:18
*** mordred has joined #openstack-infra20:18
clarkbI'm trying to put what I'm seeing together into a paste20:18
weshay|ruck+2120:20
weshay|ruckor just 120:20
mwhahahawe're not providing a Cache-Control header in our requests, trying to see what ges sent in the docker client20:20
clarkbhttp://paste.openstack.org/show/796392/ I think that shows that the manifest data isn't cached as expected, but then the docker client does manage to use cached data for the layer blobs20:26
mwhahahaso those two things are doing different operations20:28
openstackgerritIan Wienand proposed openstack/project-config master: Add pyca 3rd-party CI tenant  https://review.opendev.org/74314420:28
mwhahahathe layer should be cached, but the other bits are different actions20:28
clarkbI'm not sure I understand. Each section capture multiple operations20:28
clarkbI wanted to compare the ops between clients20:28
mwhahaharight but they aren't doing the same thing we do20:28
mwhahahaso we need to get a tags list, kolla doesn't20:29
clarkbthe last GET in both sequence is basically the same20:29
mwhahahakolla uses specific tags20:29
clarkbI would expect that last GET to be cacheable in both cases20:29
clarkbthat is the bit that isn't working how I expect20:29
mwhahahahow many times is that layer cached20:29
mwhahahaer fetched20:29
clarkbmwhahaha: why does that matter? we should get a cache missed if it is the first request but we don't get that either20:29
mwhahahasize?20:30
mwhahahado have a min size for cache?20:30
*** pkopec has quit IRC20:30
clarkbthe size is minimal for both cases20:30
clarkbthe kolla layer is less than a kb, the tripleo layer about 23 kb20:30
clarkbwe have a max size but its much larger than that20:30
mwhahahathat seems wrong for layer20:31
clarkbI think its not necessarily a complete layer20:31
mwhahahaso their request is a partial request using range20:31
clarkbdocker chunks them up into those blobs20:31
mwhahahathe reason why i asked how many times is c308ad9b6a688a9bb05caccf8055b3e3910e27a51305a1ee19434d5bd3485847 fetched is if that's the first time, it won't be a hit20:32
clarkbmwhahaha: I know that but in that case apache will still log it doesn't have it in the cache20:32
mwhahaharight but that's not a client side ask20:33
mwhahahathe only way tripleoclient could break that is if we set cache-control to not allow caching but we don't20:33
clarkbsomething about that client is causing apache to not even try the cache20:33
clarkbthats not true20:33
clarkbapache has rules for what is cacheable and not20:33
mwhahaha...20:34
clarkb$IP - - [2020-07-28 20:32:46.765] "GET /cloudflare/registry-v2/docker/registry/v2/blobs/sha256/27/27f31552aaaf7d0b8034b3ef6df2425ff0a54e75904366d490054e84722eaef4/data?verify=1595971366-6IJLMBtHINoelVCBx73kEyldqgE%3D HTTP/1.1" 200 806941 cache miss: attempting entity save20:34
clarkb"http://mirror.dfw.rax.opendev.org:8082/v2/kolla/centos-source-masakari-monitors/blobs/sha256:27f31552aaaf7d0b8034b3ef6df2425ff0a54e75904366d490054e84722eaef4" "docker/19.03.12 go/go1.13.10 git-commit/48a66213fe kernel/4.18.0-193.6.3.el8_2.x86_64 os/linux arch/amd64 UpstreamClient(docker-sdk-python/4.2.2)"20:34
clarkbthat is what a miss should look like, but in the tripleo case it doesn't even try20:34
mwhahahathe determination of caching is not a clientside ask in that case20:34
fungirunning an aggressive cache in production in the past, i recall having to custom compile squid to disable some of the cache-busting signals it obeyed20:34
mwhahahaunless you can provide the exact headers/request item that's causing your config to not cache, it's not a client problem20:34
*** Lucas_Gray has joined #openstack-infra20:34
clarkbyes, I understand. But what is cacheable is in part determined by the clients request20:35
mwhahahano it's not20:35
mwhahahait only is if we are specifyign cache related headers20:35
mwhahahaand we're not20:35
mwhahahathat's what i'm saying20:35
mwhahahaunless python-requests disables it by default which i do not believe it does20:35
mwhahahaso as far as our request, we're not specifying any cache control related headers in the client request20:36
mwhahahamy thought is maybe we need to be and that's the problem but i don't see it being set in docker client either20:36
mwhahahaunless go's http request automatically enables it20:36
clarkbwhat I'm trying to say is the the cache control headers are not the only things that apache considers20:36
clarkbI'm trying to find docs on that now20:36
mwhahahaetag/cache-control/etc20:37
clarkbfor example we specifically ignore query strings in the apache config for docker because by default apache would treat all urls with a query string as uncachable20:37
mwhahahayea i know there are multiple but we're not specifying any20:37
mwhahahaso unless you know something about python-requests that i don't, it's unclear to me how this is a client issue20:37
clarkbok I'm just trying to help figure this out20:38
clarkbI don't know for sure it is a client issue but I do know the official client works fine20:38
mwhahahaIf the response contains an "Authorization:" header, it must also contain an "s-maxage", "must-revalidate" or "public" option in the "Cache-Control:" header, or it won't be cached.20:38
clarkbyour special client does not20:38
mwhahahathat's likely that we must specify cache-control20:38
mwhahahabecause docker requests have Authorization20:38
clarkbI'm not trying to blame anyone or any software, I'm just following what the logs tell me20:38
clarkbthe logs tell me that tripleo's python client behaves differently and that likely causes some of the request limiting we see20:39
clarkb(because without caching we'll make more requests)20:39
mwhahahalet me throw in a Cache-Control: public in and see if that addresses it20:39
fungialso our dockerclient read requests mostly aren't authenticated either, eight20:40
fungis/eight/right/ ?20:40
mwhahahaall docker.io requests require auth. they might be doing something upfront20:40
mwhahahawell maybe not all, most20:40
mwhahahaso metadata and layer fetching does20:40
mwhahahabecause cloudflare says nope if your token expires20:40
clarkbyes you have to "authenticate" as an anonymous user even if fetching anonymously20:40
*** vishalmanchanda has quit IRC20:41
clarkbthis is also why I think things would work if we authenticated as a propre user (to avoid the rate limits entirely)20:43
clarkbbut maybe it is sufficient to use morecached data20:43
mwhahahahttps://review.opendev.org/#/c/743629/20:44
mwhahahathat might address it20:44
mwhahahathough that might break something else20:45
*** rlandy is now known as rlandy|brb20:45
mwhahahabut i'll play with it20:45
clarkbI think you may only want to set it on the sha256 addressed entities20:45
clarkbbecause those will never change20:45
clarkb(and if they do we have a sha256 collision and bigger problems)20:45
mwhahaharight maybe just the layer request20:46
*** evrardjp has joined #openstack-infra20:55
*** gyee has joined #openstack-infra21:02
*** rlandy|brb is now known as rlandy21:02
*** lxkong has joined #openstack-infra21:03
*** rlandy has quit IRC21:28
*** smarcet has joined #openstack-infra21:29
*** auristor has quit IRC21:32
*** slaweq has quit IRC21:34
erbarris there a way to pass 3 flat networks in devstack?21:41
*** redrobot has joined #openstack-infra21:43
*** smarcet has left #openstack-infra21:43
*** auristor has joined #openstack-infra21:47
fungierbarr: you might have more luck asking in #openstack-qa where the devstack maintainers hang out21:48
erbarrfungi: cool, thanks!21:49
*** xek_ has quit IRC22:03
gouthamrhello o/ we've a gerrit issue that with a patch in manila that i need help with...22:05
gouthamrhttps://review.opendev.org/742289/ is a backport; and it was accidentally proposed twice (https://review.opendev.org/#/c/742290/1) - I abandoned the latter change and even tried modifying the Change-ID, but zuul is still unable to vote on it - it runs the jobs fine: https://zuul.opendev.org/t/openstack/buildsets?change=74228922:05
*** auristor has quit IRC22:06
*** d34dh0r53 has quit IRC22:09
*** rcernin has joined #openstack-infra22:09
fungii'm surprised gerrit allowed the same change-id to be pushed twice for the same project+branch22:12
fungii didn't even know that was possible22:12
gouthamrfungi: an unfortunate, unhandled race condition perhaps22:15
clarkbI'm guessing you'll need a new change id22:16
*** auristor has joined #openstack-infra22:18
gouthamrclarkb: ack, i can do that and detach the cherry-pick from the parent22:19
*** auristor has quit IRC22:20
*** rcernin has quit IRC22:22
gouthamri created a fresh cherry-pick: https://review.opendev.org/743640; i'll report back in case zuul has issues again22:24
fungithanks, it seems like something i wouldn't have expected gerrit to allow (normally it would either amend the same change with a new patch set or reject the push)22:32
fungiif they were somehow pushed at the same moment then, yeah, maybe there's a race22:32
gouthamryes, they were pushed within seconds of each other, from my IRC logs:22:36
gouthamr[2020-07-21T14:38:31-0700] <openstackgerrit> Tom Barron proposed openstack/manila stable/train: Update LVM volume extend  https://review.opendev.org/74228922:36
gouthamr[2020-07-21T14:38:32-0700] <openstackgerrit> Goutham Pacha Ravi proposed openstack/manila stable/train: Update LVM volume extend  https://review.opendev.org/74229022:36
*** rcernin has joined #openstack-infra22:37
gouthamr1 second to be precise22:37
openstackgerritMerged openstack/project-config master: Add pyca/project-config  https://review.opendev.org/74314322:46
*** rcernin has quit IRC22:50
*** rcernin has joined #openstack-infra22:50
*** tkajinam has joined #openstack-infra22:52
*** dviroel has joined #openstack-infra22:53
clarkbmwhahaha: I'm looking at the mirror and grepping for logs related to this job against your change https://zuul.opendev.org/t/openstack/stream/61aa12e9474840c8969fc8426541fa41?logfile=console.log I don't see the caching happening. So maybe there is more going on. Also another thing I notice is that the same blobs seem to be fetched multiple times by the same host under the same job, that may be23:05
clarkbsomething we can optimize too (iirc the docker client would find it locally and not refetch)23:05
clarkbmight need to tcpdump -A a docker pull vs what your client is doing?23:06
mwhahahaDepends this isn't the same process as a docker pull. Additionally we should have some locking to prevent layers from being fetched excessively23:08
*** zer0c00l has joined #openstack-infra23:10
mwhahahaIf you have layer blobs Isa we can probably coordinate them in the logs23:10
clarkbmwhahaha: 6af36aed3fd9edb878221b7f08c5bcf0b4375fe4f33d179ffaacded52c476fce a blob for centos-binary-memcached appears to have been fetched 5 times by one of the hosts running that job23:10
clarkbI was grepping for 'cache' which matched on the memcached portion of the url23:10
clarkbthere may be others (or not) not sure yet23:10
clarkbI'm trying to actually look at cases for multiple fetches now23:12
zer0c00lThis has been pending for a while https://review.opendev.org/#/c/720832/23:15
zer0c00lAny chance i can get this reviewed?23:15
zer0c00lshould be an easy one.23:15
clarkbmwhahaha: http://paste.openstack.org/show/796396/23:18
openstackgerritMerged openstack/project-config master: Add pyca 3rd-party CI tenant  https://review.opendev.org/74314423:19
clarkbzer0c00l: see my comment I believe a different change fixed it23:21
*** piotrowskim has quit IRC23:22
*** dchen|away is now known as dchen23:34
*** hamalq has quit IRC23:48

Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!