19:00:39 <jeblair> #startmeeting infra
19:00:40 <openstack> Meeting started Tue Aug 25 19:00:39 2015 UTC and is due to finish in 60 minutes.  The chair is jeblair. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:00:42 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:00:43 <jesusaurus> o/
19:00:44 <jeblair> #link agenda https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting#Agenda_for_next_meeting
19:00:44 <jeblair> #link previous meeting http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-08-18-19.01.html
19:00:46 <openstack> The meeting name has been set to 'infra'
19:00:50 <jeblair> #topic Specs approval: Host Stackalytics Service
19:00:51 <ianw> o/
19:00:53 <rbradfor> o.
19:00:53 <vkmc> o/
19:00:59 <jeblair> #link Host Stackalytics Service spec https://review.openstack.org/#/c/187715/
19:01:27 <jeblair> pabelanger: put this on the agenda i believe
19:01:35 <anteaya> he did
19:01:42 <zaro> o/
19:01:51 <jeblair> i'm not entirely clear on where we are with mirantis and stackalytics.org
19:01:53 <tchaypo> \o
19:02:01 <anteaya> jeblair: they are all behind it last I heard
19:02:13 <anteaya> the patchset prior to the last has jaypipes +1
19:02:21 <anteaya> then it got removed for grammar fixes
19:02:22 <jeblair> cool, and the spec certainly says they are behind the idea of running it in infra generally at lesat
19:02:30 <anteaya> time to merge
19:02:34 <jeblair> anteaya: i think we can mentally carry that over
19:02:40 <anteaya> I'm for that
19:02:53 <jeblair> so yeah, it does seem like this has been discussed and revised appropriately and is ready for voting
19:02:57 <jeblair> any objections?
19:03:17 <fungi> i'm not convinced default_data.json should move into openstack-infra/project-config but we can fine-tune when it gets to that point
19:03:47 <pabelanger> o/
19:03:53 <jeblair> fungi: oh good point.  that may want to be its own repo (we're collecting repos that are for data files)
19:04:16 <jeblair> but agree, it won't kill us if it is, and we can amend the spec with that improvement
19:04:57 <fungi> on the whole the plan looks sound
19:05:11 <jeblair> #info Host Stackalytics Service spec voting open until 2015-08-27 19:00 UTC
19:05:21 <jeblair> pabelanger: w00t!  thanks!
19:05:26 <hashar> o/
19:05:40 <jeblair> #topic Schedule Project Renames
19:05:40 <pabelanger> jeblair: np
19:06:00 <mordred> o/
19:06:18 <jeblair> i last wee sept 11 or 12 was tentatively suggested for the pre-summit renames of stuff already in the queue
19:06:36 <clarkb> those dates still work fo rme so +1
19:06:37 <pleia2> still works for me
19:06:38 <jeblair> er, you get the idea ^
19:06:57 <clarkb> slight preference for friday so I can weekend on the weekend
19:07:00 <fungi> i'm still good with that, so if there are more people behind the idea now that everyone's back from the ops mid-cycle, let's nail it firmly
19:07:10 <anteaya> that is the ironic mid-cycle which I won't be attending
19:07:17 <anteaya> those dates are fine with me
19:07:31 <jeblair> looks clear from a release mgmt pov
19:07:43 <jeblair> those dates are good for me, also slight pref for 11th
19:07:56 <clarkb> ya it should be after the milestone and before freeze crazyness
19:08:06 <mordred> I can do those days
19:08:08 <anteaya> oops Im wrong that ironic was in august
19:08:08 <mordred> no preference
19:08:14 <anteaya> no mid-cycle on those dates
19:08:19 <jeblair> lets do 11 then, objections?
19:09:06 <jeblair> and time -- 2300?
19:09:11 <anteaya> fine
19:09:11 <fungi> wfm
19:09:12 <clarkb> wfm
19:09:33 <pleia2> wfm
19:09:35 <anteaya> are we freezing the list to what is currently there?
19:09:43 <jeblair> #agreed next project renames on fri, sept 11 at 2300 utc
19:09:51 <anteaya> or can folks stuff more in, and if they can can we have a cut off date?
19:09:59 <pleia2> anteaya: it's still a couple weeks out, I think we can give some time
19:10:09 <anteaya> can we have a cut off date?
19:10:18 <jeblair> lets do just limit it to big tent projects though
19:10:28 <anteaya> I can agree to that
19:10:37 <jeblair> since this is still manual, it will take some work
19:10:45 <anteaya> things in goverance/projects.yaml then?
19:10:49 <jeblair> i don't want to deal with the stackforge flood without automation
19:10:55 <jeblair> anteaya: yeah
19:11:03 <fungi> yep. moving non-official projects from stackforge to openstack namespace should simply happen all at once. there's no urgency for those
19:11:04 <anteaya> works for me as a definition
19:11:33 <jeblair> #agreed moving official projects only; stackforge move will happen later (with automation)
19:11:53 <fungi> (with science!)
19:11:58 <jeblair> we also need to nail down the stackforge date...
19:12:04 <jeblair> what did we propose?
19:12:10 <anteaya> was going to ask you
19:12:15 * jeblair digs
19:12:25 <clarkb> I don't think we proposed oe for stackforge
19:12:37 <jeblair> oct 17 or nov 7
19:12:38 <anteaya> it was a date in october and one in nov
19:12:39 <fungi> we proposed two rough timeframes
19:12:41 <jeblair> is what i put in the email
19:12:42 <fungi> yeah
19:12:44 <clarkb> oh right form the email
19:12:46 <jeblair> no one expressed a pref
19:12:47 <clarkb> I was thinking last meeting
19:12:50 <anteaya> nov 7 I will be at pycon.ca
19:12:59 <anteaya> preference for oct 17
19:13:04 <fungi> i'm better with sooner rather than later, since there were no real objections expressed
19:13:08 <anteaya> though I may be chrismasing
19:13:17 <clarkb> ya earlier is probably better
19:13:24 <clarkb> get it done in the quiet before the summit
19:13:33 <clarkb> then dont hae to worry about it when recovering from summitting
19:13:45 <pleia2> I'm traveling pretty much from oct 13th onward (for what feels like forever, since summit)
19:13:46 <jeblair> sounds good to me
19:14:09 <jeblair> pleia2: wave to mordred as you fly past each other
19:14:12 <fungi> that's <2 months though, so we need to create that wiki sign-up page pretty much immediately so that projects can't claim they didn't have enough time to find out and add themselves
19:14:19 * mordred plans waving at pleia2
19:14:19 <pleia2> jeblair: heh, right
19:14:22 <jeblair> fungi: agreed
19:14:30 <anteaya> fungi: very much so
19:14:49 <jeblair> so how about i set up the wiki page and send an announcement about oct 17th?
19:14:59 <pleia2> sounds good
19:14:59 <anteaya> sounds good to me
19:15:09 <fungi> you typed that faster than i could, so all yours! ;)
19:15:12 <jeblair> #agreed move stackforge projects to openstack oct 17th
19:15:22 <anteaya> how much down time will we need for that one do you think?
19:15:23 <jeblair> #action jeblair send announcement about project renames sept 11
19:15:31 <anteaya> the github changes will take for ever
19:15:32 <jeblair> #action jeblair send announcement about wiki page and stackforge move
19:15:56 <jeblair> anteaya: we could probably let the github changes lag behind on that one
19:16:04 <anteaya> oh okay
19:16:04 <jeblair> they will become eventually consistent
19:16:17 <anteaya> might want to include that bit in the announcement
19:16:31 <anteaya> to get infront of the tide hitting the channel
19:16:46 <fungi> well, if we want the renames/transfers in github to dtrt, then we likely need to make sure we disable replication to there until we finish that part
19:16:47 <jeblair> anteaya: yes, though perhaps in a later announcement when we know more about the actual mechanics?
19:17:00 <anteaya> jeblair: yep, as long as I have something to point to
19:17:03 <jeblair> fungi: i don't think it'll hurt
19:17:06 <anteaya> don't care when
19:17:23 <jeblair> fungi: some replications will just get rejected if the repos have the wrong names
19:17:27 <clarkb> fungi: it will just error
19:17:43 <jeblair> fungi: but then catch up later, and we can trigger a full run on completion
19:17:58 <fungi> oh, for some reason i thought manage-projects was going to create the "new" repos there
19:18:10 <clarkb> fungi: oh hrm it will do that
19:18:21 <clarkb> so it just dependso nwhether or not we need the github redirects
19:18:22 <fungi> so just trying to remember to account for that
19:18:30 <fungi> but not a plan we need to hash out in this meeting
19:18:34 <anteaya> perhaps a meeting agenda item for automated rename planning?
19:18:35 <jeblair> yeah, i bet we can work out a way :)
19:18:37 <mordred> fungi: ++
19:19:08 <jeblair> cool, moving on then
19:19:12 <jeblair> #topic Priority Efforts (Migration to Zanata)
19:19:39 <pleia2> so, we're in a great spot, the translators are planning on using Zanata for Liberty translations :)
19:19:47 <jeblair> woohoo!
19:19:47 <mordred> pleia2: w00t!
19:19:50 <anteaya> yay
19:19:50 <fungi> i've seen much recent traffic on the i18n ml about this
19:20:03 <pleia2> I have one last review up to fix our installation process: https://review.openstack.org/#/c/192901/
19:20:13 <pleia2> then we should be ready to launch our production server at translate.openstack.org
19:20:31 <anteaya> yay
19:20:35 <pleia2> if we can do that by the end of the week, next week can be spent making sure all our scripts are still working as expected, and do a hand off to the translations folks after labor day
19:20:41 <clarkb> StevenK also has a handful of changes related to automagically configuring zanata fo rprojects that get translated
19:20:51 <clarkb> I hvae reviewed the stack would be good if some other cores could get through those
19:20:55 * jeblair does happy dance
19:20:58 <fungi> pleia2: not being familiar with the db schema complexity in zanata, i was somewhat dubious of the "copy all the tables from the dev server" approach
19:21:04 <pleia2> we also need some details from Carlos about importing the user directory out from the -dev instance so they don't need to set all that up again
19:21:09 <fungi> is that going to be as simple as it was made to sound?
19:21:18 <pleia2> fungi: me too, I kept resisting, they all insist, so I'm leaning on Carlos for a solid plan
19:21:46 <pleia2> adding coordinators and users is actually a pain for the users, so I sympathize
19:22:27 <pleia2> unfortunately I have some unexpected travel next week, so I'm going to put all this into an email to openstack-infra so we can make sure we have a plan
19:22:42 <clarkb> and I am happy to cover for pleia2 again
19:22:47 <clarkb> as I mostly have a picture of what is going on now
19:22:48 <pleia2> and I can check in next week if needed
19:22:51 <pleia2> thanks clarkb!
19:23:00 <SpamapS> greghaynes: ah, the problem is that dnsmasq is binding to eth2.25 and not eth2 for some reason
19:23:03 <SpamapS> oh doh
19:23:07 <SpamapS> hah.. misconfigured, thats why
19:23:22 <jeblair> SpamapS: also mis-channeled :)
19:23:31 <pleia2> so we've got a little work to do, and only a little bit of time, but I think it's all doable
19:23:48 <jeblair> pleia2: cool, zanata reviews to the top of the list then
19:23:48 <anteaya> pleia2: nice work carrying this all through
19:23:52 <SpamapS> dohhh soo sory
19:23:54 <pleia2> jeblair: thanks
19:23:56 <jeblair> anteaya: pleia2 ++
19:24:50 <jeblair> #topic Priority Efforts (Downstream Puppet)
19:25:49 <jeblair> httpd module proved to have some races, difficult to fix. We propose to move to puppetlabs-apache instead (pabelanger, yolanda)
19:25:57 <yolanda_> so that raised these days
19:26:04 <yolanda_> when moving to httpd, some races are shown
19:26:23 <yolanda_> there have been some efforts to fix it, either on the httpd module or in the manifests using it
19:26:41 <clarkb> a couple things here, the races are simple to fix and moving to puppetlabs apache is not simple. I still have a strong preference for sticking with httpd module at least until it is possible to change modules then we can worry aboutswitching
19:26:42 <yolanda_> and this also raised the topic about why are we using a pretty old fork, and putting efforts on fixing that
19:26:46 <nibalizer> we didn't change anything in the module though, so I think these issues existed in the old apache module we were using
19:26:48 <clarkb> but it really isn't possible to switch yet
19:27:06 <clarkb> nibalizer: they did, I think we just tickled a puppet "bug" by changing the name hwich appears to have changed execution order
19:27:28 <yolanda_> clarkb, i agree that we cannot move in short, but have a plan to migrate
19:27:34 <crinkle> or this was happening before and we didn't notice becaues it's eventually consistent
19:27:39 <clarkb> crinkle: or that
19:27:39 <jeblair> hrm... one second
19:28:02 <nibalizer> so my thinking is we've upped our tetsing game and that has exposed the issue, not the fork
19:28:20 <jeblair> clarkb: can you quickly summarize the recent past and current issues here?  i'm slightly confused and am losing track of which modules are which and what we're doing :)
19:28:25 <yolanda_> yes, i agree it has always failed
19:28:28 <clarkb> jeblair: yup
19:28:28 <yolanda_> it works at second pass
19:28:32 <jeblair> (i'm hoping this will be beneficial for some other folks here too)
19:28:33 <fungi> nibalizer: i didn't find it through testing at all. i found it because i needed to deploy a new servert
19:28:54 <yolanda_> fungi, i have hit that several times downstream, but just fixed by re-executing puppet
19:29:03 <anteaya> jeblair: yes thank you
19:29:05 <clarkb> so the issue is that puppetlabs-apache completely removed the ability to ship in a complete working vhost template file. Instead you have to use a bunch of puppet dsl primitives to construct the vhost. This makes certain things like mod_rewrite extremely difficult to use and we use a lot of mod_rewrite
19:29:26 <asselin_> o/
19:29:27 <glauco_> I noticed this issue while writing acceptance tests for puppet-gerrit
19:29:29 <clarkb> our solution to this was keep using the old version of the module that lets us use it the way we want to under a new name so we don't conflict with third party modules that do use upstream apache
19:29:48 <pabelanger> my preference would be to fix race issue, so not to block people. In parallel start migration to puppet-apache again, while keeping everybody happy.
19:29:50 <yolanda_> clarkb, pabelanger had several changes that proved this could be easily solved, either writing a wrapper
19:29:53 <clarkb> now that we have renamed the module we find that mod installation doesn't happen before starting the apache service by default which leads to puppet apply races
19:29:55 <yolanda_> or sending the patch upstream
19:30:02 <fungi> the basic races we've exposed: if you try to install configuration files into directories created by the apache package, you have to make sure the package is installed before you do that. if you want to activate vhosts which depend on certain default-disabled apache modules, you have to make sure those modules get enabled before the vhost configuration is applied
19:30:04 <clarkb> you can easily fix this with require/before in your code that uses the apache module
19:30:18 <clarkb> fungi: right
19:30:23 <yolanda_> clarkb, it means fixing all of our manifests
19:30:29 <jeblair> we used to call our fork puppet-apache, now we call it puppt-httpd, and both of those have that problem (inheritied from the old thing we forked from), yeah?
19:30:30 <yolanda_> + adding some documentation about this usage
19:30:39 <yolanda_> while we have alternatives that work from scratch
19:30:57 <clarkb> jeblair: the old puppet-apache wasn't really a fork just an older checkout and yes according ot crinkle and nibalizer the bug likely existed in both places
19:30:58 <yolanda_> jeblair, yes
19:31:10 <clarkb> we are noticing it more now with testing
19:31:24 <jeblair> awesome, i think i am caught up, thanks!
19:31:46 <nibalizer> clarkb: thanks for explaining
19:31:48 <fungi> however i wasn't seeing this issue prior to the module rename, so suspect that puppet happened to be getting lucky and arbitrarily picking the working order before and is now picking a non-working order
19:31:57 <jeblair> fungi: oooh
19:32:05 <yolanda_> fungi, i saw that downstream when spinning new modules
19:32:07 * anteaya is also actually able to follow along
19:32:07 <jeblair> we can't fix this in the module
19:32:09 <jeblair> ?
19:32:28 <jeblair> like, have httpd::module have the correct requirements?
19:32:30 <nibalizer> jeblair: there are a few ways forward
19:32:38 <jeblair> cool, let's enumerate
19:32:40 <nibalizer> but no clearly best option
19:32:48 <yolanda_> jeblair,httpd_mod is a custom puppet type, so it will need some extra work
19:33:01 <nibalizer> 1) fix it in the module itself by hacking the type
19:33:14 <nibalizer> 2) put require => Service['httpd'] around our puppet code where necessary
19:33:21 <crinkle> s/require/before
19:33:24 <fungi> i think the various proposals are: 1. fix it in each module which uses openstackinfra/httpd; 2. fix it in openstackinfra/httpd; 3. get puppetlabs/apache working (perhaps by submitting the support we need for our workflow or perhaps by making a shim/wrapper module)
19:33:25 <nibalizer> yes sorry
19:33:41 <nibalizer> 3) Create a httpd::mod defined type that wraps httpd_mod and adds the before
19:33:51 <yolanda_> there was a proposal already written by glauco here https://review.openstack.org/216436
19:34:06 <nibalizer> 4) Pivot to later puppetlabs-apache module
19:35:14 <nibalizer> I have some opinions on which ones I like the most, I think others do as well
19:35:34 <fungi> i guess nibalizer's 1, 2 and 3 are sub-options of my #2
19:36:24 <pabelanger> Can we take working code from puppet-apache, back port into puppet-httpd?
19:36:25 <nibalizer> fungi: no my #2 is your #1,  and my 2 and 3 are sub-options of your #2
19:36:25 <jeblair> regarding nib.4 and fungi.3, wasn't there some resistance upstream to the 'dump a vhost' model?
19:36:31 <yolanda_> option 1 means hiding a problem on the module, you need to fix all the manifests, and make new manifest using that to work in the same way. I'd expect , when i use a module, that i can rely on the features, without having to know the internals of it
19:36:55 <pabelanger> this leave simple migration path to puppet-apache, vs us creating our own custom path
19:37:07 <crinkle> jeblair: I am pretty sure they would accept that patch if it's not already in there
19:37:14 <jeblair> so does that mean that to use puppetlabs apache, we either try to convince them, or start using the module the way they intend (which may be a great amount of work for us)?
19:37:19 <jeblair> crinkle: oh ok
19:37:34 <fungi> anyway, since the numbers are now confusing... the objections to fixing it in each calling module is obviously code duplication. the objections to fixing it in openstackinfra/httpd are mostly that it's throwing good money after bad/reinventing the wheel. the objections to switching to puppetlabs/apache are that we suspect it still doesn't do the things we need
19:37:34 <crinkle> pabelanger mentioned using custom_fragment which might be what we need
19:38:06 <crinkle> fungi: also that switching to puppetlabs/apache will take a while and we want a fix soon
19:38:09 <nibalizer> I think this is being brought up as a critical flaw, which I disagree with
19:38:18 <jeblair> i feel like fixing it in openstackinfra/httpd is throwing a small amount of good money after bad, and outweighs the other two.
19:38:20 <clarkb> crinkle: I looked into that back when I was told "just use custom fragment" and I wasn't happy with it
19:38:21 <nibalizer> the nature of puppet is needing to establish your before/after
19:38:22 <yolanda_> jeblair, fungi, even if we use puppetlabs-apahce the way they like, it shouldn't be complex, creating  a wrapper and using some features it offers, pabelanger had a decent sample
19:38:30 <clarkb> I like treating files as files in puppet
19:38:39 <clarkb> nibalizer: agreed
19:38:49 <crinkle> what about custom_fragment => template('my template')
19:38:59 <clarkb> crinkle: you can't because then you lose all the header stuff
19:39:02 <jeblair> clarkb, nibalizer: is that an argument for doing before in our leaf puppet modules?
19:39:03 <crinkle> clarkb: okay
19:39:05 <clarkb> crinkle: its very opinionated or was when I looked at it
19:39:12 <clarkb> jeblair: yes
19:39:15 <nibalizer> jeblair: yes
19:39:25 <fungi> right, we want it to be able to replace the entire vhost config with a template and not make decisions for us
19:39:39 <nibalizer> most puppet resources don't automagically position themselves in the graph, I'm not sure why we're so suprised this doesn't
19:39:40 <yolanda_> here, that's pabelanger sample https://review.openstack.org/#/c/216747/
19:39:52 <pabelanger> Honestly, I still don't fully understand what puppet-httpd provides that puppet-apache doesn't do.  I _think_ the custom_fragment is what people are looking for but it would be good to list some place what people actually want.  I think some people want a blank vhost.conf file that apache will load out side of puppet control?
19:39:55 <yolanda_> uses custom_fragment + template
19:39:56 <jesusaurus> i think that being explicit and adding befores where they are needed is the puppet way of doing things
19:40:01 <clarkb> the red in https://review.openstack.org/#/c/216747/2/modules/openstack_project/templates/grafana.vhost.erb is the problem
19:40:03 <clarkb> yolanda_: ^
19:40:18 <crinkle> pabelanger: i think clarkb just explained why custom_fragment is insufficient
19:40:28 <jeblair> clarkb, nibalizer: in general i agree... i guess it boils down to specifics; if we use mod_rewrite in our vhost, we need to specify that, but i think that if we say we use mod rewrite in puppet, then the httpd puppet module should know to install httpd first.
19:40:47 <yolanda_> jeblair ++
19:40:50 <mordred> jeblair: ++
19:40:54 <clarkb> thats fair
19:41:06 <fungi> jeblair: well, the problem that arises is that it currently tries to apply the vhost configuration before it has enabled mod_rewrite
19:41:32 <fungi> so not specifically a race around the httpd service
19:41:40 <jeblair> fungi: that sounds like a module bug to me; i think all mod enablement should happen before writing vhost config
19:41:59 <yolanda_> fungi, jeblair, that is fixed in the puppelabs-apache , adding a notify apache::service, that restarts on each vhost or mod change
19:42:37 <jeblair> yolanda_: yeah, it just sounds like a simple fix to our module to clear these errors, so why not do that first?
19:42:38 <fungi> but we have other unrelated ordering issues too, such as we were previously relying on the apache2 package to create /etc/apache2 and its subdirectories, but didn't require that package or the module before trying to stick files into them
19:42:42 <nibalizer> jeblair: that doesn't really jive with most of puppet
19:42:57 <nibalizer> consider that if you would like a user and an ssh key you do have to explicitly set the ordering there
19:42:58 <yolanda_> jeblair, that's what glauco tried on his patch, but it's a fix on ruby
19:42:59 <jeblair> nibalizer: that's unfortunate, because that's how you admin apache
19:43:06 <yolanda_> our httpd_mod is a custom puppet type, not a defined type
19:43:09 <yolanda_> so people were not trusting it
19:43:25 <clarkb> yolanda_: right so my suggestion ws use a defined type
19:43:31 <nibalizer> jeblair: puppet allows you to do this of course, but the idea is to put the ordering in control of the operator, and not auto-figure-it-out
19:43:32 <fungi> so some of my concern is that we have multiple bugs exposed here, and people are focusing on one or another and each may need to be solved in different ways or even different places
19:43:47 <yolanda_> clarkb yes, and that's when conversation raised about putting efforts there, or moving to apache
19:43:48 <clarkb> I explained why the other implementation is likely buggy but not one seems to understand the puppet internals enough to confirm (which is a good reason not to do it on its own)
19:43:51 <nibalizer> everywhere in infra, we tend to want puppet to do less, and we'll tell it what to do, so I'm somewhat suprised we want puppet to be clever here
19:43:52 <pabelanger> fungi: !
19:43:56 <crinkle> I'm also pretty sure glauco_'s patch doesn't work, based on the result of the beaker test
19:44:00 <yolanda_> we are also hitting some problems on our fork, so we should consider if the effort is needed
19:44:30 <jeblair> nibalizer: there's never a reason to enable a module _after_ restarting a configuration with a new vhost
19:44:38 <glauco_> crinkle: it worked fine with ubuntu trusty. Not sure why it failed for centos.
19:44:58 <jeblair> nibalizer: that's something that the module should handle for you, because it is a very well understond ordering of operations that has only one correct answer
19:45:22 <nibalizer> jeblair: sure
19:45:24 <jeblair> nibalizer: i agree, anytime it is unclear, users should be allowed to express options
19:45:31 <jeblair> i think we may need to go to the ml on this
19:45:39 <nibalizer> there are currently two patches proposed to httpd to enable that functionality
19:45:53 <jeblair> nibalizer: can you send a summary email to the list with options, and we can try to further refine?
19:45:57 <fungi> well, more to the point, configuration (vhosts or otherwise) and enabling modules should be done and any service restarts deferred until that has all completed
19:46:00 <nibalizer> sure
19:46:28 <jeblair> #action nibalizer send summary email of puppet apache issues to infra list
19:46:40 <jeblair> (i picked nibalizer since he enumerated the options so well earlier :)
19:46:53 <anteaya> nibalizer: nice enumeration
19:47:16 <jeblair> thanks all, hopefully this was a useful start
19:47:17 <jeblair> #topic Summit space (jeblair)
19:47:29 <anteaya> goodness that time again?
19:47:32 <jeblair> ttx would like to know like right now what we need in terms of summit space
19:47:33 <anteaya> already?
19:47:47 <fungi> all of it
19:47:50 <anteaya> a table on a deck
19:47:56 <anteaya> with umbrellas
19:47:58 <jeblair> i know dhellmann has at least one session he wants to propose
19:48:01 <anteaya> and baby geese
19:48:28 <jeblair> and devananda suggested maybe we could share a meetup space and do some cross-pollination with ironic/bifrost since we're infra-cloudy
19:48:35 <pleia2> I think our working group times were valuable (particularly for me working with newcomers), so space for that again would be nice
19:48:41 <jeblair> anyone else have a feeling for what we should request?
19:48:51 <jeblair> pleia2: ack
19:48:57 <fungi> can you summarize the format/options this time around? is it fishbowls and boardrooms again, or something new this time?
19:48:58 <anteaya> asselin_: do you need a space for openstackci this time?
19:49:19 <pleia2> I'll likely work with translator sessions again, no no needs on the infra side
19:49:19 <jeblair> * Fishbowl slots (Wed-Thu)
19:49:20 <jeblair> * Workroom slots (Tue-Thu)
19:49:23 <jeblair> * Contributors meetup (Fri)
19:49:31 <nibalizer> a puppety workroom slot would be great
19:49:48 <jeblair> also
19:49:48 <jeblair> - We have about twice as many workrooms than we have fishbowls
19:49:48 <jeblair> - We have less rooms compared to Vancouver
19:49:49 <jeblair> - Rooms (especially workrooms) are generally smaller
19:49:49 <jeblair> - We have a lot more teams asking for space, thanks to the Big Tent
19:49:53 <asselin_> anteaya, I was hoping to talk about common-ci. Not sure if my official presentation got accepted or not. If not, then yes it would be nice to do that still.
19:50:14 <jeblair> so that's nice: it sounds like we like workrooms and we're workroom heavy
19:50:15 <anteaya> can we pencil in a time for asselin_ and friends?
19:50:34 <jeblair> anteaya: let's just throw out ideas here, and i'll collect them and try to summarize space needs generally
19:50:41 <fungi> okay, so workrooms will probably need their topics better scoped this time. we had a lot of random people glom onto our workgroup sessions in vancouver which tended to make them less productive
19:50:42 <anteaya> very good
19:50:48 <jeblair> i think we need to estimate first, then maybe get detailed later
19:51:06 <clarkb> space to hack on zuulv3 details may be useful
19:51:06 <anteaya> other than supporting asselin_'s efforts there isn't anything I personally am working on that needs a space
19:51:06 <pabelanger> likely remote this time, so fat pipe to asterisk server works for me :)
19:51:25 <jeblair> fungi: yah, and related to what pleia2 said, we may want to try to focus something on newcomers
19:51:32 <ttx> I liked the "get something done in 40 min" concept
19:51:44 <ttx> although unsuccessful
19:51:48 <fungi> ooh, right. infra 101 tarpit/honeypot ;)
19:51:58 <jeblair> ttx: we got it done the next week and it is now awesome :)
19:52:00 <anteaya> ha ha ha
19:52:39 <anteaya> infra 101 would be great to get reps from each project to make sure they understand how to set up tests
19:52:43 <anteaya> adn read logs
19:52:54 <anteaya> at least someone from each project
19:53:00 <fungi> yeah, irc meeting management in code review was a success, so a great example we can try to match for scoping the next round of ideas
19:53:07 <jeblair> anteaya: in that case, should probably be a x-project session
19:53:22 <anteaya> I can get behind that
19:53:29 <jeblair> okay, let me know if you have other ideas
19:53:31 <jeblair> #topic Request to use cloud server for developer.rackspace.com rather than Cloud Sites (annegentle)
19:53:34 <anteaya> as long as people leave with something useful
19:53:37 <jeblair> annegentle: around?
19:54:27 <fungi> i assume the idea here is moving the developer.openstack.org site to a vhost on static.openstack.org (or to a separate server completely)
19:54:42 <fungi> but having the reasons explained would be great
19:55:16 <clarkb> I know we wanted to swift host these things and we probably can with with we know about swift now
19:55:29 <jeblair> clarkb: actually we did not want that
19:55:31 <clarkb> since we can generate indexes for the entire paths of docs (but we don't for logs and that is the remaining work item there)
19:55:33 <clarkb> jeblair: oh?
19:55:34 <fungi> also, there are challenges around the scp publisher plugin... its support for layout is not identical to what you can do with the ftp publisher
19:55:52 <jeblair> clarkb: http://specs.openstack.org/openstack-infra/infra-specs/specs/doc-publishing.html is pending completion of swift logs
19:56:03 <jeblair> clarkb: but we actually can't use swift for serving things.
19:56:06 <jeblair> fungi: yeah
19:56:21 <clarkb> jeblair: right apache would proxy like with the logs
19:56:27 <jeblair> so we _can_ move them, but it's not clear to me that it would be better than ftp at this point
19:56:33 <clarkb> jeblair: I am saying that we can do that now the work required for docs should be complete
19:56:41 <jeblair> clarkb: ok, but that's still not the plan we wrote :)
19:56:45 <jeblair> clarkb: feel free to amend :)
19:56:53 <clarkb> I must be misremembering then will reread
19:57:06 <fungi> yeah, the current spec is filesystems (maybe afs)
19:57:08 <jeblair> clarkb: it's complicated, fortunately, at least the spec captures all the reqs
19:57:22 <fungi> and rsync if memory serves
19:57:31 <jeblair> fungi: could pivot to afs, but afs isn't in the current plan either; basically rsync.
19:57:39 <clarkb> did we change it? I swear it was swift based when it started
19:58:04 <jeblair> clarkb: it hasn't changed in a while :(
19:58:10 <fungi> swift is a middle-man
19:58:15 <jeblair> yep
19:58:38 <fungi> so while the spec is "docs publishing via swift" it's not serving them from the copies in swift
19:58:49 <jeblair> annegentle: maybe post to the infra list?  we'd love to help but don't know the problem.  :)
19:58:54 <jeblair> #topic Open discussion
19:59:04 <pabelanger> Haha, 1 min
19:59:09 <pabelanger> going to point my stuff into -infra
19:59:10 <jeblair> use wisely
19:59:13 <pleia2> elections are coming up and I can't commit to help tristanC running them this time around, don't need to have special powers (fungi pulls data for us), just need to pay attention and be responsive about election things, happy to answer questions abut it but it's coming up soon
19:59:44 <pleia2> election schedule is on the release schedule: https://wiki.openstack.org/wiki/Liberty_Release_Schedule
19:59:46 <SpamapS> o/ just saying infra-cloud is ho-humming along, still fighting hardware issues but getting closer at least. :)
20:00:07 <jeblair> SpamapS: woot!
20:00:09 <jeblair> thanks all!
20:00:11 <jeblair> #endmeeting