15:31:35 <nirik> #startmeeting CAIAPI coffee klatch / brainstorming / requirements gathering
15:31:35 <zodbot> Meeting started Thu Jul 26 15:31:35 2018 UTC.
15:31:35 <zodbot> This meeting is logged and archived in a public location.
15:31:35 <zodbot> The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
15:31:35 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
15:31:35 <zodbot> The meeting name has been set to 'caiapi_coffee_klatch_/_brainstorming_/_requirements_gathering'
15:31:38 <bowlofeggs> .hello2
15:31:38 <zodbot> bowlofeggs: [hellomynameis bowlofeggs]
15:31:42 <bowlofeggs> wut
15:31:43 <nirik> Hey everyone.
15:31:48 <cverna> hello3.7
15:31:53 <bowlofeggs> haha
15:31:53 <puiterwijk> .hellomynameis iforgot
15:32:01 <bowlofeggs> .hello bowlofwut
15:32:01 <zodbot> bowlofeggs: [hellomynameis bowlofwut]
15:32:02 <nirik> zodbot has no fedora plugin loaded
15:32:04 <bowlofeggs> hahah
15:32:07 <bowlofeggs> oooh
15:32:11 <nirik> due to pkgdb retirement, so that won't work
15:32:14 <bowlofeggs> oooh
15:32:34 <nirik> anyhow, lets get into it.... puiterwijk care to give a high level overview of CAIAPI? or want me to try?
15:32:42 <puiterwijk> nirik: go ahead
15:33:13 <nirik> so the idea here is that we leverage IPA. We have it doing all the heavy lifting that we can (since we don't maintain it... hurray!)
15:33:24 <nirik> but IPA by itself can't do everything fas2 does
15:33:50 <nirik> so we want a thing that talks to IPA and provides a API
15:33:53 <puiterwijk> Also, it depends on applications directly accessing the LDAP directory, which we don't want to open up
15:34:01 <nirik> yeah. that too.
15:34:26 <nirik> so, CAIAPI will be that API, and then we will have a small app that talks to CAIAPI called "noggin"
15:34:43 <puiterwijk> (naming of "noggin" courtesy of ryanlerch - blame him)
15:34:44 <bowlofeggs> cool
15:34:50 <bowlofeggs> and noggin is like a ui?
15:34:53 <puiterwijk> yes
15:35:13 <cverna> just one question most of our apps are getting the fas info via ipsilon ?
15:35:21 <puiterwijk> cverna: that will not change.
15:35:43 <bowlofeggs> so for most use cases, our apps just keep on doing their thing like they have been doing
15:35:45 <puiterwijk> cverna: the differences are if they use the FAS API right now to get additional info about other users
15:35:54 <bowlofeggs> ah yes
15:35:55 <puiterwijk> Or for users that are not currently in a login flow
15:35:55 <nirik> so today I wanted to just talk about what we need from the api... we can stick things into a 1.0 or a 'future' milestones... I'd propose we want a minimal viable thing for 1.0 and then add extra stuff after that
15:36:08 <bowlofeggs> i don't think bodhi does that, but i suppose i should double check
15:36:14 <puiterwijk> bowlofeggs: it doesn't
15:36:21 <bowlofeggs> cool
15:36:37 <bowlofeggs> yeah MVP is def the way 2 go
15:36:37 <nirik> So, I had a few things I can toss out...
15:36:41 <puiterwijk> So for 99% of our applications, they will not notice a difference, other than possible if they use OpenID Connect with the data being more up-to-date
15:37:06 <puiterwijk> nirik: maybe I should explain one more core part of CAIAPI
15:37:15 <puiterwijk> Which is going to be the most impactful for anyone that needs to use it
15:37:36 <nirik> please do
15:38:26 <puiterwijk> Specifically: when an application needs any information about a user, there will be two types of authentication going on - the application authenticating itself, *and* the application sending a user token to prove that it is currently processing a request for a user. Based on those two, a policy will be applied that determines what information about current or other users CAIAPI will be willing to
15:38:28 <puiterwijk> provide or modify
15:39:09 <puiterwijk> This means that applications will be restricted in what they can request to the specific pieces of information they need at the moment they need it.
15:39:32 * nirik nods.
15:40:05 <puiterwijk> Also, one of my core requirements (just so eople know it's on my radar) is 2fa based on u2f
15:40:19 <nirik> yeah, that was one of the items I was going to ask about...
15:40:21 <puiterwijk> Okay, that's it from me. Now shoot at me
15:40:27 <nirik> here's the next:
15:40:31 <puiterwijk> nirik: that's a core requirement from me
15:40:46 <puiterwijk> (and it will enforce it based on group membership and user settings)
15:41:02 <nirik> FPCA/CLA handling. The way we do this in fas is to make them groups and have them as prereqs. This causes lots of confusion for people. I wonder if we shouldn't make it so when people make their account they just agree to the fpca / view the code of conduct?
15:41:31 <puiterwijk> nirik: right. For that, we should ask spot probably.
15:41:51 <puiterwijk> though I believe I've heard they might want to change it up anyway. So let's talk to Tom about that
15:42:05 <nirik> ok. Does anyone know a use case for 'I want a fas account, but no fpca' ?
15:42:10 <nirik> sure, we should.
15:42:24 <puiterwijk> nirik: Pagure is the big case I've heard
15:42:41 <puiterwijk> We got rid of it requiring FPCA
15:42:53 <nirik> ah, ok.
15:43:03 <bowlofeggs> nirik: i can't think of anything, but i also wouldn't know :)
15:43:10 <fm-apps> github.create -- codeblock created a new tag "0.4" at fedora-infra/supybot-fedora https://github.com/fedora-infra/supybot-fedora
15:43:12 <nirik> I just want to try and kill the 'cla* + 1' thing, because new people don't get it.
15:43:15 <Evolution> puiterwijk: arrfab already covered the requirements from the centos side about this right?
15:43:41 <puiterwijk> Evolution: I am going to meet up with him later about his requirements
15:43:46 <Evolution> centos doesn't require an *pca either.
15:43:58 <puiterwijk> Right. So if it's in htere, it'll certainly be an option
15:44:04 <Evolution> puiterwijk: I would like to ask for federation/namespacing as well.
15:44:06 <puiterwijk> Just like all the email and texts will be templatized... :)
15:44:13 <cverna> I had hard to get the cla+1 thing at the beginning :)
15:44:28 <Evolution> that way we can run one account system for everything and share.
15:44:39 <puiterwijk> Evolution: right. the idea for that was to do that on the IPA level
15:44:41 <Evolution> fedora and cent on the same instace(s).
15:44:44 <Evolution> okay good.
15:44:53 <puiterwijk> And have a CAIAPI for Fedora and CentOS pointing at their respective realms
15:45:39 <Evolution> puiterwijk: will that allow us to share auth/cred across domains? (have fabian admin a fedora thing, or have you admin a centos thing?)
15:45:44 <nirik> puiterwijk: so can I kill that infra issue about renaming cla_done / fpca and stick it on caiapi's tracker and cc tom on it?
15:45:55 <puiterwijk> nirik: yes, please do
15:46:04 <nirik> can do after the meeting.
15:46:23 <puiterwijk> Evolution: possibly, yes
15:46:50 <nirik> ok, another thing: can we add bugzilla email/account... that would kill our stupid overrides
15:46:58 <Evolution> puiterwijk: I would like to use that as a use case if we can. a "community" cloud that both fedora and centos share.
15:47:07 <puiterwijk> Evolution: okay
15:47:28 <Evolution> tl;dr, the next iteration of the new cloud, I'd like to be combined.
15:47:29 <puiterwijk> nirik: right. Those are going to be fun anyway with RHBZ5. I'll need to talk with the people there how to deal with it
15:47:56 <nirik> I can file an issue on that as well if you like to track it.
15:47:58 <puiterwijk> Evolution: note that it's certainly possible for one realm to auth to the other by tying the Ipsilon's together already
15:48:03 <puiterwijk> nirik: please do
15:48:35 <Evolution> puiterwijk: oh, interesting. okay.
15:49:41 <puiterwijk> Oh, for anyone that dind't know yet:
15:49:46 <puiterwijk> #link https://pagure.io/caiapi/
15:49:50 <puiterwijk> That's the project URL
15:50:07 <nirik> another one: migrating to this from fas2. I was wondering if we could drop a bunch of the dead/inactive/not used accounts... I had a idea for what we could do:
15:51:13 <nirik> I first thought about dropping inactive or not logged in in a specified time, but then I thought... hey, why don't we just drop all the fas2 accounts where they haven't logged in and synced to IPA yet? Or is that too big a chunk?
15:51:21 <puiterwijk> nirik: so, one thing to note there is that IPA has "preserved users" - which means they're in the system, useranems are reserved, but they can't login
15:51:44 <puiterwijk> So what we could do is migrate them, but add them to preserved.
15:51:55 <puiterwijk> And then later on delete users from there
15:52:07 <fm-apps> pagure.pull-request.flag.added -- jenkins #18 flagged releng/fedora-module-defaults#16 with "Build successful (commit: 907334c8)" https://pagure.io/releng/fedora-module-defaults/pull-request/16
15:52:24 <nirik> thats a thought... although I think some are sure not useful.
15:52:33 <nirik> like spamcheck_* ones
15:52:38 <puiterwijk> Sure. But then we can take chunks out from there
15:53:05 <nirik> it might be nice to have old users for history, but not sure what level/amount of those...
15:53:11 <cverna> I think I would go for the aggressive strategy :P
15:53:31 <puiterwijk> nirik: right. So, my main reason is that I do not want to make the immediate migration of data much harder with the clearing of users at the same time
15:53:33 <Evolution> puiterwijk || nirik I'd like to put milestones and due dates on the caiapi development to make sure we hit things on something like a schedule please.
15:53:42 <puiterwijk> In my mind, that's just *begging* for users to disappear incorrectly
15:54:09 <bowlofeggs> but if you remove my spam accounts how will i advertise freenode staff blogs on the wiki?
15:54:11 <puiterwijk> nirik: I want to be able to just do a count(*) on FAS and a count on IPA and have that match to know everyone's over
15:54:12 <cverna> puiterwijk: valid point
15:54:12 <nirik> puiterwijk: fair enough, but it's also a good point to drop things since we have a LOT LOT LOT of spam users.
15:54:27 <puiterwijk> nirik: sure. I'm not opposed to that. Just not at the initial migration
15:54:32 <puiterwijk> So I want to detach it from the migration
15:54:41 <nirik> Evolution: sounds good to me...
15:54:51 <puiterwijk> Evolution: ack.
15:54:57 <bowlofeggs> separation_of_concerns++
15:55:01 <cverna> could we delete the spam accounts in fas2 before the migration ?
15:55:36 <nirik> I suppose we could...
15:56:26 <pingou> +1
15:56:41 <puiterwijk> I'd say that that depends on the schedule.
15:56:49 <nirik> which brings up another item: basset
15:57:19 <puiterwijk> nirik: in what way? Since, obviously, I have that in mind.
15:57:57 <nirik> well, do we add support for basset here or do we think it's not needed or is it build more into caiapi itself?
15:58:30 <puiterwijk> CAIAPI won't need basset support. basset gets CAIAPI support and noggin submits to Basset
15:58:45 <cverna> I think it would be nice also for CAIAPI development not to be a one person job, so the knowledge of the application is spread over the team :)
15:58:57 <nirik> ah, makes sense.
15:59:53 <bowlofeggs> i can help maintain it
15:59:56 <bowlofeggs> (caipai)
16:00:06 <puiterwijk> bowlofeggs: ack, thanks
16:00:24 <puiterwijk> Also, I've had discussions with some upstream people that might be willing t pick it up if we get it working.
16:01:05 <cverna> Yeah I would be happy to help also with the development
16:01:15 <nirik> is ryan making noggin? or just doing help with design, etc?
16:01:32 <puiterwijk> nirik: he's doing a lot of it, yeah
16:01:59 <nirik> would be good to have more folks on that too so it's not one lone superman. ;)
16:02:17 <puiterwijk> nirik: yeah, I'm oging to do the final integration on it I was thinking
16:02:37 <puiterwijk> "final"...
16:02:43 <nirik> so once we switch this fasClient is replaced by ? sssd ? ipaclinent?
16:02:54 <vgolwala> apologies for out of topic question, but if i switch branch while 'bdiff-cover' is already running in Bodhi, will it continue with files loaded from old branch or the new one?
16:03:09 <puiterwijk> vgolwala: any chance you can ask that after the meeting?
16:03:20 <puiterwijk> nirik: ipaclient, together with fssh for ssh
16:03:22 <vgolwala> puiterwijk: sure, my bad!
16:03:52 <puiterwijk> nirik: but basically, ipaClient
16:03:55 * nirik tries to think of anything else he had.
16:04:22 <bstinson> fssh?
16:04:33 <fm-apps> pagure.issue.comment.edited -- mprahl edited a comment on ticket fm-orchestrator#974: "Tag into koji based on runtime requires" https://pagure.io/fm-orchestrator/issue/974#comment-523723
16:04:47 <puiterwijk> bstinson: I'll sync up later about that with you. But basically, u2f enhanced ssh stuff
16:04:54 <nirik> oh, and totpcgi replaced also with ipaclient?
16:05:01 * nirik needs to read up on it.
16:05:02 <fm-apps> pagure.issue.assigned.reset -- mprahl reset the assignee of ticket fm-orchestrator#974 https://pagure.io/fm-orchestrator/issue/974
16:05:03 <puiterwijk> nirik: no. fssh.
16:05:28 <puiterwijk> That's a different, related, topic. I'll explain that later.
16:06:31 <nirik> so back to Evolution's question... whats our timeframe for all this? :) it's just in design now, no code yet right?
16:07:12 <puiterwijk> nirik: if I can get time to focus on this without a fried brain, I'd say 2-3 weeks for staging.
16:07:43 <nirik> does noggin have a pagure project yet?
16:07:47 <Evolution> puiterwijk: +1 week for finishing up repospammer
16:07:50 <Evolution> er, spanner
16:07:55 <puiterwijk> With a fried brian, I'm going for ∞ weeks
16:07:56 <nirik> it does
16:08:07 <nirik> https://pagure.io/noggin
16:08:22 <puiterwijk> Evolution: yeah. that's why the "just this"
16:08:36 <puiterwijk> With that included, I'm going for the 4-5, since I'd like to not rush that deployment
16:08:46 <fm-apps> pagure.issue.comment.added -- mprahl commented on ticket fm-orchestrator#974: "Tag into koji based on runtime requires" https://pagure.io/fm-orchestrator/issue/974#comment-523738
16:08:58 <fm-apps> github.pull_request.synchronize -- vismay-golwala synchronized pull request #2494 on fedora-infra/bodhi https://github.com/fedora-infra/bodhi/pull/2494
16:09:09 <nirik> oh, whats CAIAPI going to be written in? python? python3?
16:09:18 <puiterwijk> nirik: python3 flask
16:09:20 <nirik> and what editor will you use? emacs?
16:09:26 <puiterwijk> vscode, probably
16:09:33 <cverna> do we know what is the scope of the MVP ? before we give a timeline ?
16:09:43 <Evolution> cverna++
16:09:45 <bowlofeggs> puiterwijk: let's switch to rust nightly
16:09:48 * bowlofeggs runs
16:09:57 * relrod feels the emacs hate and cowers in a corner :(
16:10:00 <puiterwijk> bowlofeggs: don't temp me to go Go.
16:10:01 <bowlofeggs> hahaha
16:10:15 <bowlofeggs> relrod: i've been running vim for over 20 years… i can't figure out how to exit it
16:10:20 <puiterwijk> relrod: I... don't think there's hate against it..
16:10:25 <Evolution> relrod: if you use emacs, we may have to discuss what your performance plan is going to look like.....
16:10:27 <puiterwijk> cverna: yes, pretty much
16:10:37 <relrod> Evolution: haha
16:10:50 <puiterwijk> (as in, yes, I know what the MVP is, unless anyone is going to add anything big at this moment in time)
16:11:00 <cverna> I think it would be nice to fill the pagure project with issues and use the milestone feature
16:11:04 <nirik> cverna: I'd say something that can replace fas2... but then thats kinda vuage, because we don't want something that does all fas2 did, we want to simplify
16:11:08 <puiterwijk> Which is what this meeting was for. If people think there are more critical stuff, tell me now
16:11:25 <Evolution> puiterwijk: please work with cverna to document the mvp for milestone/schedule then?
16:11:42 <cverna> so it is easy to track progress and it is also easy for me to know how I can give a hand :)
16:11:45 <nirik> yes, we should do a 1.0 MVP and push wishlist things out after that. ;)
16:12:12 <Evolution> actual measureable goal/deliverables please.
16:12:13 <puiterwijk> cverna: so, I know what you can help me with - maintain all the tickets then? :P
16:12:17 * nirik is happy to file issues and make up milestones unless someone else wants to.
16:12:25 <cverna> puiterwijk: sure :)
16:12:42 <cverna> nirik: I can help you with that
16:12:48 <Evolution> nirik: if you do, please get input from cverna, given his scrum/agile background.
16:12:55 <nirik> sure thing.
16:13:08 <bowlofeggs> RFE: the ability to disable puiterwijk's account for days he *should* be on vacation but isn't
16:13:13 <nirik> I don't care who does it, as long as it's done. ;) we can start by filing tickets on things.
16:13:29 <cverna> bowlofeggs++
16:14:20 <puiterwijk> Anyonw has anything else for this moment?
16:14:34 <nirik> I think thats it from me for now at least
16:14:34 <cverna> also we can't roll out CAIAPI without noggin ? or can we ?
16:14:46 <nirik> well, we can, but not sure how useful it would be.
16:14:46 <puiterwijk> cverna: technically, yes, practically, no
16:14:54 <puiterwijk> Well, actually....
16:15:42 <puiterwijk> So, one thing we need is an overview of any applications that use the FAS API right now.
16:16:11 <cverna> do we need to do the same milestone and feature needed for noggin ?
16:16:12 <puiterwijk> If we find anything big there that is going to take a while to migrate, we can make CAIAPI support FAS as backend, so we can start migrating those applications
16:16:48 <nirik> cverna: I'd say yes
16:17:03 <Evolution> puiterwijk: let's make sure what we do simplifies things overall.
16:17:36 <puiterwijk> cverna: if you're going to do stuff for nogging, manage it as if it's part of caiapi please. I really do not want to end up spending 50% of the time trackin gdown on which end a ticket is and updating/maintaining 20 ticket for a single thing
16:17:42 <Evolution> puiterwijk: in theory this *should* be project neutral and it would be nice for some of it to be picked up by the IPA devs.
16:18:16 <cverna> puiterwijk: I agree we need to consider these 2 projects together
16:18:19 <puiterwijk> Evolution: yes, but I meant as a migration step so as to not require everything to switch on the exact same day. And that is what I had planned myself
16:18:58 <Evolution> puiterwijk: perfect.
16:19:04 <bstinson> which project owns the workflow engine? is noggin just the frontend, or is it the process management piece as well?
16:19:14 <nirik> is there a way to gather apps that use fas api now? (by looking at fas logs or something?)
16:19:24 <puiterwijk> bstinson: process management stuff is IPA itself primarily
16:19:39 <bstinson> puiterwijk: including sponsorship workflows?
16:19:45 <puiterwijk> bstinson: yes
16:20:07 <puiterwijk> bstinson: the one thing CAIAPI will know how to do is how to exactly set up the IPA permissions to enforce our sponsorship flows
16:20:22 <puiterwijk> Since technically IPA can do it, but it requires a lot of manual fiddling. And that'll be in CAIAPI
16:20:30 <puiterwijk> But all the actual enforcement etc will be IPA
16:20:34 <bstinson> so caiapi will hold the rule definitions
16:20:51 <puiterwijk> Yes
16:21:15 <puiterwijk> But enforcement is IPA
16:21:20 <bstinson> but if i'm an admin on a group, what is my interface to provide sponsorship to someone else? is that part of noggin?
16:21:37 <puiterwijk> Do you use the API or clickety clickety?
16:21:42 <puiterwijk> Former - CAIAPI, latter - noggin
16:21:51 <puiterwijk> Noggin is literally just a frontend directly talking to CAIAPI
16:21:57 <bstinson> got it
16:22:27 <nirik> so for down the road it might be nice to have a command line util as well... but not for 1.0
16:22:40 <puiterwijk> nirik: I'm leaving that to $someone_else to do
16:22:47 <cverna> just a question any reason we choose to go with 2 different projects ?
16:23:05 <bstinson> as long as the process logic is in one place that sort of thing gets easier
16:23:13 <puiterwijk> cverna: as I said before, the plan was to do CAIAPI first backed by FAS so hubs could start using it
16:23:36 <puiterwijk> cverna: but now that hubs is no longer a concern, it's more a strict separation of concerns
16:25:01 <cverna> puiterwijk: ok, I was just thinking that since it is "just" the UI it might be easier to manage one project rather than 2. same latter with people filling bugs or trying to know if the issue is in noggin or CAIAPI
16:25:43 <puiterwijk> cverna: because it is a different problem set from CAIAPI
16:25:59 <puiterwijk> Since noggin will also need things like templating and translation.
16:26:20 <cverna> oh I have another question :)
16:26:32 <cverna> will these apps run in openshift ?
16:26:41 <puiterwijk> Yes
16:26:55 <cverna> can we use s2i ? :D
16:27:22 <puiterwijk> Did anyone build a license-enforcing s2i image yet?
16:27:23 <cverna> It would be very nice to have some sort of continuous delivery :)
16:27:32 <fm-apps> pagure.pull-request.comment.added -- mprahl commented on PR #973 on fm-orchestrator https://pagure.io/fm-orchestrator/pull-request/973#comment-59170
16:27:43 <cverna> that could be part of CAIAPI MVP
16:27:48 <puiterwijk> It is not.
16:28:05 <cverna> and that would save a lot of time in application release and deployment
16:28:19 <nirik> openshift++
16:28:19 <cverna> just saying :P
16:28:30 <fm-apps> pagure.pull-request.comment.added -- mprahl commented on PR #973 on fm-orchestrator https://pagure.io/fm-orchestrator/pull-request/973#comment-59171
16:28:32 <nirik> thats a deployment detail tho. ;)
16:28:34 <puiterwijk> I do not think I fully agree with that
16:28:43 <bowlofeggs> i think that's a separate concern
16:28:46 <puiterwijk> but we'll see
16:28:51 <bowlofeggs> probably should emphasize the M in MVP
16:29:01 <bowlofeggs> because that doesn't sound like an easy problem ot solve
16:29:01 <puiterwijk> Yep
16:29:06 <bowlofeggs> though it would be a good problem to solve in general
16:29:18 <puiterwijk> Oh, I don't disagree on that. Just not as part of CAIAPI
16:29:28 <bowlofeggs> yeah that's what i'm getting at
16:29:49 <nirik> so, we are up on an hour here... does anyone have further items? or shall we close out and go file tickets. ;)
16:29:56 <puiterwijk> Okay, it's time. Anyone else has any critical things remaining?
16:30:00 <puiterwijk> Yeah, what Kevin says
16:30:06 <cverna> I think automated deployment would save us quite some time and also enable us to deliver feature much faster. But I agree that another topic
16:30:19 <puiterwijk> cverna: I do not think I agree with that either.
16:30:43 <puiterwijk> Because I believe that what we have right now is already significantly what we'd need/want
16:30:48 <cverna> puiterwijk: happy to discuss it at flock :)
16:31:11 <puiterwijk> cverna: come to my and bowlofeggs' talk and see what you think then :)
16:31:26 <puiterwijk> So, sure, flock
16:32:08 <nirik> thanks for coming everyone!
16:32:10 <puiterwijk> Okay, if nothing else, let's call it an end. Any thing else you can ping me on IRC or file tickets
16:32:14 <nirik> #endmeeting