| @jim:acmegating.com | zuul-maint: how does this look for a release? commit 2d94f706474acfa867f3ebc002a107860bc7147d (HEAD -> master, tag: 12.0.0, origin/master, gerrit/master) | 15:33 |
|---|---|---|
| @jim:acmegating.com | opendev is running that commit. i think the notes in the upgrade section warrant the major version bump https://zuul-ci.org/docs/zuul/latest/releasenotes.html | 15:33 |
| @clarkb:matrix.org | corvus: I'll take a look once today's gerrit server swap is done | 15:35 |
| @fungicide:matrix.org | that seems to correspond to the current master branch state, 131 changes since 11.3.0 | 15:35 |
| @fungicide:matrix.org | i agree the upgrade notes justify a 12.0.0 | 15:36 |
| @fungicide:matrix.org | lgtm! | 15:37 |
| @jim:acmegating.com | thx. no rush. :) | 15:38 |
| @clarkb:matrix.org | corvus: the hash and version both lgtm. Particularly since web status url is removed that is a potentially breaking change so 12.0.0 is a good idea | 17:07 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed on behalf of Joseph Kostreva: [zuul/zuul] 933138: Add zuul regex support to project definitions https://review.opendev.org/c/zuul/zuul/+/933138 | 18:32 | |
| @clarkb:matrix.org | corvus: I guess in the unrelated refactor that ^ missed a location where we had to force to a regex? | 18:53 |
| @clarkb:matrix.org | or rather upadted things in such a way that this change's last update missed the type coercion | 18:54 |
| @jim:acmegating.com | Clark: i think that was just an unavoidable conflict; i don't think anything was missed (unless i'm missing what you're looking at). i think the latest ps is equivalent to the previous, but accounting for things being rearranged after the config object reuse stack | 19:02 |
| @clarkb:matrix.org | ack the diff doesn't show it super cleanly. But the more I look at it the less I'm concerned/confused | 19:06 |
| @clarkb:matrix.org | its basically make sure we force the regex into the regex type | 19:06 |
| @jim:acmegating.com | yep | 19:33 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 941171: Ignore file matches on changes to include-vars and playbooks https://review.opendev.org/c/zuul/zuul/+/941171 | 19:43 | |
| @jim:acmegating.com | Clark: the switch to using niz for zuul has uncovered a difference... in nodepool, the openstack driver sets private_ipv4 to public_ipv4 if there is no private_ipv4. in niz, i passed through the values from the underlying driver without change. the zuul tox-remote job notices this because it assumes private_ipv4 is always set. do you think we should continue to take this opportunity to clean up the api and leave zuul as-is and fix the job, or should we make it backwards-compatible with nodepool? | 20:27 |
| actually, i think i just came up with an obvious answer to that: how about we make the zuul.nodepool job variables backwards compatible, but add new zuul.node variables that change the api? | ||
| @jim:acmegating.com | * Clark: the switch to using niz for zuul has uncovered a difference... in nodepool, the openstack driver sets private\_ipv4 to public\_ipv4 if there is no private\_ipv4. in niz, i passed through the values from the underlying driver without change. the zuul tox-remote job notices this because it assumes private\_ipv4 is always set. do you think we should continue to take this opportunity to clean up the api and leave zuul as-is and fix the job, or should we make it backwards-compatible with nodepool? | 20:29 |
| actually, i think i just came up with an obvious answer to that: how about we make the nodepool job variables backwards compatible, but add new node variables that change the api? | ||
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 947768: Use private or public ip in nox-remote job https://review.opendev.org/c/zuul/zuul/+/947768 | 20:31 | |
| @jim:acmegating.com | that's a quick fix for the job | 20:31 |
| @clarkb:matrix.org | corvus: I think the logic behind the nodepool behavior was to prefer private addresses if set because NAT often introduces problems and if you haev a public ip you may be traversing NAT. That said we can encode that same logic in the jobs too. But then you have to reteach everyone to avoid NAT... | 20:34 |
| @clarkb:matrix.org | so basically by always ensuring private_ip is set we can easily tell people to use the private ip and not worry about that logic in different jobs. | 20:34 |
| @jim:acmegating.com | my problem with that is that nodepool is lying about what openstack returns; i don't think zuul should be in that business | 20:35 |
| @jim:acmegating.com | there is the interface ip; that's the opposite right? prefer public if it exists? | 20:36 |
| @clarkb:matrix.org | ya its a tradeoff and the tradeoff may work out differently for different groups | 20:36 |
| @jim:acmegating.com | maybe there should be a 6th ip address: the complement of interface-ip | 20:36 |
| @clarkb:matrix.org | within openstack the lie was helpful particularly with setting up our own overlay networks for multinode testing of things like neutron. But I could see some deployments treating them as distinct | 20:36 |
| @clarkb:matrix.org | yes interface ip is how to reach the node aiui | 20:37 |
| @jim:acmegating.com | i'd be fine adding the complement of interface ip... just need a name for it :) | 20:38 |
| @clarkb:matrix.org | the suggestion to have nodepool vars that are backward compatible then niz vars that aren't and I guess probably also deprecate the nodepool vars at some point makes sense to me | 20:38 |
| @clarkb:matrix.org | oh that is an interesting idea too | 20:38 |
| @clarkb:matrix.org | internal_ip ? | 20:38 |
| @clarkb:matrix.org | or local_ip maybe | 20:38 |
| @jim:acmegating.com | wfm -- minor concern that it may be too misleading if it actually ends up being a public ip | 20:39 |
| @clarkb:matrix.org | yup probably worth brainstorming a bit better if we can express what it is more accurately | 20:39 |
| @jim:acmegating.com | i think local is maybe slightly better than internal -- it's a little bit vague and doesn't scream "this is definitely rfc1918" at me :) i think i'd have to look up the docs for it, which is no bad thing. :) | 20:40 |
| @clarkb:matrix.org | as a counter example we semi recently had opendev users complaining that their builds were failing and they didn't udnerstand why. Well turns out they assumed ipv6 was available in every cloud and used the ipv6 vars in their jobs. In that case we told them they have to check if ipv6 is available first | 20:43 |
| @clarkb:matrix.org | so maybe being explicit and pushing people to understand the environment a bit better is a good thing? | 20:44 |
| @jim:acmegating.com | yeah, i do think that's best. that's why i'd strongly push for having the actual public/private v4/v6 vars be their real values. i'm more ambivalent about having helper values like interface_ip and local_ip. | 20:45 |
| @clarkb:matrix.org | ya I'd be fine with a secondary var that attempts to interpret things that people can switch to and make the explicit values consistent | 20:46 |
| @jim:acmegating.com | 12.0.0 tagged, and release announcement sent | 21:10 |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul-jobs] 947769: Add win_zuul_console to start-zuul-console https://review.opendev.org/c/zuul/zuul-jobs/+/947769 | 21:27 | |
| -@gerrit:opendev.org- James E. Blair https://matrix.to/#/@jim:acmegating.com proposed: [zuul/zuul] 947770: Adjust niz private_ipv4 behavior to match Nodepool https://review.opendev.org/c/zuul/zuul/+/947770 | 21:39 | |
| @jim:acmegating.com | Clark: i'm sure that will fail tests, but it's on the punch list now. | 21:40 |
| @clarkb:matrix.org | cool I left a couple of questjons on the win_zuul_console change | 21:41 |
| -@gerrit:opendev.org- Zuul merged on behalf of James E. Blair https://matrix.to/#/@jim:acmegating.com: [zuul/zuul] 947768: Use private or public ip in nox-remote job https://review.opendev.org/c/zuul/zuul/+/947768 | 22:31 | |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!