19:03:11 <fungi> #startmeeting infra
19:03:11 <openstack> Meeting started Tue Oct  4 19:03:11 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:12 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:03:15 <openstack> The meeting name has been set to 'infra'
19:03:17 <fungi> #link https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting
19:03:20 <clarkb> I don't have a burrito :(
19:03:24 <anteaya> :(
19:03:26 <fungi> #topic Announcements
19:03:32 <Shrews> fungi: i'm keeping my quill handy though
19:03:39 <fungi> #info reminder: fungi will be on vacation October 8-16; pleia2 has generously agreed to chair the October 11 meeting instead
19:03:46 <fungi> Shrews: of course you will
19:03:52 <fungi> as always, feel free to hit me up with announcements you want included in future meetings
19:04:01 <rcarrillocruz> o/
19:04:04 <fungi> #topic Actions from last meeting
19:04:11 <fungi> #link http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-09-27-19.02.html
19:04:16 <fungi> 1. (none)
19:04:25 <fungi> that was a remarkably successful week ;)
19:04:33 <Zara> :)
19:04:36 <fungi> #topic Specs approval
19:04:55 <fungi> nothing new this week on the agenda, though jeblair has a couple of updates for a priority spec
19:05:02 <fungi> which is next on our agenda
19:05:11 <fungi> #topic Priority Efforts: Zuul v3 (jeblair)
19:05:17 <fungi> looks like you have a couple of changes for the zuulv3 spec to discuss?
19:05:36 <fungi> #link https://review.openstack.org/381329 Zuul v3: update with Ansible role information
19:05:41 <jeblair> ya, as promised last week, i wrote up the things we discussed needed changing while in germany
19:05:55 <jeblair> that one probably merits the most discussion
19:06:01 <jeblair> so i wanted to bring it to people's attention
19:06:46 <jeblair> i think we're all in agreement on the general principle (zuul needs to do this), but there are some more options than we considered as to *how* it should do it
19:07:15 <jeblair> so, i guess bash it out in the change review and we'll see if we can get to consensus soon
19:07:49 <jeblair> #link https://review.openstack.org/381330 Zuul v3: correct vagueness in describing job inheritance
19:07:58 <fungi> it does have some implications on security/stability i guess, if we have role dependencies in ansible galaxy
19:08:06 <jeblair> that one is more of a 'catch the spec up with reality' change
19:08:12 <fungi> er, i was talking about the first one of course
19:08:14 <jeblair> fungi: indeed
19:08:28 <jeblair> fungi: i think we would not want to have external role dependencies for many of our jobs
19:08:56 <fungi> wonder how often a change to an external role will break jobs depending on it, similar to the disruption from runtime dependencies of projects changing
19:08:58 <jeblair> fungi: but i think it could be really useful for, say, advanced ansible-openstack jobs (which are likely doing exactly that today, just *within* the job)
19:09:23 <fungi> agreed, it's effectively already being done in their jobs
19:09:40 <jeblair> fungi: and i think that's the reason it ultimately doesn't really change the failure rate, etc
19:09:51 <jeblair> fungi: though... we do have the opportunity to have zuul auto-retry things in that case
19:09:52 <clarkb> ya I don't foresee them being a super common thing. Most of it is going to be bottled up in the infra roles to do common stuff I expect
19:10:14 <jeblair> fungi: (failure of a known job pre-requisite is something we can safely retry (for a fixed number of times))
19:10:19 <jeblair> clarkb: yep
19:10:33 <fungi> totally makes sense. thanks
19:10:59 <jeblair> [lacking further questions, eot from me]
19:11:43 <fungi> on the second change, this is basically clarifying that parameters redefined in later templates take the last definition, rather than an earlier one?
19:13:02 <fungi> and otherwise is a union of parameters found in each template i guess
19:13:06 <jeblair> fungi: well, it's more subtle than that
19:13:17 <fungi> hrm, it doesn't actually address redefinition of a parameter
19:13:18 <jeblair> fungi: i don't think it actually addresses multiple templates including the same job
19:14:00 <jeblair> fungi: what it does is say that if you invoke "py27" it's going to run a py27 job based on the parameters specified in all of the py27 jobs which match that change
19:14:55 <jeblair> fungi: (so if you have py27 defined globally, and then a variant for a stable branch, and then a variant for the project in question, it's going to include information from all of those (in that order))
19:15:18 <jeblair> fungi: individual parameters usually get overriden, though one or two get appended, i think
19:15:19 <fungi> and combine them into a single job
19:15:23 <jeblair> yep
19:16:01 <jeblair> (so if you say "py27 on stable branches should run on trusty" and "py27 for nova should be non-voting" then the py27 job for a nova stable branch will be non-voting and on trusty)
19:16:16 <fungi> okay, so externalizing the branching logic into a composition layer scheme instead of having to do branching logic in the job by checking those different facets
19:16:37 <jeblair> yep.  i think it much more closely matches what we want to say
19:17:11 <fungi> yea, this is good. i think it gets us to a much more human-readable configuration
19:17:33 <jeblair> not a regex in sight
19:17:49 <jeblair> (you can still regex on file matches)
19:17:52 <clarkb> and no interpolation to think about
19:18:21 <jeblair> yep.  we may get to the point where we forget that there's a py27 variant for stable branches....
19:18:42 <jeblair> so we might want some logging or to otherwise expose the variants that zuul applied in constructing the job for ease of debugging
19:19:05 <jeblair> but i think it will still be understandable
19:19:28 <fungi> this second change seems to be pretty popular. a few rollcall votes already and no requests for alteration. it's only been up for a day but maybe we put it up for a council vote until thursday?
19:19:48 <jeblair> sounds good
19:19:59 <jeblair> the other one we should probably let cook until next week
19:20:03 <fungi> the first change looks like jhesketh and mordred are still going back and forth yeah
19:20:13 <mordred> I like to go back and forth with people
19:20:58 <fungi> #info Council voting remains open on "Zuul v3: correct vagueness in describing job inheritance" until 19:00 UTC on Thursday, October 6.
19:21:18 <fungi> thanks jeblair!
19:21:28 <jeblair> np!
19:21:32 <fungi> #topic Feedback on Gerrit plugin to display zuuls cross repo `needed-by` reference (zaro)
19:21:35 <mordred> fungi: I'll try to write more words to jhesketh
19:21:58 <zaro> i was wondering whether there was interest in this
19:22:05 <zaro> http://138.68.20.113:8080/#/c/7/
19:22:33 <zaro> sorry, should have probably put it on review-dev.o.o
19:22:54 <zaro> it's the depends-on and needed-by thing in red
19:23:06 <zaro> red means there is a cycle
19:23:15 <jeblair> zaro: the needed-by is based on a reverse query of the index?
19:23:21 <jeblair> zaro: oh that's neat :)
19:23:22 <zaro> yes
19:23:35 <pleia2> oh, that's nice
19:23:36 <clarkb> the way I have always wanted that to be rendered is as a git subway graph
19:23:39 <zaro> i've added rest endpoint for it
19:23:47 <clarkb> and incorporate proper git parent child relationships too
19:23:58 <fungi> at one point there was a discussion of having it over where the related changes end up in the new change screen, rather than putting this in a part of the ui where gerrit has stopped displaying dependencies
19:24:01 <clarkb> (beacuse in current gerrit it is really hard to see those relationships)
19:24:31 <clarkb> in any case I like having the info available maybe we can extend it to also include proper parent child info
19:24:53 <zaro> clarkb: ok, maybe this could be first step. becuase it would have help me out a lot when tying a bunch of xrepo dependencies together
19:25:03 <jeblair> ++
19:25:12 <fungi> yeah, i'm not a fan of the new gerrit "related changes" box, but having the commit message scraped depends-on relationships in a completely separate part of the ui seems a little strange
19:25:13 <pabelanger> I like the idea
19:25:14 <pleia2> zaro: seems reasonable as a first step
19:25:15 <zaro> fungi: yeah, no extension point at this time.  but can be adapter in that location later
19:25:40 <fungi> zaro: as an interim solution, i agree this is useful
19:26:06 <fungi> until the webui has a means of letting you integrate it better into the related changes box
19:26:09 <zaro> cool.  i'll clean up and make it avaiable for whenever you guys decide to use it.
19:26:29 <zaro> thanks.
19:26:33 <fungi> is there an associated api call to look these up, or will other tools (e.g. gertty) need to continue to rely on a message: query?
19:26:34 <pleia2> thanks zaro!
19:26:36 <clarkb> maybe we can provide that thing in addition to related chagnes sort of like what is there now?
19:26:48 <zaro> fungi: yes, there a rest endpoint
19:26:54 <clarkb> basically let gerrit proper do the silly thing then have a plugin or whatever that shows the richer graph
19:27:18 <fungi> zaro: nice!
19:27:22 <clarkb> but ya I like having that info regardless of shinyness
19:27:43 <fungi> so maybe gertty will be able to grow needs-by lookups
19:27:51 <fungi> er, needed-by
19:28:01 <zaro> yeah, should be no problem with this plugin
19:28:25 <fungi> okay, anything else on this topic before i move on?
19:28:26 <zaro> https://github.com/zaro0508/dependson/blob/master/src/main/resources/Documentation/rest-api-changes.md
19:28:46 <fungi> #link https://github.com/zaro0508/dependson/blob/master/src/main/resources/Documentation/rest-api-changes.md
19:28:53 <fungi> awesome
19:29:14 <zaro> nothing else
19:29:16 <fungi> i've reordered the other topics to move mine to the end of the agenda, in case we run short on time
19:29:20 <jeblair> zaro: oh one thing
19:29:41 <jeblair> zaro: we may end up extending the depends-on syntax in zuulv3, but i imagine the current syntax will continue to work
19:30:04 <jeblair> zaro: (just be aware it may eventually also grow the ability to say "Depends-On: <some github change thing>" etc
19:30:08 <zaro> thanks for the heads up.  the plugin will be hosted on gerit repo
19:30:26 <zaro> i think i'll call it 'dependson' plugin
19:30:36 <anteaya> descriptive name
19:30:52 <mordred> much better than what I would have named it
19:31:13 <anteaya> indeed
19:31:30 <pleia2> hehe
19:31:37 <zaro> well good, i guess that's the hardest part :)
19:32:25 <fungi> #topic Storyboard vs. LP for openstack-dev/sandbox repository (ildikov, ianychoi)
19:32:35 <ildikov> o/
19:33:01 <ildikov> tl;dr we are working on the upstream training content and one the blocks is tracking of items
19:33:11 <anteaya> there is a patch
19:33:18 <fungi> #link https://storyboard.openstack.org/#!/story/2000734 Storyboard vs. Launchpad for new contributor trainings
19:33:19 <ildikov> as most of the projects are still using LP the idea was to create a sandbox project there
19:33:48 <ildikov> #link https://review.openstack.org/#/c/375834/
19:34:17 <anteaya> thank you
19:34:39 <ildikov> so currently we would like to teach the students the current tools
19:34:50 <ildikov> this is what we would need the LP sandbox page for
19:35:12 <anteaya> #link https://launchpad.net/openstack-dev-sandbox
19:35:13 <fungi> i think i'm fine with moving the sandbox repo off storyboard for the time being, since it's not really an infra project and i can see how having its bug integration tied to storyboard sort of makes it a training issue
19:35:47 <anteaya> I'm fine with either one or the other, I don't care which just not both
19:36:01 <fungi> i don't recall why we migrated it to storyboard (or if we even stopped to think about the implication of doing so)
19:36:03 <ildikov> additionally we plan to introduce storyboard too, but would go deeper into it, when it's more widely used
19:36:30 <Zara> cool, I was wondering if anyone being trained was likely to then contribute to a project using storyboard or not
19:36:35 <ildikov> hmm, was it originally a LP project? I mean sandbox
19:36:41 <clarkb> ildikov: are you specifically looking to show people the integration between lp and gerrit? (I think just about everything else can be done with this)
19:36:48 <clarkb> (I also have no problem with the change if that is the goal)
19:37:16 <ildikov> clarkb: we plan to show the whole workflow without messing up any project page/repo
19:37:33 <fungi> right, given that most new contributors are going to be shown to add closes:bug: lines to their commits and whatnot, having them see the integration with lp makes more sense until a majority of projects have moved from lp to sb
19:37:37 <ildikov> clarkb: so in this sense including Gerrit, yes
19:37:37 <anteaya> ildikov: everything was originally on launchpad, though I don't think we had a sandbox group on launchpad before
19:37:40 <clarkb> fungi: yup
19:38:06 <Zara> I'm +1 for giving training for whatever tools are going to be used by the people being trained, so to me it would depend what projects they're going to be working on, anyway.  :)
19:38:31 <ildikov> anteaya: right, I didn't remember the sandbox one, not following the training that long either though, so wasn't impossible :)
19:38:50 <fungi> i expect we'll switch the sandbox repo to interact with storyboard soonish, but with training activity ramping up at the summit now is not a good time to start pushing that transition
19:39:06 <anteaya> ildikov: its a good question, I dont think the sandbox repo ever had its own launchpad page before
19:39:38 <fungi> so anyway, anyone disagree about having an lp sandbox project in the interim?
19:39:38 <ildikov> Zara: we don't have a list of projects what to show, but people are usually interested in Nova and/or other core services, which haven't switched yet
19:39:50 <anteaya> fungi: I do not disagree
19:40:08 <anteaya> so the change to the patch would be to remove the use storyboard: true rule
19:40:17 <anteaya> and to remove it from storyboard
19:40:22 <fungi> i can look into what needs to be cleaned up in sb, or we could just ignore any already imported cruft in there if there is any in there
19:40:23 <SotK> yep, training explaining LP and also StoryBoard seems like a good plan, and I guess using LP with sandbox is the most sensible, given the current distribution of projects
19:40:35 <pleia2> ++
19:41:16 <ildikov> SotK: our thinking exactly
19:41:36 <SotK> (there are 15 stories against sandbox in storyboard.o.o, one about this question and the rest look like test stories)
19:41:47 <fungi> #agreed For the sake of training, we should switch the openstack-dev/sandbox repo to interact with Launchpad until a majority of official OpenStack repos have moved from there to Storyboard.
19:41:56 <ildikov> fungi: if you can point me or ianychoi to what needs to be cleaned up we are happy to do that
19:42:17 <anteaya> ildikov: we will comment on the patch
19:42:26 <fungi> SotK: i expect we can just ignore the sandbox project in sb, and let people continue to use it to test out sb for now (sans gerrit integration, which can be demonstrated with review-dev and storyboard-dev if needed)
19:42:29 <ildikov> anteaya: great, thank you!
19:42:45 <SotK> fungi: I agree
19:42:50 <Zara> yeah, storyboard-dev is already a massive playground for testing storyboard
19:43:11 <Zara> so it's easy enough to direct people there if they're curious
19:43:29 <fungi> and when the time comes to import projects, we can probably skip importing the sandbox-related project on lp into sb
19:43:30 <anteaya> ildikov: commented
19:44:01 <anteaya> ildikov: thanks for attending the meeting and for the hard work you and ianychoi and the rest of the training folks are doing
19:44:27 <fungi> just switch it back to sb at that point and ignore that the old lp bugs in it weren't imported (or import them, i guess the odds of a collision on story bumbers are unlikely given the starting offset we picked)
19:44:40 <Zara> hehe
19:44:48 <anteaya> fungi: do you want to leave the use-storyboard: true rule in project-config?
19:44:50 <fungi> s/bumbers/numbers/
19:45:00 <anteaya> I thought we were not doing both
19:45:13 <ildikov> anteaya: sure, on boarding is important, so we are trying to put a bit more effort into doing a good job with it
19:45:15 <fungi> anteaya: no, we'd remove use-storyboard in projects.yaml and add the groups entry
19:45:32 <fungi> thanks ildikov and ianychoi!
19:45:54 <anteaya> fungi: ah great, yes that is the direction my comment took
19:45:58 <anteaya> ildikov: thank you
19:46:02 <fungi> we'll follow up on the review and, if necessary, can help in #openstack-infra if you run into issues with it
19:46:20 <fungi> #topic Infra PTG presence in Atlanta (fungi)
19:46:27 <fungi> the project team gathering looks like it's going to be february 20-24 in atlanta
19:46:28 <ildikov> fungi: great, thank you!
19:46:35 <fungi> horizontal teams get monday and tuesday, vertical teams wednesday through friday (roughly, depending a bit on room availability)
19:46:47 <fungi> diablo_rojo and ttx reached out to ptls wanting to know whether our teams are likely to attend
19:46:56 <fungi> so this is an open question for the team... who expects to be able to make it?
19:47:00 <fungi> for the whole week or just part?
19:47:08 <anteaya> is this how we register to attend?
19:47:24 <fungi> this is how we try to help them figure out how much space will be needed
19:47:27 <anteaya> if yes, I would like to register to attend please
19:47:31 <ttx> anteaya: no, there will be registration after we have an idea of how many teams will show up
19:47:40 <anteaya> I thought the venue already had a space limit
19:47:45 <ttx> Probably in November or so
19:48:01 <fungi> i expect to be there, though it's an easy flight for me and possibly not for others
19:48:01 <clarkb> I expect to be there all week
19:48:14 <pabelanger> fungi: pending travel approval, I expect to be there all week
19:48:32 <fungi> and yeah, the idea is that we pick vertical teams we want to help hack on for the latter part of the week
19:48:48 <jeblair> monday is a us holiday
19:48:54 <fungi> so this is a great opportunity for some cross-team interaction
19:49:09 <fungi> jeblair: the e-mail said "monday optional"
19:49:18 <fungi> presumably for that reason
19:49:23 <clarkb> jeblair: modnay of barcelona summit is a holiday there too. maybe its a new trend
19:49:36 <fungi> though, i mean, the entire event is optional, so i don't really know what the implication of that option is ;)
19:49:55 <jeblair> plus, it's like the worst weekend to try to ski in the us, so i'm happy to date-shift it anyway :)
19:50:18 <anteaya> clarkb: yeah, not a trend I'm a fan of
19:50:50 <rcarrillocruz> if i get budget for it, i'd be all week myself too...
19:50:53 <zaro> i must have missed the memo on on PTG, can some give me one line summary?
19:51:19 <fungi> zaro: that's a tough one to distill
19:51:31 <anteaya> zaro: mid-cycles for all the teams at once, in the same locatoin
19:51:32 <zaro> or link ?
19:51:34 <anteaya> location
19:51:43 <pabelanger> zaro: https://www.openstack.org/ptg/
19:51:49 <zaro> thanks
19:51:53 <anteaya> zaro: the design summit without the conference
19:51:56 <fungi> except not really mid-cycles, because the summit becomes our mid-cycles
19:52:00 <anteaya> but not called the design summit
19:52:11 <rcarrillocruz> do we know already the location, as the hotel/whatever
19:52:11 <fungi> right
19:52:13 <rcarrillocruz> ?
19:52:14 <Zara> if I ever recover from my last brush with Atlanta airport security, I'll ask about travel.
19:52:31 <rcarrillocruz> ttx, fungi ^
19:52:32 <pabelanger> fungi: See, I thought it was for mid-cycles... TIL
19:52:40 <anteaya> rcarrillocruz: atlanta
19:52:52 <anteaya> rcarrillocruz: I don't know if a hotel has been selected
19:52:54 <rcarrillocruz> i know, i mean the hotel or convention centre
19:53:00 <fungi> yeah, i don't know what the venue is
19:53:06 <rcarrillocruz> i expect it to be a cheaper place at least, no?
19:53:18 <fungi> or if i did, i don't think i was allowed to tell anyone so i promptly forgot
19:53:50 <anteaya> rcarrillocruz: well it will be cheaper by virtue of every hotel won't triple its prices
19:53:58 <anteaya> since 7000 people are attending
19:54:11 <pleia2> there are a lot of places in atlanta for all sizes of things
19:54:16 <fungi> yeah, i don't think there's an expectation everyone will pick the same hotels to stay in anyway
19:54:24 <ttx> yes it is cheaper and less classy :)
19:54:57 <fungi> the goal is to have it be in a city where you can get cheaper flights and can find cheap (comparatively) accommodations
19:55:29 <jeblair> my flight to bcn is very cheap, fwiw :)
19:55:38 <ttx> jeblair: one-way ?
19:55:41 <fungi> though our idea of doing it on college campuses during breaks and being able to take advantage of dormitory rooming rates (like, say, debconf) didn't quite fly
19:55:43 <rcarrillocruz> good, cos chances are i may not get funding, so i would consider self-funding depending on how much will be
19:55:48 <rcarrillocruz> anyway, long way from now
19:55:51 <jeblair> ttx: why would you need a round trip? ;)
19:56:04 <ttx> jeblair: mine is very cheap too
19:56:15 <flaper87> ttx: dunno, mine too
19:56:24 <ttx> flaper87: I know right
19:56:35 <fungi> rcarrillocruz: i think the plan is that the travel support program will be extended to cover ptg attendees too
19:56:44 <ttx> fungi: it is indeed the plan
19:56:55 <flaper87> ttx: that's good news :)
19:57:19 <zaro> fungi: you can put me down for maybe at this point.
19:57:21 <rcarrillocruz> oh yeah, that's good to know, thanks :-)
19:57:43 <rcarrillocruz> it's good it's atlanta, i mean, flights wise it is going to be way cheaper, less connections
19:57:48 <fungi> #agreed There is at least a representative subset of the Infra team who would like to attend the PTG in February.
19:57:59 <fungi> i'll make sure to let diablo_rojo and ttx know
19:58:22 <fungi> #topic Ocata Summit Planning (fungi)
19:58:37 <fungi> #link https://etherpad.openstack.org/p/infra-ocata-summit-planning Infra Ocata Summit Planning pad
19:58:56 <fungi> just a minute left, but please put any session ideas there
19:59:30 <fungi> i'd like to start trying to work out how many we have and will do an ml thread to try to prioritize them so i can attempt to fit them into our schedule later this week
19:59:44 <fungi> #topic Open discussion
19:59:50 <fungi> you have 10 seconds
19:59:57 <anteaya> thank you fungi
20:00:09 <fungi> my pleasure, as always
20:00:15 <fungi> thanks everyone!
20:00:19 <fungi> #endmeeting