| *** edmondsw has joined #openstack-powervm | 00:45 | |
| *** edmondsw has quit IRC | 00:59 | |
| *** edmondsw has joined #openstack-powervm | 01:00 | |
| *** edmondsw has quit IRC | 01:05 | |
| *** Sphericus has joined #openstack-powervm | 01:48 | |
| *** fried_rice is now known as efried | 02:27 | |
| *** edmondsw has joined #openstack-powervm | 04:28 | |
| *** edmondsw has quit IRC | 04:32 | |
| *** edmondsw has joined #openstack-powervm | 06:16 | |
| *** edmondsw has quit IRC | 06:20 | |
| *** Sphericus has quit IRC | 06:47 | |
| *** k0da has joined #openstack-powervm | 07:32 | |
| *** edmondsw has joined #openstack-powervm | 08:04 | |
| *** edmondsw has quit IRC | 08:08 | |
| *** edmondsw has joined #openstack-powervm | 09:52 | |
| *** edmondsw has quit IRC | 09:56 | |
| *** smatzek has joined #openstack-powervm | 11:25 | |
| *** edmondsw has joined #openstack-powervm | 11:40 | |
| *** edmondsw has quit IRC | 11:44 | |
| *** jpasqualetto has joined #openstack-powervm | 12:01 | |
| *** edmondsw has joined #openstack-powervm | 12:01 | |
| *** edmondsw has quit IRC | 12:03 | |
| *** mdrabe has joined #openstack-powervm | 12:41 | |
| *** edmondsw has joined #openstack-powervm | 12:43 | |
| *** edmondsw_ has joined #openstack-powervm | 12:56 | |
| *** edmondsw_ has quit IRC | 12:59 | |
| *** esberglu has joined #openstack-powervm | 13:26 | |
| esberglu | efried: edmondsw: Fyi This weekend a bunch of the zuul merger nodes froze up. I think it must be related to the network issues we were having last week | 13:28 |
|---|---|---|
| efried | ight | 13:28 |
| esberglu | The same thing happened once before when the network was being iffy | 13:28 |
| edmondsw | something we can get back up again quickly? | 13:29 |
| esberglu | edmondsw: Yeah. I just have to run the zuul merger playbook (15 minutes). I was just thinking of how to avoid this in the future | 13:29 |
| esberglu | All we have to do is restart the zuul merger service | 13:29 |
| edmondsw | avoid, or recover? | 13:29 |
| esberglu | Recover | 13:30 |
| edmondsw | if you can devise an easy test, could make a cron job the runs the test and triggers the playbook | 13:30 |
| esberglu | Yeah was just about to say that | 13:30 |
| esberglu | I just have to figure out how to detect that the service is mucked up | 13:31 |
| *** edmondsw_ has joined #openstack-powervm | 13:31 | |
| *** thorst has joined #openstack-powervm | 13:31 | |
| esberglu | Because if you restart zuul-merger while it's doing a merge I'm pretty sure it will report to the job as a merge failure | 13:31 |
| esberglu | Otherwise we could just cron in such a way that they aren't restarting at the same time | 13:32 |
| *** edmondsw_ has quit IRC | 13:32 | |
| *** k0da has quit IRC | 13:37 | |
| *** kylek3h has joined #openstack-powervm | 13:37 | |
| *** smatzek has quit IRC | 13:54 | |
| *** esberglu has quit IRC | 13:59 | |
| *** esberglu has joined #openstack-powervm | 14:00 | |
| *** esberglu has quit IRC | 14:04 | |
| *** edmondsw_ has joined #openstack-powervm | 14:05 | |
| *** edmondsw_ has quit IRC | 14:09 | |
| *** smatzek has joined #openstack-powervm | 14:14 | |
| *** esberglu has joined #openstack-powervm | 14:32 | |
| *** dwayne has joined #openstack-powervm | 14:40 | |
| edmondsw | esberglu left you some comments on 5507, just readme stuff | 14:48 |
| esberglu | edmondsw: Cool. I think that is a good enough solution for now. We can look into the cron thing if this becomes a persistent issue | 14:49 |
| edmondsw | sure | 14:49 |
| openstackgerrit | Eric Berglund proposed openstack/nova-powervm master: DNM: ci check https://review.openstack.org/328315 | 14:57 |
| *** k0da has joined #openstack-powervm | 15:04 | |
| openstackgerrit | Eric Berglund proposed openstack/nova-powervm master: DNM: CI Check2 https://review.openstack.org/328317 | 15:07 |
| *** k0da has quit IRC | 15:24 | |
| *** dwayne has quit IRC | 16:21 | |
| openstackgerrit | Eric Fried proposed openstack/nova-powervm master: Clean up log messages https://review.openstack.org/476695 | 16:39 |
| openstackgerrit | Eric Fried proposed openstack/nova-powervm master: Clean up log messages https://review.openstack.org/476695 | 16:42 |
| *** dwayne has joined #openstack-powervm | 18:26 | |
| *** k0da has joined #openstack-powervm | 18:30 | |
| esberglu | efried: edmondsw: thorst: The network issues took down more stuff than I realized. I think what happened was that they caused jobs to fail before they were cleaned up | 18:53 |
| esberglu | I'm rebuilding it now | 18:53 |
| edmondsw | esberglu ack | 18:53 |
| edmondsw | esberglu where does BASE_LOG_PATH come from? I see it referenced, but not set, in both neo-os-ci and powervm-ci | 18:54 |
| esberglu | edmondsw: BASE_LOG_PATH is passed into jenkins from zuul | 18:55 |
| edmondsw | esberglu what does the value look like / mean? | 18:56 |
| esberglu | edmondsw: It's from the git ref | 18:56 |
| esberglu | ex. refs/changes/15/328315/54 | 18:56 |
| esberglu | BASE_LOG_PATH would be 15/328315/54 | 18:56 |
| edmondsw | seems like an odd name... what does it have to do with LOG? | 18:57 |
| esberglu | It gets used to setup the logserver directories | 18:57 |
| edmondsw | and if it doesn't start with a slash, why don't we have to add a slash here: | 18:58 |
| esberglu | So if you have multiple patchsets they will have the same parent directory which is the change number | 18:58 |
| edmondsw | if ! $FORCE || [ "$ZUUL_PROJECT""$BASE_LOG_PATH" ]; then | 18:58 |
| esberglu | edmondsw: It could start with a slash I would have to look | 18:58 |
| edmondsw | if it does start with a slash, we don't need slashes in other places, e.g.: | 18:59 |
| edmondsw | git fetch https://review.openstack.org/$ZUUL_PROJECT refs/changes/$BASE_LOG_PATH | 18:59 |
| esberglu | edmondsw: Just checked, no leading slash | 19:00 |
| edmondsw | hmm... so I'm not understanding that if conditional | 19:01 |
| edmondsw | must be my lack of bash mastery :) | 19:01 |
| esberglu | edmondsw: I think the second part (after ||) is just checking if they are defined | 19:03 |
| esberglu | The reason for this is for manual runs | 19:03 |
| esberglu | So I don't have to pass a bunch of parameters in | 19:03 |
| edmondsw | that makes sense | 19:03 |
| esberglu | That's what the -f flag does | 19:03 |
| esberglu | Makes it so everything in that script still works without any zuul parameters | 19:03 |
| edmondsw | esberglu so I did some playing around, and if you want to make sure that both ZUUL_PROJECT and BASE_LOG_PATH are set I think you would need to do something like this: if [[ "$ZUUL_PROJECT" && "$BASE_LOG_PATH" ]]; then | 19:06 |
| edmondsw | as it is, it looks like it will pass if either is set instead of requiring both | 19:07 |
| esberglu | edmondsw: From a manual test standpoint you would never set one without the other. If you set the BASE_LOG_PATH without setting ZUUL_PROJECT, it wouldn't know which project to apply the patch to | 19:09 |
| esberglu | If you aren't setting BASE_LOG_PATH it means you want master | 19:10 |
| edmondsw | esberglu not on purpose... ;) | 19:10 |
| esberglu | So it doesn't matter what ZUUL_PROJECT | 19:10 |
| esberglu | Since you aren't actually checking out any changes | 19:10 |
| *** smatzek has quit IRC | 19:11 | |
| esberglu | edmondsw: I guess your idea saves people from operator error | 19:11 |
| edmondsw | esberglu right | 19:12 |
| esberglu | Added to TODO list | 19:12 |
| edmondsw | and looks like the quotes aren't actually necessary... if [[ $ZUUL_PROJECT && $BASE_LOG_PATH ]]; then | 19:12 |
| edmondsw | I can throw up a patch | 19:12 |
| esberglu | edmondsw: sweet thanks | 19:12 |
| edmondsw | esberglu so I'm looking at 5502 and wondering about ordering of cherry-pick FETCH_HEAD vs. cherry-picks of patches | 19:13 |
| edmondsw | esberglu whether it matters at all... seems like it might be better to do patches first | 19:14 |
| esberglu | edmondsw: If there's a merge conflict there's a merge conflict right? Order shouldn't matter | 19:15 |
| edmondsw | esberglu and wondering about the fetches... I never use fetch, so I don't know exactly what that does, especially when you fetch twice (once for patching, once for the change you're testing | 19:15 |
| edmondsw | esberglu that makes sense about merge conflicts on the actual cherry-picks... what about the fetches? | 19:15 |
| esberglu | edmondsw: fetch just sets the FETCH_HEAD variable which is then used when you do a git pull, checkout, etc. | 19:16 |
| esberglu | edmondsw: At least if I remember correctly | 19:16 |
| edmondsw | esberglu really? Then why ever fetch... you can just cherry-pick without that | 19:16 |
| edmondsw | I think it must do more than that | 19:17 |
| esberglu | edmondsw: I'm fairly certain it had to be there but I'm not sure why | 19:17 |
| edmondsw | efried do you know? | 19:17 |
| edmondsw | question started at 15:13 | 19:18 |
| esberglu | edmondsw: It downloads the objects and references according to the docs | 19:18 |
| edmondsw | (14:13 for you) | 19:18 |
| esberglu | edmondsw: I think we had to do it that way because we are fetching changes from git.o.o | 19:18 |
| esberglu | While we cloned the projects from github | 19:18 |
| esberglu | Due to the network issues associated with g.o.o we talked about last week | 19:19 |
| esberglu | edmondsw: I can try a manual run without it at some point and see what happens | 19:19 |
| edmondsw | esberglu I'm not necessarily suggesting we stop fetching... just wondering what it does and whether the order of fetching matters if we are going to fetch twice on the same project (once for the change, again for patches) | 19:20 |
| esberglu | edmondsw: I don't think so. When we were apply multiple patches to nova/pypowervm it wasn't causing us any trouble | 19:21 |
| esberglu | *applying | 19:21 |
| edmondsw | esberglu k. Reading about git fetch, sounds like it is just fetching information like tags, not pulling code | 19:26 |
| esberglu | edmondsw: https://stackoverflow.com/questions/31882731/what-exactly-does-git-fetch-do-does-a-subsequent-fetch-overwrite-the-previous | 19:26 |
| esberglu | We could just do 1 git fetch per project | 19:26 |
| esberglu | But I think by specifying the refspec, it limits the amount of data being downloaded | 19:29 |
| *** ChanServ has quit IRC | 19:30 | |
| *** smatzek has joined #openstack-powervm | 19:34 | |
| *** smatzek has quit IRC | 19:35 | |
| *** ChanServ has joined #openstack-powervm | 19:35 | |
| *** card.freenode.net sets mode: +o ChanServ | 19:35 | |
| *** smatzek has joined #openstack-powervm | 19:36 | |
| edmondsw | esberglu yeah, sounds like it | 19:37 |
| edmondsw | I'm satisfied, +2 | 19:37 |
| *** jpasqualetto has quit IRC | 20:06 | |
| edmondsw | esberglu I momentarily confused myself on 5510... ignore ps1 | 20:29 |
| esberglu | edmondsw: ack | 20:30 |
| efried | Hey, just got caught up. | 20:46 |
| efried | [ "$one""$two" ] passes if $one or $two (or both) are nonempty. | 20:47 |
| efried | [ $one && $two ] without quotes works as long as there's no spaces in the var contents. | 20:47 |
| efried | git fetch will pull down code and create a branch, but not change the branch you're sitting on (git checkout FETCH_HEAD to do that). | 20:47 |
| efried | So multiple fetches will pull down different code (e.g. different patches) which you can then cherry-pick onto the branch you're sitting on if you're trying to apply multiple patches. | 20:48 |
| efried | actually, [ $one && $two ] is an error if either is empty. | 20:49 |
| efried | So don't do that. | 20:49 |
| efried | Actually, you can't use && within the single-bracket construct. | 20:49 |
| efried | ayee, you're using double brackets. | 20:50 |
| efried | So yeah, what you've got will work. Though it's not a syntax I'm used to. | 21:00 |
| edmondsw | efried so I should probably add the quotes back to cover cases where there are spaces... | 21:05 |
| efried | edmondsw Well, no. | 21:05 |
| edmondsw | no? | 21:05 |
| efried | First of all, there should never be spaces in those vars. | 21:05 |
| efried | Second, I actually tried it with spaces and it doesn't brok. | 21:05 |
| efried | break. | 21:05 |
| edmondsw | agreed... oh, ok | 21:05 |
| edmondsw | esberglu I'll leg you merge 5510 when you are comfortable with it | 21:06 |
| edmondsw | efried if fetch pulls down code... what code is it pulling down? | 21:06 |
| efried | edmondsw Whatever you're telling it to pull down. | 21:06 |
| *** k0da has quit IRC | 21:07 | |
| edmondsw | if you just say "git fetch" | 21:07 |
| efried | If you say 'git fetch' with no target, it'll try to pull the latest code in the branch you're sitting on. | 21:07 |
| efried | So for example, if you're sitting in master and you say 'git fetch', it'll pull down the latest master code, but leave you sitting on the commit you were on (an old master commit). | 21:08 |
| efried | Then you could say 'git pull' and you would be sitting on the latest. | 21:08 |
| edmondsw | efried git fetch seems like a waste of your time in that point... just go straight to git pull | 21:10 |
| efried | In that scenario, absolutely. I actually never use git fetch in real life. | 21:11 |
| efried | In the CI environment, it makes a ton of sense, though. You want to fetch a bunch of different specific targets and cherry pick them all together. | 21:11 |
| edmondsw | I thought git fetch was more for updating remotes, like when a new branch or tag is created | 21:11 |
| efried | Updating your local copy of what's in the remotes, yeah. | 21:12 |
| efried | You can say git fetch --all and it'll pull down everything the remote knows - but (and this is the crucial part of fetch) it won't move the branch you're sitting on. | 21:12 |
| edmondsw | it must take years to really know the ins and outs of git... | 21:13 |
| efried | edmondsw I assume that's true, though I can't imagine 99.9% of people ever need that knowledge. | 21:15 |
| efried | I feel like most people need to understand a handful of the functions that they use constantly, and don't need to worry about the other arcana. | 21:16 |
| edmondsw | efried fair enough :) | 21:16 |
| *** edmondsw has quit IRC | 21:17 | |
| *** smatzek has quit IRC | 21:18 | |
| efried | There's also more than one way to do many, many things in git. So everyone kinda figures out their own favorite way (e.g. to edit multiple patches in a series) and it's unimportant that they don't understand someone else's way. | 21:18 |
| *** edmondsw has joined #openstack-powervm | 21:18 | |
| efried | There's also more than one way to do many, many things in git. So everyone kinda figures out their own favorite way (e.g. to edit multiple patches in a series) and it's unimportant that they don't understand someone else's way. | 21:18 |
| *** edmondsw has quit IRC | 21:23 | |
| *** edmondsw has joined #openstack-powervm | 21:24 | |
| *** edmondsw has quit IRC | 21:28 | |
| *** edmondsw has joined #openstack-powervm | 21:31 | |
| *** esberglu has quit IRC | 21:32 | |
| *** esberglu has joined #openstack-powervm | 21:32 | |
| *** edmondsw has quit IRC | 21:35 | |
| openstackgerrit | Eric Fried proposed openstack/nova-powervm master: Clean up log messages https://review.openstack.org/476695 | 21:35 |
| *** esberglu has quit IRC | 21:37 | |
| *** thorst has quit IRC | 21:44 | |
| *** thorst has joined #openstack-powervm | 21:46 | |
| *** edmondsw has joined #openstack-powervm | 21:50 | |
| *** thorst has quit IRC | 21:50 | |
| *** edmondsw has quit IRC | 21:55 | |
| *** esberglu has joined #openstack-powervm | 21:57 | |
| *** esberglu has quit IRC | 21:58 | |
| *** esberglu has joined #openstack-powervm | 21:58 | |
| *** kylek3h has quit IRC | 22:01 | |
| *** kylek3h has joined #openstack-powervm | 22:02 | |
| *** thorst has joined #openstack-powervm | 22:05 | |
| *** kylek3h has quit IRC | 22:06 | |
| *** thorst has quit IRC | 22:09 | |
| *** edmondsw has joined #openstack-powervm | 22:18 | |
| *** edmondsw has quit IRC | 22:23 | |
| openstackgerrit | Eric Fried proposed openstack/nova-powervm master: Clean up log messages https://review.openstack.org/476695 | 23:07 |
Generated by irclog2html.py 2.15.3 by Marius Gedminas - find it at mg.pov.lt!