19:02:28 <jeblair> #startmeeting infra
19:02:29 <openstack> Meeting started Tue Aug  5 19:02:28 2014 UTC and is due to finish in 60 minutes.  The chair is jeblair. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:02:30 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:02:32 <openstack> The meeting name has been set to 'infra'
19:02:36 <jeblair> our agenda is here:
19:02:38 <jeblair> #link https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting
19:02:44 <jeblair> summary from last meeting:
19:02:45 <jeblair> http://eavesdrop.openstack.org/meetings/infra/2014/infra.2014-07-29-19.01.html
19:02:47 <jeblair> #link http://eavesdrop.openstack.org/meetings/infra/2014/infra.2014-07-29-19.01.html
19:03:04 <jeblair> #topic Puppet module Split out (jesusaurus/nibalizer)
19:03:11 <jeblair> #link https://review.openstack.org/#/c/99990/
19:03:36 <ianw> o/
19:03:51 <jesusaurus> 99990 has been sitting with a couple +1s for a while now, and I'm just wondering what needs to happen to help move that along
19:04:27 <jeblair> jesusaurus: very good point; i can review it today
19:04:32 <jesusaurus> do the cores have any comments/concerns?
19:04:43 * fungi feels partly to blame for not reviewing enough. added to the evening pile
19:04:53 <jeblair> hopefully another core can too.  i think it was pretty close last time i looked.
19:05:26 <pleia2> jeblair: looks like it has some overlap with your new https://review.openstack.org/#/c/110730/
19:05:35 <clarkb> I am still in a review mood I can review it today
19:05:47 <pleia2> so I'd simplify 110730 in some places to point to jesusaurus' spec
19:05:58 <jesusaurus> if its just a matter of getting burried in review backlog then i guess this will be a short topic
19:06:13 <jeblair> i think the last two comments look good -- about how to actually proceed switching each module over
19:06:14 <jesusaurus> but i wanted to give people a chance to discuss any concerns they might have
19:06:16 <clarkb> jesusaurus: ya I think with all the travel and summer we haven't kept up at all
19:06:30 <pleia2> (ah, I do see a note in the bottom of 110730)
19:06:30 <clarkb> jesusaurus: but we seems to be turning a corner on that so hopefully things start moving
19:06:39 <jeblair> pleia2: i mentioned this one in my spec; but they actually don't overlap that much.  they are complimentary
19:06:52 <fungi> i feel like i should set aside more time to review specs in general, they just take a good deal longer than the typical code change so it takes getting into the right mindset. not an excuse mind you
19:07:18 <jeblair> fungi: agreed
19:07:28 <jeblair> the specs process is still a learning process :)
19:07:44 <nibalizer> o/
19:08:07 <jeblair> any further thoughts on this, particularly any process changes once it's approved and we start in on it?
19:08:57 <nibalizer> i think we should automate it, but i doubt thats controversial
19:09:14 <fungi> as in changes to how we review additions of new puppet modules to config (deny them) or major refactors (encourage extraction first)?
19:09:14 <jesusaurus> nibalizer: what do you have in mind?
19:09:35 <nibalizer> a script to split it out
19:09:46 <nibalizer> then propose the changes
19:09:56 <nibalizer> well
19:09:59 <nibalizer> we should do one first
19:10:04 <nibalizer> get our sea legs a bit
19:10:06 <nibalizer> then automate it
19:10:08 <jeblair> nibalizer: then maybe add that script to tools/
19:10:15 <nibalizer> ya
19:10:16 <jeblair> nibalizer: but i do think we should still do the mods one at a time
19:10:22 <nibalizer> agreed
19:10:29 <jesusaurus> agreed
19:10:29 <fungi> i think the major process change once approved is that we need review diligence to avoid backsliding
19:10:58 <jeblair> fungi: yep
19:11:02 <fungi> no accumulation of new modules, no significant work on existing modules while still in the config tree
19:11:15 <jesusaurus> also some modules will be harder than others due to reviews in-flight
19:12:05 <jeblair> i'm hoping by splitting those up into individual tasks, we can help spread the work around.  in addition to actually doing the split, there will probably be some shepharding needed for the things jesusaurus mentioned
19:12:33 <jeblair> s/shepharding/cat herding/
19:13:01 <jeblair> anything else, or shall we move on?
19:13:07 <jesusaurus> also, once we starting splitting modules out, we will want to test interoperability, so i think we should work on those tests on our first split-out module before we start moving with other modules
19:13:32 <mordred> o/
19:13:35 <mordred> sorry late
19:13:41 <jeblair> jesusaurus: good point; also, making the tests on the mods themselves boilerplate
19:13:49 <jesusaurus> yeah
19:14:14 <jeblair> i just approved the zuul cloner patches; maybe we can use that to set up integration tests (so we don't have to use devstack-gate)
19:14:18 <nibalizer> if you look at the storyboard mod that i split manually
19:14:23 <nibalizer> i added rake tests and such for it
19:14:43 <nibalizer> and did a history rewrite so that the testing framework lands first
19:14:57 <jeblair> cool
19:15:02 <nibalizer> https://review.openstack.org/#/c/100370/
19:15:24 <jeblair> not sure how i feel about the history rewrite
19:15:45 <nibalizer> i'd like to see us do storyboard first, since thats the one i've been most working/familiar with, but that runs against the big refactor krotscheck is trying to land
19:16:06 <nibalizer> jeblair: its a reordeing rebase, no history is lost
19:16:11 <clarkb> nibalizer: it isn't necessary
19:16:21 <clarkb> you just need to put the tests on top as the first change
19:16:34 <nibalizer> ah and have zuul figure it out?
19:16:36 <nibalizer> gross
19:16:39 <nibalizer> okay
19:16:42 <clarkb> nibalizer: its not gross
19:16:50 <clarkb> nibalizer: you push the eixsting history into gerrit as is
19:16:55 <clarkb> nibalizer: then change one adds .gitreview and tests
19:17:10 * nibalizer is still used to a github style workflow where I do the ordering in my tree
19:17:13 <krotscheck> Note: I discovered an outstanding issue with the storyboard module that I had to fix yesterday, the module didn’t check for the existence of git.
19:18:08 <jesusaurus> okay, i think we're pretty much done with this topic now
19:18:17 <jeblair> i don't want to hold up krotscheck's module since we need to get some changes in to the running server
19:18:37 <jeblair> how close are their current states?  can we duplicate krotscheck's change onto puppet-storyboard?
19:19:51 <jeblair> nibalizer: ^?
19:21:03 <jeblair> well, i imagine we'll probably want to do something like that.  the alternative is to re-do the extraction and force-push, but that's messy and probably not warranted in this case.
19:21:37 <jeblair> #topc Discussion about the inclusion of git-upstream in Stackforge (dguerri)
19:21:39 <jeblair> #topic Discussion about the inclusion of git-upstream in Stackforge (dguerri)
19:21:46 <dguerri> first: hello folks, I am pretty new to these IRC meeting :)
19:21:58 <fungi> welcome, dguerri
19:22:01 <jeblair> dguerri: hi there!
19:22:12 <dguerri> This is about adding a new tool to Stackforge --> https://review.openstack.org/109292
19:22:22 <dguerri> I know this is not something that is usually in this agenda, sorry for the hassle...
19:22:38 <dguerri> to recap: this topic is in openstack-infra agenda as there has been a concern about the name of the tool (anteaya) as it could create confusion with git-review
19:23:00 <dguerri> After a discussion in #openstack infra, that concern is no longer. anteaya voted with a +1 to that review.
19:23:18 <jeblair> dguerri: thanks, yeah.  we don't normally weigh in too much on stackforge tools; but are certainly happy to help discuss something like this if it's necessary.
19:23:18 <dguerri> So if someone (at their convenience) could review that... that would be great! :)
19:24:00 <jeblair> it has 2x+2s, i only did not approve it since it was on the agenda
19:24:09 <dguerri> if there are no other concerns or info request... that's all
19:24:14 <dguerri> ok, thanks!
19:24:24 <jeblair> so unless any of the core's here have anything to add, we can probably go ahead and push it through
19:24:34 <clarkb> +1
19:24:41 <fungi> seems fine to me
19:24:55 <jeblair> done
19:25:04 <dguerri> cheers ;)
19:25:15 <fungi> my only concerns were when it was previously being proposed for inclusion in openstack-infra instead, at which time its scope was not as well documented
19:25:21 <jeblair> dguerri: thanks!  hope to see you around :)
19:25:25 <fungi> for stackforge it seems fine
19:25:41 <dguerri> I will be around, definitely.
19:25:45 <jeblair> yeah, seems a stretch for infra at the moment, unless we start using it for gerrit or something
19:25:52 <jeblair> #topic  Outage for proactively migrating jenkins05 to a different host (fungi)
19:26:11 <jeblair> istr this happened?
19:26:11 <fungi> jeblair: oh, i took that off the agenda after the last time you loaded it :/
19:26:16 <jeblair> haha
19:26:18 <fungi> it happened, no issues
19:26:24 <jeblair> excellent!
19:26:25 <fungi> we can move on
19:26:27 <jeblair> #topic  Pootle upgrade to 2.6.0 RC (pleia2)
19:26:30 <mordred> fungi: well done
19:26:30 <clarkb> woot
19:27:07 <clarkb> pleia2: do we need this upgrade to allow the demo to happen?
19:27:13 <pleia2> so we have a demo scheduled with a pootle person on the 18th, so I'm hoping we can get this upgraded to the latest 2.6RC so he can show off all the latest features
19:27:15 <clarkb> pleia2: I am admittedly a bit behind on the state of things here
19:27:26 <jeblair> pleia2: 19th?
19:27:30 <pleia2> er, 19th (but it's the evening of the 18th for us)
19:27:38 <jeblair> ok
19:28:03 <clarkb> I am happy to help if I can. I know jeblair has interest in this area so I may just stay out of the way :)
19:28:20 <pleia2> I am happy to get familiar with how upgrades happen and help out (might be good practice for all of us), or discuss just wiping what we have and installing fresh
19:28:28 <jeblair> i'm about to take off from mid-this-week to mid-next-week, so i will be of limited utility
19:28:38 <pleia2> I'm out thurs-fri this week
19:28:55 <jeblair> pleia2: there's some not at all documented stuff about how i placed the git repos on that server
19:28:55 <clarkb> jeblair: pootle isn't in puppet right?
19:29:03 <pleia2> clarkb: right
19:29:09 <clarkb> jeblair: but I should be able to log into the server and have root?
19:29:29 * clarkb tries to remember what the host's fqdn is
19:29:34 <pleia2> translate-dev
19:29:42 <jeblair> pleia2: i was not expecting the time delta between when i "got some stuff working" to when i would "write it up properly in puppet" to be nearly a year...
19:29:45 <jeblair> :(
19:29:52 <pleia2> jeblair: yeah :\
19:30:03 <jeblair> pleia2: so we should probably keep that around because of its institutional knowledge
19:30:17 <clarkb> yup I have root, pleia2 we can crash course on pootle upgrades between now and monday then do it on monday?
19:30:30 <pleia2> clarkb: wfm
19:30:39 <clarkb> jeblair: or would you prefer we spin up a second host and install from scratch? I am happy either way
19:30:41 <jeblair> it's probably not crazy to try to upgrade that in place, but of course, if you feel like just doing a new server, that's cool too
19:30:48 <clarkb> jeblair: ok
19:31:03 <jeblair> the only other thing on that server is that it contains my not-upstreamed patch to do openid
19:31:13 <jeblair> upstream has since incorporated a different method of doing openid
19:31:17 <jeblair> so that will require changing
19:31:23 <clarkb> jeblair: config change?
19:31:24 <pleia2> fortunately 2.5.1 is still the stable version, so it's not going to be some huge leap
19:31:27 <jeblair> clarkb: code change
19:31:40 <clarkb> jeblair: right but we can use upstreams openid now?
19:31:46 <fungi> pleia2: i'm also around normal hours all next week and am happy to pitch in on it
19:31:49 <jeblair> (i submitted the change upstream, but he wanted a different approach, which i never got around to writing)
19:31:52 <clarkb> jeblair: or do we need to apply your patch to pootle?
19:31:53 <pleia2> actually - clarkb can you confirm the version we installed? (I just clicked on "help" but now realized it doesn't specify version)
19:32:05 <jeblair> clarkb: i hope so, but i do not know.
19:32:12 <clarkb> pleia2: Pootle==2.5.0
19:32:14 <clarkb> jeblair: rdr
19:32:16 <clarkb> er rgr
19:32:20 <pleia2> clarkb: ok, thanks
19:33:18 <jeblair> sounds like a plan, thanks!
19:33:22 <pleia2> thanks :)
19:33:36 <jeblair> #topic  Rename Marconi->Zaqar (flaper87)
19:33:56 <jeblair> #link https://review.openstack.org/#/c/111244/
19:34:27 <fungi> i'm travelling a bunch this weekend, but can help/run the rename any time next week or after
19:34:31 <clarkb> I was +2 on a previous patch, need to review current patchset
19:34:38 <jeblair> i'm also not around this weekend
19:34:44 <clarkb> me 3
19:35:08 <clarkb> you can blame greghaynes for that
19:35:20 <fungi> flaper87|afk: if you're not really afk, any requested timeline for renaming?
19:35:27 <mordred> I do not think I should do it myself
19:35:37 <jeblair> SergeyLukjanov: are you around?
19:35:54 <mordred> but SergeyLukjanov and I could probably do it
19:36:04 <mordred> oh - wait - I'm also not aroudn this weekend. duh
19:36:18 <jeblair> it's sounding like we may want to tentatively schedule it for the following weekend (16-17)
19:36:24 <jeblair> along with the kite rename
19:36:35 <nibalizer> there was also something i wanted to move to the attic
19:36:52 * mordred will also not be here the following weekend, nor the weekend after that
19:37:09 <clarkb> mordred: giving up on weekend hacking?
19:37:13 <nibalizer> i think it was this http://git.openstack.org/cgit/openstack-infra/puppet-dashboard/
19:37:16 <clarkb> jeblair: 16-17 is hard for me but not impossible
19:37:18 <mordred> clarkb: wedding, burningman, burningman
19:37:27 <fungi> oh, and was there ever a decision on gantt?
19:37:46 <clarkb> fungi: I thought we were leaving gantt as is because people wanted to move it back there at some point
19:37:52 <clarkb> and we said lets not play musical chairs
19:37:53 <jeblair> fungi: i think we need to disable access to it
19:38:04 <jeblair> jraim__: ^ thoughts on moving kite to openstack on the 16-17th ?
19:38:31 <jeblair> let's revisit these next week
19:38:36 <clarkb> wfm
19:38:38 <fungi> ah, right
19:38:45 <jeblair> #topic Discuss common location for third party ci system's templates (asselin, krtaylor, joa)
19:38:47 <fungi> agreed
19:39:12 <asselin_> hi, so in the 3rd party discussion, many of us are using jaypipes's repo
19:39:23 * ttx lurks
19:39:42 <asselin_> we'd like a common place to leverage each other's work & keep in sync with infra.
19:39:51 <jeblair> asselin_: great.  that place is infra
19:39:52 <fungi> i still think rewriting/expanding the third-party.rst would be a welcome place
19:40:14 <asselin_> fungi, yes, we can do that as part of the change.
19:40:15 <clarkb> jeblair: right, I think this falls under making infra more consumable
19:40:17 <jeblair> asselin_: as you've seen from the earlier topics, there's a lot of work to make the puppet modules more reusable
19:40:50 <jeblair> asselin_: that's part of it; documentation is part of it...
19:40:51 <asselin_> yes, we've run in a few issues that hve been fixed.
19:41:13 <asselin_> I'd like to see documetation + puppet scripts (code) that does it all
19:41:24 <asselin_> we're all spending a lot of time figuring out the same things
19:41:47 <asselin_> 3rd party team though was stackforge.
19:41:49 <fungi> and yeah, as far as any of the scripting/automation side, most of that just speaks to inadequacies in consumability of our tooling (or in some cases, misunderstandings around it, thus shortcomings in documentation)
19:42:01 <asselin_> If you think o.o infra's the place, even better
19:42:47 <asselin_> fungi, I don't want to see everyone reading documentation and putting pieces togeter to get a ci system up and running.
19:42:58 <jeblair> asselin_: yep.  the goal is for all of infra to be consumable; it's going to take a bit to get there, including some things like the large puppet refactor underway.
19:42:59 <asselin_> fungi, I'm find with documentation and a solution
19:43:28 <e0ne> asselin_ infra is very specific to openstack infrastructure
19:43:54 <asselin_> i.e. something like what jaypipes started, but is now out of sync. https://github.com/jaypipes/os-ext-testing
19:44:15 <jeblair> asselin_: some of the folks working on this want a full system, including gerrit.  the third party folks, not so much.  so one thing you can do is help to make sure that as we move forward, it's modular enough to just run the bits you need.
19:44:26 <e0ne> imo, it would be better to mage infra/config more configurable to use it in 3rd party CIs
19:44:41 <jaypipes> jeblair: ++
19:44:58 <jeblair> asselin_: yeah, everyone who does something like that gets out of sync, which is why we're starting on structural changes to help avoid that
19:45:34 <jeblair> there are two infra-specs dealing with puppet refactors that are both designed to be initial steps to making this better
19:45:57 <asselin_> so perhaps we can agree to move to stack forge, to start to bring it in sync with o.o & the changes discussed earlier (puppet refactors)
19:46:00 <jeblair> (they aren't going to completely get us there, but they will make a big difference)
19:46:30 <jolyonbrown> sorry for a dumb question.. what is o.o ?
19:46:37 <asselin_> openstack.org
19:46:41 <jolyonbrown> :)
19:46:49 <clarkb> asselin_: I think the issue with going to stackforge is it is misplacing the effort needed
19:46:59 <clarkb> asselin_: if we start with infra/config you are automagically in sync
19:47:12 <fungi> ideally effort would go into improving the existing tooling rather than writing convenience wrappers around it
19:47:24 <jesusaurus> fungi: ++
19:47:54 <e0ne> fungi: agree with you
19:47:55 <asselin_> clarkb, ok, so we'll add a special 3rd party starting point in infra/config that 3rd party can use & stay in sync.
19:48:54 <krtaylor> e0ne, we have made several changes to make third-party CI easier to consume
19:48:56 <jeblair> asselin_: there's a lot of thought about how to use hiera to further refactor what we're doing; it's likely with that in place, we won't really need a separate starting point
19:49:24 <e0ne> krtaylor: looks like I missed it:(
19:49:36 <jeblair> asselin_: so i think that's why you're hearing that we want effort to go into infra
19:49:54 <asselin_> ok, I will spend my effort then to see how to make it work inside infra-config
19:49:55 <jeblair> it's not going to be fast, but in the end, i think it's going to be good, and we can use all the help we can get :)
19:50:08 <asselin_> agreed
19:50:43 <jeblair> asselin_:  so big things to watch out for are: puppet module split; openstack_project split; hiera related changes
19:50:55 <jeblair> s/watch out for/help with/ :)
19:51:02 <asselin_> yeah...good point, I don't want to add it there, just to get split out :)
19:51:45 <mordred> asselin_: also, I've been slowly working up ansible things to run the puppet - which _might_ be helpful or things you want to keep an eye on as well
19:51:47 <asselin_> e0ne, krtaylor anthing else I missed?
19:51:57 <krtaylor> we did talk about having some well commented templates
19:51:58 <jeblair> all right, thanks for bringing this up -- it's hard to overstate the number of people interested in it, and i think it's key to growing the contributor base to infra
19:52:06 <mordred> ++
19:52:13 <krtaylor> and a place to store them, but I guess that could be documentation
19:52:35 <jeblair> krtaylor: cool, check out my proposed "openstack_project" split spec and see how that relates to your idea
19:52:53 <krtaylor> I guess I could plug the Monday third-party meetings too :)
19:52:58 <jeblair> i'm going to try to move on and get the last couple topics now
19:52:58 <krtaylor> jeblair, will do
19:53:04 <asselin_> thanks
19:53:04 <jeblair> #topic  Switching all projects to trusty by default (clarkb)
19:53:11 <mordred> clarkb: do it
19:53:24 <jeblair> clarkb: make it so? :)
19:53:41 <clarkb> yes :)
19:53:55 <clarkb> so really I bring this up because I think for at least infra we want to remain as default precise
19:54:02 <mordred> do we?
19:54:13 <clarkb> mordred: all of our nodes are still precise so yes I think so
19:54:24 <mordred> sorry - mis-parsed your sentence
19:54:35 <clarkb> I can write a change that switches most everything to trusty and that may break some things and that change can default us to precise
19:54:36 <jeblair> we do want to change that; and we'll still be running py27
19:54:37 <mordred> I thought you were implying that we wanted to stay on precise as an end-goal
19:55:00 <clarkb> mordred: no no, mostly I just want to change the zuul layout.yaml name .* parameter function to default to trusty
19:55:02 <jeblair> clarkb: so i wonder what things might break?
19:55:05 <mordred> ++
19:55:10 <clarkb> then accomodate for things that should remain precise for now
19:55:11 <fungi> py33 jobs are going to be a bit of a challenge there
19:55:18 <clarkb> fungi: py33 is already handled
19:55:19 <jeblair> clarkb: sounds like a plan
19:55:21 <fungi> since we need to switch to py34 jobs replacing them
19:55:23 <fungi> already done?
19:55:34 <clarkb> fungi: no its not done, but the next item will talk about it :)
19:55:41 <jeblair> #topic  Switching to tox>=1.7.2 (clarkb)
19:55:44 <fungi> oh, got it! ;_
19:55:52 <mordred> clarkb: do it
19:55:56 <clarkb> so we currently hardcode py33 jobs to precise
19:55:57 <jeblair> clarkb: make it so?
19:56:05 <clarkb> we should make it so :)
19:56:12 <clarkb> but old tox doesn't grok py34 appearnetly
19:56:19 <fungi> ahh, that
19:56:20 <mordred> what? jesus
19:56:23 <fungi> yep, now i see
19:56:26 <mordred> that's stupid
19:56:27 <clarkb> at least not according to the tox changelog. So before we can move py33 to py34 we need to upgrade tox :)
19:56:47 <fungi> so for tox 1.7.2 we need to finish the hashseed pinning right?
19:56:52 <mordred> or move to dox
19:57:00 <clarkb> my current thought is to send mail to the list about flipping to trusty and upgrading tox in ~2 weeks
19:57:15 <clarkb> fungi: well honestly after all the -2s I have gotten I am really starting to think I should just upgrade tox
19:57:26 <clarkb> maybe that is too bofhy but its been furstrating
19:57:31 <jeblair> clarkb: -2s why?
19:57:37 <fungi> let them all break and see how fast they change their minds on setting hashseeds?
19:57:38 <mordred> seriously - that this is a probelm is VERY frustrating to me
19:57:41 <clarkb> jeblair: our backport process is ridiculous
19:58:03 <clarkb> jeblair: and you have to do all these things and people wonder why we need to support new tox on old branches and it has been one thing after another in some cases
19:58:05 <mordred> I mean, I get the thing it's supposed to be doing - but our TESTENV RUNNER should not be doign this
19:58:10 <fungi> is it just stable backports which are getting -2'd?
19:58:18 <clarkb> fungi: yes
19:58:29 <clarkb> fungi: but they will break without the hashseed tox.ini backport
19:58:52 <fungi> i can help advocate for this with the stable branch maintainers. we can't really run a different tox et cetera for testing stable patches, so yes
19:59:00 <fungi> ttx: ^
19:59:19 <jeblair> clarkb: it may be worth also bringing this up in the cross project meeting in 1 hour and one minute.
19:59:23 <mordred> ++
19:59:26 <clarkb> so should I go ahead and say ~2 weeks from now we will be doing this?
19:59:27 <fungi> definitely
19:59:28 <clarkb> jeblair: will do
19:59:34 <mordred> I'm also not really kidding about moving to dox instead
19:59:38 <clarkb> maybe wait on announcement for after the cross project meeting
19:59:41 <jeblair> mordred: except for ceilometer
19:59:45 <jeblair> mordred: i mean cinder
19:59:53 <clarkb> and tempest
19:59:55 <mordred> jeblair: cinder doesn't run iscsci in its unittestss
20:00:01 <clarkb> actually tempest should work nevermind
20:00:02 <fungi> i would let the cross-project meeting know you're doing this in 2 weeks. friendly public service announcement ;_
20:00:09 <jeblair> mordred: but it might in its functests, and we should not block that
20:00:18 <clarkb> fungi: :) sounds good
20:00:36 <jeblair> and we're at time; thanks everyone!
20:00:37 <jeblair> #endmeeting