opendevreview | Merged openstack/openstack-zuul-jobs master: prepare-zanata-client: upgrade pip in venv https://review.opendev.org/c/openstack/openstack-zuul-jobs/+/828219 | 00:10 |
---|---|---|
opendevreview | Neil Hanlon proposed openstack/project-config master: Add rockylinux-8 to nodepool configuration https://review.opendev.org/c/openstack/project-config/+/828435 | 00:32 |
*** dviroel|ruck|afk is now known as dviroel|ruck | 00:48 | |
*** rlandy|ruck|bbl is now known as rlandy|ruck | 00:57 | |
*** dviroel|ruck is now known as dviroel|ruck|out | 00:57 | |
*** dviroel|ruck|out is now known as dviroel|out | 00:57 | |
*** rlandy|ruck is now known as rlandy|out | 04:06 | |
*** amoralej|off is now known as amoralej | 08:11 | |
*** jpena|off is now known as jpena | 08:31 | |
*** sshnaidm|afk is now known as sshnaidm | 08:54 | |
*** ysandeep|out is now known as ysandeep | 09:01 | |
*** mnasiadka_ is now known as mnasiadka | 09:18 | |
*** akekane__ is now known as abhishekk | 09:26 | |
*** rlandy|out is now known as rlandy|ruck | 11:06 | |
*** dviroel|out is now known as dviroel|ruck | 11:10 | |
*** jcapitao is now known as jcapitao_lunch | 11:50 | |
*** ysandeep is now known as ysandeep|break | 12:41 | |
*** amoralej is now known as amoralej|lunch | 13:07 | |
*** ysandeep|break is now known as ysandeep | 13:13 | |
*** dasm|off is now known as dasm | 13:17 | |
*** jcapitao_lunch is now known as jcapitao | 13:31 | |
*** amoralej|lunch is now known as amoralej | 13:59 | |
*** akahat|rover is now known as akahat|PTO | 14:11 | |
sean-k-mooney | clarkb: frickler fungi was there a zuul restart about 4 days ago | 14:53 |
sean-k-mooney | https://review.opendev.org/c/openstack/nova/+/792362 | 14:53 |
sean-k-mooney | that has a +2 from zuul but it was never merged when its child merged | 14:53 |
sean-k-mooney | *parent | 14:53 |
sean-k-mooney | +w didnt seam to be enough i can recheck it but just said i would ask if it was infra related or not before i did | 14:55 |
sean-k-mooney | hum either ye retriggered it or the second +w did but zuul is runnign the gate job again in anycase | 15:22 |
fungi | sean-k-mooney: doesn't look like it would be a zuul restart, zuul voted verified +2 at 22:56z on friday | 15:32 |
fungi | it just didn't manage to tell gerrit to submit the change | 15:33 |
fungi | the last gerrit restart was over a week ago, so probably not that either | 15:33 |
fungi | the git parent of 792362,8 is 792356,7 but 792356,8 is what merged, so i don't think gerrit will let 792362 merge without a rebase | 15:39 |
fungi | however, i'm surprised zuul isn't pointing that out. i wonder if there's been a recent regression in zuul or gerrit, or if i'm just misremembering how zuul behaved in such cases | 15:40 |
fungi | clarkb: ^ please check my memory there when you have a moment | 15:40 |
*** ysandeep is now known as ysandeep|out | 15:43 | |
sean-k-mooney | fungi: well it shoudl create a merge commit right | 15:55 |
sean-k-mooney | assumign it can still apply | 15:55 |
sean-k-mooney | lookign at the status page it passed all gate jobs agin | 15:55 |
sean-k-mooney | so its just waiting for the cinder jobs to finish that it was co gating with | 15:55 |
frickler | gerrit used to give an indication about rebase needed, but maybe it no longer does with the mergeability check disabled | 15:56 |
sean-k-mooney | yes gerrit will indicate if a merge confict exists | 15:56 |
sean-k-mooney | but there isnt one in this case | 15:56 |
sean-k-mooney | frickler: everything is green https://zuul.openstack.org/status#792362 | 15:57 |
fungi | sean-k-mooney: it can't create a merge commit if the parent isn't in the tree | 15:57 |
sean-k-mooney | so zuul was clearly able to merge it with the tip of master | 15:57 |
fungi | think about how git works | 15:57 |
fungi | gerrit can't, i mean | 15:58 |
frickler | zuul rebases automatically iiuc, gerrit doesn't | 15:58 |
sean-k-mooney | thats a good point | 15:58 |
sean-k-mooney | ya zuul was able to make it work bug i have not looked in the job to see what it did | 15:58 |
frickler | you might not even see it in the job, if the zuul-merger does it. the only indication would possibly be a different sha for your commit | 16:00 |
sean-k-mooney | what gerrit/zuul effectivly are doign currently is ignoring the parent sicne the gerrit change is now merged in master and testing this patch as a patch againt master | 16:00 |
sean-k-mooney | https://zuul.opendev.org/t/openstack/build/018fde7499d446b9b2ba18c8e311e567/log/job-output.txt#316-327 | 16:01 |
sean-k-mooney | HEAD is now at 283eea6919 Merge commit 'refs/changes/62/792362/8' of ssh://review.opendev.org:29418/openstack/nova into HEAD | 16:01 |
fungi | if you `git review -d 792362` and then git log, you'll see the commit id for the parent is not in the master branch, so gerrit's going to refuse to merge it when asked | 16:02 |
frickler | yeah, let's wait what happens when the cinder patches merge and zuul tries to submit this one | 16:02 |
sean-k-mooney | i think it will work but sure | 16:03 |
sean-k-mooney | ill just rebase the patch if it fails or ping stephen to do the same | 16:03 |
frickler | seems zuul received an error from gerrit last time already https://paste.opendev.org/show/b6f1WE2hmpc3fNC65gHJ/ | 16:10 |
frickler | but that only shows up in the debug log. maybe zuul should note a comment about this in the change | 16:11 |
clarkb | fungi: I think zuul never cared about that situation. | 16:16 |
clarkb | fungi: all zuul checked was that you could merge into the target branch before running test and that you are theoretically mergable | 16:16 |
clarkb | then it checks actual ability to submit and if that fails it doesn't merge | 16:16 |
clarkb | its possible zuul coudl do a better job reporting that | 16:16 |
fungi | clarkb: i wonder why it considers that change "mergeable" when its parent isn't in the target branch. is it merging using the change refs from outside the branch instead? | 16:27 |
clarkb | fungi: it merges change ref into target branch. If git can resolve that then its ok | 16:28 |
clarkb | Then separately there is a "is this submittable" check but I believe that only happens after verified +2 is applied | 16:29 |
clarkb | (I could be wrong about when that is submittable check happens but that should be what would catch it | 16:29 |
fungi | yeah, i'm wondering how git "resolves" that, unless it uses the out-of-branch parents from the change refs | 16:30 |
clarkb | The you can only merge if your parent patchset is valid check is a gerrit thing. Zuul either needs to emulate that or rely on the is submittable check to tell it | 16:30 |
clarkb | fungi: git yes it uses the out of branch parents from the chagne refs | 16:30 |
clarkb | its just doing merge change xyz into master | 16:31 |
fungi | okay, thanks | 16:31 |
clarkb | and that will merge everything under change xyz too | 16:31 |
clarkb | If there is a conflict it will fail | 16:31 |
clarkb | which is probably more likely in the case of a parent patchset respin then in many other cases but not necessarily the case | 16:31 |
fungi | so zuul can gate changes with parents which have alternative commits in the target branch already, as long as they don't merge-conflict with what did merge instead, but gerrit explicitly refuses to create such a merge commit itself | 16:32 |
clarkb | correct | 16:32 |
clarkb | because Gerrit is aware that it doesn't make sense in the context of its code review workflow | 16:33 |
fungi | and if we had zuul pushing its merge commits instead of relying on gerrit to perform the merge, then that's what we'd get in the resulting repository branch state as well | 16:33 |
clarkb | yes I think that is correct | 16:34 |
*** ralonsoh_ is now known as ralonsoh | 16:40 | |
clarkb | hrm even if zuul did the right things (whcih it may I'm not yet sure) there is a race here depending on when the parent change updates | 16:41 |
clarkb | if zuul checks the is submittable check prior to starting gate jobs that may be true beacuse the parent is still valid. Then while the gate is running (whcih can take many hours) the parent can be updated making that check fail when zuul finishes gating | 16:41 |
clarkb | I think that means even if we do everything possible to guard against the situation sean-k-mooney found it is still possible | 16:42 |
*** ykarel is now known as ykarel|away | 16:48 | |
fungi | yeah, however zuul could probably report an error in a separate review comment on the change after the submit call to gerrit fails | 16:51 |
clarkb | yup | 16:52 |
fungi | doesn't save it from wasting time sitting in the pipeline and running jobs, but at least there's a hint to the reviewers/author afterward | 16:52 |
*** jpena is now known as jpena|off | 17:27 | |
clarkb | dpawlik3: gmann: hey I'm trying to catch up on the ELK and health stuff. I'd like to start working to remove what I can now if we are ready to start on that. | 17:28 |
clarkb | dpawlik3: gmann: I guess first major question is: can openstack use the opensearch based system now and the old ELK system can be turned off? or is there still work to be done? then for the health side I think my plan was to stop services and let them sit for a few days ebfore deleting the hosts and database entirely. Then work on retiring the infra side management | 17:29 |
clarkb | (I'm flexible here, but I think we can make some progress on the opendev side now so want to make sure that doesn't get forgotten) | 17:29 |
frickler | sean-k-mooney: seems you could rebase now | 17:44 |
frickler | 2022-02-09 16:52:02,455 DEBUG zuul.Pipeline.openstack.gate: [e: c7e9dfd1cfdd48319fc8f52e506061c7] <QueueItem db0f98a403b74131be6a1d7e14c521a5 for <Change 0x7f8b067b6280 openstack/nov | 17:44 |
frickler | a 792362,8> in gate> is a failing item because ['it did not merge'] | 17:44 |
gmann | clarkb: thanks. about health dashbaord, I do not think we got any volunteer but let me check on qa channel again. | 17:46 |
sean-k-mooney | frickler: huh ok i will zuul did +2 again | 17:58 |
sean-k-mooney | so we likely need to fix that and eitehr have zuul try to auto rebase the patch and merge again or set it in merge conflcit | 17:59 |
fungi | zuul reporting a comment on the change when it gets an error trying to submit to gerrit is probably the best option there | 18:02 |
sean-k-mooney | fungi: ya that would work | 18:02 |
fungi | i'd feel a bit weird about having zuul try to hit gerrit's rebase api method, and it's only a click away if that's how the author wants to solve things | 18:03 |
sean-k-mooney | ya there is also the machine written "code" issues | 18:03 |
fungi | i definitely wouldn't want zuul to tell gerrit to rebase and then immediately merge the result, i've seen my share of horked-up rebases because git guesses wrong for where things should go | 18:03 |
sean-k-mooney | technically zuul would have author the commit | 18:03 |
sean-k-mooney | if we could have a comment when the submit failed that would be enough | 18:04 |
*** amoralej is now known as amoralej|off | 18:17 | |
gmann | clarkb: checked and we do not have any maintainer to fix code so ok to stop the service now and later we will retire the repo. | 18:42 |
gmann | clarkb: for ELK status, I am not much following up on this, dpawlik3 can tell latest updates and plan. | 18:43 |
clarkb | gmann: thanks for the followup | 18:46 |
*** timburke__ is now known as timburke | 20:54 | |
opendevreview | James E. Blair proposed openstack/project-config master: Add zuul-web stats to zuul-status page https://review.opendev.org/c/openstack/project-config/+/828609 | 21:02 |
opendevreview | James E. Blair proposed openstack/project-config master: Add zuul-web stats to zuul-status page https://review.opendev.org/c/openstack/project-config/+/828609 | 21:03 |
*** dviroel|ruck is now known as dviroel|out | 22:33 | |
opendevreview | Merged openstack/project-config master: Add zuul-web stats to zuul-status page https://review.opendev.org/c/openstack/project-config/+/828609 | 22:38 |
*** rlandy|ruck is now known as rlandy|out | 23:23 |
Generated by irclog2html.py 2.17.3 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!