19:03:33 #startmeeting infra 19:03:34 Meeting started Tue Feb 16 19:03:33 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:35 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:03:37 The meeting name has been set to 'infra' 19:03:38 o/ 19:03:40 #link https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting 19:03:47 #topic Announcements 19:03:54 o/ 19:03:57 #info Due to the scheduled infra-cloud sprint, the usual IRC meeting we would hold next Tuesday (February 23) is cancelled. The next official IRC meeting for Infra will be Tuesday, March 1 at 19:00 UTC. 19:04:03 o/ 19:04:11 o/ 19:04:22 any other important sprint-related news i should cram in here before we move along? 19:04:33 o/ 19:04:57 #topic Actions from last meeting 19:05:02 #link http://eavesdrop.openstack.org/meetings/infra/2016/infra.2016-02-09-19.02.html 19:05:09 "1. (none)" 19:05:16 #topic Specs approval 19:05:16 i did not do that 19:05:30 #info Approved "Update unified mirror spec to support AFS" 19:05:36 #link http://specs.openstack.org/openstack-infra/infra-specs/specs/unified_mirrors.html 19:05:40 jeblair: we all did it ;) 19:05:41 #info Approved "Maintenance change to doc publishing spec" 19:05:48 #link http://specs.openstack.org/openstack-infra/infra-specs/specs/doc-publishing.html 19:05:58 (those links _should_ be correct once the post pipeline backlog clears) 19:06:03 o/ 19:06:12 just in time! 19:06:17 #topic GSOC proposals: what about adding infra-cloud? (yolanda) 19:06:19 o/ 19:06:29 \o 19:06:32 so i arrived just in time 19:06:46 i was reading that email that Victoria sent, and I thought that infra-cloud can be a good topic 19:07:10 because there can be multiple efforts associated to it. I wanted to know people's feedback 19:07:24 what's the timeline for GSOC ? 19:07:34 as in, when would an intern start doing stuff 19:07:38 yolanda: the biggest considerations are likely going to be that it should be a software development project that is completable by a student in 3 months of time 19:07:39 this friday AFAIK for application 19:07:45 deadline is 19/02 19:07:48 do we hvae any such things for infra cloud? 19:07:58 i ask cos imho there's not much room for people to do stuff 19:07:59 clarkb we can isolate some task 19:08:01 That is for organizations to submit a proposal, correct? 19:08:06 there may be once infra-cloud works 19:08:07 also, gsoc, as for outreachy, needs a clearly-defined scope. we'd need to pick a specific task or set of tasks to provide t the intern if selected 19:08:09 that deadline 19:08:16 and we can talk about other topics to improve it 19:08:21 it will be hard to get an intern up to speed and given a specific project in three months 19:08:22 ha, monitoring, whatnot 19:08:41 Moar metrics. 19:08:51 Is there a list of things currently that need help with, both GSOC and not? I know last time it was the mysql migration, but am still interested to get more involved with infracloud. 19:08:56 so not infra-cloud as a topic, but some sub-task related with it 19:08:56 I think for GSoC you do not necessarially need a clearly defined task - it is really up to the organization on how they want to do it, but it is totally valid for the mentee to assist with defining the task 19:09:09 it's been hard just getting our existing team up to speed and in a good position to make contributions 19:09:13 like, the last outreachy we did was the codesearch.o.o deployment. it was a pretty isolated scope of work and i wrote a spec for it in advance outlining what the mentor would be expected to work through 19:09:15 or yes, if infra needs more topics. I saw the wiki and nothing was proposed from infra, so there can be other things as well 19:09:21 re: GSOC, something they can continue to work on after the summer would probably be beneficial. Something they can also point to employers is especially valuable. 19:09:44 er, what the intern would be expected to work through 19:10:14 greghaynes: I think we should have at least some canned ideas that are acceptabel 19:10:18 clarkb: totally 19:10:31 I am just trying to make it known that in GSoC its our discretion, basically 19:10:38 and there are orgs which do both things 19:10:46 just coming up to speed with our code-review-based workflow is rather a lot to expect out of a college student in the timespan provided for these internships 19:10:48 crinkle: I agree, infra-cloud is a big thing, so unless the tasks are specifically isolated and don't require knowledge of the whole infra-cloud setup, I think it would be hard 19:11:08 and I'm not sure that's an achievable scope 19:11:09 i was thinking in some sub-tasks like monitoring, inventory management , logging 19:11:20 some of the topics that are listed on the mitaka etherpad 19:11:33 There is always generic puppet work that could work. Like updating modules for example 19:11:38 i think we are not at a stage right now where we can give tasks to people till we stabilize/make it work 19:11:42 yolanda: Has there been any talk with the larger openstack community about the openstack org proposal? 19:11:47 so it depeends on when the mentees really start 19:11:51 IIRC dims has done the proposal in the past 19:12:03 though again, you'd need to have the solution designed and planned. easily half the internship is going to be community/toolset learning curve 19:12:11 greghaynes what i know is from the wiki and the email that Victoria sent asking for help 19:12:19 ah, ok 19:12:32 so for the rest of teh effort, they need some pretty clearly laid out step-by-step instructions on what you want built/implemented/whatever 19:13:02 fungi, problem i see to do that, is the deadline. It's on 19/02 so we are short of time to write something solid 19:13:09 fungi: nods 19:13:43 apart from that, are there other infra efforts that can be candidates for gsoc? 19:13:43 i think a reasonable scope is to take some task that one of us would spend a couple days solid putting together. for a new intern. getting to the point that can be done and then working through it even with clear instructions is going to be the entirety of the allotted timeframe for the internship 19:14:00 yolanda: you might want to talk to zxiiro, i think his interns are 3 months as well and he got them pretty prodcutive on jjb and possibily other things. 19:14:15 i honestly think puppet openstack ci would be good for gsoc 19:14:22 +1 19:14:23 So this is an area where GSoC might work in our favor - the students are supposed to work up a proposal and mentors/orgs are supposed to work with them on making that well defined, so as long as we can define the scope of potential projects well enough I think we can leave defining details until later 19:14:23 i see it's in need of some love 19:14:42 rcarrillocruz: what exactly with puppet-openstackci? 19:14:44 like 19:14:48 'add gerrit' 19:14:49 i mean 19:14:52 there are specifics bits 19:14:55 that are missing 19:15:00 and are clearly defined 19:15:14 that's a really good project. 19:15:16 yolanda: yup. I have another intern this coming summer to work on JJB 19:15:16 i just checked today and i see gerrit and other stuff missing 19:15:25 and it's well defined 19:15:36 yep, that might be doable. adding gerrit to puppet-openstackci is fairly well-defined in scope (if maybe slightly ambitious) 19:15:37 and won't need a superhigh steep learning curve compared to infracloud 19:15:50 nod, so rather than 'implement the missing bits' 19:16:02 we could say 'implement gerrit, if possible implemented foo component' 19:16:13 yolanda: my advice is the project shouldn't be too difficult. 3 months isn't really a lot of time to do anything major, unless the student is especially keen. 19:16:24 i'm totally cool helping that out as mentor fungi 19:16:32 I would also expect htat config mgmty things aren't that desireable 19:16:47 lol 19:16:49 zxiiro yes, i agree. I've been helping with mentorship as well, and the onboarding process is complicated 19:17:03 I am going to guess that projects that involve writing what is generally considered code will be more desireable 19:17:04 clarkb: who knows, maybe htere's people loving puppet out there :D 19:17:05 shade maybe etc 19:17:07 clarkb: there is certainly a steep learning curve there too 19:17:10 Yea, this is my feeling as well. Typical projects are around software development. 19:17:11 #info rcarrillocruz willing to mentor an intern to add gerrit support to puppet-openstackci 19:17:21 a zuul feature 19:17:28 nodepool feature and so on 19:17:30 puppet not code? 19:17:48 I am trying hard to avoid that topic... 19:18:08 clarkb i have to agree with that. I've had a pair of mentees and when i was proposing config management it was not good for them. They normally prefered to code with python, javascript 19:18:10 I wouldnt say "dont even try", I am just commenting on what I have seen out there 19:18:27 it's too bad GSoC must be a code project. I think documentation would be a great project. 19:18:40 zxiiro: Yea, that is a common complaint :( 19:18:45 i think the codesearch project went really well 19:18:47 some of the other mentoring programs allow none code contributions 19:19:15 would be nice to do puppet on 1st internship then code on 2nd one. 19:19:17 that was outreachy though, right? 19:19:31 yep 19:19:34 outreachy 19:19:42 (formerly gnome opw) 19:19:47 so not the same restrictions 19:20:11 it seems a bit more open (and also decidedly non-google in nature) 19:20:43 actual open community organizing the program rather than closed, secretive corporation with own agendas 19:21:03 IMO any program which can potentially get more people involved is a win 19:21:27 so, why not both :) 19:21:39 I'm mentored out 19:21:48 okay, well that was some excellent brainstorming, i don't want to lose the entire meeting to this but does someone want to summarize? maybe interested mentors sign up per vkmc's call for help, or at least continue working out options on the infra ml first? 19:22:17 greghaynes: certainly, i'm not opposed to either, it's just that outreachy seems a little more in touch with free software than gsoc 19:22:27 Yep 19:22:27 i think mailing list is a good idea. We have time until friday 19:22:40 pleia2: lol 19:22:47 it seems like we have more potential options for outreachy 19:22:55 at the moment, at least 19:23:09 fungi: wfm 19:23:27 yeah, so maybe we save more codey-type-things for gsoc and spend our more general work options on outreachy when it comes around again 19:23:35 or something like that 19:23:51 #topic CentOS / Fedora AFS mirror hacking request (pabelanger) 19:23:55 We should just have someone add -y to everything... zuuly? Much better 19:23:58 ohai! 19:24:10 talked a little about this with mordred and jeblair last week 19:24:13 [afs everywhere] 19:24:23 just wanted to see what is needed from myside to start hacking on afs? 19:24:38 probably start with a spec? 19:24:41 fungi: good thing it's a global filesystem 19:24:41 I have local sync scripts, but don't have AFS setup locally 19:24:55 jeblair: touché 19:25:01 fungi: Oh, didn't think we need new specs for each distro 19:25:04 but I can add that 19:25:05 well, there's no reason this needs to be particularly complicated 19:25:08 maybe not 19:25:28 it's possible the wording in the unified mirrors spec is sufficient to cover our needs on this 19:25:47 at a minimum, you likely want to copy most of what's being done for the apt mirrors 19:26:04 but it sounded like instead of reprepro it's just rsync for rpm mirrors? 19:26:10 Yup, I think it is good shape locally, but things like using k5start are not being tested atm 19:26:33 pabelanger: well, if you think it's mostly there, we can just put it into production and see what breaks :) 19:26:42 yeah, are there changes proposed to implement it yet? 19:26:44 wrapping a command in k5start isn't too hard 19:26:59 we already have several k5start use examples at this point 19:27:06 okay, I am fine with that. As long as people know it is untested 19:27:30 partly untested additions of new services like this are understandable 19:27:31 yeah, it'll be on its own volume and shouldn't interfere with anything else 19:27:49 okay, so I'll clean up the scripts and get a review up 19:27:49 untested major changes to existing services/systems are slightly harder to stomach 19:27:51 so i don't think we have to get it perfect before landing it 19:28:17 an infra-root who isn't me should sign up for volume and service principal creation 19:28:32 and i should back that person up 19:28:47 i'm willing, though my bandwidth is pretty terrible at the moment so it might happen faster if someone else volunteers 19:28:59 fungi: ++bindep :) 19:29:07 indeed 19:29:37 (also part of being ptl is that i'm supposed to learn to stop volunteering to do everything myself!) 19:30:36 well, if no one steps up, i'm going to use random.choice(). :) 19:30:39 *chirp* *chirp* how did that cricket get into an irc channel? 19:31:08 brute force 19:31:36 pleia2: you win! 19:31:42 ok :) 19:32:02 yay! 19:32:09 she didn't even protest 19:32:41 pabelanger: so once your changes are close to being ready, reach out to pleia2. maybe after she's done being our beast of burden for the infra-cloud sprint 19:32:56 fungi: roger 19:33:19 any other questions on the rpm mirroring topic? 19:33:24 no sir 19:33:42 * fungi could get used to being called "sir" 19:33:52 you didn't even add "you're making a scene" 19:34:12 #topic Serving REST API docs (annegentle) 19:34:24 #link https://review.openstack.org/276484 19:34:33 o/ 19:34:35 #link http://lists.openstack.org/pipermail/openstack-dev/2016-February/086467.html 19:34:54 I updated Friday to clarify more for jhesketh and others in the same boat 19:35:33 haven't seen jhesketh pop up in meeting today, for his sake i hope he's still asleep 19:35:47 heh srsly 19:36:07 maybe mordred had a chance to review 19:36:12 * annegentle says hopefully 19:36:22 here for Qs if you need me 19:36:30 he's also not in meeting today, using "travel" as an excuse or something ;) 19:36:33 ha 19:36:41 dat happens 19:36:59 but anyway, it looks like a pretty well fleshed out spec, so hopefully we can get a few more eyes on it 19:37:45 wasn't there some talk about not needing a running server because it's basically just serving json files that don't really change (very often)? 19:38:04 jeblair: they could change as often as WADL 19:38:11 jeblair: basically JSON as doc source 19:38:46 jeblair: it's not only request and response JSON. it's JSON that describes the API 19:38:50 right, but they change when the api changes, which is not moment to moment 19:39:07 jeblair: except for the hundreds of bugs existing in the WADLs? 19:39:11 i think serving static files is the cool new thing and i don't want us to be behind the times :) 19:39:16 it sounded like there were two things the docs team wanted: a way to serve api reference details generated by a tool (that could in theory be static), and then a solution for interactive api examples (which would need its own service but could in theory be hosted separately and stitched together via a proxy) 19:39:17 heh 19:39:38 fungi: yes, this spec is only for the former for now 19:41:31 we should probably point mordred at the spec, since i think he's looked into this some 19:41:48 jeblair: yeah 19:41:53 * annegentle awaits patiently 19:42:58 I would like an end date for a decision, because we'll need to double-down on the static site work if we can't get this implemented this release... 19:43:15 and other than that i guess we need to make sure it integrates sufficiently with the updated publishing spec being finalized at https://review.openstack.org/276482 19:43:24 annegentle: yeah, my vague recollection was basically that the json that swagger generates ought to be able to be generated each time the api changes and hosted statically, rather than needing a running service. but that's where everything gets fuzzy and i shouldn't take up more time in the meeting. 19:44:19 jeblair: sure want mordred's take on this spec as a phase one then so I can get to that awesome state 19:44:38 fungi: yeah integration I basically ignore in the spec. 19:44:38 i do recall that it ends up being an annotated interactive api that we then need the job to serve locally and connect to, dump the results of querying it, and then feed that into a publication solution 19:44:47 i guess, to try to bring it on topic -- if i'm describing something that has been considered and discarded, would probably be good to have it in the alternatives 19:45:03 jeblair: yep good point. I'll see what I can find out. 19:45:46 fungi: that seems feasible 19:46:15 also on a purely non-content note, 276484 needs to update the infra-specs index to add an entry for itself to the approved list 19:46:34 fungi: okie 19:46:39 i just tried to view the draft rendering and realized it's not indexed 19:46:47 easy to overlook 19:46:57 oh, yeah, we don't do the auto-index because of $important_reasons 19:47:12 (i think url permanence was one of them) 19:48:23 i apologize for not finding time to read this spec yet, so don't have a lot of good feedback and am not in a position to make any detailed implementation recommendations in meeting. it sounds like the two core reviewers who had been looking at it are through circumstance not available today 19:48:29 ok 19:48:41 carry on with other agenda items then, I'm good 19:49:08 i think it's great getting this written down though 19:49:12 annegentle: thanks :) 19:49:24 jeblair: sure 19:49:27 so anyway, we should probably continue discussion on the review itself for now, and can punt to re-discussing in the march 1 meeting if necessary (next week the meeting is on hiatus for our infra-cloud sprint) 19:49:41 thanks annegentle for putting that together! 19:49:51 ok, that gives me a date too which we'll keep in mind for next steps 19:50:11 #topic Open discussion 19:50:25 we have our infra-cloud sprint coming up in a few days :) 19:50:27 light agenda, so we have 10 minutes for whatever 19:50:36 hiya, to try to answer the question "I want to help with infra-cloud but I don't know where to start" I started working on https://github.com/cmurphy/infracloud-development 19:50:45 pleia2: yes! thanks for putting the sprint together 19:50:46 let me know if you have any questions about where to go or anything, everything should be in the wiki 19:50:47 hoping it can help people do reviews and make changes 19:50:49 #link https://wiki.openstack.org/wiki/Sprints/InfraMitakaSprint 19:50:57 Thanks crinkle 19:51:04 I've never been there either, so it should be interesting :) 19:51:13 i have a bunch of patches out for installing d-i-b from git on nodepool. does anyone have opinions on this? i might have to turn it into a spec, because the reviews didn't get consensus 19:51:19 crinkle: ooh, that looks like an excellent intro 19:51:25 crinkle: neat 19:51:29 crinkle: thanks, bookmarking 19:51:50 do we have any update on maniphest migration? is that still gonna happen? 19:51:54 if people think it's useful I could potentially move it to an examples/ dir in the puppet-infracloud module 19:52:44 I've been stymied by conferences (LCA) and the HP cloud transition. 19:52:47 Also, just a reminder. We have atleast 2 -infra specific talks for Austin, 7578 and 7337 if you are interested in voting. Additionally, if others have submitted something, Please send them this way 19:53:00 oh yeah 19:53:01 good call 19:53:05 i have not voted 19:53:10 will check them out, thx 19:53:36 there's only one issue outstanding from my perspective zaro and patches that need reviews. 19:53:41 pabelanger: in fact there are a ton of infra-specific talks proposed, though those are definitely the front-runners ;) 19:54:13 craige: topic? 19:54:38 Manifest 19:54:46 zaro: as defined at http://specs.openstack.org/openstack-infra/infra-specs/specs/maniphest.html#gerrit-topic 19:54:51 Ugh, Maniphest 19:54:59 hopefully 19:55:18 thanks, will take a look 19:55:35 \I/ 19:56:56 autocorrect fails. 19:58:08 looks like we've actually exhausted open discussion as well, so i'll end this a couple minutes early for a change 19:58:13 thanks everybody! 19:58:24 thanks, fungi! 19:58:24 #endmeeting