| *** fungi has quit IRC | 01:18 | |
| *** odyssey4me has quit IRC | 01:19 | |
| *** dtruong has quit IRC | 01:19 | |
| *** dtantsur|afk has quit IRC | 01:19 | |
| *** fungi has joined #openstack-requirements | 01:19 | |
| *** odyssey4me has joined #openstack-requirements | 01:20 | |
| *** dtantsur has joined #openstack-requirements | 01:22 | |
| *** hongbin has joined #openstack-requirements | 01:48 | |
| *** andreykurilin has quit IRC | 01:49 | |
| *** zigo has quit IRC | 01:49 | |
| *** spsurya has quit IRC | 01:49 | |
| *** rm_work has quit IRC | 01:49 | |
| *** andreykurilin has joined #openstack-requirements | 01:49 | |
| *** rm_work has joined #openstack-requirements | 01:55 | |
| openstackgerrit | Merged openstack/requirements stable/ocata: remove documentation job from in-tree config https://review.openstack.org/597161 | 01:58 |
|---|---|---|
| *** openstack has joined #openstack-requirements | 02:51 | |
| *** ChanServ sets mode: +o openstack | 02:52 | |
| *** dtroyer has joined #openstack-requirements | 02:57 | |
| *** jhesketh has joined #openstack-requirements | 02:57 | |
| *** openstackstatus has joined #openstack-requirements | 03:01 | |
| *** ChanServ sets mode: +v openstackstatus | 03:01 | |
| *** hongbin has quit IRC | 03:51 | |
| *** spsurya has joined #openstack-requirements | 03:53 | |
| *** udesale has joined #openstack-requirements | 03:59 | |
| *** Nishant_ has joined #openstack-requirements | 04:48 | |
| *** dtruong has joined #openstack-requirements | 05:09 | |
| *** Nishant_ has quit IRC | 05:21 | |
| *** Nishant_ has joined #openstack-requirements | 05:22 | |
| *** cjloader has joined #openstack-requirements | 05:40 | |
| *** Nishant_ has quit IRC | 05:57 | |
| *** ccamacho has joined #openstack-requirements | 06:03 | |
| *** udesale has quit IRC | 06:07 | |
| *** Nishant_ has joined #openstack-requirements | 06:40 | |
| *** Nishant_ has quit IRC | 06:46 | |
| *** Nishant_ has joined #openstack-requirements | 06:47 | |
| *** udesale has joined #openstack-requirements | 06:55 | |
| *** r-mibu has joined #openstack-requirements | 07:14 | |
| *** Nishant_ has quit IRC | 07:24 | |
| *** Nishant_ has joined #openstack-requirements | 07:25 | |
| *** udesale has quit IRC | 07:31 | |
| *** jpich has joined #openstack-requirements | 07:37 | |
| *** zigo has joined #openstack-requirements | 07:56 | |
| *** ccamacho has quit IRC | 08:13 | |
| *** ccamacho has joined #openstack-requirements | 08:14 | |
| *** ccamacho has quit IRC | 08:55 | |
| *** ccamacho has joined #openstack-requirements | 08:56 | |
| openstackgerrit | Daniel Alvarez proposed openstack/requirements stable/queens: Bump ovsbdapp to 0.12.0 in Queens https://review.openstack.org/597431 | 09:12 |
| *** Nishant_ has quit IRC | 09:50 | |
| *** udesale has joined #openstack-requirements | 09:52 | |
| *** snapiri has joined #openstack-requirements | 11:01 | |
| *** udesale has quit IRC | 11:04 | |
| *** r-mibu has quit IRC | 11:16 | |
| dhellmann | prometheanfire , tonyb , dirk : the flakey nature of requirements-integration concerns me a bit. have any of you had time to look into what is causing that? | 11:27 |
| dirk | dhellmann: not yet | 11:28 |
| dhellmann | "error: can't copy 'etc/rootwrap.conf': doesn't exist or not a regular file" | 11:29 |
| dirk | http://logs.openstack.org/69/595269/3/check/requirements-integration/90bfe8f/job-output.txt.gz#_2018-08-29_01_41_06_066036 | 11:29 |
| dirk | is it really flakey? | 11:29 |
| dhellmann | it looks like a problem installing glance? | 11:29 |
| dirk | looks like a total problem | 11:29 |
| dirk | totally reproducible problem | 11:29 |
| dhellmann | yeah | 11:29 |
| dirk | un a related note I'm currently trying to understand why the opensuse-devstack jobs broke | 11:29 |
| dirk | I am not sure if its related but it happened at the same time | 11:30 |
| dhellmann | https://review.openstack.org/597451 should fix the requirements gate | 11:34 |
| openstackgerrit | Doug Hellmann proposed openstack/requirements master: Blacklist pysaml2 4.6.0 https://review.openstack.org/597179 | 11:35 |
| *** snapiri has quit IRC | 11:35 | |
| openstackgerrit | Doug Hellmann proposed openstack/requirements master: Blacklist pysaml2 4.6.0 https://review.openstack.org/597179 | 12:03 |
| *** ccamacho has quit IRC | 12:07 | |
| *** ccamacho has joined #openstack-requirements | 12:09 | |
| *** udesale has joined #openstack-requirements | 12:14 | |
| *** udesale has quit IRC | 12:16 | |
| *** udesale has joined #openstack-requirements | 12:19 | |
| *** udesale has quit IRC | 12:19 | |
| *** udesale has joined #openstack-requirements | 12:28 | |
| *** udesale has quit IRC | 12:28 | |
| *** udesale has joined #openstack-requirements | 12:31 | |
| *** jpich has quit IRC | 12:36 | |
| openstackgerrit | Doug Hellmann proposed openstack/requirements master: remove documentation job from in-tree config https://review.openstack.org/597160 | 12:41 |
| *** ccamacho has quit IRC | 12:58 | |
| *** ccamacho has joined #openstack-requirements | 12:59 | |
| *** dtantsur is now known as dtantsur|bbl | 13:04 | |
| *** snapiri has joined #openstack-requirements | 13:08 | |
| *** lbragstad has quit IRC | 13:56 | |
| *** dtantsur|bbl is now known as dtantsur | 13:58 | |
| *** lbragstad has joined #openstack-requirements | 14:06 | |
| prometheanfire | dhellmann: thanks | 14:56 |
| * prometheanfire is waiting for gertty to sync | 14:56 | |
| *** fnordahl has joined #openstack-requirements | 15:45 | |
| *** jpich has joined #openstack-requirements | 15:59 | |
| *** udesale has quit IRC | 16:16 | |
| *** jpich has quit IRC | 16:32 | |
| *** dtantsur is now known as dtantsur|afk | 16:54 | |
| *** ccamacho has quit IRC | 16:54 | |
| *** snapiri has quit IRC | 17:05 | |
| prometheanfire | dhellmann: I don't think anything changed for the check-reqs job needing to be defined, but http://logs.openstack.org/19/597019/1/check/requirements-tox-validate-projects/f109319/job-output.txt.gz#_2018-08-28_08_45_50_893556 | 18:09 |
| dhellmann | prometheanfire : do we still need that job? | 18:13 |
| prometheanfire | dhellmann: isn't that the job that helps ensure they are actually keeping things loosely in sync (not introducing new reqs and stuff)? | 18:14 |
| dhellmann | that job was enforcing the bi-directional gating, right? but we don't sync into repos any more, so do we need to enforce that rule? | 18:15 |
| prometheanfire | the reason it was in project-config is because we couldn't trust projects not to remove it 'temporarily' | 18:15 |
| dhellmann | the requirements-check job is the one that ensures they are following the rules, but the job that is failing only ensures that the ones listed in that file have that job | 18:15 |
| dhellmann | so you want to put it back into project-config? | 18:15 |
| prometheanfire | check-requirements vs requirements-check | 18:16 |
| prometheanfire | not confusing at all | 18:16 |
| dhellmann | yeah | 18:16 |
| prometheanfire | following the rules, which rules? | 18:16 |
| dhellmann | how does requirements-tox-validate-projects block a project from removing the check job? | 18:17 |
| dhellmann | s/following the rules/managing requirements the way we want/ | 18:17 |
| prometheanfire | I think having a standard format for the reqs file is still valuable | 18:17 |
| dhellmann | I agree. I don't think requirements-tox-validate-projects enforces that in any way, though. | 18:18 |
| dhellmann | the gate for openstack/ceilometer-powervm is not "blocked" right now, is it? | 18:18 |
| dhellmann | only the requirements repo gate is blocked | 18:18 |
| prometheanfire | requirements-tox-validate-projects makes sure projects have the requirements-check job | 18:18 |
| dhellmann | it tells us when they don't, but it doesn't require them to do it | 18:18 |
| dhellmann | because it does not run in their gate | 18:18 |
| prometheanfire | I want to say that it used to | 18:19 |
| dhellmann | the requirements-check job is the only thing that runs in their gate | 18:19 |
| prometheanfire | it runs playbooks/files/project-requirements-change.py I think | 18:20 |
| prometheanfire | it ensures they don't add random libs that reqs doesn't track (as one of the things) | 18:22 |
| dhellmann | I think we're talking about different things | 18:22 |
| dhellmann | there are 2 jobs | 18:22 |
| dhellmann | the one you're talking about looks at the settings in a repo and ensures they are compatible with the global list | 18:22 |
| dhellmann | the one that failed runs on changes to the requirements repo, though | 18:23 |
| prometheanfire | yes | 18:23 |
| dhellmann | and that one only tries to ensure that we do not list something in projects.sh if they are not running the other job | 18:23 |
| dhellmann | sorry, projects.txt | 18:23 |
| prometheanfire | I'm talking about if the job the one that failed to run checks for is worth keeping | 18:23 |
| dhellmann | I think we do not need requirements-tox-validate-projects but we do need requirements-check (or check-requirements) | 18:24 |
| prometheanfire | https://docs.openstack.org/project-team-guide/dependency-management.html#enforcement-in-projects | 18:25 |
| prometheanfire | ok, so we both agree on the second part at least | 18:25 |
| prometheanfire | I think we need to first part to make sure our projects.txt keeps in sync with infra | 18:25 |
| prometheanfire | the requirements-tox-validate-projects to be specific | 18:26 |
| dhellmann | the problem with requirements-tox-validate-projects is that it only fails on changes in the requirements repo, so it does not actually block teams from removing the check job | 18:26 |
| dhellmann | why do we need projects.txt any more? | 18:26 |
| prometheanfire | that's true, a job on the infra side may be better | 18:26 |
| dhellmann | now, we could set up the governance repo to let us enforce having some of those jobs | 18:27 |
| prometheanfire | uh, if we need it or not is more of a question of 'where is the source of info for a list of projects that are compliant with reqs govenance | 18:27 |
| dhellmann | define the job in openstack-zuul-jobs and apply it in governance | 18:27 |
| dhellmann | who needs the answer to that question? | 18:28 |
| prometheanfire | governance makes more sense I think, the original reason for it being here was that we could trigger reqs updates for projects | 18:28 |
| dhellmann | right | 18:29 |
| dhellmann | it helped ensure that the sync job would not fail, but it never ensured that all repos that needed the check job actually had it | 18:29 |
| prometheanfire | ya, not at the first level | 18:30 |
| prometheanfire | s/level/layer | 18:30 |
| dhellmann | if we want to set up a list of "you must run these" we should do that in a way that lets us gate changes in project-config, each repo, and governance all together | 18:30 |
| prometheanfire | project-config sourcing the list from governance sounds right | 18:31 |
| prometheanfire | so the change in governance is everything | 18:31 |
| dhellmann | yeah, I mean, we wouldn't want to allow changes in project-config to remove jobs either | 18:31 |
| dhellmann | so we either apply the jobs in governance, or we have a job that runs against all 3 repos to enforce that the job is there | 18:32 |
| dhellmann | doing the former is probably simpler but would require some special permissions in the governance repo | 18:32 |
| dhellmann | this is probably a topic for the requirements ptl to bring up with the tc :-) | 18:32 |
| prometheanfire | not sure how doing it in three repos would help | 18:33 |
| prometheanfire | dhellmann: ya I could see where this was going :P | 18:33 |
| dhellmann | if we allow the job to be applied anywhere, then we have to test 3 different places to ensure it is not removed | 18:33 |
| dhellmann | if we just apply the job in governance then we can just run a test there | 18:33 |
| dhellmann | or not even, since we're just managing the list of jobs there | 18:34 |
| dhellmann | I'm trying to think of another example of a job we would want to do this with | 18:34 |
| prometheanfire | ah | 18:34 |
| dhellmann | the PTI comes to mind, but those can be branch-specific and we don't want to deal with that at the tc level | 18:35 |
| prometheanfire | ya, my idea is that the list of projects is in governance, project-config would use that list to generate jobs for all in that list | 18:35 |
| dhellmann | in fact it might be preferable to do the 3-way testing thing just so the TC doesn't have to keep up with the job list for each repo | 18:35 |
| dhellmann | oh, hmm | 18:35 |
| dhellmann | except that not every repo needs this | 18:35 |
| dhellmann | governance includes infra, and those don't | 18:36 |
| dhellmann | nor do the specs repos | 18:36 |
| prometheanfire | ? | 18:36 |
| dhellmann | so we still need a separate list of which repos need this job | 18:36 |
| dhellmann | the specs repos do not need to be co-installable | 18:36 |
| dhellmann | project-config is a governed repo, it doesn't need the job at all | 18:36 |
| prometheanfire | there's no reason why project-config can't source the jobs from us instead of governance I don't think | 18:53 |
| prometheanfire | dhellmann: https://gist.github.com/prometheanfire/d2b9302b2e6574b91fa3d0399b20d5b2 | 18:58 |
| prometheanfire | that's my ideas on it | 18:58 |
| dhellmann | prometheanfire : a repo needs to have special permissions set in order to be able to add jobs to a "foreign" repo (rather than itself) | 18:59 |
| dhellmann | so we could do it in the requirements repo, but that implies extra scrutiny | 18:59 |
| prometheanfire | ah | 18:59 |
| prometheanfire | my other points still stand :P | 19:00 |
| dhellmann | also applying the job could be seen as part of bringing a repo under governance, so if we do it in the governance repo then it can all be done in one go | 19:00 |
| prometheanfire | ya, that's my main reason of thinking that the governance repo may be the right home | 19:01 |
| dhellmann | I don't know if we want 1 job that tries to validate all repos at once. I think we want a job that runs on changes to the zuul config for each repo that needs to have the requirements-check job. | 19:01 |
| prometheanfire | I'm not saying one job that validates all repos, we'd keep the list of projects and gernerate one job per project | 19:02 |
| dhellmann | if we apply the jobs in the governance repo, then project teams can't just remove it themselves | 19:02 |
| * prometheanfire never thought one master job was an option | 19:02 | |
| prometheanfire | yep | 19:02 |
| dhellmann | similarly, we could do it in the project-config repo and rely on the infra team to manage that, but they're overburdened right now as it is | 19:02 |
| prometheanfire | another reason the governance repo is useful | 19:02 |
| dhellmann | I don't know what line 26 means if it isn't talking about 1 job | 19:03 |
| prometheanfire | s/job/jobs | 19:03 |
| dhellmann | is that just saying zuul should look for jobs for a repo somewhere? | 19:03 |
| prometheanfire | or definitions instead of definition | 19:03 |
| dhellmann | ok | 19:03 |
| prometheanfire | ya, basically | 19:04 |
| prometheanfire | added the 's' | 19:04 |
| dhellmann | so, yeah, that's just a zuul.d/projects.yaml file | 19:04 |
| dhellmann | or project.yaml -- whatever the right naming is | 19:04 |
| prometheanfire | lol | 19:04 |
| dhellmann | we could also do it in the releases validation | 19:05 |
| dhellmann | although we still need the list of which repos need the job | 19:05 |
| prometheanfire | yep, the list's home is the source of the problem imo | 19:05 |
| dhellmann | it's probably simpler to just do the zuul config thing | 19:05 |
| prometheanfire | zuul config thing? meaning sourcing the job from another repo? | 19:08 |
| dhellmann | yeah | 19:09 |
| prometheanfire | ya | 19:09 |
| dhellmann | we should define the job in openstack-zuul-jobs and apply it from openstack/governance | 19:09 |
| prometheanfire | same reading as what you just said, guess we bring it up in the meeting then email the list? | 19:10 |
| dhellmann | the requirements meeting? yeah, that would be a good place to start | 19:12 |
| prometheanfire | going afk til then | 19:13 |
| prometheanfire | 28 min til meeting | 20:02 |
| prometheanfire | I may be late to the meeting, on the road... | 20:15 |
| prometheanfire | the only items I have are https://gist.github.com/prometheanfire/d2b9302b2e6574b91fa3d0399b20d5b2 and eventlet timing | 20:16 |
| tonyb | y'all are going that have that discussion again durin the meeting ;P | 20:30 |
| tonyb | speaking of which .... | 20:31 |
| *** hwoarang has quit IRC | 20:39 | |
| prometheanfire | I'm here now | 20:43 |
| prometheanfire | #startmeeting requirements | 20:43 |
| openstack | Meeting started Wed Aug 29 20:43:52 2018 UTC and is due to finish in 60 minutes. The chair is prometheanfire. Information about MeetBot at http://wiki.debian.org/MeetBot. | 20:43 |
| openstack | Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. | 20:43 |
| *** openstack changes topic to " (Meeting topic: requirements)" | 20:43 | |
| openstack | The meeting name has been set to 'requirements' | 20:43 |
| prometheanfire | #topic rollcall | 20:44 |
| *** openstack changes topic to "rollcall (Meeting topic: requirements)" | 20:44 | |
| prometheanfire | tonyb, prometheanfire, number80, dirk, coolsvap, toabctl, smcginnis, dhellmann ping | 20:44 |
| prometheanfire | o/ | 20:44 |
| tonyb | \o | 20:44 |
| dhellmann | o/ | 20:44 |
| prometheanfire | #topic Any controversies in the Queue? | 20:45 |
| *** openstack changes topic to "Any controversies in the Queue? (Meeting topic: requirements)" | 20:45 | |
| prometheanfire | eventlet timing | 20:46 |
| prometheanfire | release is soon, so I'd say early next week? | 20:46 |
| dhellmann | we'll tag the final release tomorrow | 20:46 |
| * tonyb would suggest waiting until the cycle-trailing projects have released or at the very least validating that they're pulling in rocky barnches of the $projects and not using eventlet themselves | 20:47 | |
| tonyb | s/would suggest/suggests/ | 20:47 |
| prometheanfire | iirc tripleo was/is always the holdout | 20:47 |
| tonyb | prometheanfire: They're often late to branch | 20:48 |
| prometheanfire | and they've branched | 20:48 |
| tonyb | great | 20:48 |
| tonyb | they're not the only cycle-trailing team | 20:49 |
| prometheanfire | I'll send the email tomorrow after the release stating monday is the day | 20:49 |
| tonyb | we had a sctipt in gerrit to work this out | 20:49 |
| prometheanfire | they aren't | 20:49 |
| tonyb | prometheanfire: As long as you do the research as part of that email ok | 20:50 |
| prometheanfire | yep | 20:50 |
| * smcginnis walks in late | 20:50 | |
| prometheanfire | smcginnis: any other yet to branch projects? | 20:50 |
| prometheanfire | kolla is one | 20:50 |
| smcginnis | There are some ansible repos, heat, one tripleo. | 20:51 |
| prometheanfire | heat still hasn't branched? | 20:51 |
| smcginnis | The others looks like tempest-plugins or QA non-branching stuff. | 20:51 |
| smcginnis | heat-agents and heat-dashboard have not. | 20:51 |
| prometheanfire | oh, ya | 20:51 |
| prometheanfire | I thought you meant the main project | 20:51 |
| smcginnis | Nope, all main service projects are good. | 20:52 |
| prometheanfire | tonyb: I've used the release repo tooling to check branching | 20:52 |
| prometheanfire | ok, anything else on the eventlet plan? | 20:52 |
| tonyb | prometheanfire: Great. As long as it's communicated it sounds ok to me | 20:52 |
| prometheanfire | ya, there will be a list of yet-to-brach repos | 20:53 |
| tonyb | and an idea of the impact to each | 20:54 |
| prometheanfire | #topic moving projects.txt under governance | 20:54 |
| *** openstack changes topic to "moving projects.txt under governance (Meeting topic: requirements)" | 20:54 | |
| prometheanfire | my reasoning is here https://gist.github.com/prometheanfire/d2b9302b2e6574b91fa3d0399b20d5b2 | 20:54 |
| tonyb | prometheanfire: gimme a few to read that | 20:55 |
| dhellmann | while tonyb reads, I will point out that we don't do similar enforcement for any of the other PTI jobs | 20:55 |
| dhellmann | so this would be a new thing, and we talked about ways to implement it but we should also talk about whether we need to do that or if we should just add it to the PTI | 20:56 |
| prometheanfire | PTI? | 20:56 |
| dhellmann | "project testing interface" | 20:56 |
| tonyb | ZOMG that hurts my brain | 20:56 |
| prometheanfire | smcginnis: https://releases.openstack.org/reference/ has no index | 20:56 |
| dhellmann | we could, for example, simply expand https://governance.openstack.org/tc/reference/pti/python.html#requirements-listing to talk about the job template that projects should adopt | 20:57 |
| smcginnis | prometheanfire: Does it need one? | 20:57 |
| smcginnis | PTI - https://governance.openstack.org/tc/reference/project-testing-interface.html | 20:57 |
| smcginnis | This is the reference section navigation point - https://releases.openstack.org/#references | 20:58 |
| prometheanfire | dhellmann: I'm of the opinion that the test should be enforced, I've seen projects try to break co-installability in the past | 20:58 |
| prometheanfire | smcginnis: up to you | 20:58 |
| dhellmann | "try to break" or "accidentally break"? | 20:58 |
| prometheanfire | second one, but when told about it probably don't care as much as they should | 20:59 |
| tonyb | Actually I think a) we move projects.txt to project-config; b) we remove tox-validate; c) rely of projects using requierments-0check from in-repo and d) add a check at release-time that a projects *requirements.txt are still good | 20:59 |
| dhellmann | what would we do with projects.txt in project-config? | 20:59 |
| tonyb | this moves the trust circle onto the project, it does add small amounts of work for the release team but really it's just +/1- from zuul and an cmment doe a core member | 20:59 |
| tonyb | well it's still used by $jobs there so it's pulling it closer to the use and we can slowly phase it out | 21:00 |
| dhellmann | and what pressure do we use to keep it up to date? | 21:00 |
| prometheanfire | tonyb: what happens when a project adds a lib (or changed version or whatever) that fails the release check | 21:01 |
| prometheanfire | time crunch + potentially massive code change doesn't sound nice | 21:01 |
| tonyb | prometheanfire: they get a -1 from zull ate release time and need to fix it | 21:01 |
| dhellmann | if we're going to check it at release time, I think the check would be that the requirements-check job is applied to the repository | 21:02 |
| tonyb | dhellmann: I'm not sure we need to keep it in sync anymore | 21:02 |
| dhellmann | that way we don't have to reproduce that job | 21:02 |
| dhellmann | tonyb : ok, me either. I feel like this is another big opportunity to stop doing something. | 21:02 |
| prometheanfire | dhellmann: applied at the commit in question, that still leaves a hole though | 21:02 |
| tonyb | dhellmann: Sure | 21:02 |
| dhellmann | prometheanfire : nothing is going to be perfect, right? | 21:02 |
| prometheanfire | just adding the job doesn't trigger it | 21:02 |
| prometheanfire | true | 21:02 |
| prometheanfire | perfect is the enemy of good and all that | 21:03 |
| dhellmann | we don't run any other test jobs against the repo at the time of release, and I don't think we want to start trying to do that | 21:03 |
| tonyb | dhellmann: Yup. There are a couple of places that use it "for real" but the main consumer requirements updates is gone | 21:03 |
| dhellmann | those validation checks right now are "are you set up right" not "does everything work as promised" | 21:03 |
| tonyb | dhellmann: Yup I'm not really convinced there is a ton of value in doing it at release time but I feel like we want a poin tin ttime check | 21:04 |
| dhellmann | yeah, I don't mind checking for the job to be configured | 21:05 |
| smcginnis | We just don't want the release time to be the only time where they find out something is wrong. | 21:05 |
| prometheanfire | have it somewhere | 21:05 |
| smcginnis | That could be months after the problem was introduced. | 21:05 |
| dhellmann | true | 21:05 |
| prometheanfire | smcginnis: that's my worry | 21:05 |
| smcginnis | So checking for the job is good. Checking that things work would be problematic. | 21:05 |
| tonyb | smcginnis: Ture but it's a problem that $project team would have taken explict steps to introduce | 21:05 |
| prometheanfire | remove job, add bad lib, ..., readd job, release | 21:07 |
| prometheanfire | that's how you work around it | 21:07 |
| tonyb | prometheanfire: right | 21:07 |
| dhellmann | the way to ensure that everyone runs the check job is to explain why that's important well enough and often enough to convince them to do it. We don't want to just hammer a bunch of rules onto teams without their understanding -- that just leads to them subverting the inconvenient rules | 21:07 |
| prometheanfire | true | 21:08 |
| prometheanfire | and name/shame the teams that do it :P | 21:08 |
| dhellmann | that's not really a way to convince them either | 21:08 |
| prometheanfire | one thing to do would be for the reqs team to submit a noop change to all projects reqs files to check their gate | 21:09 |
| prometheanfire | dhellmann: it's not, true | 21:09 |
| tonyb | at the moment what we have works only because you need to talk to project-config-cores to do that step (removing the job) | 21:09 |
| dhellmann | prometheanfire : it's possible to run that test without submitting a patch, using a tox environment in the requirements repo | 21:09 |
| dhellmann | step 1 should be to figure out which repos actually need the job, and then to look at that list and see which ones don't | 21:09 |
| dhellmann | and then we can go talk to those teams about why they should and get them to add it | 21:10 |
| prometheanfire | all repos that wish to be co-installable need the job | 21:10 |
| tonyb | moving the file will be a big job as we need to deal with brched and branchless repos etc | 21:10 |
| dhellmann | prometheanfire : yes, but we need to be more specific about what that list is. for example, earlier you seemed surprised when I said the specs repos did not need it | 21:10 |
| dhellmann | tonyb : why do we need to move the file then? | 21:10 |
| prometheanfire | I think my surprise was about something else, not specs | 21:10 |
| dhellmann | oh, ok, I misunderstood then | 21:11 |
| tonyb | dhellmann: we don't *need* to move it. I think we probably just need to stop updating it | 21:11 |
| dhellmann | tonyb : ok, that sounds better. and maybe turn off that validation job that's failing because the file is out of date. :-) | 21:11 |
| tonyb | I think we're going around in circles a little | 21:12 |
| prometheanfire | so do we not care about co-installability? | 21:12 |
| prometheanfire | that's the reason we validate that the jobs exist right? | 21:12 |
| dhellmann | ? | 21:12 |
| tonyb | the file is used in "intersting" wasy by virtue of what it once meant | 21:12 |
| dhellmann | prometheanfire : we care about the code working, too, but we don't have anything in place that forces teams to run specific test jobs because we don't need that. they understand why those jobs are useful. | 21:13 |
| tonyb | dhellmann: I'm not even sure anymore :/ | 21:13 |
| dhellmann | tonyb : so does that mean we *should* update the file? | 21:14 |
| prometheanfire | projects are less concerned about co-installability anymore (venvs, containers, etc) | 21:14 |
| dhellmann | I'm not suggesting that convincing them is going to be easy, just that it needs to be done. | 21:14 |
| tonyb | dhellmann: I don't think so. I guess we need to look at all the non-trivial uses of thew file and decide if it still has value or not | 21:14 |
| prometheanfire | I agree, but it only takes one | 21:14 |
| dhellmann | we're not going to achieve perfection | 21:15 |
| tonyb | prometheanfire: I'm not sure we really need to worry too much about projects teams doing the clearly bad thing | 21:15 |
| prometheanfire | clear to us, not to them | 21:15 |
| * tonyb wants to err on thre side of trust here | 21:15 | |
| prometheanfire | I'm not as trusting | 21:16 |
| prometheanfire | it does come down to that though | 21:16 |
| tonyb | prometheanfire: If $project does the disble/update/enable dance the *next* time they want to update that file for reall they'll also need to do that dance and *every* subsequent time | 21:16 |
| prometheanfire | yep | 21:16 |
| tonyb | that's pretty clearly a bad thing | 21:17 |
| dhellmann | yeah, the point of this team is to help the project teams achieve a good release, not build a bunch of rules without explaining them. | 21:17 |
| prometheanfire | not saying it'd happen like that | 21:17 |
| tonyb | dhellmann: ++ | 21:17 |
| prometheanfire | never said they wouldn't be explained :| | 21:17 |
| dhellmann | I believe we can have all of the necessary repos running the test job without forcing things | 21:17 |
| tonyb | Yup | 21:17 |
| prometheanfire | if ia good release means X, and X requires Y and Z then ensuring that Y and Z are actually Y and Z is a good idea | 21:18 |
| tonyb | like I said I want to err on the side of trust here | 21:18 |
| dhellmann | prometheanfire : ok. I'm reacting to what seems like your impression that teams want to *not* have co-installability. I don't think that's true. I think some don't understand what it is, or why they should care. | 21:18 |
| prometheanfire | dhellmann: I think what you think leads to what I think | 21:19 |
| dhellmann | right, so it's *our* job to explain things to them and convince them | 21:19 |
| dhellmann | it is not our job to force anyone to do anything | 21:19 |
| prometheanfire | tonyb: which release types would get the check-reqs-check job? | 21:20 |
| * tonyb will write up something for the mailing list | 21:20 | |
| tonyb | prometheanfire: what is check-reqs-check ? | 21:20 |
| prometheanfire | check requiremets-check | 21:20 |
| prometheanfire | because the name of the job is check-requirements (I think) and we are checking for it's existance | 21:21 |
| tonyb | check-requirements ? | 21:21 |
| prometheanfire | just to add more confusion | 21:21 |
| tonyb | check-requirements: is the job that any project that wants to subscribe to our 'vetted' list of libraries would run | 21:21 |
| dhellmann | what is it we want to achieve? | 21:21 |
| prometheanfire | tonyb: it also helps to ensure co-installability by denying the addition of 'bad libs' | 21:22 |
| tonyb | check-requirements: would be managed in repo as per PTI and is the job that project teams would remove/disbale if they wanted to opt out of that list or libraries | 21:22 |
| tonyb | prometheanfire: where does it do that? | 21:23 |
| tonyb | prometheanfire: it ensures consistency between *requiremenst and lower-constraints.txt | 21:23 |
| dhellmann | tonyb : it requires that all of the things in the dependency list appear in the global list | 21:23 |
| dhellmann | no, that's a different job | 21:23 |
| dhellmann | oh, wait it does do that | 21:23 |
| prometheanfire | tonyb: part of what the job does is check for playbooks/files/project-requirements-change.py | 21:23 |
| tonyb | dhellmann: right but that's less about co-installability and more about library vetting at this point | 21:23 |
| dhellmann | it doesn't test with those constraints, that's a different job | 21:24 |
| dhellmann | yeah, check-requirements matches the local dependency lists with the global dependency list, and with the global upper constraints and the local lower constraints | 21:24 |
| prometheanfire | yep | 21:24 |
| dhellmann | if there is a local lower constraints list | 21:24 |
| tonyb | wheer does it do 'and with the global upper constraints' | 21:25 |
| prometheanfire | I thought it just checked the requirements files | 21:26 |
| tonyb | I'm under the impression that our check-uc, openstack-tox* and *dsvm* jobs do that for us | 21:26 |
| dhellmann | http://git.openstack.org/cgit/openstack/requirements/tree/openstack_requirements/check.py#n151 | 21:27 |
| dhellmann | oh, sorry, that's just the dependency list not the constraints | 21:28 |
| dhellmann | hmm | 21:28 |
| tonyb | prometheanfire: IIUC it checks a projects *requiremenst.txt only lists libraries in g-r *and* if the project has a lower-constratins.txt it checks that the value in that file matches the one in the projects *requirements.tx | 21:28 |
| dhellmann | it does also check that the local exclusions are a subset of the global exclusions | 21:29 |
| tonyb | so with that understanding that job is ensuring self-consistency and that projects are only using 'vetted' code | 21:29 |
| prometheanfire | ah | 21:29 |
| tonyb | dhellmann: True I forgot that part | 21:29 |
| dhellmann | but you're right that it does not explicitly check against the u-c list | 21:29 |
| tonyb | so again that consistency and vetting not co-installability | 21:29 |
| dhellmann | well, we get it commutatively | 21:29 |
| prometheanfire | isn't that a prereq for co-installability? | 21:30 |
| dhellmann | if a projects dependencies are compatible with the global list, and the global list is compatible with the constraint, then the projects' dependencies are compatible with the constraint | 21:30 |
| tonyb | prometheanfire: not really | 21:30 |
| prometheanfire | dhellmann: right | 21:30 |
| tonyb | dhellmann: okay that's fair I stand corrected | 21:31 |
| prometheanfire | dhellmann: that's basically my reasoning | 21:31 |
| dhellmann | I think that's actually transitive, not commutative | 21:31 |
| dhellmann | it has been a long time since I studied math :-) | 21:32 |
| tonyb | dhellmann: it is but meh | 21:32 |
| prometheanfire | same | 21:32 |
| tonyb | So I think after 45mins we've decided this is complex and we need to dicuss it in the community | 21:33 |
| dhellmann | heh | 21:33 |
| prometheanfire | lol | 21:33 |
| prometheanfire | true, that was always the case | 21:33 |
| dhellmann | I don't feel like anything has really changed about this except that we should make sure the requirements repo is not blocking changes because projects.txt is out of date | 21:33 |
| tonyb | I feel like projects.txt isn't really part of that discussion as we no longer consult it from a requiremenst POV | 21:33 |
| prometheanfire | letting them know that they should use the job for x y z reasons | 21:33 |
| dhellmann | right | 21:34 |
| prometheanfire | ya, the real 'source of truth' now is project-config | 21:34 |
| prometheanfire | and relying on jobs not being removed | 21:34 |
| tonyb | prometheanfire: no | 21:34 |
| dhellmann | project-config? | 21:34 |
| tonyb | prometheanfire: the source of truth now is zuul | 21:34 |
| tonyb | (and the as yet un merged API we were promised) | 21:35 |
| prometheanfire | ? | 21:35 |
| smcginnis | I thought there was some progress on that. | 21:35 |
| prometheanfire | now I'm confused | 21:35 |
| dhellmann | there's an API to fetch the settings for a job, but they do not include which repos it's attached to | 21:35 |
| tonyb | smcginnis: you can query a job defn. but not get a list of jobs for $project | 21:35 |
| tonyb | ... at least alst time I checked | 21:35 |
| prometheanfire | the check-requirements job defined in project config for various projects is considered valuable still right? | 21:35 |
| dhellmann | prometheanfire : we are working on moving most of the zuul settings out of the project-config repository | 21:35 |
| dhellmann | the job is valuable. we are moving that setting into the repos, though. | 21:36 |
| tonyb | prometheanfire: No thre PTI changed and $projecst can move it in-repo | 21:36 |
| smcginnis | Maybe getting this all written in a post to the ML would help. | 21:36 |
| prometheanfire | dhellmann: I'm aware, iirc we kept the job in project-config because it's harder to remove | 21:36 |
| * tonyb notes hes' said he'd do that 3 times ;p | 21:36 | |
| tonyb | prometheanfire: nope we agreed to move it | 21:36 |
| dhellmann | that is not one of the jobs the scripts are leaving behind | 21:36 |
| prometheanfire | ok, guess we just assume it's going to work in the end | 21:37 |
| smcginnis | tonyb: I was trying to get it back around to that. ;) | 21:37 |
| dhellmann | http://git.openstack.org/cgit/openstack/goal-tools/tree/goal_tools/python3_first/jobs.py#n22 | 21:37 |
| tonyb | Okay we're 7mins over now | 21:39 |
| prometheanfire | we don't have anything for verifying our upper-constraints is used either, so I guess veriifcation is overblown | 21:39 |
| prometheanfire | trust but verify is just trust now | 21:40 |
| prometheanfire | tonyb: ya, I don't have anything else for the meeting | 21:40 |
| dhellmann | teams understand the value of the uc list because it helps protect their gate jobs | 21:40 |
| prometheanfire | yep | 21:40 |
| smcginnis | We could maybe add a check that their tox.ini has something like http://git.openstack.org/cgit/openstack/cinder/tree/tox.ini#n15 | 21:41 |
| tonyb | smcginnis: Perhaps but there are so many other places it's used/needed and some projects have deliberatly opt-out of u-c | 21:41 |
| prometheanfire | ya, but at this point we are beyond the meeting | 21:41 |
| prometheanfire | can carry this on after/later | 21:42 |
| * tonyb need to breakfast and get kids to school | 21:42 | |
| prometheanfire | good with that? | 21:42 |
| prometheanfire | we don't have to decide this today | 21:42 |
| smcginnis | Yep | 21:42 |
| prometheanfire | #endmeeting | 21:42 |
| *** openstack changes topic to "OpenStack Requirements - IRC meetngs on Wednesdays @ 07:00 UTC in here in #openstack-requirements - See agenda @ http://tinyurl.com/h44ryuw - IRC channel is *LOGGED* @ http://tinyurl.com/j38rk24" | 21:42 | |
| tonyb | at this point I think we should have the discussion on the ML | 21:42 |
| openstack | Meeting ended Wed Aug 29 21:42:46 2018 UTC. Information about MeetBot at http://wiki.debian.org/MeetBot . (v 0.1.4) | 21:42 |
| openstack | Minutes: http://eavesdrop.openstack.org/meetings/requirements/2018/requirements.2018-08-29-20.43.html | 21:42 |
| openstack | Minutes (text): http://eavesdrop.openstack.org/meetings/requirements/2018/requirements.2018-08-29-20.43.txt | 21:42 |
| openstack | Log: http://eavesdrop.openstack.org/meetings/requirements/2018/requirements.2018-08-29-20.43.log.html | 21:42 |
| prometheanfire | ya | 21:43 |
| prometheanfire | email os-dev about the virtues of the check-requirements test | 21:46 |
| prometheanfire | that's a task for me | 21:46 |
| openstackgerrit | Merged openstack/requirements master: remove documentation job from in-tree config https://review.openstack.org/597160 | 22:07 |
| openstackgerrit | Merged openstack/requirements master: Add Django-debreach to global-requirements.txt https://review.openstack.org/595269 | 22:45 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!