Sunday, 2021-07-25

mordredfungi: oh, i think that makes sense. And i THINK we chose that purposefully so that we'd control it for upgrades and stuff. But maybe we should rethink that strategy04:01
fungiit wasn't a big deal, just took me a moment to notice it wasn't starting on its own at boot04:13
luk4sGood afternoon12:31
luk4sI have some questions about setting up gerrit account and contributors agreement - is this the right place to discuss this?12:32
fungiluk4s: it's a fine place to discuss things, sure. what are your questions? but also it helps to say which documentation you're following and what project(s) you're preparing to participate in12:50
luk4sfungi, I'm following this documentation and the project I want to participate in is openstack/kayobe12:52
fungigreat. what issues are you running into with account creation?12:53
luk4sMy workplace has singed the CCLA but its not linked to my account - I guess my question is should it be automatically or are there additional steps that I need to complete to make it so?12:53
fungithe open infrastructure foundation's corporate contributor license agreement is legal paperwork between the foundation and employers who want to indicate which of their employees are contributing to projects, but it's not integrated into any of our systems. there is a separate "individual contributor license agreement" which is essentially an agreement between the contributor and the foundation12:56
fungiwhich *is* integrated into gerrit (our code review platform) and currently necessary to agree to if contributing to openstack projects12:56
fungiit's separate from any agreement your employer has signed12:56
luk4sso I should sign the individual contributor license agreement on top of the one that was signed by my employer?12:58
fungione is an agreement between your employer and the foundation, the other is an agreement between you and the foundation. the icla is required to push changes for review in some projects (including openstack)13:00
fungithe icla is an assertion that the changes you propose are your own work or that you have permission from the author(s) of that work to propose it for inclusion in the project13:01
luk4sfungi, ah that is where I went wrong - My reading was that its either the Individual or Corporate rather than both.13:02
fungithe individual is required for everyone contributing to those projects, while the corporate is a separate agreement limiting liability for things like patents the employer may hold for certain ideas/technologies13:02
luk4sfungi, many thanks for the explanation - all clear now :)13:03
fungii get that it's a lot of paperwork, lawyers who the foundation trusts have insisted that this is important to safeguard the liability and sovereignty of the project13:04
fungithough we're working to simplify things and hopefully switch projects like openstack from that icla to something called "developer certificate of origin" (dco) which is more like what the linux kernel developers use13:05
fungi(unfortunately it wouldn't eliminate the ccla, but at least individual contributors would no longer have to agree in advance to an icla and could instead just include specific words in each of their git commit messages)13:06
luk4sAnother question if I may, this time related to registration of additional email addresses in the gerrit account - I'm trying to add additional email address to the account, but it complains that the email address is in already use. I do have multiple accounts and are slowly trying to clean up the mess that I have created (already unified my launchpad accounts). Does the error relate to the Ubuntu SSO account, or the gerrit account that the email address is ass13:51
luk4sociated with?13:51
luk4sI have stupidly used both accounts to log in to gerrit - I can close the Ubuntu SSO account, but I can't see the option to close the gerrit one.13:54
fungiluk4s: sorry, stepped away for a few minutes... our gerrit admins can deactivate an account, which may solve that problem. more generally we have a bunch of duplicate ids on accounts because earlier versions of gerrit particularly failed to enforce e-mail address uniqueness for accounts autocreated through new openid logins, and clarkb is nearing the end of a lengthy effort to clean all those14:30
fungihe may have more insight into how to solve that the next time he's around, which might not be until tomorrow14:31
fungibut if you can /msg me the e-mail address associated with an account you want marked inactive i'm happy to try that as a first step14:31
Clark[m]fungi: you have to delete the external ids associated with the unwanted account completely. Settings the account to inactive isn't sufficient but should be done as well14:36
fungiClark[m]: okay, thanks. i've deactivated the old account luk4s asked for... what's the cleanest way to delete the id? rest api?14:37
Clark[m]Sort of, this gets complicated because if you orphan the preferred email address that becomes a config error too. What I've been doing is running the retirement script which deactivates and deletes the preferred email via a git push to all-users refs/users/xy/abxy14:39
Clark[m]Then you can use the rest api to list the external ids and then delete the external ids with the email address(es)14:39
Clark[m]All of that should be captured in the scripts I've pushed to system-config/tools 14:40
Clark[m]Doing it manually might be useful for understanding the various components and not too bad for a single account14:40
fungiClark[m]: thanks, i'll give it a shot14:41
fungiluk4s: i'm in the middle of some food prep, but as soon as i can get my hands clean i'll work on that part14:41
luk4sfungi, no rush 14:45
luk4sand thank you 14:45
*** lukas is now known as Guest214814:56
*** Guest2148 is now known as luk4s14:58
fungiokay, hands clean, looking at the account retirement scripts now15:08
fungilooks like i'll want to run first so that the preferred_email is removed from the account record, and then to remove the external id for that address from the15:11
fungiretired account15:11
fungicloned the system-config repo into /tmp on the gerrit server15:15
Clark[m]fungi: note that the retire user account should probably be run as your admin user and will talk to the Gerrit git server and not the on disk repo. That ensures verification happens and all that15:19
Clark[m]And you might need to tweak the heredoc'd commit message15:19
fungimmm, yeah i guess i need to set up account credentials to be able to push from the gerrit server? or is the idea that i would clone the all-users repo to my workstation?15:20
fungii guess i can clone that as my admin user15:22
Clark[m]Ya workstation is how I've done it15:25
fungicool, i just cloned all-users from gerrit to my workstation via ssh as my admin account, and tweaked the commit message in my checkout of the retire script, just trying to identify the account id number to retire now15:29
fungiugh, once an account has been set inactive, you can't look it up from the rest api any longer15:34
fungiis there a faster way to find it than by brute-forcing all the id refs?15:36
fungii need to step away for a few minutes, but will resume work on this shortly15:36
Clark[m]You can still lookup the account but need to be admin level privs15:48
Clark[m]Also don't forget the /a/ prefix15:48
fungiahh, okay, so can do it through the rest api authenticated16:32
fungiClark[m]: are you sure you can lookup an account via the /a/accounts/ if the associated account is set inactive? doesn't seem to be working for me (i can look up active accounts that way, but not inactive, even after elevating my account to administrators)16:36
fungi"In all cases except a bare account ID and self/me, inactive accounts are not considered. Inactive accounts should only be referenced by bare ID."
fungiseems like it's not expected to work, leaving me with a catch-2216:39
fungii'll start working on a brute-force search loop16:39
Clark[m]You have to use the account I'd number16:46
Clark[m]That is what the docs are saying16:46
Clark[m]I'm not sure how effective a brute force would be. You should have the account I'd as that is what you pushed to to deactivate the account?16:47
Clark[m]fungi ^16:51
fungii deactivated the account by e-mail address16:56
fungiyeah, short-sighted on my part, i forgot the new gerrit version no longer let you look up inactive accounts any other way (also i was used to looking them up by sql query as a fallback)16:57
fungii'm doing a brute force by id number now with git and unfortunately it takes several seconds per iteration (mostly due to the git fetch)16:57
Clark[m]So I guess you need to find the account id then you can remove the preferred email and external ids?16:58
fungimaybe brute-forcing rest api calls would be faster16:58
fungialso trying to cook lunch so slightly distracted as far as writing the script is concerned, but getting there16:58
Clark[m]One hack is to git grep the email address in the externid ids ref16:59
Clark[m]Checking that out is a bit slow since it has all the things in it. I think there may already be a checkout of it in ~gerrit2/tmp17:00
Clark[m]But just got grep with that checked out then look in the files to get the related account ids17:00
fungioh, that's not a terrible idea. i forgot the addresses will be listed in there too and it's a flat tree rather than separate git refs17:01
Clark[m]I would double check any results you get back from that hack though since it's a separate data store17:04
Clark[m]Basically query the account state and make sure it is deactivated 17:05
fungiyeah, but it's a place to start, and avoids me hammering either gerrit's ssh/git or rest api interfaces17:05
fungican't find the existing checkout, what's the refname for that again? i can also go hunting in the gerrit docs but i remember it was buried17:09
fungiwe don't seem to use it in the audit/cleanup scripts, already looked17:09
Clark[m]Is there nothing in ~gerrit2/tmp?17:10
Clark[m]In an All-Users repo?17:10
Clark[m]I'm grabbing my keys so I can look17:11
fungithere's an empty clarkb directory, also an ianw directory i didn't look in17:11
fungimaybe you're thinking of the old server? i can check there17:11
Clark[m]No it was the new server may be in ianws dir17:11
Clark[m]It was used to correct the two broken accounts when we moved servers17:11
fungioh, it was in ianw17:11
fungithanks, git grep is underway17:13
clarkbfungi: if you don't see the account it will be newer than the server move17:14
clarkbfungi: did the grep show it?17:15
fungiit turned up17:20
clarkbok cool so we don't need a newer checkout17:20
fungithough interestingly when i query the rest api (as an admin) for that id it returns a 40417:23
clarkbhow are you querying it?17:24
clarkbGET /a/accounts/abxy/detail ?17:25
fungiaha, accounts, sorry, not the bare account endpoint17:25
fungiand yeah, it comes up now17:25
clarkbI don't think there is a bare account endpoint17:25
clarkbfungi: the three things I tend to look at are /detail /emails and /external.ids17:25
clarkbin this case I think you want /detail to confirm this is the disabled account. Then also /external.ids to see what external ids may need cleanup in addition to the preferred email removal17:26
fungiand i was able to set that account back to --active to it seems to be fine and i should be able to fully retire it17:26
fungiyeah, it's the right one (there are no duplicate accounts for this address)17:27
clarkbseparately there is complaint that ios devices can't load review anymore on the openstack mailing list. I've asked for more info and double checked it works in firefox and chrome on my desktop as well as chrome on my android device17:27
fungion push i get "prohibited by Gerrit: not permitted: update"17:30
fungithat's with my admin account17:30
funginicely vague17:30
clarkbyou need to be a bootstrapper too17:31
clarkbto do the push17:31
clarkbI always forget that then get the error then remember17:32
clarkbfungi: I'm going to transition to yard work now. I'll try to keep an eye on this17:36
clarkbIts good someone else is poking at the user management stuff though :) its definitely "fun" but good to have the experience and know how17:36
fungiyep, for sure. thanks!17:40
fungiand yeah, project bootstrappers membership solved that17:42
fungiso the retirement script is run, now i just have to do the external-id removal script17:43
fungithe external-id for that e-mail address has been removed from the old account now too. luk4s: please try to add it to your new account again when you have tie18:31
fungiwhen you have time, i mean18:31
fungino tie required in this channel, we're all very casually dressed18:32
luk4s fungi will do :)18:45
luk4sfungi, clarkb many thanks for your help18:48
fungiapparently microsoft is refusing delivery for messages from the gerrit server too. i'm taking a look to see what we can do to get it allowed18:56
opendevreviewMerged openstack/project-config master: tripleo-common-tempest-plugin - Step 4: Remove Project
fungi"The IP address you submitted was successfully delisted. This may take up to 30 minutes to take effect."19:16
fungi#status log Delisted the new Gerrit server's IPv4 address from Microsoft's E-mail service spam filter19:17
opendevstatusfungi: finished logging19:17
luk4sfungi, I do a test in 30 mins19:17
fungiluk4s: great, i should still be around for a while after that too19:18
fungiluk4s: "Queued mail for delivery" this time according to the mta log on the gerrit server19:55
luk4sfungi, I can confirm that notifications are working for me now19:55
fungiawesome, thanks for working through this with us!19:56
luk4sno, thank you fungi :)19:57
fungiany time, it's my pleasure19:57
ianwfungi: on your prior comment on gerrit container not coming up but mariadb did, i proposed after i accidentally restarted them22:47
fungiahh, thanks!23:38

Generated by 2.17.2 by Marius Gedminas - find it at!