19:03:29 <fungi> #startmeeting infra
19:03:30 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:03:32 <anteaya> I like the letter 3
19:03:33 <openstack> The meeting name has been set to 'infra'
19:03:34 <zaro> o/
19:03:39 <anteaya> even better than the number 3
19:03:39 <fungi> #link https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting
19:03:47 <fungi> #topic Announcements
19:03:54 <fungi> #info REMINDER: Gerrit downtime on Friday 2016-06-03 at 20:00 UTC
19:04:00 <fungi> #link http://lists.openstack.org/pipermail/openstack-infra/2016-May/004322.html
19:04:22 <jeblair> fungi: o/
19:04:25 <pleia2> we still need a change for the openstack-infra/ansible-puppet -> openstack-infra/ansible-role-puppet rename
19:04:26 <fungi> 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 <pleia2> not sure who is responsible for that
19:04:47 <fungi> #link https://wiki.openstack.org/wiki/VirtualSprints#Infra_Trusty_Upgrade
19:05:06 <fungi> 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 <fungi> we can punt on it if there's no change come maintenance time
19:05:32 <fungi> #topic Actions from last meeting
19:05:38 <jeblair> fungi: yes!
19:05:41 <fungi> #link http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-05-17-19.01.html
19:05:49 <fungi> jeblair investigate mail filtering by recipient options for infra-root@o.o inbox
19:05:56 <fungi> what's the option?
19:06:02 <jeblair> turns out the web thingy has decent mail filtering
19:06:14 <fungi> oh, as we hoped but dared not expect
19:06:22 <jeblair> so we can filter by recipient address
19:06:23 * anteaya loves when jeblair uses the technical terms
19:06:44 <pleia2> that's helpful
19:06:45 <fungi> that makes imap a bit easier
19:06:55 <jeblair> and filter messages into folders
19:07:10 <jeblair> 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 <fungi> so we should probably plan to filter recipients for cloud provider accounts into a specific inbox we can all subscribe to
19:07:25 <pleia2> wfm
19:07:29 <jeblair> and we can just check various folders
19:07:37 <fungi> sounds great
19:07:45 <jeblair> we can continue to add aliases if we want, or of course, start filtering by from address or other things
19:08:07 <fungi> any volunteers for implementing the filtering?
19:08:21 <fungi> and letting us know which inbox(es) is/are high priority?
19:08:40 <pleia2> 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 <jeblair> 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 <fungi> pleia2: i think there's not a huge rush on it
19:09:10 <jeblair> ++
19:09:25 <pleia2> ok, I'll start taking care of it next wednesday
19:09:28 <fungi> #action pleia2 set up filtering to direct provider account contact address(es) into a high priority inbox
19:09:35 <fungi> thanks jeblair, pleia2!
19:09:54 <fungi> #topic Specs approval
19:10:02 <fungi> none new this week
19:10:17 <fungi> ttx had another update to the task tracker spec
19:10:36 <anteaya> some good reading there
19:11:11 <fungi> #link https://review.openstack.org/314185
19:11:34 <fungi> also docaedo added one for running a less-technical-user-friendly irc front-end
19:11:41 <fungi> #link https://review.openstack.org/319506
19:11:49 <docaedo> I did!
19:11:54 <bkero> docaedo++
19:11:56 <pleia2> cool
19:12:00 <fungi> and nibalizer wrote the one about server boot automation he promised at the summit
19:12:09 <fungi> #link https://review.openstack.org/310948
19:12:16 <anteaya> yay promises kept
19:13:09 <fungi> #topic Priority Efforts
19:13:17 <fungi> 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 <fungi> #action fungi start an ml thread revisiting current priority efforts list
19:13:45 <fungi> #topic Jenkins Job Builder v2 API (waynr)
19:13:50 <fungi> #link https://specs.openstack.org/openstack-infra/infra-specs/specs/jenkins-job-builder_2.0.0-api-changes.html
19:14:28 <fungi> oh, he's not in channel
19:15:07 <fungi> i'll parrot him from the agenda until he shows up...
19:15:31 <fungi> <waynr> Jenkins Job Builder v2 API has been rebased on to JJB master branch and is ready for review
19:15:32 <waynr> thanks pleia2 fungi for the reminder
19:15:47 <fungi> oh, hey! you can take over introducing your topic now ;)
19:15:53 <waynr> and apologies for the tardiness...i am so scatterbrained today :)
19:16:41 <waynr> 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 <fungi> 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 <waynr> 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 <waynr> yeah, the "feature/2.0.0" branch is no longer necessary I think
19:18:48 <fungi> i'm probably misunderstanding what went on in that feature branch, if you haven't merged it back to master yet
19:19:09 <waynr> 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 <fungi> 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 <waynr> nope, nothing was ever merged into the feature/2.0.0 branch
19:20:14 <waynr> I rebased everything that was targeting it onto master branch over the weekend
19:20:17 <fungi> oh, got it. so you just have changes proposed against master that haven't landed
19:20:24 <waynr> yeah, exactly
19:21:31 <waynr> 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 <fungi> #info Deleted openstack-infra/jenkins-job-builder feature/2.0.x branch which was previously at 245f643522da0236254bb14f055df5cbb571938f
19:22:32 <waynr> 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 <fungi> 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 <waynr> 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 <waynr> the answer might just be for me to keep pestering the other jjb cores
19:23:50 <fungi> 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 <waynr> oh sure
19:24:06 <waynr> I'm pretty sure that won't happen though
19:24:20 <jeblair> we'll probably pin jjb<2.0 for the zuul2.5 ansible launcher, since it uses internal api stuff
19:24:44 <jeblair> since our needs there are fairly static, that way we don't impact ability for jjb2 to proceed
19:24:44 <fungi> yep, as a result i'm mostly happy to give the jjb team autonomy over what's going on there
19:25:32 <jeblair> (and we can look at unpinning later when it settles)
19:25:36 <waynr> jeblair: I'd be interested in seeing what parts of the API zuul2.5 is using
19:25:54 <waynr> I wonder if it is just jenkins_jobs.cmd.execute(args)
19:26:15 <jeblair> 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 <waynr> (which is what my JJB 1.x wrapper project does)
19:26:25 <fungi> i think it's more for getting at the internal data structures representing job config data?
19:26:50 <waynr> oh... in that case I think you'll like some of the API changes I am making!
19:26:51 <fungi> but yeah, no need to dive into that under this meeting topic
19:27:28 <fungi> anything else for this? zaro/zxiiro, did you have any input for waynr?
19:27:51 <zaro> i'm fine with strategy proposed
19:28:22 <zxiiro> sounds reasonable to me
19:28:26 <waynr> 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 <waynr> 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 <waynr> (once we've begun merging changes from the jjb-2.0.0-api topic, that is)
19:29:37 <fungi> 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 <zaro> yeah, i'm not sure there's a beter alternative though.
19:31:14 <fungi> right, every patch series has this inherent risk to varying degrees anyway
19:31:48 <fungi> so it's more a question of comfort level of the reviewers
19:32:36 <fungi> okay, sounds like a bit of agreement around this. thanks waynr, zaro, zxiiro!
19:32:43 <waynr> cool
19:32:52 <zaro> waynr: you should probably get feedback from electrofelix though
19:32:56 <waynr> thanks again fungi, anteaya for reminding me about the meeting!
19:33:12 <anteaya> waynr: and pleia2
19:33:13 <waynr> zaro: I'll make sure to ping him with a link to this meeting
19:33:16 <zxiiro> 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 <waynr> and pleia2
19:33:34 <waynr> anteaya: thanks for the correction!
19:33:38 <anteaya> :)
19:33:40 <fungi> #topic OpenID implementation (notmorgan, puiterwijk)
19:33:44 <notmorgan> o/
19:33:47 <puiterwijk> I'm here still :)
19:33:58 <notmorgan> so. simply put this came up in an internal Red Hat meeting.
19:34:11 <notmorgan> looking for a general idea for the timeline of moving openstackid to ipsilon
19:34:19 <notmorgan> (desired timeline)
19:34:43 <notmorgan> and identifying what was needed, if anything, on the ipsilon side before we could do it.
19:34:57 <jeblair> smarcet is away for the next 2 weeks i believe
19:34:58 <notmorgan> aiui ipsilon now supports OIDC as well.
19:35:24 <puiterwijk> notmorgan: correct. We merged that patch last week, and have submitted certification results (all pass)
19:35:42 <fungi> 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 <puiterwijk> So in the next release, which should be end this week, it will be included
19:35:53 <pleia2> fungi: ++
19:35:59 <jeblair> as the driver for the current openstackid, i think it would be good to involve smarcet in discussions
19:36:05 <notmorgan> jeblair: ++
19:36:18 <jeblair> but perhaps we can continue to lay foundations while he's away
19:36:29 <notmorgan> fungi: or however we want to do it.
19:36:58 <fungi> 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 <notmorgan> 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 <notmorgan> not a huge hurdle
19:38:10 <fungi> 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 <notmorgan> 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 <notmorgan> 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 <notmorgan> idp.openstackid.org is sufficient imo
19:39:13 <notmorgan> puiterwijk: feel free to disagree with me if you think otherwise :)
19:39:28 <pleia2> 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 <puiterwijk> 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 <fungi> 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 <notmorgan> fungi: not sure about that.
19:40:35 <puiterwijk> fungi: as long as you setup the httpd redirects, Ipsilon can handle pretty much any url scheme you want
19:40:41 <puiterwijk> What are you using now?
19:40:50 <fungi> for example it gives https://openstackid.org/jeremy.stanley for my openid right now
19:40:50 <jeblair> fungi: i configured it to use the openstackid scheme for identifiers
19:41:12 <jeblair> i don't know that we agreed that was *desirable* but i believe it's *possible* :)
19:41:17 <notmorgan> 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 <fungi> 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 <notmorgan> rather than try and merge everything down to the bare-word domain
19:41:59 <notmorgan> i would vote for "username" not "human name"
19:42:01 <fungi> s/hane/name/
19:42:03 <notmorgan> as well.
19:42:04 <puiterwijk> 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 <notmorgan> it's why almost every IDP does that.
19:42:32 <puiterwijk> We use http://puiterwijk.id.fedoraproject.org/ (unfortunately, we started out without https, and switching later is a massive pain)
19:42:47 <jeblair> 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 <fungi> 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 <notmorgan> fungi: ++
19:43:13 <notmorgan> and i'd be more willing to argue/helpfolks make that change once.
19:43:14 <puiterwijk> For a better example: https://puiterwijk.id.gnome.org/ :)
19:43:20 <jeblair> 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 <notmorgan> over trying to deal with usernames.
19:43:28 <notmorgan> erm humannames
19:43:48 <notmorgan> so it sounds like come back in a couple weeks and work on the db backend driver bits.
19:43:57 <notmorgan> ?
19:44:10 <notmorgan> and start working on details like username vs humanname
19:44:17 <puiterwijk> Is anything wrong with the db backend driver? (sqlalchemy)
19:44:32 <puiterwijk> Oh, or did you mean auth db backend?
19:44:32 <notmorgan> puiterwijk: as long as it's configurable, no issues
19:44:37 <fungi> 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 <notmorgan> puiterwijk: auth db where the user data is.
19:44:46 <notmorgan> silverstr... what fungi said
19:44:48 <jeblair> fungi: yes i did, that's written
19:44:51 <puiterwijk> notmorgan: ah, I see :)
19:44:53 <notmorgan> ok cool.
19:45:07 <notmorgan> puiterwijk: as long as sql-a can be told to use non-sqlite dbs, we're good (for sessions etc)
19:45:34 <puiterwijk> notmorgan: yep. I would actually not suggest sqlite for production. We fully support anything that's supported by sqlalchemy
19:45:34 <fungi> it may need some extending to handle the authorization/group details there (from an oidc/oauth perspective)
19:46:03 <jeblair> 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 <jeblair> (in our environment)
19:46:28 <jeblair> i have some very basic puppet standing by as well
19:46:51 <fungi> 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 <jeblair> so perhaps i should get that into a new puppet module, and then stand up a server
19:47:03 <puiterwijk> 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 <jeblair> puiterwijk: oh cool
19:47:28 <puiterwijk> 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 <puiterwijk> (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 <notmorgan> not super worried about SSSD not working
19:48:00 <notmorgan> tbh
19:48:00 <puiterwijk> And yeah, if anyone's interested in helping packaging for Debian, feel free to get in touch.
19:48:19 <puiterwijk> 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 <fungi> 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 <puiterwijk> fungi: sounds good. If there's anyone interested in doing that, feel free to bring them in touch with me
19:49:14 <puiterwijk> 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 <fungi> 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 <puiterwijk> I have an account, and that's a good idea
19:50:23 * notmorgan steals it fast :P
19:50:31 <notmorgan> def go register it.
19:50:57 <puiterwijk> Just did.
19:51:09 <puiterwijk> Thanks for the hint
19:51:11 <fungi> okay, anything else we want to cover for now, that doesn't need to wait for smarcet to be back around?
19:52:42 <fungi> thanks notmorgan and puiterwijk!
19:52:47 <fungi> #topic Open discussion
19:53:07 * notmorgan goes back to lurker mode for a few minutes.
19:53:22 <fungi> anybody do anything fun for victoria day/patriots day, or planning something interesting for memorial day?
19:53:25 <pleia2> 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 <fungi> i've been informed i won't be around monday, so that i can get some projects done on the house
19:53:47 <anteaya> I went for a nice walk yesterday
19:53:50 <pleia2> visiting family and moose and eating lobster rolls in Maine :)
19:53:52 <anteaya> was beautiful
19:54:01 <anteaya> pleia2: nice
19:54:02 <jeblair> fungi: i think i will be joining you, in spirit at least.
19:54:09 <anteaya> fungi: lucky you
19:54:14 <ianw> promethanfire raised some issues with our project-config dib elements which resulted in https://etherpad.openstack.org/p/gentoo-ci
19:54:47 <prometheanfire> https://review.openstack.org/#/c/319030/ https://review.openstack.org/#/c/318994/
19:54:48 <ianw> so there is some work to do, but i think we can overhaul things to fix up the dependencies there
19:54:57 <prometheanfire> those are the two reviews that came from that etherpad so far
19:55:11 <anteaya> pleia2: I understand moose rolls are quite tasty
19:55:16 <fungi> 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 <fungi> s/://
19:55:46 <pleia2> anteaya: oh dear, we'll be visiting one (some?) at an animal care facility, no eating :)
19:55:58 <pleia2> (this is like the kangaroos all over again!)
19:56:00 <fungi> so i guess anybody using that dib element is in a bad way now
19:56:01 <jeblair> 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 <anteaya> pleia2: ah visiting the moose, eating lobster rolls, now I get it
19:56:21 <pleia2> anteaya: yes, eat the sea bugs, visit the fluffy animals
19:56:22 <prometheanfire> fungi: no, the dep tree is really just a collector
19:56:30 <prometheanfire> not a true graph
19:56:36 <anteaya> pleia2: enjoy the fluffy animals :)
19:56:38 <ianw> fungi: yeah, i've wondered if we really have the bandwidth to support the !minimal paths
19:56:44 <prometheanfire> so it's fine, just slightly counterintuitive
19:56:44 <pabelanger> jeblair: excellent
19:57:00 <anteaya> jeblair: all these technical terms today
19:57:04 <anteaya> I can't keep up
19:57:13 <pabelanger> 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 <zaro> fungi: most likely route to force online reindex is with admin-console plugin.
19:57:54 <ianw> 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 <jeblair> pabelanger: cool; it's not a blocker but will be nice to have when we're ready for the jenkinsectomy
19:58:33 <fungi> zaro: that sounds like a good way forward to me then. thanks for researching
19:59:16 <fungi> okay, anything else? we're at 45 seconds remaining
19:59:20 <fungi> (last call!)
19:59:29 <pleia2> thanks for chairing, fungi
19:59:34 <prometheanfire> have a nice weekend
19:59:36 <fungi> you're welcome!
19:59:58 <fungi> ...and we're out of time--thanks everyone!
20:00:01 <fungi> #endmeeting