19:31:31 <smooge> #startmeeting infra-backlog
19:31:31 <zodbot> Meeting started Thu Jan  9 19:31:31 2020 UTC.
19:31:31 <zodbot> This meeting is logged and archived in a public location.
19:31:31 <zodbot> The chair is smooge. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:31:31 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
19:31:31 <zodbot> The meeting name has been set to 'infra-backlog'
19:31:34 <bowlofeggs> hahaha
19:31:37 <nirik> bowlofeggs: either way. It's sometimes nice to have more folks around...
19:31:41 <bowlofeggs> like literally another immedaite meeting?
19:31:43 <nirik> but ok.
19:31:43 <smooge> #chair nirik bowlofeggs smooge cverna
19:31:43 <zodbot> Current chairs: bowlofeggs cverna nirik smooge
19:31:49 <nirik> yeah, I guess so. :)
19:31:52 <bowlofeggs> ahaha ok
19:32:07 <nirik> smooge has that meeting gleam in his eye.
19:32:09 <smooge> #topic You can checkout anytime but you can never leave
19:32:15 <nb> hello
19:32:16 <nirik> anyhow...
19:32:21 <bowlofeggs> .hello2
19:32:23 <zodbot> bowlofeggs: bowlofeggs 'Randy Barlow' <rbarlow@redhat.com>
19:32:24 <nb> .hello2
19:32:26 * cverna waives
19:32:26 <zodbot> nb: nb 'Nick Bebout' <nick@bebout.net>
19:32:32 <nirik> bowlofeggs: what would you think about working on https://pagure.io/fedora-infrastructure/issue/6320
19:32:35 <bowlofeggs> so, new topic, or do we want to talk about fedmsg-tail?
19:32:47 <nirik> basically we need to make a one time thing to add a bunch of fas users to a group.
19:32:54 * bowlofeggs is reading
19:33:48 <nirik> well, I guess if they even still want it... it's been 2 years. ;(
19:34:34 <bowlofeggs> hmm, i'm not sure i have the knowledge of FAS to do that effectively
19:34:45 <fm-admin> pagure.issue.edit -- cverna edited the close_status and status fields of ticket fedora-infrastructure#8515 https://pagure.io/fedora-infrastructure/issue/8515
19:34:46 <fm-admin> pagure.issue.comment.added -- cverna commented on ticket fedora-infrastructure#8515: "Fix updates in pending for ignatenkobrain" https://pagure.io/fedora-infrastructure/issue/8515#comment-620002
19:34:47 <bowlofeggs> is it easy to do it via SQL?
19:34:53 <nirik> or there's https://pagure.io/fedora-infrastructure/issue/6572 (github "badges")
19:34:57 <bowlofeggs> or do i need to learn the FAS API?
19:35:13 <nirik> I don't think it's easy to do via sql, but it might be possible...
19:35:15 <bowlofeggs> (i.e., is there python code that must trigger on group creation, to do things like send fedora-messages?)
19:35:36 <bowlofeggs> i imagine there probably are messages that should go, which would rule out SQL
19:35:38 <nirik> nope, it could be done in the db if you can get it to
19:36:03 <nirik> well, just the 'added to group x' ones. I guess that could affect badges
19:36:28 <nirik> I don't think it's that important personally.
19:36:48 <bowlofeggs> does the badges thing map to our mission well? seems like no to me?
19:36:58 <nirik> yeah, not really.
19:37:00 <bowlofeggs> that's as in github "shields", not as in "fedora badges app" right?
19:37:26 <cverna> bowlofeggs: yes I agree I don't think that map our mission
19:37:33 <bowlofeggs> if the FAS one can be a SQL query, i miiiight could take a look, but not fully comfortable promising
19:37:40 <bowlofeggs> since i don't know the schema at all
19:37:51 <nirik> bowlofeggs: ok. Thats completely fair
19:37:57 <bowlofeggs> i imagine we don't have a FAS db dump available for me to play with due to privacy?
19:37:57 <nirik> .ticket 7125
19:37:58 <zodbot> nirik: Issue #7125: RFR: repoSpanner - fedora-infrastructure - Pagure.io - https://pagure.io/fedora-infrastructure/issue/7125
19:38:05 <nirik> that can be closed now right? ^
19:38:14 <smooge> ugh yeah..
19:38:17 <bowlofeggs> nirik: yes
19:38:40 <nirik> bowlofeggs: Not a public one.... but in /backups on db-fas01 would be one. Or you could play with stg and if something messed up just sync from prod
19:38:49 <fm-admin> pagure.issue.edit -- smooge edited the close_status and status fields of ticket fedora-infrastructure#7125 https://pagure.io/fedora-infrastructure/issue/7125
19:38:50 <fm-admin> pagure.issue.comment.added -- smooge commented on ticket fedora-infrastructure#7125: "RFR: repoSpanner" https://pagure.io/fedora-infrastructure/issue/7125#comment-620004
19:38:51 <bowlofeggs> yeah stg would be fine
19:39:02 <bowlofeggs> ok, i'll take a look and let you know how easy/hard it seems
19:39:16 <bowlofeggs> get ready for some LEFT OUTER JOINs!
19:39:22 <nirik> .ticket 7260
19:39:23 <zodbot> nirik: Issue #7260: the Postorius version used for: https://lists.fedorahosted.org/ ... is stale - fedora-infrastructure - Pagure.io - https://pagure.io/fedora-infrastructure/issue/7260
19:39:24 <relrod> changing it in sql scares me for a number of reasons. I haven't read the ticket history, but can't a new group just be created?
19:39:37 <nirik> smooge: ^ thats the same as the 'move mailman3 to new os?'
19:39:44 <bowlofeggs> relrod: yeah there's a new group, but they want to mass add people from one group to the new group
19:39:59 <bowlofeggs> doingit in SQL will bypass any side effects that might be happenign in python
19:40:03 <relrod> bowlofeggs: oh that should be super easy to automate with the API
19:40:04 <bowlofeggs> which might be Bad™
19:40:18 <bowlofeggs> relrod: if it has an API, i could look at that too
19:40:24 * bowlofeggs knows nothing about FAS
19:40:27 <smooge> nirik, yeah. I think I marked it dependent. do you want me to close it out as look at 8455?
19:40:42 <nirik> .ticket 7377
19:40:43 <zodbot> nirik: Issue #7377: SSH keys length can prevent user from login in Fedora infrastructure - fedora-infrastructure - Pagure.io - https://pagure.io/fedora-infrastructure/issue/7377
19:40:51 <relrod> bowlofeggs: it does. I can try to come up with a script that someone in 'accounts' can run. It should be almost trivial.
19:40:54 <nirik> smooge: dependent is ok I guess, but seems overkill, might close one?
19:41:08 <bowlofeggs> relrod: cool, sure if you want to do it go for it
19:41:20 <bowlofeggs> relrod: it sounds like you know a lot more about it that i do
19:41:31 <fm-admin> pagure.issue.comment.added -- smooge commented on ticket fedora-infrastructure#8455: "Move mailman to newer release of Fedora or CentOS" https://pagure.io/fedora-infrastructure/issue/8455#comment-620006
19:41:33 <nirik> relrod: perhaps we could close 7377 in favor of a aaa upstream ticket to make sure the new system doesn't have that problem?
19:41:39 <relrod> bowlofeggs: well I wrote a POC fas2ipa script recently so I had to mess with it
19:41:51 <bowlofeggs> relrod: heh, oh yeah that makes sense
19:41:55 <bowlofeggs> haha you prob know a lot about it
19:42:22 <bowlofeggs> nirik: that's not a bad idea too, we can basically say it's an RFE
19:42:30 <bowlofeggs> honestly, it doesn't sound super important either
19:42:33 <fm-admin> pagure.issue.dependency.removed -- smooge removed ticket fedora-infrastructure#7260 as a dependency of ticket fedora-infrastructure#[8455] https://pagure.io/fedora-infrastructure/issue/7260
19:42:52 <fm-admin> pagure.issue.edit -- smooge edited the close_status and status fields of ticket fedora-infrastructure#7260 https://pagure.io/fedora-infrastructure/issue/7260
19:42:53 <fm-admin> pagure.issue.comment.added -- smooge commented on ticket fedora-infrastructure#7260: "the Postorius version used for:  https://lists.fedorahosted.org/ ... is stale" https://pagure.io/fedora-infrastructure/issue/7260#comment-620008
19:43:05 <relrod> nirik: I'm trying to remember details here.
19:43:52 <smooge> sorry I think (3 keys each related to 8196 bit private key), is NOT our problem
19:44:40 <relrod> well... I think it should be allowed but I don't remember where the actual issue is here. I don't remember if it's an OIDC payload length limit or what
19:45:11 <relrod> nirik: might be good to @ patrick on it and see if he can comment
19:45:32 <relrod> I think it's more on the OIDC/ipsilon side than on the AAA backend side
19:45:42 <puiterwijk> Hello there.
19:45:51 <bowlofeggs> whoah!
19:45:53 <bowlofeggs> puiterwijk!
19:45:56 <bowlofeggs> puiterwijk++
19:45:56 <zodbot> bowlofeggs: Karma for puiterwijk changed to 3 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
19:46:00 <bowlofeggs> we have missed you
19:46:03 <relrod> oh god he pings on patrick I forgot
19:46:06 <nirik> I think it's openid yes...
19:46:06 <puiterwijk> So, is there a summary, or shall I read back?
19:46:21 <bowlofeggs> puiterwijk: can you come back and be on our team again
19:46:24 <nirik> puiterwijk: 3 8192 bit ssh keys... cookie too big
19:46:29 <bowlofeggs> that's really what we were talking about
19:46:44 <puiterwijk> nirik: hah. Fun one. Solution: use smaller keys. It'll also save lots of energy!
19:46:57 <fm-admin> pagure.issue.edit -- kevin edited the close_status and status fields of ticket fedora-infrastructure#7888 https://pagure.io/fedora-infrastructure/issue/7888
19:46:57 <fm-admin> pagure.issue.comment.added -- kevin commented on ticket fedora-infrastructure#7888: "moving copr builders to kubevirt/openshift virtualization" https://pagure.io/fedora-infrastructure/issue/7888#comment-620010
19:47:30 <puiterwijk> Anyway, which application?
19:47:36 <smooge> fas
19:47:43 <smooge> and then our new fas
19:47:54 <puiterwijk> Ah
19:48:15 <puiterwijk> Right, ticket #7377
19:48:48 <puiterwijk> So, one advantage: most applications shouldn't be asking for SSH keys. Solution would just be to port the apps that do to OIDC
19:49:19 <nirik> puiterwijk: hey, while you are here... you gonna be at devconf/after devconf? :) also, any thoughts on sigul release?
19:49:44 <puiterwijk> nirik: yep, will be at devconf and/or after devconf for a few days
19:49:49 <nirik> yeah, src they could just use https...
19:49:53 <puiterwijk> And yeah, that release is on my short-term TODO
19:50:23 <nirik> pagure to oidc I am not sure where it was stalled?
19:50:52 <bowlofeggs> i think pagure might do oidc, but bodhi doesn't
19:50:58 <cverna> last we discussed it it needed some changes in ipsilon to support smart scope
19:51:08 <nirik> awesome! there is some talk about other places using it, but they wanted it to be... up to date on things like gpg2
19:51:31 <nirik> bowlofeggs: but bodhi shouldn't ask for ssh key. :)
19:51:39 <bowlofeggs> yeah i don't think it does
19:51:52 <cverna> https://pagure.io/pagure/pull-request/3016
19:51:53 <smooge> no it should.. it should require the private keys
19:51:53 <puiterwijk> cverna: that was the idea at the time yes, but then we decided to in the long term move to something that won't include dynamic/smart scopes anyway, so maybe we should just flatten them..
19:52:15 <cverna> puiterwijk: ha ok I did not know about that :)
19:52:16 <bowlofeggs> patrick gave me his private key before he abandoned us in case i needed it
19:52:17 <puiterwijk> nirik: right. And the current master *is* compatible with gpg2 and py3, and both are tested.
19:52:28 <puiterwijk> cverna: yeah, sorry, I should've commented back on that at some point.
19:52:39 <cverna> puiterwijk: no problem :)
19:53:03 <puiterwijk> So, let's say that we should flatten that to standard scopes and then get that moved at some point
19:54:03 <cverna> +1
19:54:13 <cverna> the key part being at some point :P
19:54:15 <puiterwijk> nirik: also, small correction: the problem here isn't per se cookies, but it's also just the standard HTTP header maxlength of browsers :)
19:54:33 <nirik> ah indeed.
19:54:35 <smooge> i am confused.. are we still talking 7377?
19:54:41 <puiterwijk> cverna: I'm no longer involved in the prioritisation, so I'll go with whatever you guys tell me :)
19:54:50 <puiterwijk> smooge: yes and then I got questions in the middle.
19:55:02 <puiterwijk> My last remark (cookies vs header maxlength) was about 7377
19:55:56 <nirik> bowlofeggs: another thing if you have cycles would be to help us finish the fedmsg producing stuff. Thats 8213
19:56:16 <smooge> puiterwijk, thanks
19:56:53 <nirik> hacky way to see whats still doing fedmsgs: fedmsg-tail --terse | grep -v amqp-bridge
19:57:35 <nirik> huh, wait... thats not right
19:58:57 <bowlofeggs> lemme see
19:59:56 <nirik> there should be some way to tell...
20:00:48 <bowlofeggs> oh wow, that's enormous
20:01:02 <nirik> which?
20:01:07 <bowlofeggs> 8213
20:01:22 <bowlofeggs> that seems like the sort of thing we'd want to formally plan out, for each app
20:01:44 <bowlofeggs> unless there's some specific item from that that's smallish
20:01:52 <bowlofeggs> i.e., this would take me more than a year to do probably hahaha
20:02:02 <nirik> yeah, can you point me to the 'each app' list? :)
20:02:16 <nirik> ie, we have no such list
20:02:34 <nirik> especially since it's not just apps, it's scripts...
20:02:47 <nirik> Many things are done already.
20:02:58 <cverna> for me retiring fedmsg is an initiative on its own
20:02:59 <bowlofeggs> oh, i was referring to the list of playbooks at the begining
20:03:10 <bowlofeggs> i took that to mean "the apps tied to these playbooks still use fedmsg)
20:03:12 <nirik> cverna: yeah, could well be...
20:03:21 <bowlofeggs> uh, s/\)/"/ ?
20:03:27 <cverna> I guess if the sustaining team has some cycle we should look at that
20:03:28 <nirik> it would be nice to know whats left now
20:03:39 <nirik> my tail does work...
20:03:48 <cverna> It would be really good to have done before colo move, but I don't think that will happen
20:04:05 <nirik> so I think so far I have seen: github2fedmsg, src?
20:04:11 <bowlofeggs> yeah that seems like a huge effort to me
20:04:43 <nirik> yep
20:05:18 <cverna> even more since we don't have much knowledge of fedmsg in the team anymore
20:05:30 <nirik> bowlofeggs: I can keep poking around for good things for you with a programming slant if you like... I don't think we found you much so far...
20:05:30 <bowlofeggs> s/much/any/ ? ☺
20:05:37 <cverna> bowlofeggs: :)
20:06:02 <cverna> bowlofeggs: we have fedora-messaging schema to write
20:06:03 <nirik> right, but the usual action is: port to fedora-messaging
20:06:05 <bowlofeggs> i think p to the atrick was the last person to know it well
20:06:12 <cverna> bowlofeggs: that would be really helpful
20:06:14 <bowlofeggs> i bet he doesn't get alerted on that
20:06:25 <bowlofeggs> i can do some schema
20:06:38 <cverna> the koji plugin would be good
20:06:48 <bowlofeggs> it's tedious, but i think it's also important
20:06:56 <cverna> agreed
20:07:01 <bowlofeggs> cverna: where is that code?
20:07:06 <cverna> let me try to find it
20:07:09 <relrod> I need to run to the DMV (wish me luck - I have an appointment so hopefully not TOO much waiting around).
20:07:14 <cverna> it is somewhere in pagure
20:07:17 <nirik> relrod: good luck
20:07:19 <smooge> ok anything else for this meeting?
20:07:28 <bowlofeggs> relrod: some good practice at standing in line for you!
20:07:42 <cverna> bowlofeggs: https://pagure.io/koji-fedmsg-plugin
20:07:51 <bowlofeggs> cverna: cool, i'll take a look at that
20:08:00 <relrod> nirik: could you at some point temporarily add me to accounts on staging fas, so I can test/knock out a script for #6320
20:08:01 <cverna> bowlofeggs++
20:08:01 <zodbot> cverna: Karma for bowlofeggs changed to 1 (for the current release cycle):  https://badges.fedoraproject.org/tags/cookie/any
20:08:25 <nirik> relrod: ok
20:08:29 <bowlofeggs> oh wow, no tests
20:08:32 <bowlofeggs> that's not… good
20:08:44 <bowlofeggs> that means there's no way to know if changes break it
20:08:50 <cverna> yes tests would be nice too
20:09:01 <cverna> also moving the project to github :P
20:09:14 <cverna> but that's a different topic
20:09:31 <nirik> also, it would be nice if it had more error handling so if rabbitmq was unhappy it errored
20:09:49 <nirik> ok, lets end meeting and talk amoungst ourselves
20:09:54 <cverna> +1
20:10:14 <nirik> oh, ansible git is still fedmsg.
20:11:11 <nirik> #endmeeting