19:03:11 #startmeeting infra 19:03:11 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:03:15 The meeting name has been set to 'infra' 19:03:17 #link https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting 19:03:20 I don't have a burrito :( 19:03:24 :( 19:03:26 #topic Announcements 19:03:32 fungi: i'm keeping my quill handy though 19:03:39 #info reminder: fungi will be on vacation October 8-16; pleia2 has generously agreed to chair the October 11 meeting instead 19:03:46 Shrews: of course you will 19:03:52 as always, feel free to hit me up with announcements you want included in future meetings 19:04:01 o/ 19:04:04 #topic Actions from last meeting 19:04:11 #link http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-09-27-19.02.html 19:04:16 1. (none) 19:04:25 that was a remarkably successful week ;) 19:04:33 :) 19:04:36 #topic Specs approval 19:04:55 nothing new this week on the agenda, though jeblair has a couple of updates for a priority spec 19:05:02 which is next on our agenda 19:05:11 #topic Priority Efforts: Zuul v3 (jeblair) 19:05:17 looks like you have a couple of changes for the zuulv3 spec to discuss? 19:05:36 #link https://review.openstack.org/381329 Zuul v3: update with Ansible role information 19:05:41 ya, as promised last week, i wrote up the things we discussed needed changing while in germany 19:05:55 that one probably merits the most discussion 19:06:01 so i wanted to bring it to people's attention 19:06:46 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 so, i guess bash it out in the change review and we'll see if we can get to consensus soon 19:07:49 #link https://review.openstack.org/381330 Zuul v3: correct vagueness in describing job inheritance 19:07:58 it does have some implications on security/stability i guess, if we have role dependencies in ansible galaxy 19:08:06 that one is more of a 'catch the spec up with reality' change 19:08:12 er, i was talking about the first one of course 19:08:14 fungi: indeed 19:08:28 fungi: i think we would not want to have external role dependencies for many of our jobs 19:08:56 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 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 agreed, it's effectively already being done in their jobs 19:09:40 fungi: and i think that's the reason it ultimately doesn't really change the failure rate, etc 19:09:51 fungi: though... we do have the opportunity to have zuul auto-retry things in that case 19:09:52 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 fungi: (failure of a known job pre-requisite is something we can safely retry (for a fixed number of times)) 19:10:19 clarkb: yep 19:10:33 totally makes sense. thanks 19:10:59 [lacking further questions, eot from me] 19:11:43 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 and otherwise is a union of parameters found in each template i guess 19:13:06 fungi: well, it's more subtle than that 19:13:17 hrm, it doesn't actually address redefinition of a parameter 19:13:18 fungi: i don't think it actually addresses multiple templates including the same job 19:14:00 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 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 fungi: individual parameters usually get overriden, though one or two get appended, i think 19:15:19 and combine them into a single job 19:15:23 yep 19:16:01 (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 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 yep. i think it much more closely matches what we want to say 19:17:11 yea, this is good. i think it gets us to a much more human-readable configuration 19:17:33 not a regex in sight 19:17:49 (you can still regex on file matches) 19:17:52 and no interpolation to think about 19:18:21 yep. we may get to the point where we forget that there's a py27 variant for stable branches.... 19:18:42 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 but i think it will still be understandable 19:19:28 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 sounds good 19:19:59 the other one we should probably let cook until next week 19:20:03 the first change looks like jhesketh and mordred are still going back and forth yeah 19:20:13 I like to go back and forth with people 19:20:58 #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 thanks jeblair! 19:21:28 np! 19:21:32 #topic Feedback on Gerrit plugin to display zuuls cross repo `needed-by` reference (zaro) 19:21:35 fungi: I'll try to write more words to jhesketh 19:21:58 i was wondering whether there was interest in this 19:22:05 http://138.68.20.113:8080/#/c/7/ 19:22:33 sorry, should have probably put it on review-dev.o.o 19:22:54 it's the depends-on and needed-by thing in red 19:23:06 red means there is a cycle 19:23:15 zaro: the needed-by is based on a reverse query of the index? 19:23:21 zaro: oh that's neat :) 19:23:22 yes 19:23:35 oh, that's nice 19:23:36 the way I have always wanted that to be rendered is as a git subway graph 19:23:39 i've added rest endpoint for it 19:23:47 and incorporate proper git parent child relationships too 19:23:58 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 (beacuse in current gerrit it is really hard to see those relationships) 19:24:31 in any case I like having the info available maybe we can extend it to also include proper parent child info 19:24:53 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 ++ 19:25:12 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 I like the idea 19:25:14 zaro: seems reasonable as a first step 19:25:15 fungi: yeah, no extension point at this time. but can be adapter in that location later 19:25:40 zaro: as an interim solution, i agree this is useful 19:26:06 until the webui has a means of letting you integrate it better into the related changes box 19:26:09 cool. i'll clean up and make it avaiable for whenever you guys decide to use it. 19:26:29 thanks. 19:26:33 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 thanks zaro! 19:26:36 maybe we can provide that thing in addition to related chagnes sort of like what is there now? 19:26:48 fungi: yes, there a rest endpoint 19:26:54 basically let gerrit proper do the silly thing then have a plugin or whatever that shows the richer graph 19:27:18 zaro: nice! 19:27:22 but ya I like having that info regardless of shinyness 19:27:43 so maybe gertty will be able to grow needs-by lookups 19:27:51 er, needed-by 19:28:01 yeah, should be no problem with this plugin 19:28:25 okay, anything else on this topic before i move on? 19:28:26 https://github.com/zaro0508/dependson/blob/master/src/main/resources/Documentation/rest-api-changes.md 19:28:46 #link https://github.com/zaro0508/dependson/blob/master/src/main/resources/Documentation/rest-api-changes.md 19:28:53 awesome 19:29:14 nothing else 19:29:16 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 zaro: oh one thing 19:29:41 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 zaro: (just be aware it may eventually also grow the ability to say "Depends-On: " etc 19:30:08 thanks for the heads up. the plugin will be hosted on gerit repo 19:30:26 i think i'll call it 'dependson' plugin 19:30:36 descriptive name 19:30:52 much better than what I would have named it 19:31:13 indeed 19:31:30 hehe 19:31:37 well good, i guess that's the hardest part :) 19:32:25 #topic Storyboard vs. LP for openstack-dev/sandbox repository (ildikov, ianychoi) 19:32:35 o/ 19:33:01 tl;dr we are working on the upstream training content and one the blocks is tracking of items 19:33:11 there is a patch 19:33:18 #link https://storyboard.openstack.org/#!/story/2000734 Storyboard vs. Launchpad for new contributor trainings 19:33:19 as most of the projects are still using LP the idea was to create a sandbox project there 19:33:48 #link https://review.openstack.org/#/c/375834/ 19:34:17 thank you 19:34:39 so currently we would like to teach the students the current tools 19:34:50 this is what we would need the LP sandbox page for 19:35:12 #link https://launchpad.net/openstack-dev-sandbox 19:35:13 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 I'm fine with either one or the other, I don't care which just not both 19:36:01 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 additionally we plan to introduce storyboard too, but would go deeper into it, when it's more widely used 19:36:30 cool, I was wondering if anyone being trained was likely to then contribute to a project using storyboard or not 19:36:35 hmm, was it originally a LP project? I mean sandbox 19:36:41 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 (I also have no problem with the change if that is the goal) 19:37:16 clarkb: we plan to show the whole workflow without messing up any project page/repo 19:37:33 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 clarkb: so in this sense including Gerrit, yes 19:37:37 ildikov: everything was originally on launchpad, though I don't think we had a sandbox group on launchpad before 19:37:40 fungi: yup 19:38:06 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 anteaya: right, I didn't remember the sandbox one, not following the training that long either though, so wasn't impossible :) 19:38:50 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 ildikov: its a good question, I dont think the sandbox repo ever had its own launchpad page before 19:39:38 so anyway, anyone disagree about having an lp sandbox project in the interim? 19:39:38 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 fungi: I do not disagree 19:40:08 so the change to the patch would be to remove the use storyboard: true rule 19:40:17 and to remove it from storyboard 19:40:22 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 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 ++ 19:41:16 SotK: our thinking exactly 19:41:36 (there are 15 stories against sandbox in storyboard.o.o, one about this question and the rest look like test stories) 19:41:47 #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 fungi: if you can point me or ianychoi to what needs to be cleaned up we are happy to do that 19:42:17 ildikov: we will comment on the patch 19:42:26 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 anteaya: great, thank you! 19:42:45 fungi: I agree 19:42:50 yeah, storyboard-dev is already a massive playground for testing storyboard 19:43:11 so it's easy enough to direct people there if they're curious 19:43:29 and when the time comes to import projects, we can probably skip importing the sandbox-related project on lp into sb 19:43:30 ildikov: commented 19:44:01 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 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 hehe 19:44:48 fungi: do you want to leave the use-storyboard: true rule in project-config? 19:44:50 s/bumbers/numbers/ 19:45:00 I thought we were not doing both 19:45:13 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 anteaya: no, we'd remove use-storyboard in projects.yaml and add the groups entry 19:45:32 thanks ildikov and ianychoi! 19:45:54 fungi: ah great, yes that is the direction my comment took 19:45:58 ildikov: thank you 19:46:02 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 #topic Infra PTG presence in Atlanta (fungi) 19:46:27 the project team gathering looks like it's going to be february 20-24 in atlanta 19:46:28 fungi: great, thank you! 19:46:35 horizontal teams get monday and tuesday, vertical teams wednesday through friday (roughly, depending a bit on room availability) 19:46:47 diablo_rojo and ttx reached out to ptls wanting to know whether our teams are likely to attend 19:46:56 so this is an open question for the team... who expects to be able to make it? 19:47:00 for the whole week or just part? 19:47:08 is this how we register to attend? 19:47:24 this is how we try to help them figure out how much space will be needed 19:47:27 if yes, I would like to register to attend please 19:47:31 anteaya: no, there will be registration after we have an idea of how many teams will show up 19:47:40 I thought the venue already had a space limit 19:47:45 Probably in November or so 19:48:01 i expect to be there, though it's an easy flight for me and possibly not for others 19:48:01 I expect to be there all week 19:48:14 fungi: pending travel approval, I expect to be there all week 19:48:32 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 monday is a us holiday 19:48:54 so this is a great opportunity for some cross-team interaction 19:49:09 jeblair: the e-mail said "monday optional" 19:49:18 presumably for that reason 19:49:23 jeblair: modnay of barcelona summit is a holiday there too. maybe its a new trend 19:49:36 though, i mean, the entire event is optional, so i don't really know what the implication of that option is ;) 19:49:55 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 clarkb: yeah, not a trend I'm a fan of 19:50:50 if i get budget for it, i'd be all week myself too... 19:50:53 i must have missed the memo on on PTG, can some give me one line summary? 19:51:19 zaro: that's a tough one to distill 19:51:31 zaro: mid-cycles for all the teams at once, in the same locatoin 19:51:32 or link ? 19:51:34 location 19:51:43 zaro: https://www.openstack.org/ptg/ 19:51:49 thanks 19:51:53 zaro: the design summit without the conference 19:51:56 except not really mid-cycles, because the summit becomes our mid-cycles 19:52:00 but not called the design summit 19:52:11 do we know already the location, as the hotel/whatever 19:52:11 right 19:52:13 ? 19:52:14 if I ever recover from my last brush with Atlanta airport security, I'll ask about travel. 19:52:31 ttx, fungi ^ 19:52:32 fungi: See, I thought it was for mid-cycles... TIL 19:52:40 rcarrillocruz: atlanta 19:52:52 rcarrillocruz: I don't know if a hotel has been selected 19:52:54 i know, i mean the hotel or convention centre 19:53:00 yeah, i don't know what the venue is 19:53:06 i expect it to be a cheaper place at least, no? 19:53:18 or if i did, i don't think i was allowed to tell anyone so i promptly forgot 19:53:50 rcarrillocruz: well it will be cheaper by virtue of every hotel won't triple its prices 19:53:58 since 7000 people are attending 19:54:11 there are a lot of places in atlanta for all sizes of things 19:54:16 yeah, i don't think there's an expectation everyone will pick the same hotels to stay in anyway 19:54:24 yes it is cheaper and less classy :) 19:54:57 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 my flight to bcn is very cheap, fwiw :) 19:55:38 jeblair: one-way ? 19:55:41 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 good, cos chances are i may not get funding, so i would consider self-funding depending on how much will be 19:55:48 anyway, long way from now 19:55:51 ttx: why would you need a round trip? ;) 19:56:04 jeblair: mine is very cheap too 19:56:15 ttx: dunno, mine too 19:56:24 flaper87: I know right 19:56:35 rcarrillocruz: i think the plan is that the travel support program will be extended to cover ptg attendees too 19:56:44 fungi: it is indeed the plan 19:56:55 ttx: that's good news :) 19:57:19 fungi: you can put me down for maybe at this point. 19:57:21 oh yeah, that's good to know, thanks :-) 19:57:43 it's good it's atlanta, i mean, flights wise it is going to be way cheaper, less connections 19:57:48 #agreed There is at least a representative subset of the Infra team who would like to attend the PTG in February. 19:57:59 i'll make sure to let diablo_rojo and ttx know 19:58:22 #topic Ocata Summit Planning (fungi) 19:58:37 #link https://etherpad.openstack.org/p/infra-ocata-summit-planning Infra Ocata Summit Planning pad 19:58:56 just a minute left, but please put any session ideas there 19:59:30 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 #topic Open discussion 19:59:50 you have 10 seconds 19:59:57 thank you fungi 20:00:09 my pleasure, as always 20:00:15 thanks everyone! 20:00:19 #endmeeting