19:03:29 #startmeeting infra 19:03:30 Meeting started Tue May 24 19:03:29 2016 UTC and is due to finish in 60 minutes. The chair is fungi. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:03:31 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:03:32 I like the letter 3 19:03:33 The meeting name has been set to 'infra' 19:03:34 o/ 19:03:39 even better than the number 3 19:03:39 #link https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting 19:03:47 #topic Announcements 19:03:54 #info REMINDER: Gerrit downtime on Friday 2016-06-03 at 20:00 UTC 19:04:00 #link http://lists.openstack.org/pipermail/openstack-infra/2016-May/004322.html 19:04:22 fungi: o/ 19:04:25 we still need a change for the openstack-infra/ansible-puppet -> openstack-infra/ansible-role-puppet rename 19:04:26 also worth noting, we're in an ad hoc sprint upgrading a bunch of our servers from ubuntu 12.04 to 14.04 this week 19:04:45 not sure who is responsible for that 19:04:47 #link https://wiki.openstack.org/wiki/VirtualSprints#Infra_Trusty_Upgrade 19:05:06 pleia2: mordred added that one to the list, but he may have hoped one of us would fill in the blanks 19:05:12 * pleia2 nods 19:05:21 we can punt on it if there's no change come maintenance time 19:05:32 #topic Actions from last meeting 19:05:38 fungi: yes! 19:05:41 #link http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-05-17-19.01.html 19:05:49 jeblair investigate mail filtering by recipient options for infra-root@o.o inbox 19:05:56 what's the option? 19:06:02 turns out the web thingy has decent mail filtering 19:06:14 oh, as we hoped but dared not expect 19:06:22 so we can filter by recipient address 19:06:23 * anteaya loves when jeblair uses the technical terms 19:06:44 that's helpful 19:06:45 that makes imap a bit easier 19:06:55 and filter messages into folders 19:07:10 so we can continue to use a single storage account, which will make the foundation happy that they don't have to pay for more than one 19:07:14 so we should probably plan to filter recipients for cloud provider accounts into a specific inbox we can all subscribe to 19:07:25 wfm 19:07:29 and we can just check various folders 19:07:37 sounds great 19:07:45 we can continue to add aliases if we want, or of course, start filtering by from address or other things 19:08:07 any volunteers for implementing the filtering? 19:08:21 and letting us know which inbox(es) is/are high priority? 19:08:40 if it can wait until next week, it's probably a good sister's couch task for me to take while I'm east coasting 19:08:45 the filtering is easily created/modified through the usual webmail interface (so no admin perms needed) (adding aliases requires an admin, of which there are few) 19:08:58 pleia2: i think there's not a huge rush on it 19:09:10 ++ 19:09:25 ok, I'll start taking care of it next wednesday 19:09:28 #action pleia2 set up filtering to direct provider account contact address(es) into a high priority inbox 19:09:35 thanks jeblair, pleia2! 19:09:54 #topic Specs approval 19:10:02 none new this week 19:10:17 ttx had another update to the task tracker spec 19:10:36 some good reading there 19:11:11 #link https://review.openstack.org/314185 19:11:34 also docaedo added one for running a less-technical-user-friendly irc front-end 19:11:41 #link https://review.openstack.org/319506 19:11:49 I did! 19:11:54 docaedo++ 19:11:56 cool 19:12:00 and nibalizer wrote the one about server boot automation he promised at the summit 19:12:09 #link https://review.openstack.org/310948 19:12:16 yay promises kept 19:13:09 #topic Priority Efforts 19:13:17 no updates this week, but i plan to start a thread on the ml to discuss updates to the current priority efforts list 19:13:37 #action fungi start an ml thread revisiting current priority efforts list 19:13:45 #topic Jenkins Job Builder v2 API (waynr) 19:13:50 #link https://specs.openstack.org/openstack-infra/infra-specs/specs/jenkins-job-builder_2.0.0-api-changes.html 19:14:28 oh, he's not in channel 19:15:07 i'll parrot him from the agenda until he shows up... 19:15:31 Jenkins Job Builder v2 API has been rebased on to JJB master branch and is ready for review 19:15:32 thanks pleia2 fungi for the reminder 19:15:47 oh, hey! you can take over introducing your topic now ;) 19:15:53 and apologies for the tardiness...i am so scatterbrained today :) 19:16:41 okay, so basically I understand that JJB and the v2 API efforts in particular are not a high priority for openstack-infra 19:17:40 facilitating your work is still a high priority for me, so let me know what sorts of things you need (branch deletions, tags pushed) and i'm happy to do it 19:17:57 but wanted to bring it up here anyway to make sure I am doing everything I can to make it high visibility since it can be difficult for me also to sustain attention on a project like this for long periods of time (it's also not a huge priority for my team at work, it's mostly my pet/side project) 19:18:14 yeah, the "feature/2.0.0" branch is no longer necessary I think 19:18:48 i'm probably misunderstanding what went on in that feature branch, if you haven't merged it back to master yet 19:19:09 I think we came to the conclusion about a month ago that it would be too difficult to maintain two active branches of development so the 2.x series is what we want to move forward with as the main line of development 19:19:43 so do you have changes which landed on that branch that you need merged into master before you continue work in the master branch toward the 2.0 release? 19:20:01 nope, nothing was ever merged into the feature/2.0.0 branch 19:20:14 I rebased everything that was targeting it onto master branch over the weekend 19:20:17 oh, got it. so you just have changes proposed against master that haven't landed 19:20:24 yeah, exactly 19:21:31 so yeah, deleting that feature branch is the next step (I can update the 2.0.0 api spec if necessary to avoid possible confusion about what branch these changes are targeting) 19:21:41 #info Deleted openstack-infra/jenkins-job-builder feature/2.0.x branch which was previously at 245f643522da0236254bb14f055df5cbb571938f 19:22:32 again, another reason for me to bring up the 2.0.0 API work here is just to increase visibility (maybe someone who sees this discussion will be interested enough to help review :) 19:22:53 from an openstack infra/ci perspective, as long as those changes aren't modifying the xml output by jjb i think we don't have much of a stake in the order in which you merge things. i'd leave that determination to the jjb core reviewers (zaro, electrofelix, zxiiro) 19:23:32 i might throw this up onto the open discussion section of the meeting periodically if y'all think this is a good way to achieve that visibility goal (otherwise, I am open to alternatives) 19:23:44 the answer might just be for me to keep pestering the other jjb cores 19:23:50 if the xml comparison ci job indicates a difference, please give me or one of our other admins some heads up and an opportunity to review the results 19:24:00 oh sure 19:24:06 I'm pretty sure that won't happen though 19:24:20 we'll probably pin jjb<2.0 for the zuul2.5 ansible launcher, since it uses internal api stuff 19:24:44 since our needs there are fairly static, that way we don't impact ability for jjb2 to proceed 19:24:44 yep, as a result i'm mostly happy to give the jjb team autonomy over what's going on there 19:25:32 (and we can look at unpinning later when it settles) 19:25:36 jeblair: I'd be interested in seeing what parts of the API zuul2.5 is using 19:25:54 I wonder if it is just jenkins_jobs.cmd.execute(args) 19:26:15 waynr: i'll point them out to you in channel after meeting; i did have to do a couple things i didn't like, maybe could positively influence jjb2 19:26:15 (which is what my JJB 1.x wrapper project does) 19:26:25 i think it's more for getting at the internal data structures representing job config data? 19:26:50 oh... in that case I think you'll like some of the API changes I am making! 19:26:51 but yeah, no need to dive into that under this meeting topic 19:27:28 anything else for this? zaro/zxiiro, did you have any input for waynr? 19:27:51 i'm fine with strategy proposed 19:28:22 sounds reasonable to me 19:28:26 so the final thing was just protocol as far as merging changes in a large series such as this...is it fine to merge earlier commits once they are approved even if there is remaining 2.0.0 api work left to do? 19:29:01 zaro zxiiro the reason I ask this is that if for example someone wanted to get a high priority feature released they wouldn't be able to get it until the first 2.0 release 19:29:17 (once we've begun merging changes from the jjb-2.0.0-api topic, that is) 19:29:37 i'll defer to zaro and zxiiro on that as well. the usual concerns are that if you disappear without finishing it then there could be a half-implemented transition worth of technical debt to support or try and unwind again 19:30:27 yeah, i'm not sure there's a beter alternative though. 19:31:14 right, every patch series has this inherent risk to varying degrees anyway 19:31:48 so it's more a question of comfort level of the reviewers 19:32:36 okay, sounds like a bit of agreement around this. thanks waynr, zaro, zxiiro! 19:32:43 cool 19:32:52 waynr: you should probably get feedback from electrofelix though 19:32:56 thanks again fungi, anteaya for reminding me about the meeting! 19:33:12 waynr: and pleia2 19:33:13 zaro: I'll make sure to ping him with a link to this meeting 19:33:16 cool. I think electrofelix mentioned we can get high priority patches in a stable release branch too once we start merging 2.x stuff 19:33:18 and pleia2 19:33:34 anteaya: thanks for the correction! 19:33:38 :) 19:33:40 #topic OpenID implementation (notmorgan, puiterwijk) 19:33:44 o/ 19:33:47 I'm here still :) 19:33:58 so. simply put this came up in an internal Red Hat meeting. 19:34:11 looking for a general idea for the timeline of moving openstackid to ipsilon 19:34:19 (desired timeline) 19:34:43 and identifying what was needed, if anything, on the ipsilon side before we could do it. 19:34:57 smarcet is away for the next 2 weeks i believe 19:34:58 aiui ipsilon now supports OIDC as well. 19:35:24 notmorgan: correct. We merged that patch last week, and have submitted certification results (all pass) 19:35:42 i'm not sure we ever got complete consensus that we would necessarily replace openstackid with ipsilon, though we mighth start using ipsilon for things other than the www.openstack.org site if the foundation developers aren't keen on moving their site off openstackid 19:35:43 So in the next release, which should be end this week, it will be included 19:35:53 fungi: ++ 19:35:59 as the driver for the current openstackid, i think it would be good to involve smarcet in discussions 19:36:05 jeblair: ++ 19:36:18 but perhaps we can continue to lay foundations while he's away 19:36:29 fungi: or however we want to do it. 19:36:58 so while it would be preferable to make sure ipsilon can be used to achieve the same things the www site needs from openstackid, i wouldn't want to completely predicate our implementation on them agreeing to stop using openstackid there 19:37:06 the only concern i have if we don't replace openstackid.org is we may need a new domain for cookie isolation etc 19:37:14 not a huge hurdle 19:38:10 we have idp.openstackid.org as jeblair's early poc. seems like an okay one to keep using (unless the worry is that a compromise on the current openstackid.org server could be leveraged to steal authentication secrets from ipsilon sessions) 19:38:20 i do want to point out that merging ids later (from a standpoint of registeted IDP) is more of a headache than not. 19:38:47 fungi: that is a concern, but i think we're in a boat where that level of compromise is going to get ugly no matter what 19:38:54 idp.openstackid.org is sufficient imo 19:39:13 puiterwijk: feel free to disagree with me if you think otherwise :) 19:39:28 it would be nice to see zanata move over to ipsilon, they're using them together upstream (in fedora) so that would give us a tested, known pairing there 19:39:54 notmorgan: that sounds about right to me. Moving is a concern, and the cookies shouldn't be too much worse I'd say 19:40:10 did we figure out whether we're able to (or even want to) use the same url pattern as openstackid uses for identifiers? 19:40:23 fungi: not sure about that. 19:40:35 fungi: as long as you setup the httpd redirects, Ipsilon can handle pretty much any url scheme you want 19:40:41 What are you using now? 19:40:50 for example it gives https://openstackid.org/jeremy.stanley for my openid right now 19:40:50 fungi: i configured it to use the openstackid scheme for identifiers 19:41:12 i don't know that we agreed that was *desirable* but i believe it's *possible* :) 19:41:17 i do want to say that if we lean on idp.openstackid.org for non-o.o sites, i would advocate moving o.o over to idp.oid.o if we decide to use ipsilon (we can use some httpd things for redirects...but in general) 19:41:31 i worry that tying the id to a human hane is problematic because humans change their names on occasion (i've brought that up with the openstackid devs more than once) 19:41:35 rather than try and merge everything down to the bare-word domain 19:41:59 i would vote for "username" not "human name" 19:42:01 s/hane/name/ 19:42:03 as well. 19:42:04 fungi: right. That's why in Fedora we decided to use username as the non-changing ID which is used as identity. 19:42:18 it's why almost every IDP does that. 19:42:32 We use http://puiterwijk.id.fedoraproject.org/ (unfortunately, we started out without https, and switching later is a massive pain) 19:42:47 i initially did that so that we could minimize the complexity of changing things that use openstackid to using ipsilon, as well as eventually moving ipsilon from idp.o.o to o.o 19:42:49 i like that. we have some systems which consider username unchangeable once set (e.g., gerrit) so tying them together feels natural 19:42:59 fungi: ++ 19:43:13 and i'd be more willing to argue/helpfolks make that change once. 19:43:14 For a better example: https://puiterwijk.id.gnome.org/ :) 19:43:20 however, we can still accomplish those things with more complexity (like, using a script and a database dump to make the mappings) 19:43:24 over trying to deal with usernames. 19:43:28 erm humannames 19:43:48 so it sounds like come back in a couple weeks and work on the db backend driver bits. 19:43:57 ? 19:44:10 and start working on details like username vs humanname 19:44:17 Is anything wrong with the db backend driver? (sqlalchemy) 19:44:32 Oh, or did you mean auth db backend? 19:44:32 puiterwijk: as long as it's configurable, no issues 19:44:37 i think jeblair already wrote a fairly basic backend db driver to grok the silverstripe user db used by the www site (same db that openstackid.org is looking at) 19:44:42 puiterwijk: auth db where the user data is. 19:44:46 silverstr... what fungi said 19:44:48 fungi: yes i did, that's written 19:44:51 notmorgan: ah, I see :) 19:44:53 ok cool. 19:45:07 puiterwijk: as long as sql-a can be told to use non-sqlite dbs, we're good (for sessions etc) 19:45:34 notmorgan: yep. I would actually not suggest sqlite for production. We fully support anything that's supported by sqlalchemy 19:45:34 it may need some extending to handle the authorization/group details there (from an oidc/oauth perspective) 19:46:03 i ran into some minor speedbumps setting up ipsilon; i think a good thing to work on now might be standing up a server with just the test backend (don't worry about silverstripe yet) and shake out the installation/config bits 19:46:08 (in our environment) 19:46:28 i have some very basic puppet standing by as well 19:46:51 sounds like there was also some work done recently to make sure it's more solid on debian-based distros, and there was talk of finding someone willing to make official debian packages for it? 19:46:53 so perhaps i should get that into a new puppet module, and then stand up a server 19:47:03 jeblair: for puppet, you might want to use ipsilon-db2conf. That will generate you a configuration file if you prefer to use that over web administration 19:47:15 puiterwijk: oh cool 19:47:28 fungi: yeah, I've been testing various parts on Debian, and am now adding test skipping to the test suite so I can actually run the suite on Debian 19:47:45 (there's a few modules that will unfortunately not work on Debian anytime soon like SSSD, but the rest should work just fine) 19:47:57 not super worried about SSSD not working 19:48:00 tbh 19:48:00 And yeah, if anyone's interested in helping packaging for Debian, feel free to get in touch. 19:48:19 notmorgan: yeah, didn't think so. But that's one of the reasons you can't run the test suite right now, because there's no easy way to skip those tests on Debian :) 19:48:25 also, if there's interest, we may have people willing to help get sdist/wheel working so you can publsh releases to pypi too 19:48:50 fungi: sounds good. If there's anyone interested in doing that, feel free to bring them in touch with me 19:49:14 notmorgan: after I get the test skipping et al in, I plan to add Debian to the list of OS's that need to pass for every patchset to be merged. 19:49:26 puiterwijk: also you may want to create an account on pypi.python.org and register https://pypi.python.org/pypi/ipsilon so that it doesn't get snapped up by a squatter or something 19:49:41 I have an account, and that's a good idea 19:50:23 * notmorgan steals it fast :P 19:50:31 def go register it. 19:50:57 Just did. 19:51:09 Thanks for the hint 19:51:11 okay, anything else we want to cover for now, that doesn't need to wait for smarcet to be back around? 19:52:42 thanks notmorgan and puiterwijk! 19:52:47 #topic Open discussion 19:53:07 * notmorgan goes back to lurker mode for a few minutes. 19:53:22 anybody do anything fun for victoria day/patriots day, or planning something interesting for memorial day? 19:53:25 fyi, I'm taking a long memorial day weekend, so I'll be away this Thursday - Tuesday, then working east coast time Wed-Friday 19:53:47 i've been informed i won't be around monday, so that i can get some projects done on the house 19:53:47 I went for a nice walk yesterday 19:53:50 visiting family and moose and eating lobster rolls in Maine :) 19:53:52 was beautiful 19:54:01 pleia2: nice 19:54:02 fungi: i think i will be joining you, in spirit at least. 19:54:09 fungi: lucky you 19:54:14 promethanfire raised some issues with our project-config dib elements which resulted in https://etherpad.openstack.org/p/gentoo-ci 19:54:47 https://review.openstack.org/#/c/319030/ https://review.openstack.org/#/c/318994/ 19:54:48 so there is some work to do, but i think we can overhaul things to fix up the dependencies there 19:54:57 those are the two reviews that came from that etherpad so far 19:55:11 pleia2: I understand moose rolls are quite tasty 19:55:16 bswartz: also pointed out that the ubuntu-core trusty base images dib's ubuntu element (but not the ubuntu-minimal element we use for nodepool) are no longer being provided by canonical 19:55:23 s/:// 19:55:46 anteaya: oh dear, we'll be visiting one (some?) at an animal care facility, no eating :) 19:55:58 (this is like the kangaroos all over again!) 19:56:00 so i guess anybody using that dib element is in a bad way now 19:56:01 the ansible environment variable situation is "whack". i'm nearing the bottom of that; when i get there, i think we'll be ready for zuulv2.5 19:56:11 pleia2: ah visiting the moose, eating lobster rolls, now I get it 19:56:21 anteaya: yes, eat the sea bugs, visit the fluffy animals 19:56:22 fungi: no, the dep tree is really just a collector 19:56:30 not a true graph 19:56:36 pleia2: enjoy the fluffy animals :) 19:56:38 fungi: yeah, i've wondered if we really have the bandwidth to support the !minimal paths 19:56:44 so it's fine, just slightly counterintuitive 19:56:44 jeblair: excellent 19:57:00 jeblair: all these technical terms today 19:57:04 I can't keep up 19:57:13 jeblair: I'll try and finish off the zuul-worker DIB element this week. Need to do a few updates to some puppet bits 19:57:54 fungi: most likely route to force online reindex is with admin-console plugin. 19:57:54 fungi: yeah, deps run in different phases ... but it would sure be nice for testing if caching the repos was a separate thing. currently it gets pulled in before we run puppet 19:58:00 pabelanger: cool; it's not a blocker but will be nice to have when we're ready for the jenkinsectomy 19:58:33 zaro: that sounds like a good way forward to me then. thanks for researching 19:59:16 okay, anything else? we're at 45 seconds remaining 19:59:20 (last call!) 19:59:29 thanks for chairing, fungi 19:59:34 have a nice weekend 19:59:36 you're welcome! 19:59:58 ...and we're out of time--thanks everyone! 20:00:01 #endmeeting