| *** rlandy|ruck is now known as rlandy|out | 01:52 | |
| *** ysandeep|out is now known as ysandeep | 05:14 | |
| opendevreview | daniel.pawlik proposed openstack/ci-log-processing master: Add ansible role that is configuring logscraper https://review.opendev.org/c/openstack/ci-log-processing/+/817050 | 07:12 |
|---|---|---|
| opendevreview | daniel.pawlik proposed openstack/ci-log-processing master: Add ansible role that is configuring logscraper https://review.opendev.org/c/openstack/ci-log-processing/+/817050 | 07:21 |
| opendevreview | daniel.pawlik proposed openstack/ci-log-processing master: Add Log Processor module https://review.opendev.org/c/openstack/ci-log-processing/+/817436 | 07:21 |
| opendevreview | daniel.pawlik proposed openstack/ci-log-processing master: Add log gearman role https://review.opendev.org/c/openstack/ci-log-processing/+/817759 | 07:22 |
| *** akekane_ is now known as abhishekk | 07:52 | |
| *** amoralej|off is now known as amoralej | 08:10 | |
| *** akahat|rover is now known as akahat|lunch | 08:36 | |
| *** jpena|off is now known as jpena | 08:37 | |
| ttx | reed: you dream about my code at night? | 09:09 |
| *** akahat|lunch is now known as akahat|rover | 09:59 | |
| opendevreview | daniel.pawlik proposed openstack/ci-log-processing master: Add ansible role that is configuring logscraper https://review.opendev.org/c/openstack/ci-log-processing/+/817050 | 10:05 |
| opendevreview | daniel.pawlik proposed openstack/ci-log-processing master: Add ansible role that is configuring logscraper https://review.opendev.org/c/openstack/ci-log-processing/+/817050 | 10:25 |
| *** ysandeep is now known as ysandeep|afk | 11:04 | |
| *** rlandy|out is now known as rlandy|ruck | 11:11 | |
| *** ysandeep|afk is now known as ysandeep | 12:22 | |
| jpodivin | rlandy|ruck: Hi. The last dependency on the OVB job was merged today. The patch https://review.rdoproject.org/r/c/rdo-jobs/+/36700 is now ready for final review | 12:46 |
| rlandy|ruck | jpodivin: thanks | 12:50 |
| rlandy|ruck | adding to our team's review list | 12:50 |
| jpodivin | rlandy|ruck: thank you | 12:52 |
| *** amoralej is now known as amoralej|lunch | 13:24 | |
| *** amoralej|lunch is now known as amoralej | 14:15 | |
| *** rlandy|ruck is now known as rlandy|ruck|biab | 15:08 | |
| *** ysandeep is now known as ysandeep|out | 15:13 | |
| *** dviroel is now known as dviroel|lunch | 15:20 | |
| *** rlandy|ruck|biab is now known as rlandy|ruck | 16:22 | |
| opendevreview | Merged openstack/project-config master: Retire puppet-senlin - Step 3: Remove Project https://review.opendev.org/c/openstack/project-config/+/817327 | 16:40 |
| *** dviroel|lunch is now known as dviroel | 16:54 | |
| opendevreview | Ghanshyam proposed openstack/openstack-zuul-jobs master: Update Yoga job template for updated testing runtime https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/818609 | 17:24 |
| *** amoralej is now known as amoralej|off | 17:29 | |
| *** jpena is now known as jpena|off | 17:41 | |
| opendevreview | Jeremy Stanley proposed openstack/pbr master: Use context blocks for open() calls in packaging https://review.opendev.org/c/openstack/pbr/+/818622 | 18:37 |
| reed | ttx: your code gives me nightmares at night 🙂 although it could have been the burrito | 19:30 |
| fungi | burritocode | 19:36 |
| reed | yummy | 19:44 |
| opendevreview | Ghanshyam proposed openstack/openstack-zuul-jobs master: Update Yoga job template for updated testing runtime https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/818609 | 19:57 |
| opendevreview | Ghanshyam proposed openstack/project-config master: Retire training-labs: remove project infra https://review.opendev.org/c/openstack/project-config/+/817507 | 20:03 |
| opendevreview | Ghanshyam proposed openstack/project-config master: Retire training-labs: remove project infra https://review.opendev.org/c/openstack/project-config/+/817507 | 20:07 |
| opendevreview | Ghanshyam proposed openstack/project-config master: Remove 'publish-training-labs-scripts' definition https://review.opendev.org/c/openstack/project-config/+/818628 | 20:17 |
| opendevreview | Ghanshyam proposed openstack/project-config master: Remove 'publish-training-labs-scripts' definition https://review.opendev.org/c/openstack/project-config/+/818628 | 20:19 |
| gmann | fungi: clarkb ^^ what is best way to move the job from project-config to in-tree (without renaming the job) https://review.opendev.org/c/openstack/project-config/+/818628 https://review.opendev.org/c/openstack/training-labs/+/818626 | 20:22 |
| gmann | renaming job in moving patch will need update on many stable branch of retired training-labs | 20:23 |
| gmann | or we just keep it in project-config? | 20:23 |
| clarkb | you have to rename the job to move it | 20:23 |
| fungi | gmann: remove the job from project-config (and everywhere it's used), then add it back in the new location | 20:23 |
| gmann | fungi: clarkb yeah rename or remove-usage first is work on more stable branch which is feel unnecessary. any objection on keeping it in project-config ? | 20:24 |
| clarkb | so this is realted to my email about cleaning up zuul errors. I personally think you should be cleaning up all the stable branches too | 20:27 |
| clarkb | because what is effectively happening here is retired repos are creating more work for zuul operators when they don't properly clean up | 20:27 |
| clarkb | (usually because some other repo gets renamed or retired impacting the old branches of other retired repos) | 20:27 |
| clarkb | then when I ask that peopel clean them up they say no beacuse it is a stable branch | 20:27 |
| fungi | gmann: if you're retiring training-labs you'll be removing it from the zuul tenant's projects list anyway, so the job will no longer be used and can be cleaned up normally right? | 20:28 |
| gmann | fungi: it is used in stable branch of training-labs - https://opendev.org/openstack/training-labs/src/branch/stable/stein/.zuul.yaml#L11 | 20:29 |
| gmann | master branch content is removed but not stable branch | 20:29 |
| fungi | gmann: but once training-labs is removed from zuul, it won't matter? | 20:29 |
| clarkb | fungi: it will matter if other repos use the job (this is what causes the errors I've asked people to clean up) but if it is just training-labs that uses it then youare correct should be fine | 20:30 |
| gmann | yeah PS2 config erorr - https://review.opendev.org/c/openstack/project-config/+/817507 | 20:30 |
| clarkb | ya you have to remove the job after you remove the repo from zuul | 20:31 |
| gmann | clarkb: I see your point, let me clean it up otherwise we forget the stable branch config error | 20:31 |
| clarkb | gmann: well in this case if that is the only repo using the job then it won't be an error once you remove training-labs from zuul | 20:31 |
| clarkb | its only a problem when we remove repos from zuul that define jobs that other repos use | 20:32 |
| clarkb | (which happens often and now I'm being told they won't clean it up because its a stable branch) | 20:32 |
| gmann | clarkb: humm, it is the only used in that repo but zuul gave error PS2 in https://review.opendev.org/c/openstack/project-config/+/817507 | 20:32 |
| gmann | did i miss anything on removing repo from zuul in ^^ | 20:33 |
| clarkb | gmann: yes, project-config is trusted config so it won't speculatively load | 20:33 |
| clarkb | 817507 needs to land first. Then you can have another followup change that removes the jobs | 20:33 |
| fungi | further, the zuul tenant config isn't something that could be speculatively tested that way anyway, it has to be deployed and zuul reconfigured with the updated copy | 20:33 |
| gmann | ah got it. | 20:35 |
| clarkb | fungi: re cleanups for stable branches I've not come to my own conclusions yet on how we should handle that but I think our options are 1) ok they are your zuul config errors we won't help you further with this 2) opendev manually fix the repos (force merging .zuul.yaml updates) 3) remove the repos from zuul. I think either 1 or 2 is preferable but I don't know which makes | 20:35 |
| clarkb | the most sense | 20:35 |
| clarkb | with my openstack hat on I'd prefer that we keep the zuul config as clean as possible to avoid unexpected behaviors | 20:36 |
| fungi | 2 already has the blessing of the tc | 20:36 |
| clarkb | stable branches are still valid code or should be EOL'd | 20:36 |
| clarkb | with my opendev hat on I don't think we should be micromanaging unless it directly impacts opendev services and currently it does not | 20:36 |
| gmann | clarkb: fungi follow up is also here, please review both https://review.opendev.org/c/openstack/project-config/+/818628/ https://review.opendev.org/c/openstack/project-config/+/817507 | 20:36 |
| *** dviroel is now known as dviroel|out | 20:37 | |
| clarkb | additionally with my opendev hat on I'm inclined to stop renaming openstack projects if they leave a giant mess afterwards | 20:37 |
| clarkb | It isn't fair to us to have us do project renames only for nothing further to happen except zuul config tech debt | 20:37 |
| clarkb | gmann: both changes lgtm. I also noted that you can recheck the child change once the parent lands and zuul has a chance to reload its config | 20:42 |
| clarkb | gmann: I don't think it is instantaneous as the tenant config reload is triggered by ansible. But should be safe an hour or so later | 20:43 |
| gmann | clarkb: thanks, noted | 20:43 |
| fungi | clarkb: for dealing with the config errors, we could set a deadline after which removals will be directly merged in gerrit for any references which are still remaining in error | 20:45 |
| clarkb | fungi: ya I think my concern is more that we either A) care about the errors and then have to do the work ourselves in which case renames are a no no. Or B) we say ok fine we don't care and proceed as is | 20:46 |
| clarkb | I'd like to avoid creating more work for us, but I'm not sure B is the right choice either | 20:47 |
| fungi | there's always option c... we can remove projects which don't clean up their errors | 20:47 |
| fungi | we can ask the tc to make a choice | 20:48 |
| gmann | I think deadline is good idea but removal I am not sure we should do | 20:48 |
| gmann | I did fix one neutron error when my DNM patch on neutron stable failed with config error but we still have many | 20:49 |
| clarkb | gmann: ya there are a lot I wrote an email about it and called out the projects. At least one is saying they won't fix it because it is on stable branches | 20:50 |
| clarkb | fwiw I don't think we should remove projects. That seems worse than having broken configs. The goal here isn't to make the bell go away but to ensure things are functioning as expect for the projects | 20:51 |
| fungi | but what's the point of keeping branches with broken job configs when you can't test them? | 20:52 |
| gmann | yeah, i saw that email. | 20:53 |
| clarkb | fungi: I guess we could eol the branches? | 20:54 |
| gmann | fungi: I think it is tested until change in zuul.yaml so mostly are not known for example in case of neutron stable branch for networking-midonet case | 20:54 |
| clarkb | gmann: they are, but its hard to know if the tests are working in those cases | 20:54 |
| gmann | right | 20:54 |
| clarkb | gmann: because the config they are using is a bit undefined (there are rules to it but I couldn't tell you what they are off the top of my head | 20:54 |
| gmann | I think in retirement process we need to tell clearly on how to find this repo used in other project stable branch either directly or job defined in retiring repo | 20:55 |
| gmann | so that we can clean it up during retirement only. currently we mostly do cleanup in master only | 20:56 |
| clarkb | I don't have a problem with waiting for zuul to complain as it should give a pretty comprehensive list | 20:57 |
| clarkb | the problem is when we just leave it there that way | 20:57 |
| gmann | clarkb: I am writing my TC weekly summary and I will mention it there. Also I will put this in TC meeting agenda to cleanup(by TC or ask projects to cleanup). | 21:01 |
| clarkb | gmann: really I think the main issue here is that if there are errors like that the testing may not be doing what you expect it to do | 21:01 |
| clarkb | correcting it for that reason is the main priority. Beyond that it is nice to avoid the noise | 21:01 |
| gmann | exactly. | 21:01 |
| fungi | zuul config errors will also in at least some cases make it impossible to test new changes for those branches at all | 21:02 |
| gmann | can we error on such case from zuul side? like job not defined(due to removed or config error) then zuul error instead of ignoring the job run ? | 21:03 |
| clarkb | gmann: I think zuul avoids doing that because its tricky to prevent fallout from that | 23:21 |
| clarkb | basically its better for zuul to not completely fail so taht zuul runs sufficiently to check the fixes | 23:21 |
| clarkb | It is probably doable but not already done | 23:21 |
| clarkb | Bike rides are good for thinking. From opendev perspective I think we shouldn't care too much if errors happen and as such don't worry about renames making more errors | 23:22 |
| clarkb | But the Tact sig should continue to encourage fixing those errors for teh reasons we noted above (unexpected behavior being a problem) | 23:22 |
| gmann | clarkb: yeah. | 23:34 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!