19:02:51 #startmeeting infra 19:02:52 Meeting started Tue Jun 16 19:02:51 2015 UTC and is due to finish in 60 minutes. The chair is jeblair. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:02:53 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:02:55 o/ 19:02:56 The meeting name has been set to 'infra' 19:02:59 o/ 19:03:01 Morning 19:03:01 #link agenda https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting 19:03:02 \o 19:03:05 o/ 19:03:10 #link previous meeting http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-06-09-19.01.html 19:03:12 o/ 19:03:14 o/ 19:03:14 o/ 19:03:25 o/ 19:03:30 hello infra! 19:03:32 hi 19:03:33 o/ 19:03:34 #topic Specs approval 19:03:46 we approved some specs last week: 19:03:50 #topic Specs approval: Shade (mordred) 19:03:50 #link shade spec http://specs.openstack.org/openstack-infra/infra-specs/specs/shade.html 19:03:50 #info shade spec was approved 19:04:19 with that we've documented the project direction for shade 19:04:44 and i have added SpamapS and Shrews (who is not here) to shade-core 19:04:45 yay! 19:04:51 \o/ 19:04:52 great 19:05:04 yay 19:05:07 #topic Specs approval: Puppet apply (mordred) 19:05:08 #link puppet apply spec http://specs.openstack.org/openstack-infra/infra-specs/specs/ansible_puppet_apply.html 19:05:08 #info puppet apply spec was approved 19:05:31 (i don't have anything to say about this, though i feel positively about it) 19:05:48 I am excited! 19:05:53 yay! 19:05:57 looking forward to ansible launcher 19:06:02 me too 19:06:26 this isn't actually assigned to anyone, though i think we all actually expect/believe that mordred is/will be working on it 19:06:47 i'd love to see puppet apply come to life 19:06:52 and get rid of puppetmasters 19:06:56 I think he will think about it from time to time 19:07:06 I plan to shadow development, i have a hack going local already :) 19:07:33 pabelanger: so maybe you and mordred should chat when mordred is on a higher-bandwidth device 19:07:41 (i believe he's currently on a phone in a cab) 19:07:58 jeblair, I don't have an issue with that 19:08:10 I assume we will also be quick adopters of that effort 19:08:15 oh, i am mistaken, this is assigned to mordred and nibalizer 19:08:21 yeah, that's why i didn't council +1 it. was uncomfortable with the idea of an approved spec with no assignee 19:08:22 sorry about that, it's the next one that's unassigned 19:08:24 nibalizer, yes, we need to be 19:08:29 the next one, right 19:08:35 I am arriving at the tel Aviv airport in fact 19:08:42 I'd actually like to see it as its own playbook but that is just me 19:08:47 pabelanger: so talk to mordred + nibalizer if you want to pitch in 19:08:49 (the launcher part) 19:08:54 pabelanger: ++ 19:08:58 I agree 19:09:24 #topic Specs approval: Puppet 4 preparation and testing (mordred) 19:09:24 #link puppet4 testing spec http://specs.openstack.org/openstack-infra/infra-specs/specs/puppet_4_prelim_testing.html 19:09:24 #info puppet4 testing spec was approved 19:09:24 jeblair, will do 19:09:33 yay 19:09:34 okay, so _this_ is the one with no assignee 19:09:34 yay testing 19:09:51 fungi: i sympathize with your concern... 19:09:59 right, i was cool with the spec as written, but abstained from the vote 19:10:04 I will not do much on this one any time soon 19:10:19 i think we certainly won't approve a priority effort spec without a point person 19:10:22 would love a human intetested 19:10:25 ++ 19:10:36 i'm sort of ambivalent otherwise... 19:10:53 this does seem like something that someone new to the project might be able to pick up and help on 19:11:03 so it seemed like it might be worth having it written and approved 19:11:13 "low-hanging spec" 19:11:15 i can work on this 19:11:17 * taron is curious, but doesn't have a good idea of what puppet testing even looks like 19:11:22 at any rate, maybe we avoid making policy for now; play it by ear, and see what happens? 19:11:31 ++ 19:11:36 should be fine 19:11:37 taron: figure out puppet first before you commit to testing 19:11:46 but also keep fungi's concern in mind and not go crazy with the non-assignee specs 19:11:51 crinkle: and that's cool :) 19:12:22 #topic Specs approval: Maniphest bug tracking (mordred) 19:12:23 #link maniphest spec http://specs.openstack.org/openstack-infra/infra-specs/specs/maniphest.html 19:12:23 #info maniphest spec was approved 19:12:26 well, after taron finishes the code search spec, that should provide ample introduction to puppet 19:12:33 fungi, taron: ++ 19:12:34 cool 19:12:36 yay 19:12:38 fungi: nods 19:13:10 i find that i would really like to use this asap for infra-cloud work 19:13:40 didn't zaro say he would look into standing one up? 19:14:16 well, mordred has a lot of work in progress/nearly completed on it 19:14:23 ah great 19:14:23 well, there is a demo one already running, but... yeah having one spun up from the puppet module would be swell 19:14:40 not sure what it's present status is 19:14:56 at any rate, i'm highly motivated to review its patches. just throwin' that out there. ;) 19:15:02 fungi, I don't mind firing up a puppet module, if one needs to be done 19:15:53 we have a puppet-phabricator module 19:16:06 right, I meant testing / debuging locally 19:16:09 my bad 19:16:09 ah ok 19:16:37 I am happy to work in it tomorrow with someone 19:16:45 it's ready for next steps 19:16:53 w00t 19:17:03 and I'm home tomorrow 19:17:10 even more w00ty 19:17:13 so I can work 19:17:30 #topic Specs approval: Puppet Functional Testing (nibalizer, crinkle) 19:17:30 #link puppet functional testing spec http://specs.openstack.org/openstack-infra/infra-specs/specs/puppet-module-functional-testing.html 19:17:30 #info puppet functional testing spec was approved 19:17:32 s/work/review/ 19:18:01 * mordred hands lifeless a somewhat unused entrecĂ´te 19:18:20 i think our first stab at this with puppet-openstackci is about ready to land 19:18:26 yea 19:18:27 could probably use another review 19:18:30 !!! yay! 19:18:31 mordred: Error: "!!" is not a valid command. 19:18:37 aw 19:19:00 #topic Specs approval: Host a code search service (taron, fungi, pleia2) 19:19:00 #link code search spec http://specs.openstack.org/openstack-infra/infra-specs/specs/code-search.html 19:19:00 #info code search spec was approved 19:19:03 we have some work to do around fully integrating zuul/zuul-cloner but I think jeblair is saying we can patch that in a bit later 19:19:35 i gather taron will be freed up from classes to work on this in another couple weeks 19:19:37 yay 19:20:00 just wanted to make sure we had some good guidance in place for the project 19:20:12 not sure there's anything else to add at this stage 19:20:28 I think that's it, she knows were to find us :) 19:20:31 besides thanks taron! 19:20:31 awesome, so we should not expect this to start in earnest for a little bit 19:20:46 * taron is free of it now, digging into go portions this week 19:21:04 oh even better! 19:21:06 oh! right, there was some upstream fixing/triage to do as part of it 19:21:32 anyway, ask questions in irc, point us at changes to review when it gets to that point 19:21:38 ++ 19:21:46 will do 19:22:02 we don't have any new specs ready for voting this week; but that's okay, last week will keep us busy for a while. 19:22:11 uhm, yeah 19:22:26 #topic Schedule Project Renames 19:22:27 there are some administrivia cleanup patches to existing specs which i'm unclear how those are handled 19:22:47 fungi: oh, yeah, er, poke me for aprv if i get behind? 19:22:58 we're definitely not going to vote on them formally or anything 19:22:59 jeblair: i'll take a look through them later today 19:23:25 we renamed some stuff, boy howdy 19:23:56 mad props to fungi and jeblair 19:24:09 though keystone already has a new rename on the way 19:24:09 fungi, jeblair, anteaya: Thanks for those renames! 19:24:14 yeah, nice work guys 19:24:33 related to this, i have proposed https://review.openstack.org/192016 19:24:42 probably could have gotten its own agenda item... 19:25:07 it's been an interesting discussion so far 19:25:15 but anyway, it's exploring the idea that there's not much difference between stackforge and big-tent-openstack, and we should retire the use of stackforge in favor of just having projects be in openstack 19:25:34 mostly, i want us to stop renaming projects as part of their development lifecycle because that just seems crazy to me 19:26:06 +1 19:26:09 not sure where it's going to go, but other options have been thrown out as well, such as "provisinal use of openstack namespace" etc 19:26:13 ++ 19:26:31 I support our non rename overlords 19:26:32 so i'm hoping that regardless of what final form it takes, we can stop renaming projects unless, you know, they need to be _renamed_ :) 19:26:57 per my review comment, i'd also love for this to provide additional impetus for clearing up the cla situation 19:27:11 ++ 19:27:52 fungi: yeah, considering we have "official" projects in infra without a cla, that's also weird. 19:28:14 agreed 19:28:43 anyway... er, we talked about shade-core membership already, so... 19:28:45 #topic Hosting for Manila service image (u_glide, bswartz) 19:29:03 u_glide1: ping 19:29:12 Hello folks! 19:29:25 I'm core team member of Manila project. We have created new sub-project manila-image-elements which produces a binary image in qcow2 format. This image is used by our devstack plugin and we need to host this image somehow. Is it possible to host this image as regular release on http://tarballs.openstack.org/ ? And does it have enough bandwidth? 19:29:26 Hello u_glide1! 19:30:05 i think/hope the answer to all is yes 19:30:09 this seems like the agent images we already build and host for... is it ironic? 19:30:14 trove? 19:30:16 yup 19:30:16 both? 19:30:30 is there an example of how others do this that we can simply copy? 19:30:35 so yes, there are some jobs already that publish images to tarballs.o.o. i think they are post jobs? 19:30:44 * SpamapS is having de ja vu 19:30:50 then we would want to get that image listed in devstack so that it is cached on our build nodes 19:31:04 SpamapS may be well-placed to provide guidance here too ;) 19:31:11 u_glide1: see jenkins/jobs/trove.yaml in project-config 19:31:11 that means that we wouldn't have to download it every time (but our images only update once per day) 19:31:29 AJaeger: thanks, looking 19:31:56 jeblair: caching sounds like an excellent idea 19:32:02 the middle ground is that devstack can perhaps download if what's hosted is newer than what's cached 19:32:37 It's probably worth seeing if the method devstack uses to download the image supports If-Modified-Since. 19:32:47 fungi: yeah (though that works better if it doesn't update too often) 19:33:09 jeblair: caching +100 19:33:13 so you get the extra download overhead until the next worker image update happens in nodepool, allowing you to fix blocking bugs in your jobs that might depend on an updated image 19:33:16 I presume our static hosting site would respond appropriately. 19:33:20 the qcow2 would be updated for every commit to the manila-image-elements project, but commits would be hopefully rare 19:33:26 (as a side note, i believe the list of images to cache should end up moving into DIB in project-config soonish; devstack is not really the right place anymore) 19:33:35 (but it's still currently devstack) 19:33:58 bswartz, fungi: that sounds reasonable 19:33:58 SpamapS: our static hosting site is currently filesystem-backed apache, so yes. eventually swift with some cdn, but probably still yes in that case? 19:34:05 agree, dib's caching is pretty strong on this front too. 19:34:16 fungi: CDN will definitely support IMS 19:34:27 I kind fo hope swift does. 19:34:40 i kind of would be surprised if it doesn't 19:34:47 for very large values of "kind of" 19:35:18 so anyway, it sounds like its more important that it find its way into the images 19:35:45 oh, also, how large is it? 19:35:53 u_glide1: ^ what he said. 19:35:53 ~300MB? 19:36:08 300 Mb 19:36:11 there's an effort to make it smaller but that's what it is right now 19:36:51 we are getting closser and closer to hitting the limit with this methodology; we may have to eventually switch to using per-region mirrors and _not_ local image caching. 19:37:08 that's not too much larger than http://tarballs.openstack.org/ironic-python-agent/coreos/ 19:37:27 (or at least, anything < X MB gets cached, anything larger gets on the per-region mirror) 19:37:28 but yeah, death by a thousand cuts 19:37:36 o/ 19:37:52 u_glide1, bswartz: does that cover your questions? 19:37:58 especially when some of our providers now only give us a 20gb filesystem 19:38:03 I dunno 19:38:12 yes, seems that we just should copy trove project config and that's it :) 19:38:12 jeblair: ++ to large in per region mirrors 19:38:30 I think glance and nova-compute will be more efficient at spraying bits onto compute nodes than local mirrors and vms will. 19:38:54 There may be some cognitive overhead in the image approach that I'm missing though. 19:38:57 thanks a lot guys! 19:39:01 yes 19:39:02 ty 19:39:15 SpamapS: definitely, but we're running out of space on the dsvm images we create 19:39:32 bswartz, u_glide1: you're welcome. thanks for asking. :) 19:39:44 SpamapS: small disk on flavors 19:39:57 jeblair: right, and as I think about it, the hit rate doesn't go up with more cached things, just the breadth of things that can be serviced, so I think the mirror approach does make more sense as we add more things. 19:40:17 yah 19:40:21 SpamapS: yep, and hopefully we can drive frequent jobs to use things that are cached 19:40:29 (i'm certain we can continue to cache cirros) 19:41:03 do I invoke Andrew's law if I say afs? 19:41:08 good point. having stats on what we mirror to tell us what's heavily used can provide us guidance on what to switch to local caches 19:41:18 fungi: ++ 19:41:19 mordred: i thought 'per-region mirror' was spelled 'afs' 19:41:27 jeblair: :) 19:41:41 #topic Mid-cycle (virtual) meetup (pabelanger) 19:41:49 * krotscheck makes a note to have everything javascript be spelled "AFS" 19:42:00 yeah, there's definitely no reason why a static file mirror shouldn't just be an afs volume mounted on the workers 19:42:07 mostly a simple question, if there is any need or upcoming mid-cycle meeting. 19:42:20 travel requests are being asked for 19:42:45 i've heard some good suggestions for things we might do that could reasonably benefit from in-person time: 1) hack on infra-cloud; 2) zuulv3. 19:43:08 as far as zuulv3 goes, i haven't gotten the spec in shape to be approved yet. 19:43:22 i mean, i'm optimistic and all, and i expect to do that this week. but that's just where we are. 19:43:45 I would be supportive of a mid-cycle for zuul v3 hackery. 19:43:52 I'm very interested in hacking on improving CI/CD of infra itself. 19:44:05 people _seem_ to be progressing on infra-cloud without being in the same room 19:44:11 i personally don't want to travel just for the sake of it, so i'd set a pretty high bar for what we want to do and why we need to be in person 19:44:19 my summer is largely spoken for already 19:44:39 jeblair, right. I agree with that 19:44:42 (my productivity drops when i travel) 19:44:46 i'm buying a house, and i expect that to make travel i haven't planned for yet a little more of a stretch for me 19:45:01 i'm also a big fan of virtual sprints 19:45:31 our team manages to do a good job with virtual sprints 19:45:37 i assume zuul v3 will progress pretty steadily once there's a spec formalized too 19:45:48 in-person sprint or no 19:45:54 i feel like we've had some good face-time with infra-cloud that put us in a good place to proceed offline for a while 19:46:24 and i lean toward saying we should not plan on meeting just for that, at least, unless we find it going off into the weeds and we need to redesign something to get it back on track 19:46:28 most of the key folks on infra-cloud are on the west coast, might be easier just to gather the few of us for a few days here than a larger infra meeting 19:46:32 but for the moment, we've got a roadmap and we just need to move 19:46:46 but I don't strictly see it as required right now 19:47:17 jeblair: concur that we have plenty to do that is clear and actionable offline on infra-cloud. 19:47:35 jhesketh was around earlier, but i don't see him now. i'll try to speak for him and say that getting together lets us overcome the timezone difficulty. 19:47:43 I'm in support of a mid cycle. It's perhaps a personal thing or maybe a time zone thing, but it's massively easier to maintain momentum working on something when you can turn to the relevant person and have them look over your shoulder 19:47:48 oh there he is! 19:48:02 jhesketh: hobart is an option? 19:48:33 maybe we should do more virtual sprints (or even mini-sprints) to help with at least the timezone part of that (if not the in-person part) 19:48:35 So with virtual sprints I'd like to see more hand over between timezones, but that's a tangent 19:48:48 i think that's a realistic expectation 19:48:52 jhesketh: I think that's something we can work on doing a better job of 19:48:56 ++ 19:49:09 anteaya: sure, but I think it makes more sense to be closer to the majority of people to reduce costs and increase attendance 19:49:16 jhesketh: :) 19:49:30 just love the view from your house 19:49:31 additionally, interest more apac people in infra so jhesketh isn't as lonely ;) 19:49:46 jhesketh, because I don't know, which TZ (location) are you based out of? 19:49:49 * jeblair moves west 19:49:56 Utc+10 19:49:58 jeblair: you'll get wet 19:50:07 jeblair: i hear french polynesia is lovely this^H^H^H^Hany time of year 19:50:39 and bora bora too, we have a user group there 19:51:14 but I don't know how active they are 19:51:18 * krotscheck thinks the productivity benefit of colocation may be offset by the relaxation benefit of the location. 19:51:30 this has sort of transitioned into the next topic 19:51:30 I'm okay with a sprint objective of margarita 19:52:00 I think the part lost with virtual sprints is pair programming which can be a great way of getting things done and helping each other out (not to mention learning) 19:52:03 my productivity massively increases proportional to my relaxation 19:52:14 jhesketh: you make a good point 19:52:47 jhesketh, i agree with you, the ones with different timezones have that more difficult, and sprints help with that 19:53:02 I think there is room for both virtual and physic sprints but I have a personal preference for physical 19:53:53 if you want to make it sydney, let me know and i'll get space at red hat. good view 19:54:02 it sounds like the contributors working on specific efforts might benefit from finding somewhere mutually agreeable to get together and focus on something for a few days or a week without it needing to be an official "team" event 19:54:08 So even aside from timezones I've had great success working on projects face to face with teams just in Australia. It helps create a focused environment and encourage that team work 19:54:17 There's specific sprint days at PyCon AU in August. 19:54:36 fungi: that might be a bit more manageable 19:54:51 krotscheck: indeed, those are great too! :-) 19:55:24 also, the pycon au point... if people find that they're going to be at a conference with collaborators on something, extend your stay a day or two to hack on whatever it is you're collaborating on 19:55:40 who's at pyconau and who's at oscon? 19:55:44 https://etherpad.openstack.org/p/pyconau-sprints 19:55:50 <-- pyconau 19:55:59 i'll be in pdx for oscon 19:55:59 i'll be at oscon and there are a couple days in there where i'm not spoken for 19:56:05 Extending on what fungi said, I think it's important for mid cycles to be very much optional 19:56:09 i'll also be in pdx for oscon 19:56:13 I'll be at pyconau 19:56:19 not strictly attending, but I'll be around oscon sat-tuesday (fly home wednesday afternoon) 19:56:27 I'll be in pdx for oscon too 19:56:28 But nothing else yet 19:56:34 pleia2: aww, you won't be there for my talk! ;) 19:56:34 pleia2: i was also considering the beer track 19:56:37 i'm on the hallway track for oscon 19:56:40 fungi: I know, sadness! 19:56:54 it's okay, i hear from the author that it'll likely be really boring 19:56:57 jhesketh, maybe the question is where are people going, and see what overlap there is for sprints 19:57:10 fungi: it'll be wonderful, I am actually quite sorry to miss it 19:57:23 i don't sell it very well 19:58:04 at any rate, it sounds like we are unlikely to have a formal general infra team meetup at this point 19:58:19 pabelanger: sure, so long as it's a good fit and people won't be burnt out from the conference to work for a week 19:58:28 but keeping the door open to virtual sprints, conference overlap, and more focused events 19:58:46 #topic Open discussion 19:58:56 (not that it wasn't already, but hey we have 2 mins left) 19:59:09 what's the status of Zanata integration? 19:59:43 mrmartin: still hacking away at it, StevenK is working on the import scripts we'll use and I'm in the process of fixing a restart bug with our puppet module 20:00:01 great, thnx 20:00:04 still aiming for having a test instance to the i18n team with current translations imported by early july 20:00:10 thanks everyone! 20:00:14 #endmeeting