20:27:58 #startmeeting opendev-maint 20:27:59 Meeting started Fri Jun 12 20:27:58 2020 UTC and is due to finish in 60 minutes. The chair is fungi. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:28:00 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 20:28:02 The meeting name has been set to 'opendev_maint' 20:28:09 #link https://etherpad.opendev.org/p/gerrit-2020-06-12 20:29:16 clarkb: do you recall what file it is we create on bridge.o.o to pause deployments? 20:29:58 fungi: it should be in the etherpad 20:30:11 its also documented in bridges system config dics 20:30:14 *docs 20:30:29 in which etherpad? 20:30:48 i wasn't finding where we did it in the last one from 2020-03-20 20:31:42 the one I did for this time 20:31:46 * clarkb looks 20:31:50 oh, there was another pad? 20:31:55 anyway, yeah, docs say /home/zuul/DISABLE-ANSBILE 20:32:29 https://etherpad.opendev.org/p/gerrit-project-renames-20200612 20:32:34 #info did `sudo touch /home/zuul/DISABLE-ANSBILE` on bridge.o.o 20:32:46 aha, i'll switch to that pad. didn't realize you already had one 20:32:59 I put that together yesterday and libked it in irc. Your url earlier looked similar enough that I thought they were the same 20:33:08 #link https://etherpad.opendev.org/p/gerrit-project-renames-20200612 20:33:15 nah, i just missed that you had already created one 20:35:38 clarkb: the pad says to put review.o.o in emergency disable *and* stop deployments, is the emergency disable list addition actually necessary? 20:36:29 also i guess i should pull a copy of renames/20200612.yaml from https://review.opendev.org/735211 onto bridge.o.o 20:41:05 fungi: I don't think it is necessary 20:41:23 and the renames file should already be there at the path I list (double check though) 20:42:29 yep, i see now in the pad you already staged it at /root/renames/20200612/20200612.yaml 20:43:31 confirmed it's there and checksum matches the one from 735211 20:44:15 i've started a screen session as root on bridge.o.o 20:44:33 I've joined it 20:45:09 i'm standing by 20:45:54 and yeah, since these are all repositories moving to different namespaces i wouldn't have expected any groups to get renamed (as we aren't namespacing groups... yet anyway) 20:46:18 ya I double checked just to be sure fwiw, but there weren't any I saw 20:46:36 i looked through the changes as well and didn't see any 20:47:44 the acls in them are only git moves, with the exception of cla enforcement added ni one 20:49:49 10 minutes to go. i suppose at the 5 minute mark i can send a status notice that gerrit is being restarted 20:50:31 sounds good 20:52:00 something like... 20:52:02 status notice The Gerrit service on review.opendev.org is going offline momentarily at 21:00 UTC for project rename maintenance, but should return within a few minutes: http://lists.opendev.org/pipermail/service-announce/2020-June/000004.html 20:52:10 lgtm 20:52:34 hopefully if that takes anyone by surprise, it'll be incentive to subscribe to service-announce 20:55:28 #status notice The Gerrit service on review.opendev.org is going offline momentarily at 21:00 UTC for project rename maintenance, but should return within a few minutes: http://lists.opendev.org/pipermail/service-announce/2020-June/000004.html 20:55:28 fungi: sending notice 20:57:39 i've staged the ansible-playbook command from the pad in the screen session, ready to engage at 21:00 20:58:44 fungi: finished sending notice 20:58:58 doing last minute sanity checks and the flag to run gerrit init before gerrit start seems to default to false which is what we want 20:59:22 thanks 20:59:48 oh we explicitly set it to false when we run it too 21:00:00 go time. green light from mission control? 21:00:24 the command looks correct to me 21:00:29 corvus: ^ you ready and go? 21:00:29 #info running `ansible-playbook /home/zuul/src/opendev.org/opendev/system-config/playbooks/rename_repos.yaml -e@/root/renames/20200612/20200612.yaml` 21:00:48 clarkb: yep 21:01:20 repolist is undefined 21:01:33 edit repos to repolist? 21:01:41 * clarkb looks at historical lists 21:02:05 it has always been repos before /me looks at the code now 21:02:40 -e repolist=ABSOLUTE_PATH_TO_VARS_FILE 21:02:46 is the command wrong? 21:02:57 oh ya we didn't do repolist= 21:02:58 that ^ is from the docs 21:03:19 is that -e repolist=@filename or -e@repolist=filename? 21:03:25 -e@repolist=/root/renames/ or? 21:03:33 checking docs 21:03:36 i think it should not have @ 21:03:45 playbooks/rename_repos.yaml: - include_vars: "{{ repolist }}" 21:03:48 cause that's how it's used 21:04:18 docs say -e repolist= 21:04:24 corvus: got it and ya I think that is correct. -e repolist=filepath 21:04:57 #info running `ansible-playbook /home/zuul/src/opendev.org/opendev/system-config/playbooks/rename_repos.yaml -e repolist=/root/renames/20200612/20200612.yaml` 21:04:59 sorry I took that from the etherpad we used last time and didn't cross check the docs 21:05:14 looking better, thanks ;) 21:05:19 i updated the etherpad for today to avoid perpetuating the error in case that happens again 21:05:33 ++ 21:06:36 hrm looking at zuul status I think our jobs are not pausing 21:06:58 we don't have any hourly gitea or gerrit jobs queued though so we are probably ok 21:07:36 the jobs themselves start, but ansible blocks if that file is present, from what i gather 21:07:46 okay, i just saw some errors scroll by 21:08:02 user id changes biting us? 21:08:13 seems likely 21:08:16 the project key moves failed 21:08:51 ya that seems likely related to the regrouping and reuiding 21:08:53 that seems to have been the only issue it encountered 21:09:09 re the jobs, that is correct but two jobs have succeeded since after you reported touching that file 21:09:19 fungi: it should stop completely once it hits the first error 21:09:32 ahh, okay, so there was still more to run 21:09:55 i'll make a new playbook 21:10:20 it should be zuuld and ya we should make a new playbook for things that happen from failure forward. thank you corvus 21:10:42 yeah, so looks like we're using zuuld on the schdeduler now, not zuul 21:10:51 fungi: ya this was missed when we changed that stuff 21:10:52 ~corvus/rename_repos.yaml look good? 21:10:52 and the playbook tried to chown to zuul which dne 21:11:14 corvus: yes lgtm 21:11:31 yep, that looks like the remaining tasks with the first one fixed to the new username 21:11:59 should we move that playbook into place? 21:12:12 i was simply going to run `ansible-playbook ~corvus/rename_repos.yaml -e repolist=/root/renames/20200612/20200612.yaml` 21:12:13 i can't remember if it references any roles or includes 21:12:23 if it does, those will be relative to the playbook path 21:12:24 corvus: it does for the gitea stuff 21:12:25 but yeah, i can move it 21:12:29 and for gerrit start 21:12:38 then best to cp it to pwd 21:12:39 hold on 21:12:50 if zuul is running jobs the jobs could undo that copy 21:12:51 or rather, the system-config/playbooks dir 21:13:23 would it be ebtter to make a copy of the subtree and then copy your edit into that? 21:13:31 (I'm trying to understand what zuul is doing now fwiw) 21:13:54 i could just put it at /home/zuul/src/opendev.org/opendev/system-config/playbooks/fixed_rename_repos.yaml and then reference that new playbook name, right? 21:14:06 and then clean up the checkout when we're done 21:14:36 fungi: assuming that workspace setup doesn't reset --hard 21:15:21 if it does, we'll just get an error at that point anyway, right? non-destructive if so 21:15:40 good point 21:15:43 then ya I think thats the way to do it 21:15:47 corvus: ^ that sound good? 21:16:06 fwiw I only see an older (possibly stale) remoet_puppet else run from zuul ansible 21:16:15 and we're seeing jobs rotate attempts now 21:16:27 wfm 21:16:29 so I think we may be good either way 21:16:33 #info ran `cp ~corvus/rename_repos.yaml /home/zuul/src/opendev.org/opendev/system-config/playbooks/fixed_rename_repos.yaml` 21:16:54 #info running `ansible-playbook /home/zuul/src/opendev.org/opendev/system-config/playbooks/fixed_rename_repos.yaml -e repolist=/root/renames/20200612/20200612.yaml` 21:17:13 it's gotten further, thanks 21:18:08 we are to the step wehere we check gerrit is up again and happy before hitting enter 21:18:23 yeah, ssh: connect to host review.opendev.org port 29418: Connection refused 21:18:27 the process is running but not yet httpd'ing for me yet 21:19:36 I wnt to say this takes ~3-4 minutes now? 21:19:45 yeah, i'm not worried (yet) 21:20:05 responding! 21:20:06 [2020-06-12 21:20:00,219] [main] INFO com.google.gerrit.pgm.Daemon : Gerrit Code Review 2.13.12-11-g1707fec ready 21:20:16 httpd still not there yet 21:20:42 well, ssh api is responding so we can proceed 21:20:47 any objections? 21:21:07 there are sshd exceptions in the error log 21:21:10 (at least our reminder there says "Make sure that Gerrit ssh api is accepting requests" which it seems to be 21:21:13 did you login and run a command? 21:21:17 i did 21:21:30 web is up for me now anyway 21:21:30 i mean, i asked it for ssh api help, but i can do more 21:21:32 I think we can proceed 21:21:44 I was thinking something like ls-projects but I expect its fine as web responds now too 21:21:45 i can get it to list projects 21:21:46 i just pushed up a change 21:21:53 i'd call that working 21:21:56 cool lets proceed 21:21:56 okay, continuing 21:21:58 21:21 < openstackgerrit> James E. Blair proposed opendev/system-config master: Fix rename playbook after zuul user rename https://review.opendev.org/735397 21:22:13 #info gerrit api is responding, continued 21:22:22 #info playbook run completed 21:22:31 no new errors 21:22:51 anybody want to double-check anything before we start approving the rename changes? 21:23:13 if I search for changes on the renamed proejcts I get no results 21:23:21 do we have to wait for reindexing to complete for that to work? 21:23:30 yes 21:23:45 fungi: that was the only other thing I was going to check 21:23:46 searches hit the index 21:23:55 but if we have to reindex I don't know if we want to wait 21:24:02 if you know a change for one of those projects, you should still be able to access it 21:24:11 ah ok let me see 21:24:28 queries which involve the project name will fail to find it though 21:25:02 once the online reindex reaches the renamed projects, they'll be searchable again 21:25:29 which thankfully is long, long before the reindex completes 21:25:58 (unless we rename nova, openstack-manuals, neutron, or something similarly large) 21:26:22 https://review.opendev.org/#/c/726006/ errors which I think is a refstack or interop change 21:26:44 java.lang.IllegalArgumentException: passed project openstack/refstack when creating ChangeNotes for 726006, but actual project is osf/refstack 21:26:56 maybe we need reindexing to finish for that to work too? 21:27:05 ahh, yeah okay so i guess they can't be reached until the index is done 21:27:20 though we don't typically wait for reindex to complete to do the project-config changes 21:27:52 but will likely need to wait to be able to update .gtireview files for those repos 21:28:50 I've double checked that refstack hasn't reindexed it (just to be sure the problem is likely related to idnexing) and it has not so thats good 21:29:39 corvus: you still have a wip on 714478, mind if i delete it? or do you want to undo that (or approve the change)? 21:29:52 i'll +w if we're ready 21:30:31 ya I think I'm about as ready as I'll be without waiting for reindexing to finish 21:30:39 done 21:30:44 cool, thanks 21:30:47 should we rm the DISABLE-ANSIBLE file to ensure those jobs run properly? 21:30:55 in particular I think we need them to update zuul config 21:31:02 that's probably a stellar idea 21:31:22 it wasn't clear to me whether we needed to wait until the changes merged to clear DISABLE-ANSIBLE 21:31:54 in the past we didn't resume configuration management for the gerrit server until the rename changes merged, so that manage-projects wouldn't recreate old stuff 21:32:05 yeah - that's probably a good idea ... 21:32:08 fungi: thats a good point 21:32:11 we use tip of project-config 21:32:17 I think the correct thing now is to rm the file bceause of ^ 21:32:19 oh wait 21:32:23 no I see 21:32:27 we want them to merge then rm I get it 21:32:29 no - I think let's wait to rm until the patches merge 21:32:31 yeah 21:32:42 yeah, we've scripted changes to match the future state of project-config, not the present satte 21:32:59 so if manage-projects runs with the present state, we'll wind up with a mess 21:33:24 yup 21:33:34 and I guess we can always reenqueue if we need to once things have merged 21:33:40 rather than try and sync with zuul perfectly 21:33:54 gerrit is slowly chewing the the largest repos now 21:34:22 734669 fails zuul configuration. are we going to need to bypass gating on that one? 21:35:40 that probably could be merged by zuul if it were split into 2 changes 21:35:47 change main.yaml first, then the rest. 21:36:05 but as written, yes, that would need to be force-merged 21:36:08 i can split it up 21:36:22 depends on how long you want to stick around. :) 21:36:35 we can always bypass check 21:38:33 i'd vote to force-merge 21:38:44 ya I'm ok with force merge too 21:38:57 about halfway through the dance to split the patch, but i'll just do that instead 21:39:31 one thing I notice is we haev a lot more "big" repos to reindex now 21:39:39 we've only finished a handful so far 21:39:45 but it is progressing 21:40:07 also we should really do that gerrit disk cleanup I never do because its scary 21:40:14 we haev 23GB free where the git repos and indexes live 21:40:20 (enough for now but steadily getting smaller) 21:40:37 yeah. we have a LOT of saved indexes in the homedir too 21:40:47 mordred: ya exactly 21:41:17 #info bypassed gating on 734669 so as not to spend time splitting the change during maintenance 21:41:27 zuul's reindexing now 21:41:35 that means zuul is one of our bigger repos :) 21:42:57 fungi: re removing the disable file has the change replicated first? 21:43:07 I think we want to wait for that as well? 21:43:12 i haven't removed it yet 21:43:21 just documenting in the pad that it's a step 21:43:23 (I want to say reindexing and replication are different worker threads so that should work well) 21:44:25 though yes, i guess the question remains whether we need to make sure something is replicated to gitea before we turn jobs back on... they use branch tip so do they get that directly from gerrit or gitea? 21:44:46 gitea 21:44:47 I want to say it is from gitea 21:44:53 definitely gitea 21:45:13 okay, so we need to make sure the project-config changes have replicated to gitea i guess 21:45:25 ugh local network has suddenly gone flaky for me so whwen I run the show-queue commands ssh says review.o.o is unreachable. Then I run it again and it is reachable 21:45:42 its not review I notice it typing in this shell for irc too 21:46:11 i've noted the additional wait condition in the pad 21:47:08 #link https://opendev.org/openstack/project-config/commits/branch/master 21:47:18 i see merge commits for both rename changes 21:47:28 so we should be safe? 21:48:53 I like the check the individual backends and I just do that they all look good 21:49:12 okay, thanks for confirming 21:50:02 progress is picking up with reindexing which is what we expect since it starts with the most expensive ones and proceeds to the cheaper ones 21:50:08 so we should be all clear to remove /home/zuul/DISABLE-ANSIBLE now 21:50:22 fungi: yes I think so 21:50:26 mordred: corvus ^ do you agree? 21:50:43 ++ 21:50:57 abstain (weak agree) 21:52:02 so i was *going* to remove it 21:52:09 but it's no longer there 21:52:24 i wonder if that explains the behavior clarkb was seeing 21:52:31 uh - what removed it? 21:52:41 i'd love to know 21:52:47 fungi: I see it 21:53:01 root@bridge:/home/zuul# ls -ltra /home/zuul/DISABLE-ANSBILE 21:53:03 -rw-r--r-- 1 root root 0 Jun 12 20:32 /home/zuul/DISABLE-ANSBILE 21:53:07 oh 21:53:09 nope 21:53:14 I see a file named incorrectly 21:53:57 oh ya looking at scrollback thats the file that was there when I was trying to figure out why things were running 21:54:08 this is maybe a stupid idea - but maybe we should make a helper utitlity called "disable-ansible" that touches the file 21:54:10 so uh 21:54:14 so that we can dis 21:54:17 we may have recreated the refstack and interop repos? 21:54:17 and not worry about misspelling 21:54:24 yeah. we probably did 21:54:31 ansibile is great 21:54:35 wow 21:54:44 corvus: so is ansbile 21:54:51 i picked the ONE place in our documentation where it's mistyped, and didn't notice 21:55:08 https://docs.opendev.org/opendev/system-config/latest/bridge.html#running-ansible-on-nodes "When done, don’t forget to remove /home/zuul/DISABLE-ANSBILE" 21:55:19 okay, so how do we remove those repos? 21:55:32 I think we have to shut gerrit down again 21:55:53 I'm not 100% sure what the right choice is on the gitea replicas 21:56:02 since I'm guessing the new repos will have removed the redirects 21:56:07 mordred: they did I just checked 21:56:22 I mean - obvs we can do db surgery to fix the redirects 21:56:31 but that'll take some investigation 21:56:41 can we even delete projects? 21:56:42 i'll start working on the gitea stuff 21:56:47 in gerrit I mean 21:56:57 or do we toggle some flag saying this isn't visible instead? 21:57:07 please shut gerrit down now 21:57:18 can we safely stop it if it is reindexing? 21:57:25 I assume so since its online 21:57:28 because we can delete projects if they haven't changed 21:57:32 gotcha 21:57:44 #status notice gerrit is being taken offline for emergency cleanup, will return to service again shortly 21:57:44 fungi: sending notice 21:57:46 yeah - I think worst case it'll just be another reindex 21:58:24 do we use docker-compose to take it down now? 21:58:38 fungi: yes, cd /etc/gerrit-compose && sudo docker-compose down 21:58:41 yeah 21:58:44 doing that now 21:59:10 it's stopped 21:59:21 corvus: removing from gerrit is removing the git repo - do we need to delete from db there too? 21:59:25 * mordred can work on that 21:59:36 yes, needs to be removed from the mysql db 21:59:36 mordred: dunno 21:59:40 same tables we rename in 22:00:37 account_project_watches where project_name = oldname 22:00:55 fungi: finished sending notice 22:01:01 changes where dest_project_name = oldname 22:01:20 though hopefully those match zero rows 22:01:22 I found https://stackoverflow.com/questions/8723716/delete-a-project-in-gerrit which seems to indicate that removing the git dirs may be sufficient on some versions of gerrit (maybe those with notedb though?) 22:01:31 yeah - probably so 22:01:47 now I'm wondering why /root/.my.cnf doesn't have the ssl=true line that's in our ansible config management 22:01:58 but maybe that can be a task for older monty 22:01:59 clarkb: yeah, i think that stuff winds up in special refs in those repos with notedb 22:02:26 but also if nobody created new changes or watches on those recreated repos, it's likely we won't have anything to remove from the db 22:02:42 fungi: yeah - I'm going to quick select to see if that's true 22:02:53 for gitea -- how about we use the web ui to delete the old name, rename the new name to the old, then rename the old to the new? 22:03:13 corvus: we should be able to test that on a single backend too to ensure it works properly 22:03:17 but that plan sounds good to me 22:03:22 me too 22:03:23 separately, should we touch that ansible file now? 22:03:26 the proper one? 22:03:28 yes 22:03:32 clarkb: yes; i expect it too because i did that when testing renames originally 22:03:37 corvus: that sounds like it should create redirects again... though doesn't our redirect creation also have the same effect if it reruns after we delete the old repos? 22:03:56 (part of the reason for recording those in yaml) 22:04:02 fungi: no 22:04:07 that hasn't been implemented yet 22:04:12 we've been reocrding things so that we can do that 22:04:13 oh, okay 22:04:22 sometimes i confuse the future with the present, sorry :/ 22:04:35 I'm touching the ansible disable file now 22:04:37 we could just manually delete the old names in gitea and then run that part of the playbook 22:05:02 or rather, manually delete the old names, move the new to the old, then run the playbook 22:05:05 that only saves one step though 22:05:21 corvus: ya I think your plan was great myself and gets us to the end state we want 22:05:27 yep, agreed 22:05:31 does anyone else want to double check the file in /home/zuul on bridge/ 22:06:12 I do not believe there are any gerrit db changes 22:06:15 thinking out loud on how to address zuul running in the future. Maybe we should edit authorized keys? 22:06:18 mysql> select * from account_project_watches where project_name in ('openstack/refstack', 'x/whitebox-tempest-plugin', 'openstack/python-tempestconf', 'openstack/refstack-client'); 22:06:20 Empty set (0.01 sec) 22:06:25 clarkb: it looks correct this time, thanks 22:06:27 mysql> select * from changes where dest_project_name in ('openstack/refstack', 'x/whitebox-tempest-plugin', 'openstack/python-tempestconf', 'openstack/refstack-client'); 22:06:29 Empty set (0.64 sec) 22:06:54 mordred: is there a general projects table too? 22:07:04 basically what does ls-projects read? 22:07:14 no. no projects table 22:07:16 clarkb: i expect the current method for disablement is just fine as long as we type it correctly 22:07:32 fungi: sure, but its fragile whereas breaking ssh is robust 22:07:33 I believe it reads from a cache that's related to git repos on disk 22:07:39 mordred: rgr 22:07:53 mordred: and to confirm I t hink what I hear you saying is we only need to remove the git dirs? 22:07:58 i should have looked more closely at the command i cut and pasted, and not just assumed our documentation is somehow magically immune to typos 22:08:02 clarkb: yes - I believe that is correct 22:08:27 clarkb, fungi: I think making a utility script to set the file would be a very easy one-liner and prevent future mistakes while keeping things simple 22:08:38 that sounds reasonable 22:08:41 I like that 22:08:56 clarkb: I will now delete the git repos 22:09:19 clarkb: I think you already have done that 22:09:23 as I do not see them 22:09:55 or manage-projects never actually made it that far? 22:10:01 mordred: I have not 22:10:13 perhaps we only made the projects in gitea 22:10:14 fungi: manage projects succeeded 22:10:18 the job I mean 22:10:48 well - that's disturbing - because there are no projects named that in gerrit now 22:10:50 does it only apply repos which changed, or do we do a full run when we trigger it? 22:11:02 OH 22:11:04 you know what? 22:11:04 https://gitea01.opendev.org:3000/openstack/interop should be complete 22:11:13 those repos are going to be in the manage-projects cache on gerrit 22:11:25 so manage-projects isn't going to try to re-created them gerrit side - purely accidentally 22:11:43 mordred: yup I'm reading the logs on bridge now and I concur that is what happened 22:11:48 \o/ 22:11:49 it basically said "my shas match so I'm good" 22:12:02 cool. so gerrit is actually fine (and will remain fine) 22:12:03 someone else may want to double check that manage projects logs on brdige to concur too but that is my read of it 22:12:19 corvus: redirect wfm there 22:12:45 yes - I concur 22:13:00 corvus: did you do that by clicking things? 22:13:29 mordred: yes 22:14:26 okay, so we're ready to start gerrit again? 22:14:44 do we want to wait until gitea is done? replication 22:15:02 ya that way everything works properly when it starts functioning 22:15:12 oh, right, that, sorry missed it wasn't done on all the backends 22:15:42 corvus: yeah - I think that's safest 22:15:58 i also have the documentation correction for "ansbile" ready to push once it's up (interesting fact, it's not the only place in our documentation where we did that) 22:16:12 im confused -- 1 sec 22:16:48 i don't see an x/whitebox-tempest-plugin; it still has a redirect 22:17:00 maybe it just didn't get around to it? 22:18:24 corvus: that one is ok 22:18:35 corvus: because it was in the first chagne that merged which is what ran manage-projects 22:18:43 ah ok 22:18:45 its was the gap between first and second changes merging that bit us 22:18:59 and so only ssecond change's projects are sad (I noted the list on the etherpad too) 22:18:59 oh, right 22:19:14 so if the three-rename change had merged first we'd only have to correct x/whitebox-tempest-plugin 22:20:14 yes 22:21:03 okay i've done all the things for gitea01 22:21:21 are other folks idle? should we just divide up the clicking? 22:21:30 it's silly, but it's probably ~= to the time to make a playbook 22:21:43 I can click buttons if we decide that is easiest 22:21:44 I can click. should we divide up backends? 22:22:00 k; ya'll grab the root password from bridge 22:22:07 i'll lay stuff out in the etherpad 22:22:09 corvus: it's in hostvars right? 22:22:12 yep 22:22:28 git grep gitea_root_password 22:23:00 yup found it. is the username admin? 22:23:04 root 22:23:14 heh that makes sense given the key name 22:24:10 corvus has done 01 - actually, why don't I make an etherpad list and we can grab backends 22:24:50 corvus has done it better than me 22:24:50 oh heh i was about to say i like that better 22:25:11 okay we'll do it my way :) 22:25:24 clarkb, mordred: etherpad make sense? gtg? 22:25:31 corvus: we go to /login ? 22:25:34