| slittle1 | please add me "Scott Little" as a core reviewer for group starlingx-vault-armada-app-core. I can populate the rest of the core group | 03:43 |
|---|---|---|
| *** ykarel|away is now known as ykarel | 04:49 | |
| *** ysandeep|away is now known as ysandeep | 05:04 | |
| *** bhagyashris|afk is now known as bhagyashris | 05:08 | |
| openstackgerrit | Ian Wienand proposed opendev/zone-opendev.org master: Add new graphite and grafana servers https://review.opendev.org/739162 | 05:37 |
| openstackgerrit | Ian Wienand proposed opendev/system-config master: Add new graphite and grafana servers https://review.opendev.org/739163 | 05:38 |
| *** hashar has joined #opendev | 06:17 | |
| ianw | slittle1: done | 06:36 |
| *** mnasiadka_ is now known as mnasiadka | 06:42 | |
| ianw | i 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 monday | 06:45 |
| ianw | hamilton releases in 15 minutes so i have to go :) | 06:46 |
| *** sorin-mihai has joined #opendev | 06:49 | |
| *** ysandeep is now known as ysandeep|afk | 07:17 | |
| *** fressi has quit IRC | 07:23 | |
| *** fressi has joined #opendev | 07:23 | |
| *** tosky has joined #opendev | 07:26 | |
| frickler | does anyone else see the line numbers and lines not matching up in gitea? looking at https://opendev.org/openstack/neutron-tempest-plugin/src/branch/master/zuul.d/base.yaml#L65-L69 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 ysandeep | 07:56 | |
| *** moppy has quit IRC | 08:01 | |
| *** moppy has joined #opendev | 08:01 | |
| *** dtantsur|afk is now known as dtantsur | 08:11 | |
| *** priteau has joined #opendev | 08:14 | |
| yoctozepto | morning | 08:24 |
| yoctozepto | did etherpad upgrade? ;o | 08:24 |
| *** tosky has quit IRC | 08:32 | |
| hrw | yoctozepto: o! nicer font and buttons | 08:38 |
| priteau | No more squinting to read Etherpad | 08:42 |
| hrw | I will probably make another userscript for it. and use 'Fira Sans' | 08:44 |
| *** DSpider has joined #opendev | 08:44 | |
| *** hashar has quit IRC | 08:44 | |
| yoctozepto | re: openstack project-config is control-plane-minimal element ever used? can't see http://codesearch.openstack.org/?q=control-plane-minimal&i=nope&files=&repos= | 09:07 |
| *** sshnaidm|afk is now known as sshnaidm|off | 09:15 | |
| *** ysandeep is now known as ysandeep|lunch | 09:19 | |
| *** ryohayakawa has quit IRC | 09:20 | |
| *** tosky has joined #opendev | 09:21 | |
| openstackgerrit | Sorin Sbarnea (zbr) proposed opendev/system-config master: Move CI status table after the big table https://review.opendev.org/739191 | 09:35 |
| *** ysandeep|lunch is now known as ysandeep | 09:36 | |
| *** tkajinam has quit IRC | 09:46 | |
| *** sshnaidm_ has joined #opendev | 10:47 | |
| *** sshnaidm|off has quit IRC | 10:48 | |
| *** priteau has quit IRC | 11:19 | |
| *** bhagyashris is now known as bhagyashris|brb | 11:30 | |
| *** hashar has joined #opendev | 12:18 | |
| *** bhagyashris|brb is now known as bhagyashris | 12:29 | |
| *** marios has joined #opendev | 13:01 | |
| marios | mordred: o/ so wrt 3rd party ci and -2 like we are trying with https://review.rdoproject.org/r/#/c/28307/ is no-go since the policy is 3rd party doesn't get that right | 13:03 |
| mordred | marios: that's right - the reason is that we don't want projects to get stuck when resources from a single provider break | 13:03 |
| marios | mordred: 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 definition | 13:04 |
| mordred | with 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 wrong | 13:04 |
| marios | mordred: 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 example | 13:05 |
| mordred | that's just the thing though - it's not "your" project - tripleo is an openstack project, not a red hat project | 13:05 |
| marios | mordred: 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 project | 13:05 |
| mordred | marios: I mostly wanted to give you deeper context | 13:05 |
| marios | weshay_ruck: fyi ^^ | 13:05 |
| marios | mordred: thanks for taking the time | 13:05 |
| * weshay_ruck reads | 13:06 | |
| mordred | sure! and I know it can get tricky for sure finding the right balance here | 13:06 |
| marios | mordred: 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 party | 13:07 |
| weshay_ruck | what if we have two clouds? lolz | 13:07 |
| *** ysandeep is now known as ysandeep|afk | 13:08 | |
| mordred | weshay_ruck: heh. | 13:08 |
| *** ysandeep|afk is now known as ysandeep | 13:37 | |
| panda | mordred: would a Code-Review -2 be acceptable instead ? | 13:39 |
| fungi | just 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 |
| panda | fungi: that's when the fun starts. | 13:48 |
| fungi | i guess the workaround is that someone has the credentials used by the third-party ci system and can use them to reverse those votes | 13:49 |
| *** bhagyashris is now known as bhagyashris|afk | 13:49 | |
| zbr | offtopic: seeing such interesting changes in python-dev, or ansible. I wonder who will date to propose renaming master branch to main | 13:50 |
| fungi | but 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 field | 13:51 |
| fungi | zbr: 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 likes | 13:52 |
| panda | fungi: I guess the same cores on the project would have credentials of the third party CI user. | 13:52 |
| panda | fungi: so the difference would be only that instead of a human there's a machine blocking tthe patch | 13:53 |
| zbr | fungi: i wished to have seeing a similar level of common sense on other projects. | 13:53 |
| fungi | panda: 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 though | 13:54 |
| fungi | basically 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 deliverable | 13:55 |
| panda | fungi: understood, it's not the method the problem, the keywork here is third-party CI. | 13:57 |
| fungi | zbr: 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 using | 13:57 |
| panda | fungi: 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 |
| zbr | my guess is that some projects will learn about the butterfly effect | 14:01 |
| fungi | panda: 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 |
| clarkb | frickler: yes that rendering issue shows up on my mobile browser. Will check desktop in a bit | 14:02 |
| fungi | panda: 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 |
| fungi | i keep seeing messages about how it's offline for days at a time, but without context i'm probably misinterpreting that | 14:04 |
| clarkb | frickler: the offset seems to start at line 1 too so its the whole file? | 14:04 |
| panda | fungi: 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 |
| fungi | panda: 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 |
| panda | fungi: 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 |
| panda | like a weak CI vote ? | 14:11 |
| panda | fungi: 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|away | 14:12 | |
| mnaser | panda: i think in this case, the onus is on the cores to make sure all third parties have successsfully reported before merging | 14:12 |
| mnaser | it'd be a little unfair for patch affecting Y component to sit and wait for X component third party ci | 14:13 |
| panda | mnaser: 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 |
| mnaser | panda: that's a people problem which i don't think a technical problem is the solution for | 14:17 |
| mnaser | technical solution is the solution* | 14:17 |
| panda | mnaser: 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 |
| mnaser | panda: 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 queue | 14:23 |
| mnaser | if 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 report | 14:24 |
| mnaser | it might slow down the project a lot | 14:24 |
| panda | mnaser: 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 |
| mnaser | i'd be surprised if anything inside openstack merged in under 3 hours :) | 14:25 |
| mnaser | and if it does, it probably is trivial enough that 3pci doesn't matter that much | 14:25 |
| panda | mnaser: 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 |
| mnaser | panda: 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 on | 14:26 |
| panda | mnaser: we are breaking ourselves mostly :) | 14:29 |
| frickler | clarkb: 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 older | 14:36 |
| mnaser | panda: don't do that :D | 14:37 |
| panda | mnaser: are you saying that with your tc hat on ?? | 14:38 |
| mnaser | panda: :D | 14:38 |
| fungi | panda: 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 it | 15: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 IRC | 15:06 | |
| *** markmcclain has joined #opendev | 15:08 | |
| *** sshnaidm_ is now known as sshnaidm|off | 15:11 | |
| *** ykarel is now known as ykarel\away | 15:19 | |
| *** ykarel\away is now known as ykarel|away | 15:20 | |
| *** dtantsur is now known as dtantsur|afk | 15:20 | |
| *** cloudnull0 has joined #opendev | 15:23 | |
| *** weshay_ has joined #opendev | 15:24 | |
| *** weshay_ruck has quit IRC | 15:25 | |
| *** cloudnull has quit IRC | 15:25 | |
| *** cloudnull0 is now known as cloudnull | 15:25 | |
| *** fressi has quit IRC | 15:30 | |
| *** hashar has quit IRC | 15:47 | |
| *** marios has quit IRC | 15:51 | |
| fungi | i 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 |
| clarkb | exciting | 16:35 |
| clarkb | I am around fwiw, but distracted by hamilton | 16:36 |
| fungi | the broadway show? | 16:36 |
| fungi | i never went | 16:36 |
| clarkb | yup, they filmed it in 2016 before the original cast stopped doing the show and it premiered on disney+ today | 16:37 |
| fungi | anyway, 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 |
| fungi | because obviously nobody just uses whatever the latest setuptools version is, you know, they look at the version numbers and decide when to upgrade | 16:37 |
| AJaeger | Oh fun ;( | 16:41 |
| frickler | does this change the pip install path? devstack fails with "/usr/local/bin/keystone-manage: No such file or directory" now https://zuul.opendev.org/t/openstack/build/55e53d1c37194d8992f79a4090da86ee | 17:13 |
| clarkb | frickler: 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 | https://zuul.opendev.org/t/openstack/build/55e53d1c37194d8992f79a4090da86ee/log/job-output.txt#3700 | 17:18 |
| * frickler resigns and flees into the weekend, not yet another major breakage *sigh* | 17:20 | |
| clarkb | frickler: enjoy the weekend, fixing this can weait | 17:20 |
| frickler | thx, safe fireworks to anyone affected | 17:21 |
| *** weshay_ is now known as weshay_ruck | 17:39 | |
| openstackgerrit | Sean McGinnis proposed zuul/zuul-jobs master: Install venv for all platforms in ensure-pip https://review.opendev.org/739272 | 18:11 |
| openstackgerrit | Sean McGinnis proposed openstack/project-config master: update-constraints: Install pip for all versions https://review.opendev.org/738926 | 18:11 |
| openstackgerrit | Sean McGinnis proposed zuul/zuul-jobs master: Install venv for all platforms in ensure-pip https://review.opendev.org/739272 | 18:13 |
| openstackgerrit | Sean McGinnis proposed openstack/project-config master: update-constraints: Install pip for all versions https://review.opendev.org/738926 | 18:13 |
| *** sorin-mihai has quit IRC | 18:15 | |
| openstackgerrit | Sean McGinnis proposed openstack/project-config master: update-constraints: Install pip for all versions https://review.opendev.org/738926 | 18:35 |
| *** lseki has joined #opendev | 18:39 | |
| *** hashar has joined #opendev | 20:26 | |
| openstackgerrit | Rafael Folco proposed openstack/diskimage-builder master: Enable py3 on dib release 7 https://review.opendev.org/736421 | 20:53 |
| *** piequi has joined #opendev | 21:18 | |
| piequi | I 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/__init__.py) | 21:27 |
| mordred | piequi: that's weird, that should Just Work. You might want to try asking in #openstack-ansible-sig | 21:39 |
| mordred | piequi: but I'm not at a laptop right now so can't check | 21:40 |
| openstackgerrit | Ghanshyam Mann proposed openstack/project-config master: Rename transparency-policy from openstack/ to osf/ namespace https://review.opendev.org/739286 | 21:44 |
| mordred | piequi: I have reproduced this issue locally - so I agree with you. I'm going to guess something changed upstream | 21:54 |
| mordred | sshnaidm|bbl: ^^ | 21:55 |
| mordred | gah | 21:55 |
| mordred | sshnaidm_: ^^ | 21:55 |
| *** hashar has quit IRC | 22:14 | |
| mordred | piequi: https://review.opendev.org/739287 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_ fix | 22:32 |
| *** tosky has quit IRC | 22:50 | |
| *** factor has joined #opendev | 22:51 | |
| piequi | mordred: thanks ! I'll have a look to the fix | 23:51 |
| *** piequi has quit IRC | 23:51 | |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!