Friday, 2020-07-03

slittle1please add me "Scott Little" as a core reviewer for group  starlingx-vault-armada-app-core. I can populate the rest of the core group03:43
*** ykarel|away is now known as ykarel04:49
*** ysandeep|away is now known as ysandeep05:04
*** bhagyashris|afk is now known as bhagyashris05:08
openstackgerritIan Wienand proposed opendev/ master: Add new graphite and grafana servers
openstackgerritIan Wienand proposed opendev/system-config master: Add new graphite and grafana servers
*** hashar has joined #opendev06:17
ianwslittle1: done06:36
*** mnasiadka_ is now known as mnasiadka06:42
ianwi ran out of time to commit the grafana and graphite servers, but they're up and ready (and graphite has storage attached) ... i'll look on monday06:45
ianwhamilton releases in 15 minutes so i have to go :)06:46
*** sorin-mihai has joined #opendev06:49
*** ysandeep is now known as ysandeep|afk07:17
*** fressi has quit IRC07:23
*** fressi has joined #opendev07:23
*** tosky has joined #opendev07:26
fricklerdoes anyone else see the line numbers and lines not matching up in gitea? looking at the marked block goes from the middle of 65 to the middle of 70 for me (using firefox)07:46
*** ysandeep|afk is now known as ysandeep07:56
*** moppy has quit IRC08:01
*** moppy has joined #opendev08:01
*** dtantsur|afk is now known as dtantsur08:11
*** priteau has joined #opendev08:14
yoctozeptodid etherpad upgrade? ;o08:24
*** tosky has quit IRC08:32
hrwyoctozepto: o! nicer font and buttons08:38
priteauNo more squinting to read Etherpad08:42
hrwI will probably make another userscript for it. and use 'Fira Sans'08:44
*** DSpider has joined #opendev08:44
*** hashar has quit IRC08:44
yoctozeptore: openstack project-config is control-plane-minimal element ever used? can't see
*** sshnaidm|afk is now known as sshnaidm|off09:15
*** ysandeep is now known as ysandeep|lunch09:19
*** ryohayakawa has quit IRC09:20
*** tosky has joined #opendev09:21
openstackgerritSorin Sbarnea (zbr) proposed opendev/system-config master: Move CI status table after the big table
*** ysandeep|lunch is now known as ysandeep09:36
*** tkajinam has quit IRC09:46
*** sshnaidm_ has joined #opendev10:47
*** sshnaidm|off has quit IRC10:48
*** priteau has quit IRC11:19
*** bhagyashris is now known as bhagyashris|brb11:30
*** hashar has joined #opendev12:18
*** bhagyashris|brb is now known as bhagyashris12:29
*** marios has joined #opendev13:01
mariosmordred: o/ so wrt 3rd party ci and -2 like we are trying with is no-go since the policy is 3rd party doesn't get that right13:03
mordredmarios: that's right - the reason is that we don't want projects to get stuck when resources from a single provider break13:03
mariosmordred: how about in a 'special' ;) case like this. i.e. we are going to block our own project, i.e. this is defined against the tripleo-ci repo/project definition13:04
mordredwith opendev gate jobs, there's always multiple cloud providers that can provide resources, and all of the jobs and infrastructure are managed in opendev as well, so devs can have an expectation of being able to help fix things that go wrong13:04
mariosmordred: btw, sorry, i don't mean to distract you into a discussion, i thought it was a simpler yes/no answer .. i can bring it up on mailing list for example13:05
mordredthat's just the thing though - it's not "your" project - tripleo is an openstack project, not a red hat project13:05
mariosmordred: yeah ok ack on 16:05 < mordred> that's just the thing though - it's not "your" project - tripleo is an openstack project, not a red hat project13:05
mordredmarios: I mostly wanted to give you deeper context13:05
mariosweshay_ruck: fyi ^^13:05
mariosmordred: thanks for taking the time13:05
* weshay_ruck reads13:06
mordredsure! and I know it can get tricky for sure finding the right balance here13:06
mariosmordred: so really anything we come up with here is no go... i.e. wether with some zuul native way with a pipeline or with an external agent (which i really don't want to do)... we just won't get the permission to -2 as third party13:07
weshay_ruckwhat if we have two clouds? lolz13:07
*** ysandeep is now known as ysandeep|afk13:08
mordredweshay_ruck: heh.13:08
*** ysandeep|afk is now known as ysandeep13:37
pandamordred: would a Code-Review -2 be acceptable instead ?13:39
fungijust to be clear, if that third-party ci goes rogue and leaves a verified -2 or code-review -2 on all your changes, but upstream zuul is still working normally, are core reviewers on the project going to be able to fix and bypass that?13:48
pandafungi: that's when the fun starts.13:48
fungii guess the workaround is that someone has the credentials used by the third-party ci system and can use them to reverse those votes13:49
*** bhagyashris is now known as bhagyashris|afk13:49
zbrofftopic: seeing such interesting changes in python-dev, or ansible. I wonder who will date to propose renaming master branch to main13:50
fungibut from an openstack governance perspective, i expect the worry is that whoever is operating that third-part ci system (vs the community-operated ci system) gains the ability to arbitrarily block changes leading to an unlevel playing field13:51
fungizbr: i believe the idea currently is opendev will follow upstream git's lead on what default branch names should be, but make sure things are engineered so a project can use whatever default branch name it likes13:52
pandafungi: I guess the same cores on the project would have credentials of the third party CI user.13:52
pandafungi: so the difference would be only that instead of a human there's a machine blocking tthe patch13:53
zbrfungi: i wished to have seeing a similar level of common sense on other projects.13:53
fungipanda: potentially. i guess either red hat is okay with non-rh folks having access to the network that ci system relies on? this is really a conversation the openstack tc should be involved in though13:54
fungibasically a question of whether it's okay for a third-party ci system operated by an arbitrary company to block any changes they like from merging in an official openstack deliverable13:55
pandafungi: understood, it's not the method the problem, the keywork here is third-party CI.13:57
fungizbr: well, my take on it is that if people are offended by git's choice of default branch name, they should be using another revision control system (there are plenty more to choose from) and not just working around it by adjusting the default so they don't have to be reminded that they have a fundamental disagreement with the upstream decisions for the revision control system they're using13:57
pandafungi: but it's a fine line. I could run as core a set of jobs from a personal server that trigger automatically on a change on a project, and make the server report with as core reviewer a -2 if the jobs don't pass. Would that be third party CI too ?14:00
zbrmy guess is that some projects will learn about the butterfly effect14:01
fungipanda: it would be a bypass of our expectations for the platform, that humans use code-review votes (which can be removed by other humans with the same permissions in a pinch) while automation uses verified votes (which core reviewers are unable to remove)14:02
clarkbfrickler: yes that rendering issue shows up on my mobile browser. Will check desktop in a bit14:02
fungipanda: also i'm curious, i guess this discussion has come up because rdo's testing is more stable and returns faster results than upstream jobs?14:03
fungii keep seeing messages about how it's offline for days at a time, but without context i'm probably misinterpreting that14:04
clarkbfrickler: the offset seems to start at line 1 too so its the whole file?14:04
pandafungi: it's not a matter of stabilily, the reason is always the same, there are tests that cannot be run in upstream. jobs that require isolated networks to run.14:05
fungipanda: we're also not set up to force changes to wait for a third-party ci system to vote, so your reviewers would be able to approve changes even if it hasn't... what's the difference between expecting them to wait until it votes and expecting them to not approve if it leaves a verified -1?14:07
pandafungi: I would see as a (from a technical perspective) an acceptable trade off. Ad third party is not reliable and official, we are not really bound by the results it reports if it ever reports, but they can still warn the developer against merging the change. A warn that can be bypassed at that point easily if the need arises.14:10
pandalike a weak CI vote ?14:11
pandafungi: I guess developer could always merge and approve without waiting, that they would need a core reviewer as accomplice, and also be determined to ignore all the result the third party provides.14:12
*** ysandeep is now known as ysandeep|away14:12
mnaserpanda: i think in this case, the onus is on the cores to make sure all third parties have successsfully reported before merging14:12
mnaserit'd be a little unfair for patch affecting Y component to sit and wait for X component third party ci14:13
pandamnaser: that would not be enforced at tha point, the vote could be bypassed anyway. I'd wonder how many changes are merged in such an hurry that cores would approve before all the third party jobs have run.14:16
mnaserpanda: that's a people problem which i don't think a technical problem is the solution for14:17
mnasertechnical solution is the solution*14:17
pandamnaser: well, even if it's technically possible, a "please don't do that" from the person involved, would be enough for me not to proceed. But I'd like to understand the reasons behind the decision. I think I partially understand, but would also be willing to bend things a little to give the third party a bit more power on the destiny of the patch.14:21
mnaserpanda: if you're doing 3pci, you are going to 99% most likely report faster than zuul's first-party ci because you have a smaller queue14:23
mnaserif you're reporting _slower_ than the first party ci, and devs are merging code _so quickly_ that an hour or two is not enough for you to report14:24
mnaserit might slow down the project a lot14:24
pandamnaser: not in this case ... those jobs are really heavy and may take even 3 hours. But the results are needed anyway, because the give necessary coverage.14:25
mnaseri'd be surprised if anything inside openstack merged in under 3 hours :)14:25
mnaserand if it does, it probably is trivial enough that 3pci doesn't matter that much14:25
pandamnaser: merging without those results is a risk in any case, and would be considere bad practice. But that's the problem since we have no way to block patches, it's just a practice and it's difficult to enfoce.14:26
mnaserpanda: if you have any projects that are merging code which breaks your stable 3pci, please reach out and i'll gladly talk to the projects with my tc hat on14:26
pandamnaser: we are breaking ourselves mostly :)14:29
fricklerclarkb: yes, that was just the random sample I was looking at where I noticed this. not sure too whether it started with the latest update or might be older14:36
mnaserpanda: don't do that :D14:37
pandamnaser: are you saying that with your tc hat on ??14:38
mnaserpanda: :D14:38
fungipanda: what i was trying to say is, while it might be possible for a third-party ci to block a patch from entering the gate pipeline, it's not really going to be feasible to have zuul prevent enqueuing if that third party ci hasn't voted, so reliance on core reviewers to wait for it to report before approving is the same as reliance on core reviewers to not approve a change if there's a negative vote from it15:03
fungi(or if the vote from it is weeks/months stale and it may no longer pass but you wouldn't know)15:03
*** markmcclain has quit IRC15:06
*** markmcclain has joined #opendev15:08
*** sshnaidm_ is now known as sshnaidm|off15:11
*** ykarel is now known as ykarel\away15:19
*** ykarel\away is now known as ykarel|away15:20
*** dtantsur is now known as dtantsur|afk15:20
*** cloudnull0 has joined #opendev15:23
*** weshay_ has joined #opendev15:24
*** weshay_ruck has quit IRC15:25
*** cloudnull has quit IRC15:25
*** cloudnull0 is now known as cloudnull15:25
*** fressi has quit IRC15:30
*** hashar has quit IRC15:47
*** marios has quit IRC15:51
fungii expect most people aren't around (i'm not!) but setuptools 48 was just released, and now subsumes distutils from stdlib, so expect all sorts of new hard to diagnose breakage. let the fun begin!16:35
clarkbI am around fwiw, but distracted by hamilton16:36
fungithe broadway show?16:36
fungii never went16:36
clarkbyup, they filmed it in 2016 before the original cast stopped doing the show and it premiered on disney+ today16:37
fungianyway, the distutils maintainers mention in their release announcement that they expect setuptools 48 is probably "really unstable" (and so say that's why they made it a major version bump)16:37
fungibecause obviously nobody just uses whatever the latest setuptools version is, you know, they look at the version numbers and decide when to upgrade16:37
AJaegerOh fun ;(16:41
fricklerdoes this change the pip install path? devstack fails with "/usr/local/bin/keystone-manage: No such file or directory" now
clarkbfrickler: oh it might because that behavior relies on a thing that debuntu do to override python path stuff and maybe new setuptools ignores that?17:14
* frickler resigns and flees into the weekend, not yet another major breakage *sigh*17:20
clarkbfrickler: enjoy the weekend, fixing this can weait17:20
fricklerthx, safe fireworks to anyone affected17:21
*** weshay_ is now known as weshay_ruck17:39
openstackgerritSean McGinnis proposed zuul/zuul-jobs master: Install venv for all platforms in ensure-pip
openstackgerritSean McGinnis proposed openstack/project-config master: update-constraints: Install pip for all versions
openstackgerritSean McGinnis proposed zuul/zuul-jobs master: Install venv for all platforms in ensure-pip
openstackgerritSean McGinnis proposed openstack/project-config master: update-constraints: Install pip for all versions
*** sorin-mihai has quit IRC18:15
openstackgerritSean McGinnis proposed openstack/project-config master: update-constraints: Install pip for all versions
*** lseki has joined #opendev18:39
*** hashar has joined #opendev20:26
openstackgerritRafael Folco proposed openstack/diskimage-builder master: Enable py3 on dib release 7
*** piequi has joined #opendev21:18
piequiI have some difficulties running 'tox -e linters' to validate a change; I get the error : cannot import name 'AnsibleCollectionLoader' from 'ansible.utils.collection_loader' (/home/marc-antoine/workspace/ansible-collections-openstack/.tox/linters/lib/python3.8/site-packages/ansible/utils/collection_loader/
mordredpiequi: that's weird, that should Just Work. You might want to try asking in #openstack-ansible-sig21:39
mordredpiequi: but I'm not at a laptop right now so can't check21:40
openstackgerritGhanshyam Mann proposed openstack/project-config master: Rename transparency-policy from openstack/ to osf/ namespace
mordredpiequi: I have reproduced this issue locally - so I agree with you. I'm going to guess something changed upstream21:54
mordredsshnaidm|bbl: ^^21:55
mordredsshnaidm_: ^^21:55
*** hashar has quit IRC22:14
mordredpiequi: fixes it for me locally - but like I said, I'm not really here, so I haven't thought through whether that's the _right_ fix22:32
*** tosky has quit IRC22:50
*** factor has joined #opendev22:51
piequimordred: thanks ! I'll have a look to the fix23:51
*** piequi has quit IRC23:51

Generated by 2.17.2 by Marius Gedminas - find it at!