19:01:02 <jeblair> #startmeeting infra
19:01:03 <openstack> Meeting started Tue Feb  3 19:01:02 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:04 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:01:06 <openstack> The meeting name has been set to 'infra'
19:01:16 <ianw> o/
19:01:23 <jeblair> #link completely unverified agenda https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting
19:01:31 <jeblair> #link previous meeting http://eavesdrop.openstack.org/meetings/infra/2015/infra.2015-01-27-19.06.html
19:01:46 <fungi> we can have a completely unverified meeting to go along with it
19:01:59 <jeblair> #topic Actions from last meeting
19:01:59 <mordred> o/
19:02:10 <jeblair> i'm going to skip zaro's action item and talk about it later...
19:02:13 <jeblair> but project renames!
19:02:14 <jhesketh> Morning
19:02:15 <jeblair> were done
19:02:31 <fungi> yep
19:02:32 <mordred> woo!
19:02:41 <jeblair> did anyone write an oslo.version patch for governance?
19:02:43 <fungi> we attic'd those projects something fierce
19:02:50 <fungi> i did not, but will now
19:02:51 <jeblair> i saw annegentle wrote one for the api projects
19:02:57 <jeblair> fungi: cool, thx
19:03:21 <jeblair> #topic Priority Efforts (Swift logs)
19:03:27 <yolanda> hi
19:03:52 <jeblair> i think the partial console download problem is solved, yeah?
19:03:56 <clarkb> yup
19:04:10 <jeblair> and we're dogfooding a devstack job now
19:04:25 <jeblair> clarkb found and jhesketh fixed a ux problem with the sorting in the index
19:04:41 <clarkb> has the sort change merged yet? I need to review it if now
19:04:44 <clarkb> s/now/not/
19:04:57 <AJaeger> clarkb: https://review.openstack.org/152346
19:04:57 <jeblair> so next steps are to merge that, wait for image updates, check it out, and then maybe roll out to more jobs?
19:05:02 <jeblair> #link https://review.openstack.org/152346
19:05:04 <nibalizer> o/
19:05:07 <AJaeger> clarkb: not merged
19:05:26 <clarkb> jeblair: I think possibly remove old school logging from the dg tempest jobs to rely only on the swift logs
19:05:35 <clarkb> jeblair: and that can happen while we roll out to other jobs too
19:05:35 <jeblair> clarkb: ok
19:05:38 <jhesketh> +1
19:06:18 <jeblair> cool, anythig else for swifty logs?
19:06:38 <jhesketh> Also I'd like to thank clarkb for all his hard work finding bugs, fixing things and rolling out new images as we've been working on it for the last 6ish months!
19:06:44 <mordred> ++
19:06:50 <jeblair> (it feels like we're nearing the end!)
19:07:05 <AJaeger> yeah!
19:07:24 <jeblair> #topic Priority Efforts (puppet module split)
19:07:24 <clarkb> jhesketh: no problem, you did the hard stuff
19:07:25 <jhesketh> Yep, I think we're very close now. Just switching over and discovering edge cases
19:07:33 <jeblair> speaking of the end...
19:07:37 <pleia2> \o/
19:07:44 <jeblair> this is the last meeting for this topic!
19:07:56 <jeblair> asselin is on vacation, but says:
19:08:03 <jhesketh> (and other assets that aren't logs such as tarballs and docs)
19:08:05 <jeblair> "Sprint DONE, fun & successful! "
19:08:07 <pleia2> it was really great to use Storyboard for task assignments, I think it went really smoothly
19:08:16 <jeblair> "Huge thanks to everyone who helped submit patches, review, and prepare. "
19:08:20 <jesusaurus> pleia2: agreed
19:08:25 <jeblair> and i agree with him
19:08:29 <jeblair> and pleia2
19:08:36 <jhesketh> +1
19:08:51 * mordred is sad he missed it - but was really impressed seeing all the stuff happen
19:08:57 <nibalizer> ya its huge
19:09:10 <jeblair> i wonder if it would be worth sending an email to the list describing our experiences with virtual sprints
19:09:22 <mordred> totally
19:09:24 <jeblair> we've had 2 so far and i think they've been great
19:09:30 <pleia2> I can draft something in an etherpad
19:09:30 <fungi> and lack of need for videoconferencing ;)
19:09:36 <mordred> we invited midcycles - maybe we can help invent not-midcycles too
19:09:55 <jeblair> the third-party folks had one too for docs; we could ask them how theirs went
19:09:58 <mordred> ++
19:10:06 * pleia2 nods
19:10:07 <jeblair> (also, they probably came up with changes for us to review :)
19:10:18 <jeblair> pleia2: that would be cool, thanks!
19:10:22 <pleia2> yeah, they had a tag for their sprint too
19:10:23 <clarkb> they work really well. Probably good to just have everyone agree to focus on a specific task over a couple days
19:10:35 <jeblair> #action pleia2 draft summary email about virtual sprints
19:10:42 <clarkb> and have an organized way to go about it
19:10:50 <jeblair> i really like the #sprint channel
19:10:58 <jeblair> being able to ignore -infra is very helpful
19:11:33 <jeblair> i'd love it if we could figure out a way to make the gerritbot configuration for that easier
19:11:43 <dstanek> jeblair: i'd really like to hear about the virtual sprints so i can contrast it with my mid-cycle experiences
19:11:45 <jeblair> that's the only thing i thought was missing
19:12:15 <jhesketh> Agreed. I think some handover of a sprint between timezones is also quite helpful. I was able to help out a lot more on this one thanks to jeblair bringing me up to speed before logging off for the night
19:12:22 <jeblair> dstanek: ++
19:12:44 <jeblair> jhesketh: good point.  it's probably best to try to plan that out too.
19:12:54 <jhesketh> Yep
19:12:55 <jeblair> jhesketh: maybe instead of just signup, we should do signup with hours
19:12:57 <fungi> dstanek: my #1 favorite thing about virtual sprints... no sitting on airplanes
19:13:12 <dstanek> fungi: ++
19:13:21 <fungi> and #2, no staying in hotels
19:13:28 <pleia2> so probably have a "helpful tips" section, which includes having handoffs, clearing your schedule (ignore -infra) and using a gerrit topic for all changes
19:13:29 <mordred> jeblair: what about "gerritbot give me a sprint channel for X hours" - and it either hands you one or makes a new one
19:13:59 <fungi> gerritbot make me a sandwich^Wsprint
19:14:00 <jeblair> mordred: well we also have the #openstack-sprint channel logged, so that would be coordinated too
19:14:06 <mordred> yah
19:14:39 <jeblair> it's just that to put gerritbot in there currently means 2 (possibly substantial) changes to project-config
19:14:52 <jeblair> that might just end up being a wishlist item for gerritbot-next-gen
19:15:00 <fungi> i think if gerritbot ever gets a rewrite, yeah
19:15:19 <mordred> oh - yeah - I was thinking a gerritbotv2 feature
19:15:23 <jeblair> ah k
19:15:25 <fungi> register the list of project names associated with a given sprint (maybe as a regex)
19:15:31 <mordred> for an etherpad-like "give me a channel" thing
19:15:32 <fungi> anyway, fodder for a spec
19:15:38 <mordred> so you get #openstack-sprint-aslekn34
19:15:52 <mordred> or something
19:16:03 * mordred gesticulates wildly, then falls over
19:16:03 <jeblair> mordred: (chanserv registration mumble mumble)
19:16:07 <mordred> yeah
19:16:13 <jeblair> anyway
19:16:21 <jeblair> in summary for this topic; w00t
19:16:30 <mordred> #agreed w00t
19:16:39 <jeblair> #topic Priority Efforts (Nodepool DIB)
19:16:58 <mordred> the changes for rackspace config-drive have gone live
19:17:06 <fungi> mmmnodes
19:17:07 <mordred> so I can respin the dib elements related to that
19:17:19 <mordred> to consume that and do less crazy with xenstore api nova-agent things
19:17:39 <fungi> i'm still playing with and redesigning my thoughts on getting database configuration moved from image build time to job run time
19:17:41 <clarkb> I am working on figuring out why we build one devstack-precise/devstack-trusty node then upload each of those twice. Trying to replicate locally using fake providers without much luck so far and have some new logging that I will restart nodepool for after the meeting
19:18:10 <clarkb> so we have a few concurrent things going on here.
19:18:24 <mordred> cool. I also learned some things from notmyname about internals of swiftclient that I think we can use for more efficient uploads for that case
19:18:36 <fungi> also trying to think about how database setup fits in with more general convergence between teh devstack and bare image types (and how we should skin package caching/installation)
19:18:52 <mordred> fungi: I am in favor of said convergence
19:18:55 <clarkb> fungi: ++
19:19:26 <mordred> also - can haz shade reviews ... the current set are gnarly enough that I don't really want to add the keypair stuff on top until the current set is landed because _Sanity_
19:19:47 <fungi> though the database config work is at this point a prerequisite for being able to try running unit tests on debian/jessie (since we'd need to dib that in hpcloud, they don't provide base images for it like rax does)
19:20:00 <mordred> fungi: ++
19:20:09 <mordred> so we're still a few weeks away
19:20:45 <zaro> o/
19:21:11 <fungi> and debian/jessie interest in turn because it has a python 3.4 which is new enough to not have the same bugs as ubuntu trusty
19:21:22 <jeblair> this is looking really promising though.  i feel like we've wrapped our heads around quite a few things
19:22:06 <fungi> it's getting usable enough to fan out in parallel bug fixing/feature adding efforts now
19:22:12 <jeblair> ++
19:22:22 <mordred> ya
19:22:26 <fungi> rather than collectively figuring out how to make it work at all
19:22:44 <mordred> it's amazing how much freedom the "build base image from scratch " option gives us in problem solving
19:22:47 <clarkb> yup and other than the duplicate uploads I haven't really seen any issues
19:22:56 <clarkb> we missed one item in an element for a while that jogo fixed
19:23:06 <clarkb> mordred: its so much faster too
19:23:24 <mordred> once it's done, I think we need to take a pass through our elements and our puppet and probably refactor some stuff
19:23:33 <fungi> absolutely
19:23:37 <mordred> because it's a bit rube-goldberg right now - but it's good enough to not touch for the moment
19:23:45 <jeblair> and i expect fungi's work on image consolidation will help prep us for that
19:24:02 <fungi> at the moment it's more of a facsimile of our snapshot-based build process
19:24:10 <fungi> translated to dib
19:24:29 <fungi> so lots of opportuities for simplification and decruftifying
19:24:37 <clarkb> indeed
19:24:50 <fungi> opportunities too
19:24:54 <clarkb> also its probably worth noting that if anyone wants me to walk them through building a local image I am happy to do that
19:25:07 <clarkb> its super easy at this point and is potentially useful for testing security bugs and the like
19:25:16 <fungi> though perhaps an opportuity is where opportunity and tuits meet
19:25:28 <jeblair> and...
19:25:29 <jeblair> #topic Priority Efforts (Jobs on trusty)
19:25:43 <fungi> i think we can probably stop covering this one after this week
19:25:53 <jeblair> we are knocking them out! :)
19:25:54 <dstanek> clarkb: i'd like to learn. any chance you could screencast it?
19:26:06 <fungi> at least until it comes time to eol icehouse, but that's months out
19:26:08 <clarkb> dstanek: ya I can probably typescript record it
19:26:11 <mordred> dstanek: that's a great idea
19:26:14 <jeblair> clarkb: ooh, ooh, or live screencast it!
19:26:18 <mordred> ++
19:26:31 <fungi> i still have a handful of cleanup patches to rip out our py3k special snowflakeness
19:26:54 <jeblair> fungi: are they up for review?
19:26:56 <fungi> #link https://review.openstack.org/151715
19:27:03 <jeblair> (why, yes!)
19:27:08 <fungi> #link https://review.openstack.org/152215
19:27:21 <fungi> #link https://review.openstack.org/152217
19:27:27 <fungi> i think they need to merge in that order
19:27:36 <fungi> mordred just approved the one which needed to merge before them
19:28:01 <fungi> so should be safe to lift my -2 on 151715 soon
19:28:10 <jesusaurus> clarkb: i'd like that typescript as well
19:28:29 <fungi> <plug>zuul cross-repo dependencies would have been _very_ useful for this series</plug>
19:28:46 <fungi> though i'm thrilled that's almost a thing now
19:28:50 <jeblair> (zuul crd changes are up for review)
19:29:03 <fungi> yep, been reviewing. can't wait
19:29:17 <fungi> anyway, that's all i have for precise->trusty migration
19:29:26 <jeblair> #topic Priority Efforts
19:29:52 <jeblair> it would be great of folks could review the changes linked above
19:29:58 <jeblair> the meeting log will call them out easily
19:30:11 <jeblair> and next week, i think we are going to have some openings for new priority efforts
19:30:25 <mordred> ooh
19:30:26 <jeblair> so we can probably nominate some and discuss them then
19:30:33 <fungi> that'll be great
19:30:45 * clarkb puts an early vote in for zanata
19:31:04 <pleia2> +1
19:31:12 <mrmartin> I want to use zanata with groups portal
19:31:14 <mrmartin> so +1
19:31:19 <jeblair> yeah, that seems a shoe in :)
19:31:25 <pleia2> yeah, mrmartin and I talked about it some while at fosdem (hi mrmartin!)
19:31:31 <fungi> we could have cross-repo dependencies between zanata and groups changes ;)
19:31:38 <jeblair> fungi: nicely done
19:31:40 <mrmartin> hi, yeah, I can help in this zanata story
19:31:47 * mordred hands fungi a lovely goat
19:31:53 <fungi> lovely, lovely
19:31:54 <jeblair> #topic Upgrading Gerrit (zaro)
19:32:02 <jeblair> zaro: what's new?
19:32:11 <zaro> so i've tested the WIP plugin.
19:32:47 <zaro> it's not looking good for 2.9.x.  I've entered a few issues into the gerrit issue tracker for David O.  to look at.  he's already fixed some.
19:32:56 <fungi> also zaro wrote up a plan for moving from precise to trusty based on when he migrated review-dev last week
19:33:00 <fungi> #link https://etherpad.openstack.org/p/review-to-trusty
19:33:10 <zaro> but it requires changes in gerrit core which is only available on master
19:33:11 <fungi> we should think about when we want to do that
19:33:37 <zaro> ohh yes.  review-dev is already on trusty
19:33:50 <pleia2> nice
19:34:00 <zaro> that would be the 1st step towards upgrade actually.
19:34:12 <mordred> zaro: were there any issues with trusty? or was it pretty straightforward?
19:34:16 <fungi> i haven't torn down the old review-dev server yet, but will soon if nobody needs anything from it
19:34:51 <jeblair> zaro: that looks like an os upgrade combined with a gerrit upgrade, is that correct?
19:34:52 <zaro> No issues.  Just required new libs.
19:35:04 <zaro> yes, that is correct.
19:35:25 <jeblair> cool, i think that's probably fine
19:35:26 <clarkb> fungi: I don't need anything fwiw
19:35:32 <zaro> these are the new libs i'm refering to : https://review.openstack.org/#/c/151368/
19:35:57 * jeblair looks at https://wiki.openstack.org/wiki/Kilo_Release_Schedule
19:36:08 <fungi> i guess we could consider refactoring the work into two steps (move to trusty, upgrade to 2.9) with breathing room between to iron out new bugs we find
19:36:10 <jeblair> let's not do it this week.  :)
19:36:11 <zaro> been testing gerrit with zuul as well.  looking good so far.
19:36:33 <mordred> jeblair: NOW. DO IT NOW!!!
19:36:34 <zaro> been debugging zuul-dev, it's almost fixed.  zuul-merger seems to be having issues cloning from repo
19:36:36 <fungi> but yeah, we're getting close to busytime for the release cycle
19:36:53 <zaro> it's something to do with the ssh host key
19:37:21 <fungi> zaro: if it's the error message you pasted earlier, it's the client public key needing to get loaded into gerrit
19:37:31 <fungi> not the host key
19:37:47 <zaro> fungi: yah, i think you are correct.  jsut haven't had time to do it.
19:38:14 <jeblair> this weekend is probably too short notice.  people we like will yell at us if we do it next weekend.
19:38:34 <mordred> jeblair: there are people we like?
19:38:51 <fungi> i have travel for several weekends after that so probably won't be able to help during
19:39:14 * fungi double-checks calendar thingy
19:39:48 <mordred> weekend after next I'm booked - but other than that I'm actually back to the world of being able to help people with things
19:39:51 <fungi> yeah, i'm around for the next two weekends, then otherwise occupied for the three following
19:40:34 <fungi> but if i'm not around, i'm not around. feel free to do it without me
19:40:46 <pleia2> I'm busy this weekend and the next, then my schedule is quite clear for a while
19:41:03 <fungi> there's always another gerrit upgrade on the horizon, after all ;)
19:41:17 <jeblair> okay, let's take this offline for now
19:41:42 <jeblair> #topic (yamamoto) Portability question
19:41:47 <clarkb> and maybe consider not weekend but other off hours?
19:42:11 <jeblair> " I'm not sure if I can attend the meeting, sorry. I added this here as it's suggested that this needs wider audience."
19:42:12 <mordred> I have two concerns with the portability patches
19:42:17 <jeblair> " It's easier for me to be able to run "tox" tests on non-linux environments. "
19:42:27 <jeblair> "On the other hand, the gain of portability to platforms that OpenStack does not support is questionable."
19:42:32 <jeblair> "My suggestions "
19:42:37 <jeblair> " Do not refrain from using non-portable features when necessary"
19:42:40 <jeblair> " Accept best-effort changes to make it portable, unless they have significant drawbacks"
19:42:46 <jeblair> (end of quote)
19:42:54 <jeblair> #link https://review.openstack.org/#/c/150264/
19:43:12 <fungi> is this specific to the bash->sh portability changes?
19:43:12 <clarkb> my major concern initially was there was no accompanying info with why the changes were more protable, but that appears to have been fixed in newer patchsets
19:43:14 <mordred> k. that actually addresses one of my concerns - which is that _like_ using bash and dont' think that bourne shell compat leads to nice scripts
19:43:15 <fungi> #link https://review.openstack.org/#/q/owner:zhaoxinyu%2540huawei.com+status:open,n,z
19:43:18 <clarkb> fungi: and find args and so on
19:43:21 <fungi> k
19:43:39 <clarkb> mordred: that and bash is usually bash when you invoke bash. sh on the other hand is an non portable mess :)
19:43:39 <mordred> my other being that we don't have non-linux machiens, so I fear these would bitrot almost immediately
19:43:43 <mordred> clarkb: ++
19:44:02 <fungi> er, wrong link there, sorry
19:44:03 <mrmartin> freebsd supports bash
19:44:06 <mordred> that said - I don't have a problem with the nature of most of the changes (other than s,/bin/bash,/bin/sh,) on their merits
19:44:13 <clarkb> so its actually hard to know whether or not the sh you write is properly portable
19:44:14 <mrmartin> and OSX too
19:44:33 <fungi> #link https://review.openstack.org/#/q/status:open+project:openstack-infra/project-config+topic:portability,n,z
19:44:38 <ianw> this has come up with devstack too, zsh fixes for example
19:44:59 <ianw> my thinking is if the change is minimal then whatever makes peoples life easier
19:45:27 <fungi> tweaking devstack to run under zsh is a little more dubious i think
19:45:28 <ianw> but if it's worse code, then no.  for example replacing ${!expand-me} with tricks involving execs etc
19:45:31 <jesusaurus> clarkb: well, proper sh could be enforced with bashate
19:45:39 <mordred> ianw: ++
19:45:42 <fungi> i mean, what platforms are going to have zsh but no bash?
19:45:49 <sdague> jesusaurus: bashate doesn't do that
19:46:04 <mordred> we could always just rewrite all of our shell in perl ...
19:46:07 <fungi> bash8 --posix
19:46:33 <jeblair> https://review.openstack.org/#/c/150265/2/tools/run-layout.sh
19:46:37 <sdague> fungi: also, we don't really support zsh in devstack, we've let compat patches in for the openrc file so you can source openrc from zsh
19:46:38 <jeblair> i'm not certain that is not worse ^
19:46:39 <jesusaurus> sdague: not currently, but it is already opinionated, so it would become sh-opinionated
19:46:45 <jesusaurus> s/would/could
19:46:52 <fungi> sdague: okay, that makes slightly more sense
19:47:05 <sdague> jesusaurus: -2, it's not the purpose of the tool
19:47:13 <clarkb> so ya I think keep bash but find/mkdtemp etc changes are fine
19:47:27 <mordred> (the find | xargs is the pattern I usually use so it makes sense to me with slightly less thinking)
19:47:36 <clarkb> though I am super biased to gnu tools after living on solaris I don't mind if other people are making the fixes
19:48:11 <sdague> you also only get arrays in bash with bash4, which mac does not have
19:48:21 <sdague> which at least a few tools use
19:48:32 <AJaeger> sdague: indeed, the translation jobs do
19:48:34 <fungi> so, i can sort of see the case that developers hacking on patches for this stuff want to be able to test their proposed changes locally with minimal fuss, and maybe installing bash is effort, but still curious what platforms it's a burden on
19:49:17 <fungi> "non-linux environments" is a little unspecific
19:49:35 <fungi> there's nothing linux-specific about bash after all
19:50:03 <jeblair> without regular contributions from folks on non-linux platforms and testing, i don't think we can make any guarantees about this
19:50:14 <fungi> and "portability" is a slippery slope. i don't want to be reviewing 100 one-line changes to shebang lines and what have you
19:50:37 <jeblair> i do agree that portability patches are generally non-harmful, but we have way too many changes already, and i don't want to review them
19:51:11 <AJaeger> These are tests run in the gate - that's where they have to work.
19:51:13 <jeblair> since we will not be able to prevent non-portable things from sneaking in, we would probably be continually receiving patches to fix them
19:51:21 <AJaeger> The contributor wanted to run locally a tox -e XXX.
19:51:43 <AJaeger> That's something that should work in general - but I agree that we should use some sane defaults.
19:52:04 <AJaeger> ... or requirements.
19:52:20 <jeblair> so who is interested in supporting this effort by reviewing these changes?
19:52:35 <mordred> I could see a general rule that things called by tox could want a /bin/sh shebang line
19:52:38 <jeblair> (and future ones)
19:52:40 <mordred> since that's a specific bounded usecase
19:53:06 <jeblair> mordred: that just means you can run the script until the next error
19:53:06 <ianw> mordred: but can it assume a gnu toolchain?
19:53:11 <fungi> i am fine reviewing changes such as "this script uses bashisms but starts with a /bin/sh shebang line"
19:53:18 <mordred> but broadly across all the test of our bash- I think it's a no-go
19:53:23 <fungi> i consider that a bug
19:53:27 <jeblair> fungi: makes sense
19:53:36 <fungi> assuming "sh" is bash is an obvious portability problem
19:53:44 <AJaeger> fungi, agreed
19:53:45 <fungi> declaring "bash" is not
19:54:19 <AJaeger> mordred: I would support an exception for tox called scripts - but right now I think it's not worth the effort.
19:54:31 <AJaeger> This will bitrot soon again.
19:55:00 <jeblair> so i think it's worth giving the feedback that there is not a lot of interest from core reviewers to maintain compatability in the scripts themselves
19:55:13 <clarkb> its also worth noting that none of the software this tests is intended to run on OS X for example. We don't use portable python event polling in all places
19:55:21 <fungi> so it sounds mostly unanimous that without a clear mandate to support running our scripts under constrained environments, we should probably set expectations that we won't be reviewing that sort of improvement
19:55:21 <jeblair> clarkb: true
19:55:30 <clarkb> and so on, so I think that we may have already asserted you need a linux install
19:55:33 <fungi> yeah, agreed
19:55:53 <jeblair> okay, a few more mins for mrmartin
19:55:56 <jeblair> #topic  Askbot migration (mrmartin)
19:56:11 <mrmartin> ok, I just like to get a little care regarding this askbot migration
19:56:33 <fungi> on that note, i should order the replacement https cert for that today. it expires in a few weeks now
19:56:46 <mordred> fungi: ++
19:56:56 <mrmartin> so I like to ask somebody to dedicate himself to review the patches, but the larges part is that we need to create the new instance
19:57:11 <jeblair> mrmartin: we probably want to land all the patches first
19:57:28 <fungi> i can iterate on trying to boot the instance once the patches have made it through sufficient review (preferably approval)
19:57:28 <jeblair> once that's done, hopefully spinning up the new instance will be easy
19:57:32 <mrmartin> jeblair: right, it was there since december, and was splited up last week
19:57:43 <clarkb> making this a priority effort is probably a good way to stay on top of it
19:57:58 <jeblair> mrmartin: there are some jenkins -1 votes on those
19:58:16 <mrmartin> so after instance creation, we need to backup the existing site and restore in new instance
19:58:26 <mrmartin> jeblair: yes, due to a puppet-module dependency
19:58:34 <mrmartin> need to approve the puppet-solr module first
19:58:52 <mordred> sounds like a job for the new depends-on code
19:59:02 <fungi> mrmartin: i can definitely dump/import the data as long as i know where it goes and what should be run to load it
19:59:33 <fungi> mrmartin: so maybe some minimal documentation around that would be helpful if you haven't written such a thing already
19:59:33 <mordred> it does sound liek this might want to join zanata as a priority effort next week
19:59:33 <mrmartin> so, as it is a high traffic site, I like to see a silent pilot period before we move the dns zones
19:59:44 <jeblair> #link https://review.openstack.org/140043
19:59:50 <jeblair> #link https://review.openstack.org/151912
19:59:51 <fungi> mrmartin: that seems reasonable
19:59:57 <jeblair> #link https://review.openstack.org/151910
20:00:15 <mrmartin> fungi: right, I can write a spec for this similar to module split out
20:00:18 <pleia2> fyi, I'll be mostly out Friday and Monday for some appointments and things (yay for being home)
20:00:19 <jeblair> i think the reviews for that need to happen bottom-up ^
20:00:27 <fungi> mrmartin: we can put it in dns under an alternative name if you want, or just expect testers to modify /etc/hosts
20:00:42 <mrmartin> I think hosts file modification is more then enough
20:00:44 <jeblair> we're at time.  thanks everyone!
20:00:49 <jeblair> #endmeeting