19:01:37 #startmeeting infra 19:01:38 I am going to hvae to go read up on smtp now 19:01:38 Meeting started Tue Sep 1 19:01:37 2015 UTC and is due to finish in 60 minutes. The chair is jeblair. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:01:39 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:01:41 o/ 19:01:41 <-- slow train wifi 19:01:42 The meeting name has been set to 'infra' 19:01:50 O/ 19:01:52 jeblair: ELHO 19:01:56 o/ 19:01:58 gah 19:02:00 hah 19:02:02 o/ 19:02:06 you mean EHLO 19:02:06 * mordred is a bad mail server 19:02:10 o/ 19:02:11 o/ 19:02:13 clarkb: just issue "HELP" :) 19:02:14 indeed. are you running exchange? 19:02:24 that's just mean 19:02:31 #link agenda https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting 19:02:34 #link previous meeting http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-08-25-19.00.html 19:02:34 * mordred cries in the corner 19:02:38 * fungi is cruel and insensitive when it comes to mtas 19:03:04 all the actions from last meeting were done and involved sending mail, so skipping that. 19:03:15 email is so last week 19:03:15 woo 19:03:21 #topic Specs approval 19:03:28 #info Host Stackalytics Service spec was approved 19:03:28 #link Host Stackalytics Service spec https://review.openstack.org/#/c/187715/ 19:03:35 woot 19:03:42 Yay 19:03:43 er, i got distracted and didn't push the button on that until just now, but it's totally legit 19:03:52 is it too legit? 19:04:01 no 19:04:05 o/ 19:04:05 phew 19:04:25 #topic Priority Efforts 19:04:48 i also didn't clean out the agenda last week; are there zanata things to discuss? 19:04:56 mordred: too legit to quit? (hey! hey!) 19:04:57 yes 19:05:06 #topic Priority Efforts (Migration to Zanata) 19:05:16 stevenk, carlos and I will be doing a bunch of the work to transition from transifex to zanata this week 19:05:17 zanata would be good to stay on top of just because of the impending cut-over 19:05:38 #link https://etherpad.openstack.org/p/zanata-deploy 19:05:39 Morning 19:05:45 o/ 19:05:55 thats the draft set of steps that pleia2 left us with to go through, if anyone else notices somethng wrong there please do let us know 19:06:01 the cutover is next week, yeah? 19:06:10 basic idea is we copy users from -dev over to prod so that the group management doesn't have to be redone 19:06:12 jeblair: yes 19:06:24 well, the announcement said "no later than" implying it _could_ happen sooner 19:06:24 morning jhesketh 19:06:33 but certainly doesn't have to 19:06:46 then we populate the projects using the jeepyb script, then we import to zanata from transifex and finally flip the switch on the jenkins proposal jobs to use the zanata prod server 19:06:58 I expect it to not happen until then just because there are a few things to work thorugh 19:07:19 this is very exciting 19:07:21 so I may be asking for help on reviews or babysitting certain steps of that but I intend to do as much as I can 19:07:21 should we schedule a time? 19:07:37 jeblair: ya I need to talk to carlos and find out how soon he can get the user script thing done 19:07:54 as I think everything else is just ready to go so scheduling depends on when the user migration can happen 19:08:26 I also need to investigate if we can put transifex into read only mode 19:08:30 that idea just occured to me 19:08:30 clarkb: okay, so plan is basically: get script from carlos, then find soonest reasonable time to run it? 19:08:36 jeblair: yup 19:08:39 +1 user migration 19:09:02 #info zanata migration to be scheduled pending receipt of user migration script from carlos 19:09:38 clarkb: cool, anything else? 19:09:39 does carlos know we are waiting for him? 19:09:46 anteaya: yes there have been many emails 19:09:54 great 19:09:58 I will reping and make sure that everyone is on the same page 19:10:00 jeblair: nope thats it 19:10:48 cool, thanks! 19:10:53 #topic Priority Efforts (Downstream Puppet) 19:11:03 we chatted about this in email 19:11:28 and i think yolanda, i, and fbo all replied similarly 19:11:54 have we achieved consensus? 19:12:20 I haven't responded to the thread but I agree with the way forward 19:12:26 I agree with everyone 19:12:36 this is the apache module question?? 19:12:41 anteaya: yes 19:12:47 well didn't everyone agree two different options were fine? 19:12:57 maybe I misread but I wasn't sure that we had decided on a specific option 19:13:18 I have no opinion just trying to follow along 19:13:35 clarkb: i think the important thing is "create and use httpd::mod" 19:13:36 specific options, presumably, for the various bugs we're encountering 19:13:51 I think creating httpd::mod and use it everywhere is the plan 19:14:14 ok wfm 19:14:24 i'm mostly curious what the way forward is on parent directories for configuration 19:14:27 there are some suggestions as to how to actually implement it which are easy to tweak and change later, but getting buy in to the idea that we should use httpd::mod to encapsulate the ordering needed, and we should change our manifests to use that are the big things i think 19:14:40 the module dependencies is easy enough to work around regardless 19:15:21 fungi: apparently parent dir file resources are autorequired 19:15:34 fungi: should be easy enough, i'll be happy to work with you next time it comes up 19:15:48 jeblair: in fungi's case the file resource doesn't exist because we expect the package to handle that 19:15:50 maybe this is referencing a thing i missed? 19:16:16 ah; configuration file requires package? 19:16:23 right, i have a review for etherpad_lite currently in limbo waiting to figure out how we want to move forward 19:16:29 fungi: link? 19:16:50 #link https://review.openstack.org/215169 19:17:16 config files go in directories the package creates on installation 19:17:29 we're puppeting the configs as regular file resources 19:17:40 but also setting a notify to the service on some 19:17:45 fungi: related to that have we swapped out etherpad-dev yet? anything I can do to help with that (other than unlimboing this change) 19:18:10 clarkb: we have not, but i saw the change merged yesterday so i can work on that in the background during the next two meetings 19:18:22 fungi: it seems like setting a require => Package[httpd] would do, right? (or require => Package[httpd::package] to deal with variable package names) 19:18:48 jeblair: fungi yes I think so 19:19:05 jeblair: tried but the notify of the service causes a circular dependency. i'll see if i can find other solutions along those lines 19:19:46 we can refactor the httpd module to have an 'httpd::install' class that you can hang on to, is one solution 19:20:28 right, it seems like there's a couple possible ways to do it if we want the httpd module to be handed those files 19:20:46 rather than treating them as regular file resources in the consuming module 19:22:04 anything else? 19:22:21 nope, just making sure we don't conclude the discussion on the ml without addressing all the ordering issues which seemed to crop up from the module rename 19:22:39 so i'll continue to follow up there 19:22:47 fungi, nibalizer: cool, thanks 19:22:56 #topic The Outreachy internship with our team has completed, congratulations taron! 19:23:00 #link http://lists.openstack.org/pipermail/openstack-internships/2015-August/000025.html 19:23:03 gj taron 19:23:12 thanks for the help, taron!!! 19:23:38 well done taron 19:23:45 (and feel free to stick around and help us finish, or help with other things, or just hang out) 19:24:06 ++ 19:24:38 and share your feedback with us 19:24:42 yay! it seems like we're pretty close to having it up and running too; i know i'm looking forward to it :) 19:25:02 yay hound 19:25:28 yeah, the progress was good and implies the plan and choice of software was solid, though there are still some upstream improvements which would be helpful too 19:25:53 yes good planning 19:25:56 for taron or anyone else who thinks they want to try hacking in go 19:26:09 yes please 19:26:29 like https://github.com/etsy/hound/issues/119 19:26:39 #link https://github.com/etsy/hound/issues/119 19:26:53 * mordred looks around for people interested in writing go 19:27:50 #topic Open discussion 19:27:56 i'm soliciting negative feedback on 19:27:57 #link https://review.openstack.org/#/c/219372/ 19:28:07 woo! 19:28:16 also, nobody ever solicits NEGATIVE feedback! 19:28:16 right on 19:28:19 puppet sprint sarts tomorrow: https://wiki.openstack.org/wiki/VirtualSprints#Puppet_OpenStack 19:28:37 i'll be sure to get as negative as my liquor cabinet can get me 19:28:40 Clint: only negative? 19:28:50 Clint: thanks for taking this on, btw. most appreciated 19:29:03 oh that's looking so helpful already 19:29:23 anteaya: well, negative is probably more helpful at this point 19:29:30 mordred: just tried my hand at some Go. might try some more soon. 19:29:36 out of curiousity why yaml and not just rst or markdown or similar human readable listing? 19:29:51 rbradfor: do you want to plug your discussion thread on making code coverage reports more consumable? 19:29:58 clarkb: yaml is human readable! 19:30:01 jeblair: barely 19:30:08 o/ 19:30:09 clarkb: you wound me 19:30:12 Clint: I'll read when I'm cranky 19:30:25 jeblair: its good for when computers have to consume the data structure too 19:30:25 clarkb: structure seemed appealing, and i was thinking about color-coding based on tags and such 19:30:34 which would be more work in .rst 19:30:38 and its not clear to me that that is the case here seems more geared towards humans for which rst would be better imo 19:30:40 asselin_: you will want to see this: https://review.openstack.org/#/c/219372/2/status/openstackci.yaml 19:31:18 clarkb: could be premature optimziation 19:31:25 pretend i can spell 19:31:45 looking for any other feedback on my artifact signing spec. i'll submit it for approval in a week 19:31:47 #link https://review.openstack.org/213295 19:31:50 anyways I am reading the zanata file and I am not sure I understand what it is trying to tell me 19:31:55 so thats my feedback 19:33:00 anteaya, looking 19:33:12 yeah, i think more a more structured schema might help for the yaml. right now it's a little too extensible 19:33:32 clarkb: i get that carlos is working on a script, and then we need to run some stuff (which no one is working on) 19:33:38 feels more like a linked list of structs ;) 19:33:41 i also get that maniphest is danger-zone 19:34:09 anteaya, Clint does it generate into the docs or not yet? 19:34:18 asselin_: only if you run it by hand 19:34:44 Clint: i can point you to a couple example sphinx plugins where we autogenerate documentation from structured data and a script 19:35:04 fungi: sounds good 19:35:04 thanks, wilhelm, that's super helpful 19:35:04 Clint: i think the openstack/governance repo has some scripts that process yaml for inclusion into sphinx 19:35:19 the openstack/ossa repo too 19:35:38 jeblair: yah. mhu returned from vacation yesterday and is quite willing to help figure out the cauth->maniphest bit 19:35:59 haven't been keeping up, but what is the status of maniphest? 19:36:00 mordred: awesome! 19:36:28 ohh i see still waiting for cauth 19:36:32 zaro: current next step is "take mhu's cauth-openid work and figure out how to deploy it in front of maniphest 19:37:13 zaro: I believe the relevant openid support is now in cauth - we just need to actually do the integration work now 19:37:45 #link https://git.openstack.org/cgit/openstack/ossa/tree/doc/source/_exts 19:37:47 Clint: ^ 19:38:25 fungi: thanks 19:38:40 Clint: also... 19:38:42 #link https://git.openstack.org/cgit/openstack/governance/tree/doc/source/_exts 19:38:49 * Clint nods. 19:39:50 add your extension entrypoint to the conf.py in the parent directory 19:40:02 and it'll get run automagically 19:40:43 then you can reuse our existing documentation testing and publishing jobs 19:40:49 definitely sounds cleaner than what i was thinking 19:41:44 Clint, thanks, I'll add comments 19:42:40 also, on second look there is more structure in the pm yaml, i think it was just overwhelmed by having references and todo lists first, so maybe just a little reordering would help skimmability 19:42:51 Sure people know, but di-b is currently failing for ubuntu trusty dibs. If somebody won't mind looking at https://review.openstack.org/#/c/219199/ 19:43:44 pabelanger: there is a fix up 19:43:51 oh, I should poke people about that 19:44:02 fungi: yeah, i just sorted them all for uniform ordering without other considerations 19:44:44 that would be a key difference between machine-friendly and human-readable 19:45:12 anyway, i'll chuck some noise into a review comment. looks good so far 19:45:54 cool, i think we'll wrap it up this week then 19:45:58 thanks everyone! 19:46:05 #endmeeting