18:00:01 <nirik> #startmeeting Infrastructure (2016-05-19)
18:00:01 <zodbot> Meeting started Thu May 19 18:00:01 2016 UTC.  The chair is nirik. Information about MeetBot at http://wiki.debian.org/MeetBot.
18:00:01 <zodbot> Useful Commands: #action #agreed #halp #info #idea #link #topic.
18:00:01 <zodbot> The meeting name has been set to 'infrastructure_(2016-05-19)'
18:00:02 <nirik> #meetingname infrastructure
18:00:02 <zodbot> The meeting name has been set to 'infrastructure'
18:00:02 <nirik> #topic aloha
18:00:02 <nirik> #chair smooge relrod nirik abadger1999 lmacken dgilmore threebean pingou puiterwijk pbrobinson
18:00:02 <zodbot> Current chairs: abadger1999 dgilmore lmacken nirik pbrobinson pingou puiterwijk relrod smooge threebean
18:00:02 <nirik> #topic New folks introductions / Apprentice feedback
18:00:08 <smooge> .hello
18:00:09 <zodbot> smooge: (hello <an alias, 1 argument>) -- Alias for "hellomynameis $1".
18:00:14 <puiterwijk> .hello puiterwijk
18:00:15 <zodbot> puiterwijk: puiterwijk 'Patrick "マルタインアンドレアス" Uiterwijk' <puiterwijk@redhat.com>
18:00:17 <smooge> works for me
18:00:31 <tflink> .hello tflink
18:00:32 <zodbot> tflink: tflink 'Tim Flink' <tflink@redhat.com>
18:00:41 <smooge> hellomynameis $1
18:00:58 <lousab> .hello lousab
18:00:59 <zodbot> lousab: lousab 'luigi sainini' <luigi.sainini@tiscali.it>
18:01:00 <nirik> .hellomynameis Ingio Montoya!
18:01:02 <zodbot> nirik: Sorry, but you don't exist
18:01:10 <nirik> anyhow, welcome everyone.
18:01:38 <sayan> .hello sayanchowdhury
18:01:39 <zodbot> sayan: sayanchowdhury 'Sayan Chowdhury' <sayan.chowdhury2012@gmail.com>
18:01:47 <nirik> Any new folks like to give a short one line introduction? Or any apprentices with questions or comments ? (which we could also wait and cover in the apprentice office hours time later)
18:02:56 <nirik> okey dokey.
18:03:18 <nirik> on to info/status/announcements
18:03:22 <nirik> #topic announcements and information
18:03:22 <nirik> #info comps and spin-kickstarts moved to pagure.io - kevin
18:03:23 <nirik> #info removed old docs-backend01 el6 instance, no longer needed - kevin
18:03:23 <nirik> #info added a number of jenkins projects and packages to jenkins builders - kevin
18:03:23 <nirik> #info helped work on https://pagure.io/quick-fedora-mirror with tibbs - kevin
18:03:24 <nirik> #info removed download-ib02 (01 is ready to take it's place) - kevin
18:03:26 <smooge> I think there is a lot of between school stuff
18:03:27 <nirik> #info Fixed up several hosts whos playbooks wouldn't complete - kevin
18:03:29 <nirik> #info Finally got all lists moved and collab03/hosted-lists01 can be retired - kevin/abompard
18:03:31 <nirik> #info OpenID Connect / OAuth2 support merged into Ipsilon - patrick
18:03:36 <nirik> anyone have anything to add or want to discuss in those?
18:03:50 <nirik> smooge: likely so. Lots of vacationing too.
18:04:35 * pbrobinson is lurking, on another conf call
18:05:09 <nirik> #topic Fedorahosted migration / EOL - kevin
18:05:27 <nirik> so I didn't have much on this, still need to contact projects and gather more requirements.
18:05:37 <nirik> I did move comps and spin-kickstarts over to pagure...
18:05:48 <nirik> I still need to clean up docs and announce things, etc.
18:06:14 <nirik> The trac ticket importer is coming along nicely, but still had a few rough edges...
18:06:17 <puiterwijk> I think one thing we can decide here is that new projects will either need to be on Pagure or have a strong reason why they couldn't. So in other words, don't add any new projects.
18:06:29 <nirik> we will need that to be solid before we move anything that needs to keep it's tickets
18:06:54 <nirik> puiterwijk: yeah, I have been doing that for a while... when someone requests a hosted project I ask them to look at pagure.
18:07:08 <puiterwijk> nirik: sure, but maybe document it so that other people also do that for requests?
18:07:23 <nirik> sure. Perhaps we could adjust the ticket template...
18:07:40 <smooge> when is infrastructure moving over to pagure?
18:07:56 <puiterwijk> Also, note that merging a project that has already partially moved to Pagure is going to be a massive pain, because the ticket numbers won't be able to come across anymore.
18:08:09 <nirik> smooge: well, at least not until the ticket migrator works 100%
18:08:40 <nirik> puiterwijk: you mean if a project has issues and tickets enabled in both places and wants to move to just issues
18:08:41 <nirik> ?
18:09:01 <puiterwijk> Well, even if they have tickets in Trac but only PRs in Pagure
18:09:10 <puiterwijk> since in Pagure, issues and PRs share the numbering namespace
18:09:31 <nirik> sure. I don't think we should allow/encourage 1/2 moves.
18:09:47 <puiterwijk> For example Ipsilon is going to have this issue: we have been using Pagure's PR system, but trac's ticketing system since it is more feature-complete
18:10:08 <puiterwijk> When we decide to move that over, it's going to cause pain for us in one way or the other, since there's namespace conflicts
18:10:56 <puiterwijk> And I think there's a few other projects that have done the same.
18:11:27 <nirik> ah. bummer.
18:11:50 <puiterwijk> Yeah, I think we need to figure out how we deal with those cases..
18:11:55 <nirik> well, I am sure we can work something out in those cases, but not going to be easy
18:12:19 <puiterwijk> I have been considering sugesting a per-project option in Pagure to not share the namespace
18:12:29 <puiterwijk> Which means that you can have ticket #1 and PR #1 and they'd be different
18:12:31 <nirik> that would work I guess.
18:12:56 <nirik> or renumber the tickets you import to a new range?
18:13:10 <nirik> but thats confusing if you knew it by old name
18:13:18 <puiterwijk> Well, the problem is that we have commits with "Fixes: #54"
18:13:28 <puiterwijk> and you can't change commit message without a force push and all
18:14:12 <nirik> yeah
18:14:38 <smooge> well I expect the simplest is to just sya "ooops we screwed up. we are calling ourselves ipsilon2 and all tickets are new"
18:14:42 <nirik> so indeed moving the pr numbers would be better if they aren't used
18:15:15 <puiterwijk> nirik: except we also have some "Merges: #X" because that was the only way to mark a PR closed as merged
18:15:34 <nirik> ah well, no good answer I fear.
18:15:45 <puiterwijk> so moving PR numbers and ticket numbers is both going to cause a lot of pain. I think splitting of namespace is the only option in these cases
18:16:15 <nirik> but even that isn't ideal. ;)
18:16:32 <puiterwijk> Although personally, I would be much more favorable with moving PR numbers around, since those are "less critical" and only mentioned to close them
18:16:41 <puiterwijk> (well, over moving ticket numbers that is)
18:16:56 <nirik> right.
18:16:59 <puiterwijk> I just think that this needs a per-project discussion.
18:17:11 <puiterwijk> So any project that's already i nboth will need to be a special case.
18:17:13 <nirik> anyhow, we can discuss this more out of meeting and once pingou is back
18:17:16 <puiterwijk> Yep
18:18:11 <nirik> as far as I know the importer needs to handle tags better (it did odd things with them when I tested), make sure no notifications are sent (it sent some on issue create) and handle attachments...
18:18:31 <nirik> and this split case (or perhaps thats something that has to be manual)
18:18:44 <puiterwijk> Right. And the last thing  (attachments) needs attachments implemented for Pagure
18:19:03 <nirik> ah. didn't know they were not yet. yeah.
18:19:17 <nirik> also, FYI:
18:19:29 <nirik> #info article on pagure.io in this weeks lwn.net weekly
18:19:44 <smooge> yeah. that was an interesting read
18:20:17 <nirik> #info updated the new fedorahosted ticket template to ask people to look at pagure.io before filing their request
18:20:30 <nirik> ok, anything else on this? or shall we move on?
18:21:05 <puiterwijk> A lot more, but for next time :)
18:21:05 <nirik> #topic Start developing against OIDC with iddev - patrick
18:21:15 <nirik> puiterwijk: take it away.
18:21:25 <puiterwijk> Okay, so. As I mentioned in the info blob before, Ipsilon now has OpenID Connect / OAuth2 support.
18:21:56 <puiterwijk> If any application developers want to start developing against this, we have a dev instance on iddev.fedorainfracloud.org, this supports dynamic discovery and registration, so should work entirely without my help
18:22:05 <puiterwijk> But feel free to ask me for any help to get started
18:22:06 <nirik> and to be clear, this is our idea of sane things implemented from OAuth2 right?
18:22:22 <puiterwijk> nirik: what do you mean?
18:22:59 <nirik> I thought the OAuth2 spec was vuage and had a bunch of things that we probibly didn't want... perhaps I am misremembering...
18:23:15 <puiterwijk> Oh, right. Most of that got filled in by OpenID Connect
18:23:44 <nirik> oh good.
18:23:46 <puiterwijk> So, yes, this is a sane implementation, that's fully standards compliant.
18:23:47 * nirik hasn't been following
18:23:58 <puiterwijk> (even more compliant than Google's...)
18:24:01 <nirik> so the plan is to move everything to using this someday right?
18:24:21 <puiterwijk> Yes. This would give us easy API tokens for CLI tools and single login/logout standardized
18:24:26 <nirik> and does this get us tokens?
18:24:29 <puiterwijk> Yep
18:24:29 <nirik> ha.
18:24:49 <nirik> cool. It might be nice to make a wiki page or something with status for all our apps...
18:24:56 <nirik> so people know what needs to be done, etc
18:24:57 <puiterwijk> For anyone that wants to start porting: for flask, I have taken over Flask-OIDC, expect a new release from that within this week, and then a flask_fas_oidc module in python-fedora
18:25:14 <puiterwijk> Yep, sounds good. I'll get on that after the meeting
18:25:19 <nirik> ie, patches done, accepted, release with support, etc.
18:25:42 <nirik> you said I think you had some oauth2 patches for koji? would that get us off the certs there?
18:25:45 <puiterwijk> The ipsilon version with this is probably going to be release within 2 weeks, so I hope to have this in at least stg before freeze
18:26:00 <puiterwijk> nirik: yes. That would allow us to get rid of certs
18:26:16 <nirik> hurray.
18:26:22 <puiterwijk> I will need to make a few small adjustments to my patches, but can send those upstream very soon.
18:26:43 <puiterwijk> I am also implementing the client side for -hubs, so people can use that as a point of reference.
18:27:08 <puiterwijk> (since -hubs is going to heavily use API tokens and such, and it's still i ndevelopment, we figured it'd be best to do that first, and right now)
18:27:37 <puiterwijk> For other applications, I'm going to say maintainers can do that themselves, but they can always ask me for help or info
18:27:44 <nirik> perhaps after a while it would be cool to do a class type thing like you did for old openid to go over how it works, etc.
18:28:07 <puiterwijk> Definitely. I was considering submitting that for today but then I saw you already had another one for that :)
18:28:25 <nirik> well, you can take today if you like. :)
18:28:32 <puiterwijk> But this will likely be a bigger series, since these specifications are huge. (which is also why I'd suggest people just ask me for questions rather than reread the specs themselves)
18:28:47 <nirik> yeah, they get more complex as time goes on
18:29:02 <puiterwijk> Yeah, and the original core specs are already complex enough...
18:29:19 <nirik> ok, anything else on this for now?
18:29:21 <puiterwijk> nirik: as for today: let's see how much time we have left after apprentice hour?
18:29:24 <nirik> sure
18:29:38 <puiterwijk> Nope. Just wanted to offer help so people know they can start and contact me
18:29:48 <nirik> Oh, I had one more discussion item I forgot to add...
18:29:56 <nirik> #topic Mass update/reboot cycle next week
18:30:07 <nirik> So next week is the last week before we go into final freeze...
18:30:22 <nirik> so I'd like to do a mass update/reboot cycle... probibly tuesday/wed again.
18:30:29 <puiterwijk> +1. Cloud tuesday, build wednesday, rest thursday again?
18:30:36 <nirik> Anyone have any issues with that or want a different schedule?
18:30:36 <puiterwijk> oh, or mon-tue-wed
18:30:53 <nirik> mon-tue-wed might be better
18:31:01 <puiterwijk> Sure, sounds fine to me
18:31:08 <nirik> I was thinking perhaps of doing things a bit differently this time....
18:31:17 <puiterwijk> Oh?
18:31:22 <nirik> on monday: update everything. reboot staging hosts.
18:31:38 <nirik> on tuesday: update everything again. reboot build hosts in outage window
18:31:51 <nirik> on wed: update everything again. reboot non build in outage window
18:32:10 <nirik> ie, just mass update everything instead of doing it slowly virthost by virthost
18:32:22 <nirik> I think it might save us a lot of time to have the updates already in place
18:32:25 <puiterwijk> Right. That means we can just run ansible yum update all
18:32:31 <nirik> yeah
18:32:34 <nirik> well, or dnf
18:32:38 <puiterwijk> Yeah, agreed. But it is dangerous for some things..
18:32:51 <puiterwijk> like the gluster packages have a %post with "service glusterd restart"
18:33:11 <nirik> they do, but that normally doesn't cause much issue.
18:33:14 <puiterwijk> (same for some openstack parts if I recall correctly)
18:33:18 <nirik> it just restarts.
18:33:27 <nirik> yeah, openstack may be seperate from this
18:33:42 <puiterwijk> Yeah, openstack should be separate. I need a couple of hours for just that every time
18:33:46 <nirik> something always breaks there
18:33:51 <puiterwijk> Hah. No kidding there
18:34:07 <nirik> what was the status on the upgrade there? were you going to try and get it before freeze?
18:34:17 <puiterwijk> I am trying to do that, yes
18:34:42 <nirik> update/reboot for it can hold to whenever you want to schedule that.
18:34:42 <puiterwijk> And with my current speed, I might be able to. At least having it up by that time should be fine, not sure if we can move everything before freeze
18:35:19 <nirik> oh right you were going to startup a new one and migrate
18:35:36 <puiterwijk> Yes, because the current setup is... interestingly setup with regards to base.
18:35:42 <nirik> anyhow, we can also do this cycle like we have... or I could apply updates like an hour before outage
18:35:59 <puiterwijk> nirik: well, I'm in favor of the new system.
18:36:00 <nirik> but I will send out outage announcements tomorrow most likely.
18:36:04 <puiterwijk> Just wanted to point it out
18:36:14 <nirik> sure. If things break we can address them/fix them...
18:36:16 <puiterwijk> ("it" being that a few services might possibly do things on yum update)
18:36:26 * nirik nods
18:36:33 <puiterwijk> Yep, then I'm +1 to the mass update and reboots within window
18:36:39 <puiterwijk> Should make the outages a lot shorter hopefully
18:36:51 <nirik> yeah, that was my hope. Save us from sitting around waiting for updates.
18:37:07 <nirik> ok... moving on...
18:37:11 <nirik> #topic Apprentice office hours
18:37:27 <nirik> Any apprentices looking for things to do? or have questions ?
18:38:37 <nirik> seems not? :)
18:38:47 <nirik> I failed to do any screencasts last week...
18:39:01 <nirik> I was going to, but then my weekend was... not very computery
18:39:15 <nirik> will try again this coming weekend. ;)
18:39:39 <nirik> puiterwijk: you want to talk about openid-connect today? I was just going to go over mailman3 from a high level, can do that anytime...
18:40:12 <puiterwijk> Sure.
18:40:20 <puiterwijk> I can give a quick overview of the core
18:40:56 <puiterwijk> Or a highlevel overview might be best to see where things fall together
18:41:46 <nirik> sure.
18:41:48 <nirik> take it away
18:41:52 <puiterwijk> #topic Learn about: OpenID Connect - highlevel overview
18:42:17 <puiterwijk> So, for those not knowing what it all is: OpenID Connect is an entirely new authentication protocol, built on top of OAuth 2.0
18:42:40 <puiterwijk> It sounds like OpenID, which we have been using at Fedora before, but it is not. It is completely, entirely different.
18:43:13 <nirik> nice of them to reuse the name. ;) (But I guess it had some recognition)
18:43:16 <puiterwijk> So, the core for OpenID Connect is the OAuth2 specifications, aand then they filled in a lot of the things that that specification left undefined.
18:43:23 <puiterwijk> nirik: well, that's because it's still from the OpenID Foundation :)
18:43:50 <puiterwijk> To which I'm a member, and Red Hat is a contributor with me as representative, which means that I have a hand in the specifications.
18:44:11 <nirik> great!
18:44:44 <puiterwijk> One of the major differences between OpenID Connect and OpenID 2.0 is that OpenIDC requires client registration, which also establishes a secret between server and client
18:44:57 <puiterwijk> Or the correct terms would rather be the Identity Provider and the Relying Party.
18:45:27 <puiterwijk> the Identity Provider is Ipsilon: that generates claims and sends them back to the website that wants a user to authenticate, which relies on its information, which is why it's called a Relying Party
18:45:27 <smooge> puiterwijk, is that like the kerberos keytab?
18:45:44 <puiterwijk> smooge: you can see it as something like that, yes.
18:46:00 <puiterwijk> It establishes an way the client can authenticate to the server
18:46:40 <puiterwijk> One difficult thing here is that there are a LOT of difficult terms, and things that sound alike but aren't
18:47:35 <puiterwijk> So one thing to take care of is that when you "do OpenID Connect", there's no just one flow. There are three different flows that follow the same basics, but the results differ significantly, and also what you can do with the results
18:47:59 <smooge> oooh twisty turney passages all alike
18:48:05 <puiterwijk> So, there is a flow where the application can ask for login, and it gets information from the user back, and that's all.
18:48:30 <puiterwijk> But it can also request an access token at the same time with a set of scopes. That token would then be able to be used as API token for external applications once those start to accept them
18:49:09 <puiterwijk> And the third possible response is an Authorization Code. That means that the response doesn't contain an access token, but instead an authorization code that the application can exchange for an access token.
18:49:32 <puiterwijk> The choice between these three flows heavily depends on what the application intends to do.
18:49:46 <nirik> how does this all fit into 2fa? Is there a possibility to still require a second factor from the user if desired?
18:50:12 <puiterwijk> Yep. The application can specify an Authentication Class Reference that needs to be fulfilled, and 2fa would be one
18:50:23 <nirik> excellent
18:50:33 <puiterwijk> The application can also specify that it wants the user to have been authenticated at most X seconds ago
18:51:13 <puiterwijk> So for lower security applications, we can say there's no such expiration, but for higher security things we can say the user needs to reauth if their last login was more than 5 minutes ago (for example)
18:52:48 <puiterwijk> So, getting back to the different flows: as said, this depends on the application's requirements. A very short summary is that you pretty much always want to use an authorization code because of the security and privacy this brings, but that's impossible for CLI applications (because those can't store a client secret)
18:53:29 <nirik> I assume the application might also be able to get additional info ? ie, groups or email address or whatever if we want it to?
18:53:34 <misc> unless it has been specifically done to store one, ie, you mean "regular application" ?
18:53:41 <puiterwijk> nirik: yes
18:54:18 <puiterwijk> misc: well, the specifications say that the client secret needs to not be available to any user. And I can't see a way where a local CLI application can store a client secret in such a way that the user can't get to it :)
18:54:34 <puiterwijk> "any user" being "the user of the application", aka, not admin
18:54:34 <misc> puiterwijk: ok so I misunderstood
18:55:00 <misc> (in fact, i could see stuff using a tpm, but I disgress)
18:55:09 <puiterwijk> nirik: that extra information can be provided in a multitude of ways. The OpenID foundation loves choices....
18:55:42 <smooge> twitter tweets
18:55:45 <nirik> why only have one way to do something when you can have 10 confusing ones. ;)
18:55:53 <puiterwijk> The good part is that I'm currently writing a wrapper around some libraries to make it quite easy for Fedora people to use our implementation
18:56:11 <puiterwijk> nirik: don't talk to me about it... the OAuth2 spec has more "This is outside of the scope of this specification" than sentences....
18:56:19 <puiterwijk> s/sentences/sections
18:56:34 <misc> nirik: but Linu^W openid is about choice :p
18:56:48 <puiterwijk> So if anyone starts to panic, don't. If you want to get started, just get in touch with me.
18:56:50 <nirik> indeed.
18:57:21 <puiterwijk> I can give more explanations of specific parts of the specifications next times, since as said they're quite complicated
18:58:02 <puiterwijk> I expect to have our flask client done by this week, and the generic and CLI client somewhere next week. Documentation will be part of that.
18:59:13 <puiterwijk> I'm sorry if this explanation was very jumpy between subjects, there's just a lot to cover and I didn't have much time to prepare it.. :). So if there are any questions, just ask me here or in any of the channels
18:59:26 <nirik> sounds good.
19:00:18 <nirik> anything else, or shall we hit open floor real quick?
19:00:33 <puiterwijk> For now I'm out of time, otherwise I would have a lot more :)
19:00:47 <nirik> #topic Open Floor
19:00:56 <nirik> anything for open floor before we close out.
19:01:00 <nirik> thanks for the info puiterwijk!
19:02:02 <nirik> ok, thanks for coming everyone!
19:02:05 <nirik> #endmeeting