Thursday, 2022-04-28

*** rlandy|bbl is now known as rlandy00:59
*** rlandy is now known as rlandy|out01:00
*** ysandeep|out is now known as ysandeep01:23
*** ysandeep is now known as ysandeep|breakfast03:16
*** ysandeep|breakfast is now known as ysandeep04:19
*** ysandeep is now known as ysandeep|afk06:06
opendevreviewIan Wienand proposed openstack/openstack-zuul-jobs master: Build CentOS 9 RPM packages  https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/83968906:45
*** ysandeep|afk is now known as ysandeep06:48
opendevreviewIan Wienand proposed openstack/openstack-zuul-jobs master: Build CentOS 9 RPM packages  https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/83968906:52
*** jpena|off is now known as jpena06:58
opendevreviewIan Wienand proposed openstack/openstack-zuul-jobs master: Build CentOS 9 RPM packages  https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/83968907:14
*** ysandeep is now known as ysandeep|lunch08:13
*** ysandeep|lunch is now known as ysandeep09:40
*** rlandy|out is now known as rlandy10:25
*** ysandeep is now known as ysandeep|afk10:56
*** dviroel|rover|out is now known as dviroel|rover11:23
opendevreviewMerged openstack/project-config master: Add the cinder-three-par to Openstack charms  https://review.opendev.org/c/openstack/project-config/+/83778211:38
*** ysandeep|afk is now known as ysandeep11:45
*** dasm|off is now known as dasm13:10
*** ysandeep is now known as ysandeep|out14:10
*** jpena is now known as jpena|off14:14
fungigmann: you're clearly confused. we can continue discussing after the tc meeting ends, but neutron-fwaas was not going to be renamed into the x/ namespace. there was an option to fork it but we would not have moved it because that's against the current tc policy15:02
fungi"The solution to this problem is to follow the repository retirement process in openstack any time a deliverable repository is removed from current governance, regardless of whether its authors intend to continue development on it outside governance. OpenDev allows multiple repositories to have the same base names across different namespaces, so this does not mean a project has to15:06
fungichange its new name. It does however mean that the repository must be forked into the new namespace, leaving behind its Gerrit reviews and no redirection (the README file can certainly mention where to find continued development however). This forces existing consumers of the source code to take note of the change in governance, clarifying that no official OpenStack project team is15:06
fungiresponsible for it any longer."15:06
fungihttps://governance.openstack.org/tc/resolutions/20190711-mandatory-repository-retirement.html15:06
*** dviroel|rover is now known as dviroel|rover|lunch16:02
*** dviroel|rover|lunch is now known as dviroel|rover16:41
opendevreviewGage Hugo proposed openstack/project-config master: End project gating for openstack-helm-docs  https://review.opendev.org/c/openstack/project-config/+/83910317:15
opendevreviewGage Hugo proposed openstack/project-config master: Retire openstack-helm-docs repo, step 3.3  https://review.opendev.org/c/openstack/project-config/+/83942717:17
opendevreviewGage Hugo proposed openstack/project-config master: Retire openstack-helm-docs repo, step 3.3  https://review.opendev.org/c/openstack/project-config/+/83942717:20
gmannfungi: ok, my main goal to order that way is we get the governance patch merged first before we mark the project retire in project-config and stop infra for that. 17:21
fungigmann: that was already the case with the gating removal depending on the governance patch17:22
gmannwell it was not clearly documented, we used to do reverse of it always. governance patch depends on gating removal17:23
fungithe effective change is that now we can turn off gating and merge a change to clear out the repository before the tc agrees to retire the project, rather than only after the tc agrees17:23
fungigmann: https://review.opendev.org/837787 is actually very confusing, because step #1 is to remove the deliverable from governance before proceeding with retiring its repository, but now the project-team-guide says step #1 needs to happen after steps 3-5, yet it's still "step #1"17:27
gmannfungi: yes because we know in governance that retirement is happening and if any strong objection then we can review on repo content removal or so. I added a note there the intension of that.17:28
fungiokay, but from a config-core review perspective, since there's no depends-on from the initial retirement changes to the governance removal, we can just merge those changes now, even if the tc hasn't reached agreement that they're a good idea?17:29
gmannconfusing things there is step3-5 is mixed with single ref to opendev link which I can separate out and make it more clear about each step order17:30
fungistep #1 is to remove the deliverable from governance. if the change to remove the deliverable from governance hasn't merged, then that step isn't complete since the deliverable hasn't been removed from governance17:31
fungihas step #1 become to simply propose removal to the governance repository?17:31
gmannfungi: well that is needed because we have a check in governance about proper retirement of repo content. that is why governance patch needs to wait for repo content removal. let me check if we can remove that dependency without loosing the proper-retirement-check17:31
fungiand then other steps can proceed even though the deliverable hasn't been removed yet17:31
fungigmann: oh, so 837787 was driven by the addition of consistency checks in the governance repo? that would have been very useful information to include in the commit message, or at least in a review comment. commit messages are supposed to be about why changes are being made, rather than just listing the changes being made17:33
fungi(hence the request for clarification i left in a comment on it after it merged, as i hadn't seen it before then)17:33
opendevreviewMerged openstack/project-config master: End project gating for openstack-helm-docs  https://review.opendev.org/c/openstack/project-config/+/83910317:39
*** rlandy is now known as rlandy|mtg19:05
*** rlandy|mtg is now known as rlandy19:23
*** dviroel|rover is now known as dviroel|rover|brb20:31
*** dasm is now known as dasm|off20:32
*** rlandy is now known as rlandy|out22:45
timburke_did something change with our node pool recently? i've got a test job that used to pass fairly reliably and take about an hour (and only rarely over 1.25hr), but in the last couple days has reliably timed out after two: https://zuul.opendev.org/t/openstack/builds?job_name=swift-probetests-centos-8-stream&project=openstack%2Fswift&result=SUCCESS&result=FAILURE&result=TIMED_OUT23:01
clarkbwe've not added any new clouds. One cloud went away a ocuple months ago but thats it23:04
clarkbthe images do get updated daily though so it is possible you're seeing a regression in the distro. Or just unlucky with noisy neighbors23:04
timburke_might be something with the distro image... the centos7 equivalent has been fine: https://zuul.opendev.org/t/openstack/builds?job_name=swift-probetests-centos-7&project=openstack%2Fswift&result=SUCCESS&result=FAILURE&result=TIMED_OUT&skip=0&limit=10023:15
timburke_idk *how* a distro could regress like that, though :-/23:16
clarkbtimburke_: anytime there is weird slowness like that I immediately think about swapping23:17
clarkbmaybe double check you aren't swapping?23:17
timburke_host info lists the same ansible_memtotal_mb for an arbitrary (pass, fail) pair, and ansible_swaptotal_mb: 023:23
clarkbtimburke_: that is collected at the beginning of the test job not the end23:25
clarkbdevstack has some profiling data it collects23:25
clarkbif you use devstack there should be a file for that23:25
timburke_not for this one :-/23:29
*** dviroel|rover|brb is now known as dviroel|rover23:52

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