Wednesday, 2022-03-09

*** dviroel|afk is now known as dviroel|out00:46
opendevreviewMerged opendev/system-config master: Correct Apache restart for vexxhost-sjc1 mirror
opendevreviewMerged openstack/project-config master: Remove 'glance' group from project entry
opendevreviewIan Wienand proposed openstack/project-config master: grafana: remove bridge-runtime graphs
*** ykarel is now known as ykarel|mtg05:26
opendevreviewIan Wienand proposed opendev/system-config master: prod-playbook : send playbook runtime/status to graphite
*** ykarel|mtg is now known as ykarel07:01
*** arxcruz|off is now known as arxcruz08:12
*** jpena|off is now known as jpena08:36
*** rlandy|out is now known as rlandy|ruck11:14
*** dviroel|out is now known as dviroel11:19
opendevreviewyatin proposed zuul/zuul-jobs master: [multi-node-bridge] Allow to skip openvswitch installation
*** ykarel is now known as ykarel|away13:32
*** iurygregory_ is now known as iurygregory13:48
*** dviroel is now known as dviroel|lunch15:14
yoctozeptohello! would it be possible to enable private changes in gerrit? to allow for easier sharing and review of security patches15:38
clarkbyoctozepto: no there isn't such a thing15:38
clarkbgerrit doesn't support it15:38
clarkbthe closest thing would be to maintain forks of all the projects under different names that are not replicated or to run a second gerrit15:39
yoctozeptoclarkb: well, I can run git-review with -p but it says private changes have been disabled15:39
clarkbyoctozepto: yes because they aren't actually private15:39
clarkbits a trap15:39
yoctozeptoclarkb: lol15:39
clarkbthey explicitly say do not use this feature for security fixes15:41
clarkbwe have explicitly disabled them because that is exactly what everyone assumes they can do15:41
yoctozeptoclarkb: well, only the last bullet point bothers me - is it affecting us? guessing yes?15:43
yoctozeptothe other bullet points are non-issue to us15:43
fungiwe replicate all references to our git servers15:44
clarkbyes it most definitely affects us15:44
fungishare patches in your defect tracker15:44
clarkbyoctozepto: read above the pitfalls15:44
clarkbthey explicitly say do not do this for the reasons that we shouldn't :)15:45
fungiyoctozepto: the openstack vmt has spent years trying to come up with better solutions which won't add additional administrative overhead for someone, but defect trackers (and only having private discussions about bugs when absolutely necessary) are the best options we have15:46
fungiyoctozepto: privately discussing security bugs should really only be something you do for very, very serious exploitable vulnerabilities, not just a general thing you do for anything which might seem like it could be a security risk15:47
yoctozeptoclarkb, fungi: ack, thanks for the explanations15:48
fungiit's fine to start a discussion about a bug in private if you're unsure, but by the time you get to the point where you're writing fixes it's almost never necessary to keep things private at that point. on the rare occasions where it is, reviewing patches in a defect tracker shouldn't be a massive inconvenience15:49
fungialso if we went out of our way to make private code review easier, people would have a tendency to use it even when not absolutely necessary, and that erodes community trust15:50
fungiyoctozepto: is also a really good read on that subject15:52
fungiand if you need help with a vulnerability report in openstack, it's fine to hit up the vmt members for help too15:54
yoctozeptofungi: thanks, that's an interesting viewpoint16:01
funginote that kurt is a long-time lead vulnerability manager at red hat too16:02
clarkbfwiw I believe upstream gerrit runs a second gerrit with a fork of gerrit to do their security fixes16:02
clarkbthen they push the end results of change sthere to new branches in the canonical repo then merge that branch in16:02
fungiyeah, at one time long ago i was looking at making a second secret gerrit for vulnerability patches, and quickly realized that doubling the gerrit infrastructure for the benefit of 0.00001% of openstack's patches was not a worthwhile cost/benefit ratio16:03
*** dviroel|lunch is now known as dviroel16:42
*** marios is now known as marios|out16:51
fungi#status log Restarted the ptgbot service on eavesdrop since it seems to have not started cleanly when the server was rebooted on 2022-01-2717:12
opendevstatusfungi: finished logging17:12
corvusfungi: clarkb i had a summit committee meeting recently where we tried to use meetpad, and had audio issues similar to those clarkb and i had, but we couldn't resolve them and changed platforms.  it may be worth some more investigation.17:21
clarkbhrm. Ya I guess the difficult thing is trying to determine if the error is on the client or the server. In my case restarting the client fixed it17:23
clarkbI wonder if the browser debug tools have any insight into webrtc17:24
clarkb if we can reproduce it something like this may be the next thing to look at17:26
fungiwhich audio issues did you have?17:30
clarkbfungi: corvus and I started a call and he couldn't hear me.17:30
fungii was able to use it successfully recently for a diversity and inclusion working group meeting17:30
clarkbI theorized at hte time that the issue may be that I had unmuted my mic in pulseaudio after joining the call. I stopped chrome and then started it again so that it would start with the mic unmuted and it worked17:31
clarkbof course that is one small sample point and the issue oculd be elsewhere17:31
fungii've stopped having as many audio issues after i found pavucontrol and have used it to consistently disable all the inputs and outputs i'm not using so that my browser correctly picks the right ones17:31
clarkbya pavucontrol is what I used to unmute my mic. But I had done that after I had joined the call so theorized that maybe the browser didn't know which input to pull from17:32
fungii've noticed that both ff and chrome have gotten really terrible at picking the right devices or giving in-browser apps an adequate view of them17:32
clarkbI think we can do some test calls and if we manage to reproduce have the client side open the webrtc info pages for the browser they are using and see if webrtc is doing useful stuff17:33
clarkband then dig from there17:33
fungidiscovered that whenever my audio cuts out, it's almost always that the browser has decided to route audio to an hdmi connector17:33
fungibut yeah, i agree there are so many possible causes, debugging them further is warranted17:34
*** jpena is now known as jpena|off17:52
*** odyssey4me is now known as Guest171618:49
ianwclarkb: are you ok with, which makes the prod runs send stats again?  instead of deleting the old grafana page, i might try to update it19:58
clarkblet me see19:59
clarkbya I think that is fine20:01
ianwthanks; i did test out that delta split/munging on a local run, but will monitor closely today20:02
ianwi also have a couple of fixes for the dib-build grafana page too20:05
ianwalthough weirdly, one of the stats doesn't seem to get through20:05
ianwi'm wondering if maybe "duration" is a reserved word and you can't have a key named that?20:06
ianwoh doh, i guess it's under 'stats.timers.nodepool.dib_image_build' ...20:13
ianwohhh, interesting ...20:20
ianwthe "Build duration" looks right, but graphite is sending us back an error20:21
ianwgrafana does a POST with20:21
ianwtarget:"alias(keepLastValue(stats.timers.nodepool.dib_image_build.ubuntu-focal.status.duration.mean, 'None'), \"Time\")"20:21
ianwgraphite is actually responding with a python exception :
*** dviroel is now known as dviroel|out21:29
*** artom__ is now known as artom22:49
corvusclarkb: it appears zuul-core is owned by infra-ptl...i think that is an omission -- we probably forgot to make it self-owned after the, erm, graduation or whatever we're calling it... do you agree?23:08
corvus(also zuul-jobs-core)23:09
corvusClark: ^23:13
*** rlandy|ruck is now known as rlandy|ruck|bbl23:26

Generated by 2.17.3 by Marius Gedminas - find it at!