| *** openstack has joined #zuul | 07:32 | |
| *** ChanServ sets mode: +o openstack | 07:32 | |
| *** holser has joined #zuul | 07:34 | |
| *** tosky has joined #zuul | 07:37 | |
| ianw | clarkb: might want to squish https://review.opendev.org/#/c/742057/ into your wheel patch to get something that works together | 07:38 |
|---|---|---|
| *** wuchunyang has joined #zuul | 07:45 | |
| openstackgerrit | Fabien Boucher proposed zuul/zuul master: gitlab: remove default mutables https://review.opendev.org/741938 | 07:46 |
| *** jpena|off is now known as jpena | 07:50 | |
| *** piotrowskim has joined #zuul | 07:58 | |
| *** nils has joined #zuul | 08:13 | |
| *** wuchunyang has quit IRC | 08:46 | |
| *** bhavikdbavishi has quit IRC | 08:57 | |
| *** bhavikdbavishi1 has joined #zuul | 08:57 | |
| *** djinni` has joined #zuul | 08:58 | |
| openstackgerrit | Fabien Boucher proposed zuul/zuul master: gitlab: support the MR merged event https://review.opendev.org/742107 | 08:58 |
| *** bhavikdbavishi has joined #zuul | 09:00 | |
| *** jcapitao has quit IRC | 09:00 | |
| *** bhavikdbavishi1 has quit IRC | 09:02 | |
| *** jcapitao has joined #zuul | 09:02 | |
| *** holser has quit IRC | 09:26 | |
| *** holser has joined #zuul | 09:27 | |
| *** jcapitao has quit IRC | 09:34 | |
| *** bhavikdbavishi has quit IRC | 10:07 | |
| *** bhavikdbavishi has joined #zuul | 10:07 | |
| *** bhavikdbavishi has quit IRC | 10:18 | |
| *** jcapitao has joined #zuul | 10:30 | |
| *** jcapitao is now known as jcapitao_lunch | 10:30 | |
| *** jcapitao_lunch has quit IRC | 10:39 | |
| *** bhavikdbavishi has joined #zuul | 10:40 | |
| *** jcapitao_lunch has joined #zuul | 11:27 | |
| *** jpena is now known as jpena|lunch | 11:40 | |
| *** sshnaidm|afk is now known as sshnaidm | 11:41 | |
| *** iurygregory has quit IRC | 11:49 | |
| *** jcapitao_lunch is now known as jcapitao | 11:57 | |
| *** iurygregory has joined #zuul | 11:59 | |
| *** rlandy has joined #zuul | 12:00 | |
| *** rlandy is now known as rlandy|ruck | 12:01 | |
| *** rfolco has joined #zuul | 12:08 | |
| *** Goneri has joined #zuul | 12:17 | |
| *** jpena|lunch is now known as jpena | 12:43 | |
| openstackgerrit | Clark Boylan proposed zuul/nodepool master: Omnibus nodepool container image fixes https://review.opendev.org/741942 | 13:14 |
| clarkb | all the fixes squashed together. I expect that may be landable to get an image out even if it isn't the exact end state we want | 13:14 |
| *** holser has quit IRC | 13:20 | |
| *** holser_ has joined #zuul | 13:20 | |
| *** holser_ has quit IRC | 13:32 | |
| *** holser has joined #zuul | 13:33 | |
| felixedel | zuul-maint: Could I get a review on two small PF4 fixes/improvements https://review.opendev.org/#/c/740914/ and https://review.opendev.org/#/c/740923/ ? | 13:35 |
| *** bhavikdbavishi has quit IRC | 13:42 | |
| clarkb | ugh cryptography literally just did a release so that wheel isn't in our arm cache | 13:51 |
| clarkb | and the change I just pushed is trying to build cryptography. I guess we'll see if it can get that done within the timeout time | 13:51 |
| clarkb | felixedel: I'm trying but admittedly somewhat lost. In https://review.opendev.org/#/c/740923/1/web/src/App.jsx do we rely on activeClassName on line 102 to do the equivalent of the old check for isActive via react magic? | 14:01 |
| clarkb | I think I'm ok approving that one except I don't quite understand exactly how we're checking which item is the active item | 14:01 |
| clarkb | felixedel: and for the other change I feel like I'm even more lost :) | 14:04 |
| felixedel | clarkb: The activeClassname property comes with the NavLink component. It's a component from react-router that allows custom styling of the currently active Route. So in that case I would call it "react-router magic" ;-) | 14:06 |
| felixedel | Ah, now I see what you mean. The isActive was a leftover from PF3 and not used anymore in PF4. | 14:07 |
| fungi | digging into a bit of an odd situation in opendev... we restarted the scheduler on 2020-07-17 with current master branch of zuul/zuul deployed, zuul-web was not restarted at that time (last restarted 2020-06-16). github webhooks continue to be processed by zuul-web and submitted to the scheduler via rpc, but the scheduler does not log seeing them since it was restarted | 14:10 |
| clarkb | yup after some googling I've discovered that NavLink does magic :) | 14:10 |
| felixedel | PF4 wants you to implement an onClick handler on the navitem to highlight the current one. But that won't work if somebody visits a page directly. Since I didn't find a proper solution for that with PF4 components I came up with the react-router solution | 14:11 |
| clarkb | felixedel: I left an idea on https://review.opendev.org/#/c/740923 but +2 otherwise. | 14:11 |
| fungi | not finding any related exceptions/tracebacks in debug logs for either the scheduler nor zuul-web | 14:11 |
| clarkb | fungi: my hunch is that we've chagned something related to the zk switch and old zuul-web is still relying on gearman where it isn't expected to | 14:11 |
| clarkb | fungi: but I've not been able to keep up with all of the zkification changes | 14:11 |
| clarkb | now trying to google around PageHeader and better understand that | 14:12 |
| tobiash | nothing has changed yet regarding gearman vs zk | 14:12 |
| clarkb | oh page header is local not part of react | 14:13 |
| clarkb | tobiash: thanks for confirming | 14:13 |
| felixedel | clarkb: https://www.patternfly.org/v4/documentation/react/components/nav | 14:13 |
| clarkb | aha thanks | 14:13 |
| tobiash | clarkb: do you see "Github Webhook Received" in the scheduler logs? | 14:13 |
| fungi | tobiash: not since the scheduler restart, no | 14:13 |
| tobiash | that should be logged before it is even trying to access github | 14:13 |
| felixedel | clarkb: For the whole PageHeader I took this demo as example https://www.patternfly.org/v4/documentation/react/demos/pagelayout | 14:13 |
| tobiash | hrm, can you get a list of gear functions? | 14:14 |
| tobiash | there should be a function "github:<connection name>:payload" function registered by the scheduler | 14:14 |
| fungi | tobiash: oh, wait, grep failure on my part. we do get it from geard: | 14:14 |
| fungi | 2020-07-21 14:09:57,953 DEBUG zuul.GithubGearmanWorker: [e: dab55200-cb5b-11ea-8377-eaa62efdaa50] Github Webhook Received | 14:14 |
| tobiash | can you grep for dab55200-cb5b-11ea-8377-eaa62efdaa50 ? | 14:15 |
| felixedel | clarkb: Where are you lost in the other change (740914) ? :) | 14:15 |
| fungi | tobiash: yeah, just did: http://paste.openstack.org/show/796160/ | 14:16 |
| clarkb | fungi: mostly just how logoComponent translates to "construct this as an intelligent link" | 14:16 |
| clarkb | digging through pf docs now to see how that works | 14:16 |
| tobiash | fungi: are there exceptions between the start and end timestamp (without filtering)? | 14:17 |
| fungi | tobiash: just a sec, finding a better example (a pull_request event for something we should be running jobs on) | 14:20 |
| corvus | oh we're over here now | 14:20 |
| tobiash | fungi: that's ok, there should be more in between the last two lines | 14:21 |
| tobiash | regardless of configured jobs | 14:21 |
| tobiash | hrm, exceptions should be logged with the event id there actually | 14:23 |
| fungi | tobiash: yeah, nothing between those lines, you can see the line numbers to the left of the timestamps in this paste: http://paste.openstack.org/show/796162/ | 14:23 |
| corvus | fungi: for comparison i looked at an older event; i think this is typical: zgrep 9e9a8e00-c7f7-11ea-94ba-01b971d1bdde debug.log.4.gz | 14:24 |
| tobiash | between starting and finished event processing this runs: https://opendev.org/zuul/zuul/src/branch/master/zuul/driver/github/githubconnection.py#L368 | 14:25 |
| corvus | yeah and we don't see either the type or unhandled message, could self.connector._stopped be true? | 14:26 |
| fungi | corvus: agreed, we're not seeing the zuul.GithubConnection line or anything after it | 14:26 |
| tobiash | but this should always log something | 14:26 |
| tobiash | corvus: yes, that's the only explanation I have atm | 14:26 |
| tobiash | but why should _stopped be true? | 14:26 |
| corvus | it looks like it's only set if we're shutting down | 14:27 |
| tobiash | yeah | 14:27 |
| tobiash | maybe a thread dump helps (or even repl to check that variable) | 14:27 |
| corvus | tobiash: the threading around the event processor is a little weird... | 14:28 |
| corvus | tobiash: it runs in a thread pool, and its run method has a try/finally but no exception | 14:28 |
| corvus | tobiash: so what happens if _process_event raises an exception? | 14:28 |
| tobiash | that's a good question, maybe that doesn't log it then | 14:29 |
| corvus | tobiash: would it propogate up through the future and log here? https://opendev.org/zuul/zuul/src/branch/master/zuul/driver/github/githubconnection.py#L719-L727 | 14:29 |
| tobiash | exceptions are propagated and raised when calling result() yes | 14:30 |
| tobiash | so yes, we would see "Exception moving GitHub event" | 14:31 |
| corvus | ok, just wanted to make sure we covered all the exits from that method | 14:31 |
| fungi | definitely not getting those in the logs | 14:31 |
| tobiash | https://docs.python.org/3/library/concurrent.futures.html#concurrent.futures.Future.result | 14:32 |
| tobiash | "If the call raised, this method will raise the same exception." | 14:32 |
| tobiash | fungi: can you check the logs at that timestamp without grepping for the event id? | 14:34 |
| tobiash | maybe there is an exception but without the event id | 14:34 |
| fungi | tobiash: those are line numbers from the log | 14:34 |
| tobiash | because I think this is broken: https://opendev.org/zuul/zuul/src/branch/master/zuul/driver/github/githubconnection.py#L378 | 14:34 |
| fungi | tobiash: they're sequential, so no lines appear in the log between them | 14:34 |
| tobiash | ah ok | 14:34 |
| openstackgerrit | Tobias Henkel proposed zuul/zuul master: Fix accessing the installation map in _process_event https://review.opendev.org/742211 | 14:37 |
| tobiash | I think this should fix this ^ | 14:37 |
| corvus | tobiash: how do we hit that without getting an exception? | 14:37 |
| tobiash | that's what I don't understand, does try/finally catch all exceptions? | 14:37 |
| corvus | tobiash: the exception should still be raised because it's unhandled | 14:38 |
| corvus | oh | 14:38 |
| tobiash | that's what I thought as well | 14:38 |
| corvus | fungi: the exception would be *after* the finished line | 14:39 |
| tobiash | oh right | 14:39 |
| fungi | ahh, well, my workstation's display locked up so i'm in the middle of rebooting it while the opendev conference is on a quick break, but i can look again shortly | 14:39 |
| corvus | i'll check | 14:39 |
| tobiash | I guess you'll have plenty of hits when searching for "Exception moving GitHub event" | 14:40 |
| fungi | tobiash: i did grep the log for that string earlier and had no hits | 14:40 |
| tobiash | weird | 14:40 |
| corvus | tobiash: any idea why this isn't tested? | 14:41 |
| tobiash | hrm, I think the events in the test cases don't have installation ids | 14:42 |
| tobiash | so the tests don't enter this condition | 14:42 |
| corvus | i concur with fungi there are no hits for that string, and there's nothing interesting within 100 lines of the "Finished event" log line; so it's still a mystery how we're getting out of there with no output | 14:44 |
| corvus | tobiash: i think we'll learn a lot if we can reproduce this with a test; do you think you can add/update a test to use an installation id? | 14:46 |
| fungi | yeah, no Traceback lines at all in the log after the event i'm looking at | 14:46 |
| fungi | [e: 27912c80-cb4c-11ea-9cf1-66c0ab8a82ba] | 14:46 |
| tobiash | corvus: I'll try to add a test case but maybe it makes sense in a followup since it's broken atm | 14:46 |
| corvus | tobiash: a followup is fine, but i think i'd like to see the results from the test case before we restart opendev (there's still something we don't understand about this, so we may not have the full story). | 14:48 |
| corvus | (iow, i'm happy to approve the expected fix now, but don't want to take 2 outages if we find something else when we do the test case) | 14:49 |
| corvus | tobiash: also, are you running this in prod yet? or do you not have installation ids? | 14:49 |
| fungi | yeah, i mean the situation for us is not great, but it's also not urgent since we don't really do much with github | 14:49 |
| tobiash | no, that's not yet deployed in our prod | 14:49 |
| fungi | and i agree, not restarting twice would be preferable | 14:50 |
| tobiash | k, if it's not so urgent I'll try the test case before merging the fix | 14:50 |
| corvus | i think it's fine to merge the fix | 14:50 |
| corvus | i just don't want to restart with the fix until we've at least run the test case locally :) | 14:51 |
| fungi | i concur | 14:51 |
| corvus | (because i figure since there's part of this we still don't understand, there's a 10% chance the test case might uncover something else) | 14:51 |
| fungi | so i guess connection.installation_map still exists (or else we'd be raising exceptions)? | 14:54 |
| tobiash | no, it doesn't | 14:54 |
| fungi | so something must be swallowing the exception from _process_event() as it's not inside a try/except block there | 14:57 |
| tobiash | ok, I have a quick and dirty local reproducer which fails the test but doesn't print the exception as well | 14:59 |
| tobiash | and the fix proposed makes that test green | 14:59 |
| tobiash | now I'll check why the exception is hidden | 14:59 |
| tobiash | oh I know why: https://opendev.org/zuul/zuul/src/branch/master/zuul/driver/github/githubconnection.py#L366 this sets a valid return code and prevents the exception from bubbling up | 15:02 |
| tobiash | just removing that try/finally makes the exception visible | 15:02 |
| clarkb | tobiash: can we and an exception handler there that simply logs the error then let finally run? | 15:03 |
| clarkb | that way we at least get the logging | 15:03 |
| tobiash | the exception handler there is just for logging the finished message | 15:04 |
| openstackgerrit | Fabien Boucher proposed zuul/zuul master: Remove shebang for base/library/command.py|zuul_console.py https://review.opendev.org/728955 | 15:04 |
| corvus | tobiash: wow i didn't expect that | 15:04 |
| tobiash | I think it's the return which inhibits all exceptions | 15:05 |
| corvus | tobiash: yeah, that works under normal circumstances (even just a plain function call -- doesn't need a thread pool) | 15:06 |
| corvus | til. | 15:06 |
| corvus | clarkb, fungi: seems like https://review.opendev.org/742211 is gtg if you want to +3 it | 15:06 |
| corvus | unless you want to wait for the exception handler logging | 15:06 |
| fungi | i think i'm good with it, i just wanted to understand first how we weren't getting an exception raised from that | 15:07 |
| clarkb | corvus: done | 15:07 |
| clarkb | ya I think now that we know what the problems are we can easily address those in a followup | 15:07 |
| tobiash | yepp, confirmed the return in the finally inhibits the exception even if there is an explicit raise in the handler | 15:07 |
| tobiash | because after thinking about a return 'repairs' the exception state if it's within the finally clause | 15:08 |
| tobiash | fix for the event handling is then just unindenting the return :) | 15:08 |
| *** bhavikdbavishi has joined #zuul | 15:11 | |
| openstackgerrit | Tobias Henkel proposed zuul/zuul master: Don't mask exceptions in _process_event https://review.opendev.org/742222 | 15:13 |
| openstackgerrit | Tobias Henkel proposed zuul/zuul master: Add repository and installation id to events in tests https://review.opendev.org/742223 | 15:13 |
| tobiash | logging fix and the test case (tested with one test case locally) ^ | 15:14 |
| tobiash | ftr: "If the finally clause executes a return, break or continue statement, the saved exception is discarded" from https://docs.python.org/3/reference/compound_stmts.html#the-try-statement | 15:18 |
| corvus | all approved, thanks tobiash! | 15:20 |
| tobiash | thanks for saving me from catching this in prod :) | 15:20 |
| *** bhavikdbavishi has quit IRC | 15:20 | |
| *** bhavikdbavishi has joined #zuul | 15:23 | |
| fungi | tobiash: yw! thankfully it's not as severe an impact for us as it would have been for you or others | 15:27 |
| openstackgerrit | Merged zuul/zuul master: Fix brand logo link for dashboards deployed on a sub-url https://review.opendev.org/740914 | 15:28 |
| tobiash | corvus: do you want more reviews on the change queue changes since you didn't +w them? | 15:36 |
| tobiash | (https://review.opendev.org/718531 and child) | 15:38 |
| corvus | tobiash: oh, i was going through in series and didn't want to +w until i got to the end. but then the really complicated change was at the end and i was out of brainpower, and i've forgotten to get back to it. | 15:38 |
| corvus | sorry | 15:38 |
| corvus | tobiash: i'll try to review the last change after we cut the release | 15:39 |
| tobiash | thanks! | 15:40 |
| *** yolanda has quit IRC | 15:42 | |
| corvus | we got an error on the stable/3.x branch: https://zuul.opendev.org/t/zuul/build/86a2c3b858d34aa2a1c7aa63c517b501/console#2/0/56/ubuntu-bionic | 15:42 |
| corvus | /usr/bin/python3: No module named pip | 15:42 |
| corvus | clarkb, fungi: does that make sense to you? | 15:43 |
| corvus | tobiash: oh -- https://review.opendev.org/742074 | 15:43 |
| clarkb | corvus: I374dac18b9b7e376d924b11f4661355ea7c4d149 and I3dec251d19dd7b3807848a54e6a20a8e89d30a4e probably need to be included? | 15:44 |
| *** yolanda has joined #zuul | 15:44 | |
| corvus | clarkb: i think tobiash's change may be enough? | 15:44 |
| corvus | i think the move to pre is more or less an optimization | 15:45 |
| clarkb | corvus: I think its two different jobs | 15:45 |
| clarkb | quickstart and log streamer | 15:45 |
| tobiash | at least 742074 has a green check | 15:45 |
| clarkb | maybe we only run log streamer under specific cases | 15:45 |
| clarkb | ya 742974 looks good | 15:45 |
| clarkb | *742074 | 15:45 |
| corvus | i approved it and rebased the other 2 changes on it | 15:46 |
| zbr|rover | tobiash: can you please look again at https://review.opendev.org/#/c/739482/ ? i think i addressed your concerns. | 15:48 |
| openstackgerrit | Tobias Henkel proposed zuul/zuul master: Block localhost shell tasks in untrusted playbooks https://review.opendev.org/742229 | 15:49 |
| corvus | zbr|rover: you gonna look into redux? | 15:49 |
| tobiash | remote: Block localhost shell tasks in untrusted playbooks https://review.opendev.org/742230 | 15:49 |
| clarkb | I've approved both after skimming and confirming they look the way I expected | 15:53 |
| clarkb | corvus: tobiash ^ | 15:53 |
| felixedel | clarkb: Basically the logoComponent specifies which component (or tag) should be used for the link element. By default that's an <a>. The patch changes this to a <Link> so we can utilize react-router's capabilities to get the correct relative URL | 16:00 |
| clarkb | felixedel: yup I finally tracked that down and left a link to the docs in the change that explains the <a> vs <Link> thing | 16:01 |
| tobiash | zbr|rover: auto reload still seems to be off by default (tried in multiple browsers and with private more) | 16:02 |
| tobiash | toggling seems to behave correctly now | 16:03 |
| felixedel | clarkb: Regarding your idea on https://review.opendev.org/#/c/740923/. I think this should be part of a separate change if we decide to do so. But I think other websites also use a URL schema like builds/ and build/:id (which would also reflect the URLs of the API). | 16:06 |
| openstackgerrit | Merged zuul/zuul master: Fix accessing the installation map in _process_event https://review.opendev.org/742211 | 16:06 |
| *** marios has quit IRC | 16:07 | |
| corvus | clarkb: if you're in a web-space, https://review.opendev.org/740345 and parent could use a +w | 16:13 |
| openstackgerrit | Merged zuul/zuul master: Don't mask exceptions in _process_event https://review.opendev.org/742222 | 16:16 |
| zbr|rover | tobiash: going to test the default value now. | 16:20 |
| openstackgerrit | Merged zuul/zuul master: Add repository and installation id to events in tests https://review.opendev.org/742223 | 16:22 |
| *** hamalq has joined #zuul | 16:27 | |
| *** hamalq has quit IRC | 16:28 | |
| *** bhavikdbavishi has quit IRC | 16:28 | |
| openstackgerrit | Sorin Sbarnea (zbr) proposed zuul/zuul master: Enable optional pre-wrapping on console and output https://review.opendev.org/723603 | 16:28 |
| *** hamalq has joined #zuul | 16:29 | |
| *** bhavikdbavishi has joined #zuul | 16:30 | |
| openstackgerrit | Sorin Sbarnea (zbr) proposed zuul/zuul master: Enable optional pre-wrapping on console and output https://review.opendev.org/723603 | 16:33 |
| corvus | zbr|rover: if you're interested in learning about redux i can answer questions and give you pointers | 16:40 |
| zbr|rover | corvus: clearly that I am because i wasn't able to figure it out from my initial attempts. | 16:42 |
| zbr|rover | sadly the attention lifespan is close to a goldfish, i always endup being pinged to fix something else before i managed to get it right. | 16:43 |
| zbr|rover | good part is the the ^ above adds preferences w/o need for redux, at least it will make the other change easier to review. | 16:43 |
| zbr|rover | making wrapping configurable works with pure css variables quite nice | 16:44 |
| zbr|rover | i was impressed to get it working from 1st attempt | 16:44 |
| corvus | zbr|rover: :) okay so the way i see it is that it's a pretty simple system that has been made unecessarily complex and hard to understand. basically there's a thing called a reducer which is just a function that updates a central state object. redux calls the reducer and updates the state object with the value it returns. there's an action which is really just a string constant. there's a function | 16:46 |
| corvus | associated with the action which sends that string constant to redux, and it calls the appropriate reducer. so when you "dispatch" an "action", redux calls the "reducer" for the action and updates the state. | 16:46 |
| zbr|rover | clarkb: do you remember asking me about cmd changes? here is how it looks now, without pre: https://sbarnea.com/ss/Screen-Shot-2020-07-21-17-45-42.64.png | 16:46 |
| corvus | zbr|rover: it looks like the timezone feature uses redux, and is fairly self-contained, you can probably use that as a model for most of it. | 16:46 |
| corvus | zbr|rover: the extra part will be that we'll need to set the initial/default value of the state to something loaded from localStorage, and write to localStorage whenever it's updated. that means that the reducer function should write out to local storage. | 16:47 |
| zbr|rover | probably we need a generic preferences loader that loads all of them, so we do not have to reimplement it for each option we add. | 16:48 |
| corvus | zbr|rover: agreed, we can have a preferences object and each of the preferences being an attribute on the object | 16:49 |
| corvus | (then serialize that object to json for storage) | 16:49 |
| zbr|rover | i kinda like keeping settings as individual entries in localStorage, makes it much easier to debug and tune. | 16:50 |
| zbr|rover | do we have any performance limitations from using individual keys for each option? | 16:50 |
| zbr|rover | i know it supports few MB of data, so I doubt "blob" approach is really needed. | 16:50 |
| corvus | zbr|rover: it's easy to debug a json serialized string in storage. that lets us save/load the entire preference blob in one line. i think it's going to be a lot more concise. | 16:51 |
| *** bolg has quit IRC | 17:01 | |
| *** jpena is now known as jpena|off | 17:05 | |
| *** yolanda has quit IRC | 17:10 | |
| *** bhavikdbavishi has quit IRC | 17:10 | |
| *** yolanda has joined #zuul | 17:13 | |
| *** nils has quit IRC | 17:15 | |
| *** hamalq has quit IRC | 17:16 | |
| *** hamalq has joined #zuul | 17:16 | |
| openstackgerrit | Tobias Henkel proposed zuul/zuul master: Block localhost shell tasks in untrusted playbooks https://review.opendev.org/742229 | 17:18 |
| tobiash | clarkb, corvus: that needed a small fix for the zuul-stream tests ^ | 17:19 |
| tobiash | there was a bug lurking in the test that hit us now: https://review.opendev.org/#/c/742229/2/playbooks/zuul-stream/templates/ansible.cfg.j2 | 17:19 |
| tobiash | remote: Block localhost shell tasks in untrusted playbooks https://review.opendev.org/742230 | 17:21 |
| corvus | tobiash, clarkb: i re +3d; i think clarkb is afk but i'm sure he'd be okay with that fix :) | 17:24 |
| *** jcapitao has quit IRC | 17:26 | |
| fungi | is that a backport from master? | 17:30 |
| fungi | ahh, yeah now i see 742229 | 17:32 |
| tobiash | yes, cherry pick | 17:32 |
| tobiash | I didn't really have to 'backport' it :) | 17:32 |
| fungi | fair | 17:33 |
| fungi | if you cherry-pick -x then it will add a line to the commit message referencing the original commit id too | 17:34 |
| tobiash | thanks for the hint for next time, this time I was lazy and just hit the cherry pick button in gerrit | 17:36 |
| fungi | can sometimes help with clarity, though in this case i think we all understand that basically everything on that temporary stable/3.x branch is taken from changes in master | 17:36 |
| fungi | and it's not like we expect to be doing this all the time | 17:37 |
| fungi | ahh, that was the cherry-pick button, got it | 17:37 |
| tobiash | well, we already have two cherry picks on the stable branch... | 17:37 |
| tobiash | but anyway, thanks for that tip, I never used cherry-pick -x yet :) | 17:39 |
| openstackgerrit | Merged zuul/zuul master: Keep active nav links highlighted while browsing the page https://review.opendev.org/740923 | 17:39 |
| tobiash | remote: https://review.opendev.org/742260 Create virtualenvs in series to avoid cache race | 17:43 |
| tobiash | clarkb, corvus: the stable branch needs another cherry-pick for the stream tests ^ | 17:43 |
| tobiash | fungi: now used cherry-pick -x :) | 17:43 |
| tobiash | but it looks odd having that comment beneath the change id so I reordered that part of the commit message | 17:44 |
| fungi | oh, yeah the change-id does have to be in the last "paragraph" | 17:44 |
| openstackgerrit | Sorin Sbarnea (zbr) proposed zuul/zuul master: Enable optional pre-wrapping on console and output https://review.opendev.org/723603 | 17:52 |
| openstackgerrit | Merged zuul/zuul master: Block localhost shell tasks in untrusted playbooks https://review.opendev.org/742229 | 18:15 |
| *** vishalmanchanda has quit IRC | 18:26 | |
| corvus | felixedel: i've noticed on the status page that pageup/down doesn't seem to scroll | 18:51 |
| clarkb | neither does spacebar fwiw | 18:52 |
| fungi | was anyone able to work out why the x11 primary selection buffer no longer gets populated when console stream text is highlighted with the pointer? | 18:53 |
| clarkb | fungi: fwiw that rarely works for me in ff or chrome | 18:57 |
| clarkb | I have to right click copy and then right click paste in my DE for whatever reason | 18:57 |
| fungi | i think some javascripty lib must be capturing mouseclicks or selection events | 19:10 |
| ianw | i like whatever happened to the UI since i last looked; one weird thing on mine is that the hosts under "Results" are much smaller font size than everything else (https://imgur.com/a/91hKUDD). it looks a bit weird to me | 19:47 |
| corvus | ianw: https://review.opendev.org/740121 | 19:47 |
| corvus | and child | 19:48 |
| clarkb | also I think it broke the whitelabeled setup for openstack | 19:48 |
| clarkb | I'm not sure if that is just browser cache problems though | 19:48 |
| corvus | clarkb: wfm | 19:48 |
| clarkb | ah yup it seems to workfor me now too. likely was just caches | 19:48 |
| ianw | corvus: cool ... the site preview link there doesn't work? https://9f9df69279350fd5a76c-d6fd3b06d50c034d0364bbf684ea1b1c.ssl.cf1.rackcdn.com/740121/1/check/zuul-build-dashboard-opendev/8132036/npm/html/ | 19:51 |
| corvus | ianw: maybe try the child? | 19:52 |
| ianw | corvus: yeah, that seems to | 19:53 |
| ianw | i still feel like the size is wrong with the child change | 19:54 |
| corvus | ianw: oh, yeah, i think my change doesn't fix that | 19:54 |
| ianw | ... interesting ... if i narrow the window, the font gets bigger, make it wider, and it gets smaller | 19:55 |
| ianw | i also don't see any buttons next to "Results" which i feel like maybe i should with that child change | 19:55 |
| corvus | ianw: it's in the console tab, not the results section | 19:56 |
| ianw | corvus: here's what i'm seeing ... https://imgur.com/a/KcrbuAy | 20:02 |
| ianw | when i pull it inwards, i think the font size goes from 12 to 16 point | 20:02 |
| ianw | (to be clear, 16px makes it look consistent) | 20:04 |
| corvus | ianw: yep i'm seeing it too | 20:11 |
| ianw | i have something that fixes it for me ... | 20:11 |
| corvus | i fixed a similar issue on a different page | 20:11 |
| corvus | 2 weeks ago | 20:11 |
| corvus | was just hoping someone would approve the change | 20:12 |
| corvus | i think we should merge that, and merge the build page refactor before the backlog becomes too large | 20:12 |
| openstackgerrit | Ian Wienand proposed zuul/zuul master: ui: make list-group-item-heading same size as other fonts https://review.opendev.org/742274 | 20:12 |
| corvus | tobiash: https://review.opendev.org/742271 | 20:13 |
| corvus | tobiash: i think that's only other thing we said we were going to put in 3.19.1? so we should land that and then cut a release? | 20:13 |
| tobiash | ++ | 20:14 |
| tobiash | clarkb: you mean selecting in the live log stream? | 20:17 |
| tobiash | I think there we need to handle the key combimations ourselves if I remember correctly | 20:19 |
| corvus | ianw: are you going to leave a review on https://review.opendev.org/740345 and parent? | 20:21 |
| ianw | corvus: i can, if "i played with this" is sufficient :) | 20:22 |
| corvus | i think so :) | 20:23 |
| mnaser | is there a good example of a change that does multiarch image builds? | 20:25 |
| mnaser | or switched an image to using multiarch | 20:25 |
| tobiash | mnaser: I think nodepool does multiarch in the meantime (if the jobs are fixed already) | 20:29 |
| tobiash | mnaser: or maybe not yet, this is the latest attempt to fix those: https://review.opendev.org/#/c/741942 | 20:30 |
| mnaser | oh wow that seems to be quite a performance hit | 20:31 |
| mnaser | i was looking to build a small golang docker image, maybe that might be a lot less of an impact | 20:31 |
| mnaser | ok ill try it for a very tiny golang project and see what happens | 20:33 |
| corvus | mnaser: we're building under qemu, so anything we have to compile is really slow | 20:33 |
| corvus | otherwise, it's not too bad | 20:33 |
| mnaser | corvus: if a cloud has nested virt, does that actually have an impact/use a speed up? | 20:33 |
| mnaser | oh wait, nevermind | 20:34 |
| mnaser | this is a different architecture | 20:34 |
| clarkb | corrwct neated virt only helps for same arch | 20:34 |
| clarkb | and I cant type | 20:34 |
| mnaser | ok, seems to work, though i had a GOARCH=amd64 that i just had to remove | 20:51 |
| *** y2kenny has joined #zuul | 21:12 | |
| mnaser | time="2020-07-21T21:03:36Z" level=fatal msg="Error initializing image from source docker://127.0.0.1:60319/vexxhost/node-labeler:latest: unsupported docker v2s2 media type: \"application/vnd.oci.image.layer.v1.tar+gzip\"" | 21:22 |
| mnaser | did i do something wrong? | 21:22 |
| corvus | mnaser: that msg is not familiar to me; more context? | 21:22 |
| mnaser | corvus: i was trying to enable multi-arch builds for this very small golang project - https://review.opendev.org/#/c/742276/2 | 21:23 |
| corvus | i think our reno setup is really unhappy with multiple branches | 21:23 |
| corvus | this is the preview build for the tip of 3.x: https://7c3f904deee39351719a-9c035ca54e1e355b36ad4d338836f375.ssl.cf1.rackcdn.com/742271/1/gate/zuul-tox-docs/ac36a3a/docs/reference/releasenotes.html | 21:24 |
| clarkb | corvus: reno jobs should only run from master branch | 21:24 |
| corvus | it's empty | 21:24 |
| mnaser | and the image built fine, but then the push-to-intermediate-registry blew up | 21:24 |
| clarkb | at least that is how openstack has dealt with reno confusion there | 21:24 |
| clarkb | mnaser: is your intermediate registry up to date? there were a number of bugs fixed around it | 21:24 |
| corvus | clarkb: so the next time we land a master change after 3.19.1 is tagged, it should show up there? | 21:24 |
| mnaser | clarkb: patch is on opendev.. so it should be? :) | 21:25 |
| corvus | clarkb: but in the mean time, we don't have a way to preview what the 3.19.1 reno section will have? | 21:25 |
| clarkb | corvus: yes aiui reno will evaluate all the branches | 21:25 |
| clarkb | I'm not sure about the preview question | 21:25 |
| openstackgerrit | Merged zuul/zuul master: Web: Adjust console tab type sizes for pf4 https://review.opendev.org/740121 | 21:25 |
| corvus | cause as it stands, i don't actually know if we have any release notes for 3.19.1, and it seems like we should | 21:25 |
| openstackgerrit | Merged zuul/zuul master: Add an icon next to result buttons on the console log https://review.opendev.org/740345 | 21:25 |
| mnaser | and my job is `vexxhost-build-docker-image` which is nothing but a child of `opendev-build-docker-image` | 21:25 |
| corvus | mnaser: https://bugzilla.redhat.com/show_bug.cgi?id=1794167 seems relevant? | 21:29 |
| openstack | bugzilla.redhat.com bug 1794167 in ansible-role-tripleo-modify-image "buildah builds images that podman can't pull (unsupported docker v2s2 media type: "")" [High,Closed: errata] - Assigned to aschultz | 21:29 |
| corvus | mnaser: maybe we need to add the --format docker argument to our buildx invocation? | 21:30 |
| corvus | i don't know why we haven't hit this with nodepool though | 21:30 |
| corvus | clarkb: i guess i should tag locally and do a reno build? | 21:31 |
| mnaser | corvus: maybe it's because something something the base image i use is golang and it has something something that causes this? | 21:31 |
| corvus | mnaser: could be | 21:31 |
| clarkb | corvus: ya that may be the easiest thing? I don't really have better ideas. smcginnis may though? | 21:32 |
| corvus | smcginnis: (wondering what's the best way to find out what the release notes will look like for a release on a non-master branch -- the preview job doesn't seem to produce any output: https://7c3f904deee39351719a-9c035ca54e1e355b36ad4d338836f375.ssl.cf1.rackcdn.com/742271/1/gate/zuul-tox-docs/ac36a3a/docs/reference/releasenotes.html ) | 21:32 |
| smcginnis | corvus: Typically you need to have some sort of landing page that will pull in the notes for that branch. | 21:37 |
| smcginnis | corvus: Kind of like what we do for stable branch release notes: https://opendev.org/openstack/cinder/raw/branch/master/releasenotes/source/ussuri.rst | 21:38 |
| smcginnis | corvus: So looks like you would need a file that includes a directive to pull in stable/3.x | 21:38 |
| corvus | hrm; i just want all the versions on one page | 21:39 |
| corvus | i tagged 3.19.1 locally, ran tox-docs, and got no output just like the preview | 21:40 |
| smcginnis | corvus: You can do that. You would just need something like an index.rst that includes that directive for each branch you want to show. | 21:40 |
| corvus | this is an ephemeral branch though | 21:40 |
| corvus | it's about to be deleted | 21:40 |
| corvus | will it show up in master after i merge the branch into master? | 21:41 |
| smcginnis | dhellmann might know a better way, but doesn't look like he's present. | 21:41 |
| smcginnis | corvus: Where is the release notes source docs? I see the notes in zuul/zuul, but not the rst files. | 21:41 |
| corvus | i added a branch directive to that, and it only pulled in 3.19.0 | 21:41 |
| corvus | smcginnis: doc/source/reference/releasenotes.rst | 21:42 |
| smcginnis | I *think* if it doesn't specify the branch, it should just pick up local changes. | 21:42 |
| smcginnis | Hmm | 21:42 |
| smcginnis | Trying to build that one locally. | 21:44 |
| corvus | this is unfortunate -- i merged 3.x into master locally and ran the build, and got the same thing as we're currently publishing: https://zuul-ci.org/docs/zuul/reference/releasenotes.html | 21:44 |
| corvus | (which is incorrect, that should have all of the releases ever) | 21:44 |
| corvus | i'm afraid we've somehow made a hash of this :( | 21:45 |
| smcginnis | Yeah, something doesn't look right here. | 21:45 |
| corvus | https://zuul-ci.org/docs/zuul/3.19.0/reference/releasenotes.html | 21:45 |
| corvus | that's the page from the last release, so what we're publishing should look like that plus the in-development section at the top | 21:45 |
| smcginnis | corvus: Have there been release notes added since 3.19.0? I don't see one being added in the patch you referenced. | 21:46 |
| corvus | smcginnis: i suspect not (that was the original question i set out to answer) | 21:46 |
| fungi | if you locally tag a 3.19.1 on stable/3.x and then merge it back into master do you get release notes for it? or is that what you're trying? | 21:46 |
| corvus | fungi: that's what i tried and got the same thing that is currently published | 21:47 |
| corvus | fungi: (the in-development section only) | 21:47 |
| smcginnis | So I think if you don't specify branch, it only goes back to the last tag. So if there aren't any other release notes added, that may make sense. | 21:48 |
| corvus | smcginnis: so if we assume there are no release notes, and some kind of behavior switch has happened to cause reno to only show the most recent notes, then both builds are "correct" according to those rules -- 3.x (3.19.1) has zero notes, and master has only the in-development ones. but the critical error is that master should also have all the previous releases. | 21:48 |
| corvus | smcginnis: until recently, that has not been the case -- our builds had all the releases https://zuul-ci.org/docs/zuul/3.19.0/reference/releasenotes.html | 21:49 |
| smcginnis | Yeah, based on the 3.19.0 release notes page you linked. | 21:49 |
| corvus | (i think we can live with 3.19.1 having a screwed up release notes page, but the master one being broken is a showstopper) | 21:49 |
| fungi | and if you tag 3.19.1 on the stable/3.x branch but don't merge it back to master what does reno on master do? | 21:50 |
| clarkb | did adding the branch change reno behavior? | 21:50 |
| *** Goneri has quit IRC | 21:50 | |
| corvus | fungi: checking; clarkb i have lots of branches locally, i'd think this wouldn't be any different | 21:51 |
| fungi | oh, good point, maybe tag 3.19.1 on the stable/3.x branch but don't merge it back to master *and* then delete the stable/3.x branch | 21:51 |
| fungi | just to rule out reno treating stable/.* branch presence specially | 21:51 |
| corvus | fungi: same behavior (in development only) with 3.19.1 tagged on stable/3.x and not merged to master then running tox -edocs on master | 21:51 |
| corvus | i'll delete stable now | 21:51 |
| fungi | if that's the case, then may also want to try with less-recent reno if there's been a very recent release... checking | 21:52 |
| corvus | i deleted my local branch; i wonder if it looks at remotes? | 21:52 |
| corvus | same behavior | 21:53 |
| fungi | reno 3.1.0 was 2020-05-14 | 21:53 |
| smcginnis | Looking at a git diff 3.19.0...HEAD, I'm not seeing anything that looks like it should have affected this. | 21:53 |
| corvus | trying with reno 3.0.1 | 21:55 |
| corvus | same | 21:56 |
| fungi | does deleting the 3.19.1 tag restore the old behavior? | 21:57 |
| corvus | fungi: nope, same behavior | 21:57 |
| fungi | that's really strange | 21:57 |
| fungi | so the only things for it to be keying on at that point are recent commits in master | 21:58 |
| corvus | i just tried it in a clean checkout and got the same behavior | 21:59 |
| smcginnis | corvus: You had tested with 3.0.1, not 3.1.0, right? | 22:00 |
| corvus | smcginnis: both | 22:00 |
| smcginnis | I see a couple of potential suspects commits to reno, but they were both added in 3.1.0. | 22:01 |
| corvus | let me try a clean tree with 3.0.1 | 22:01 |
| corvus | (the clean tree test got 3.1.0 for obvious reasons) | 22:01 |
| smcginnis | Timing-wise, 3.0.1 should have been what was used for 3.19.0, but you could try reno 3.0.0 to be really safe. | 22:02 |
| corvus | 3.0.1 on clean tree has the same behavior | 22:04 |
| corvus | will try with 3.0.0 | 22:04 |
| *** decimuscorvinus has quit IRC | 22:06 | |
| corvus | same behavior | 22:06 |
| fungi | i wonder how we got it to build those currently published release notes then | 22:07 |
| corvus | me too | 22:07 |
| *** decimuscorvinus has joined #zuul | 22:11 | |
| fungi | yeah, even if i reset master to 3.19.0 i get the same | 22:13 |
| corvus | i'm stumped | 22:14 |
| fungi | actually, no, it's not building the release notes at all for me | 22:14 |
| fungi | `tox -e docs` is expected to build them? | 22:14 |
| corvus | fungi: yeah, if i build 3.19.0 i get a blank page (versus master where i get only the notes after 3.19.0) | 22:15 |
| corvus | fungi: and yes | 22:15 |
| corvus | re tox | 22:15 |
| corvus | what does this mean from reno: got versions [] | 22:15 |
| fungi | yep, okay, that matches what i'm seeing then | 22:15 |
| smcginnis | I think that means it scanned through and didn't find anything. | 22:15 |
| smcginnis | Which explains why it's blank, but doesn't explain what the heck changed. | 22:16 |
| corvus | got versions ['3.19.0-77'] | 22:16 |
| corvus | that's what i get on master | 22:16 |
| corvus | and [] on the blank pages | 22:16 |
| fungi | i wonder if some recent behavior change in setuptools could be at fault | 22:17 |
| openstackgerrit | Sean McGinnis proposed zuul/zuul master: Add reno configuration settings https://review.opendev.org/742296 | 22:18 |
| fungi | though no, reno should be looking at git versions not python versionbs | 22:18 |
| smcginnis | That should do it ^^ | 22:18 |
| smcginnis | But I still don't like that we don't know why that is now needed. | 22:18 |
| corvus | smcginnis: i agree that works as expected | 22:19 |
| corvus | let me try redoing the 3.19.1 tag and see what happens | 22:20 |
| corvus | i'm going to output some test results here, so to be clear, i'll repeat the first one i did: | 22:21 |
| corvus | master, no tags or stable branch, with smcginnis patch: works as expected (in development followed by all previous releases) | 22:21 |
| corvus | stable/3.x with smcginnis patch: works as expected (3.19.0 and previous releases -- no release notes on 3.19.1 branch yet) | 22:22 |
| corvus | stable/3.x with smcginnis patch and a new release note: works as expected (in development followed by all previous releases) | 22:24 |
| smcginnis | So all looks right now? | 22:25 |
| corvus | stable/3.x with smcginnis patch and a new release note, tagged as 3.19.1: works as expected (3.19.1 and all previous releases) | 22:25 |
| corvus | smcginnis: so far so good; going to test a few more things | 22:25 |
| smcginnis | Whew | 22:25 |
| corvus | build on master with smcginnis patch, and previous stable/3.x branch and tag also existing locally: works as expected (in development from master and 3.19.0 and previous releases) | 22:26 |
| corvus | build on master with smcginnis patch and stable/3.x (tagged as 3.19.1) merged into master: not as expected: it only shows in development features | 22:30 |
| corvus | smcginnis: ^ if we merge stable/3.x back into master, i'd expect it to find all the releases (3.19.1 from the stable branch and 3.19.0 and all prior from the shared branch history), but it doesn't; instead it only finds the in-development notes. any idea why? | 22:32 |
| corvus | i feel like "stop_at_branch_base: false" says don't do that | 22:35 |
| fungi | is that even after deleting the stable/3.x branch? | 22:35 |
| corvus | no didn't try that | 22:36 |
| corvus | fungi: same behavior | 22:36 |
| corvus | smcginnis: is there a way to get debug output from reno? | 22:37 |
| corvus | (maybe if i run it outside of sphinx?) | 22:37 |
| fungi | i want to say the reason openstack stopped merging stable branch tags back into master was that it "confused" reno. i'll grant when i suggested the temporary branch i wasn't considering the need for release notes in things we tagged on it appearing on the master branch release notes | 22:37 |
| fungi | though maybe there's a way to make reno not get confused by it these days | 22:38 |
| corvus | i don't know, but my perspective is that i never want to not have release notes | 22:38 |
| corvus | i'm simple that way | 22:38 |
| corvus | i found: reno -v report >/dev/null | 22:41 |
| corvus | i'm trying to see if there are any clues in that output | 22:41 |
| fungi | or maybe reno has a provision for manual additions? that's one of the reasons i've been wary about it in the past is over concern that there's no way to fix up whatever it generates or add stuff after the fact | 22:41 |
| corvus | fungi: manual additions of what? | 22:42 |
| fungi | releases | 22:42 |
| corvus | fungi: manually tell it to add each of the previous tags? | 22:42 |
| corvus | that sounds tedious | 22:42 |
| fungi | just the one on the temporary branch i mean | 22:42 |
| corvus | oh | 22:42 |
| corvus | i would rather the tail (reno) not wag the dog (git) on this | 22:43 |
| fungi | though maybe the other concern is that you want the tag from the temporary branch to also appear in master's history? | 22:43 |
| corvus | yes, i think that most closely expresses our view of the development history in graph form | 22:43 |
| fungi | got it. i also hadn't considered that desire when suggesting the temporary branch because openstack had given up on merging tags back into master when it adopted reno | 22:44 |
| fungi | but point is, reno seems mostly adapted to openstack's release workflows | 22:45 |
| corvus | ignoring null-merge commits | 22:45 |
| corvus | treating b'7ce9cd026606a2488e6af3d632aa2c4a21ebff54' as a null-merge because parent b'd1e48428f8d3e9f95089ccce66d4268ed532e6f8' has tag( | 22:45 |
| corvus | s) ['3.19.1'] | 22:45 |
| corvus | i wonder if that's relevant | 22:45 |
| fungi | https://review.openstack.org/470023 introduced that check | 22:46 |
| corvus | +ignore_null_merge: false | 22:48 |
| corvus | that does correct the behavior | 22:48 |
| *** rlandy|ruck is now known as rlandy|ruck|bbl | 22:48 | |
| corvus | i feel like the erroneous behavior doug describes is the behavior that i desire | 22:48 |
| corvus | well actually | 22:49 |
| corvus | it ended up putting the in-development notes under 3.19.1 | 22:49 |
| corvus | i'm assuming if we merged 3.19.1 into master after we made a release, it might work as expected? | 22:50 |
| corvus | that's not ideal though | 22:51 |
| fungi | not sure, it might just put all the 4.0.0 release notes under 3.19.1 | 22:51 |
| corvus | so at the moment, we still have no way to build a page with all the notes of all the releases. | 22:52 |
| fungi | the mechanism by which reno tries to match notes file additions up with tags in which they appear is likely seeing those files getting added before the 3.19.1 tag merged to master | 22:52 |
| corvus | to be honest, i'm wondering if we should revert everything in master back to 3.19.0, make our patches, make a 3.19.1 release, then unrevert everything after | 22:52 |
| corvus | and never do this again | 22:52 |
| fungi | i'm questioning the utility of reno for projects which don't follow openstack's release workflows | 22:53 |
| fungi | the assumptions it makes about git history are fragile | 22:53 |
| fungi | granted, i also thought openstack had a merged release notes for all its versions rather than per-branch release notes | 22:54 |
| fungi | but apparently they do not | 22:55 |
| fungi | maybe if reno grew a means of being able to retroactively associate specific notes with specific releases, to correct its autodetection failures | 22:56 |
| *** y2kenny has quit IRC | 22:59 | |
| *** Goneri has joined #zuul | 22:59 | |
| corvus | fungi: to answer an earlier question -- merging 3.19.1 after 4.0.0 is tagged looks correct | 23:00 |
| corvus | so it's just that the un-tagged notes get "tagged" once we merge 3.19.1 into master | 23:00 |
| corvus | if they already show up in 4.0.0, then it's fine | 23:00 |
| corvus | maybe we could remove the in-development release notes, tag 3.19.1, merge it to master, then re-add the release notes | 23:01 |
| fungi | oh, i hadn't thought of that. could actually work | 23:01 |
| corvus | it's easier than removing all the code :/ | 23:02 |
| corvus | i'll try that | 23:02 |
| fungi | right, the blunt force solution would be a squashed revert of everything after 3.19.0, cherry-picking all commits (except .gitreview) from stable/3.x into master, deleting stable/3.x branch, tagging 3.19.1 on master, and then reverting the revert with some merge conflict resolution for the stuff picked earlier | 23:02 |
| fungi | which also basically creates two new bisect event horizons, so messy | 23:02 |
| corvus | still working on that test | 23:09 |
| corvus | nope that doesn't work | 23:10 |
| corvus | as soon as we un-revert the notes, they end up in 3.19.1 | 23:10 |
| corvus | though... | 23:10 |
| corvus | i guess we can re-add them with different uids | 23:11 |
| corvus | that does look like it will work | 23:15 |
| openstackgerrit | Pierre-Louis Bonicoli proposed zuul/zuul-jobs master: Use ansible_distribution* facts instead of ansible_lsb https://review.opendev.org/742310 | 23:15 |
| corvus | we're going to have an increasing amount of "unable to find release notes file" spam, but we can live with that; we might be able to add those to an ignore list | 23:15 |
| corvus | zuul-maint: it looks like there's a difficulty using reno with releases made from temporary branches; i think we can work around it. here's the process: | 23:17 |
| corvus | 1) add release notes to stable/3.x about the security update and the other important fixes. this can be done in one new commit. | 23:17 |
| corvus | 2) add the reno options to stable/3.x | 23:17 |
| corvus | 3) release 3.19.1 from stable/3.x | 23:18 |
| corvus | 4) remove the pending release notes from master | 23:18 |
| corvus | 5) merge stable/3.x into master and delete the branch | 23:18 |
| corvus | 6) re-add the pending release notes to master under a new filename | 23:18 |
| corvus | [eol] | 23:18 |
| corvus | fungi, smcginnis: ^ that look good? | 23:18 |
| corvus | it's been a long day for me, i need to eod, i'll pick this up tomorrow | 23:21 |
| clarkb | for step 5 its a ours/theirs to just tie the history but not change cod eright? | 23:33 |
| fungi | it's probably all the same since the changes on stable/3.x since branching are just cherry-picks (aside from the .gitreview adjustment and release note additions) | 23:34 |
| fungi | corvus: that seems reasonable. i guess tagging before we remove the release notes on master is fine so long as it's before we merge stable/3.x back in | 23:36 |
| *** Goneri has quit IRC | 23:36 | |
| fungi | er, so long as they're removed from master before we merge back in | 23:36 |
| corvus | clarkb: yes. currently there's a minor conflict related to the quickstart, but i expect us to resolve in favor of the master branch; fungi yes i think that's fine based on seeing the correct output from reno on the stable branch (did not include orphaned master notes) | 23:39 |
| *** iurygregory has quit IRC | 23:42 | |
| dmsimard | o/ long time no see | 23:43 |
| dmsimard | I know there are people who like TTYs and CLIs here :P currently iterating on CLI for ara and thought you might be interested: http://paste.openstack.org/show/796192/ | 23:44 |
| dmsimard | it's very rough, it might not be the right columns in the right order but it's there and it works | 23:45 |
| *** tosky has quit IRC | 23:47 | |
| openstackgerrit | Pierre-Louis Bonicoli proposed zuul/zuul-jobs master: Avoid to use 'length' filter with null value https://review.opendev.org/742316 | 23:52 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!
