19:01:00 <fungi> #startmeeting infra
19:01:01 <openstack> Meeting started Tue Oct 22 19:01:00 2013 UTC and is due to finish in 60 minutes.  The chair is fungi. Information about MeetBot at http://wiki.debian.org/MeetBot.
19:01:02 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic #startvote.
19:01:05 <openstack> The meeting name has been set to 'infra'
19:01:13 <fungi> #link https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting
19:01:48 <fungi> #link http://eavesdrop.openstack.org/meetings/infra/2013/infra.2013-10-15-19.02.html
19:02:14 <clarkb> o/
19:02:28 <fungi> #topic Actions from last meeting
19:02:35 <anteaya> zaro around today?
19:02:47 <clarkb> I think he is travelling to jenkins conf
19:02:49 <anteaya> ah
19:02:58 <fungi> jeblair move tarballs.o.o and include 50gb space for heat/trove images
19:03:10 <krtaylor> o/
19:03:34 <fungi> i assume that will remain in progress for a bit while jeblair is travelling, lest someone else has time to do it sooner
19:03:58 <fungi> that's all we had on action items
19:04:05 <fungi> #topic Trove testing (mordred, hub_cap)
19:04:21 <fungi> hub_cap said he knows how it's going to work and someone else is going to do it rsn
19:04:39 <fungi> but that he's on a call right now, so not making the meeting
19:04:46 <clarkb> and that he wouldn't make it to the meeting to talk about it otherwise :) but excited that there is a plan somewhere :)
19:05:00 <anteaya> yay for a plan
19:05:21 <fungi> #topic Tripleo testing (lifeless, pleia2)
19:05:29 <fungi> you have the floor
19:05:36 <pleia2> we have a super basic experimental test now
19:05:45 * anteaya applaudes
19:05:46 <pleia2> it just runs a simple echo script on a tripleo cloud system
19:06:24 <fungi> those new images worked out for you then?
19:06:26 <clarkb> it would be great if https://bugs.launchpad.net/openstack-ci/+bug/1217815 could be updated. I want to say that tripleo still wants to use toci as it will test different things than the upstream integrated tests
19:06:29 <uvirtbot> Launchpad bug 1217815 in openstack-ci "Tripleo ci service account in gerrit" [Undecided,New]
19:06:35 <pleia2> fungi: yes! thank you
19:06:38 <clarkb> fungi: pleia2 lifeless ^ but I am not sure of all the details
19:07:03 <pleia2> I'm going through this https://etherpad.openstack.org/p/tripleo-test-cluster - so iteration 1 is completed, and I'm working on 2 now
19:07:18 <fungi> #link https://etherpad.openstack.org/p/tripleo-test-cluster
19:07:35 <pleia2> lifeless: I don't know the status on https://bugs.launchpad.net/openstack-ci/+bug/1217815 - any insights?
19:07:37 <uvirtbot> Launchpad bug 1217815 in openstack-ci "Tripleo ci service account in gerrit" [Undecided,New]
19:08:21 <fungi> maybe he's sleeping in the middle of the night for a change
19:08:32 <pleia2> he's running the tripleo meeting in -alt :)
19:08:35 <anteaya> he is chairing in the other channel
19:08:39 <fungi> oh, or that :/
19:08:49 <pleia2> maybe we come back to this bug later/after meeting
19:08:55 <pleia2> that's all the updates I have
19:09:05 <anteaya> great work, pleia2
19:09:20 <fungi> yeah, no worries. i don't think it's a direct action item from this topic, but an update from someone in the bug would be swell
19:09:30 <fungi> #topic Wsme / pecan testing (sdague, dhellman)
19:10:04 <lifeless> pleia2: clarkb made one.
19:10:08 <fungi> i know a little about this, but would be better if one of them wants to go into detail
19:10:11 <pleia2> lifeless: bug done?
19:10:16 <clarkb> I didn't make an account
19:10:16 <pleia2> saw a the review for this trickle in this morning https://review.openstack.org/#/c/53136/
19:10:26 <lifeless> pleia2: oh, then mordred did
19:10:28 <lifeless> clarkb: ^
19:10:34 <clarkb> thanks I will update the bug
19:10:42 <lifeless> anyhow, bug can be closed, we have a suitable account.
19:10:49 <lifeless> tripleo-cd-bot IIRC.
19:11:28 <fungi> okay, well, in absence of sdague and dhellmann, i'll attempt a tl;dr on the current topic
19:12:13 <fungi> basically, there is a desire to more tightly couple wsme and pecan gating into devstack, so changes to them can avoid breaking the projects which depend on them
19:13:08 <fungi> some of it is in progress already... making devstack use the git master branches of those instead of pypi released versions, and adding the devstack/tempest jobs to those projects
19:13:44 <sdague> oh, sorry, stepped out for a sec
19:13:45 <fungi> there is an additional desire to gate them against stable branches of devstack-integrated projects to avoid breaking stable released versions
19:13:51 <fungi> oh! sdague can take over
19:14:12 <sdague> well, I think you are basically completely on target
19:14:57 <fungi> dhellmann was also talking about maybe figuring out how to integrate the unit tests of other projects as part of the gating for pecan and wsme, but that would need a little additional engineering design
19:15:26 <sdague> I think that once we have this - https://review.openstack.org/#/c/53136/ we can fix it on the devstack / devstack-gate side
19:15:43 <sdague> that will make pecan / wsme part of the big happy family
19:15:45 <clarkb> I am excited for what comes out of this. Is there any concern that we are massively overengineering the whole thing?
19:16:01 <fungi> #link https://review.openstack.org/#/c/53136/
19:16:04 <fungi> probably special versions of the unit test runner which would munge the requirements and override the target branch (to support backward-compat runs)
19:16:06 <sdague> I did however also propose a session about a bigger vision
19:16:17 <sdague> http://summit.openstack.org/cfp/details/340
19:16:31 <fungi> #link http://summit.openstack.org/cfp/details/340
19:16:33 <fungi> excellent
19:16:40 <sdague> because I think we might want to build something to more generically attack this for libraries beyond our control
19:16:53 <sdague> but that's summit material
19:17:15 <fungi> i hope it makes it into the schedule, because i want to talk about it too
19:17:22 <sdague> honestly once https://review.openstack.org/#/c/53136/ is approved, we can probably pull the rest together within a day or two
19:17:40 <fungi> anything else on the current topic then?
19:17:49 <sdague> not from me
19:17:49 <clarkb> yes
19:18:23 <clarkb> is the plan to make gating mutual or just one direction? I think one problem that we will run into is openstack breaking wsme
19:18:32 <clarkb> but we shouldn't be gating openstack on wsme
19:18:40 <clarkb> something to think about at least
19:18:43 <sdague> clarkb: how would openstack break wsme?
19:18:58 <sdague> I actually think there is a direction flow in dependencies
19:19:13 <sdague> so I'm not actually concerned that we could break wsme
19:19:19 <clarkb> sdague: if openstack were to continue using deprecated interfaces then wsme can't deprecate them and so on
19:19:55 <fungi> i think this is at least a little better than the horizon/keystone auth plugin where we had openstack depending on not-openstack depending on openstack (thankfully resolved now)
19:19:58 <sdague> symetric gating wouldn't solve that though
19:20:11 <clarkb> sdague: right I think they are both wrong :)
19:20:18 <clarkb> but need to think about it more
19:20:41 <sdague> yeh, I think we should do this thing, to solve a problem we know we have, then if we create a new problem, solve that later
19:20:50 <clarkb> wfm
19:20:51 <fungi> wfm
19:21:02 <fungi> anything else on the current topic then?
19:21:05 <sdague> I think the emergent behavior of these interconnections has shown we often poorly predict the future problems :)
19:21:27 <sdague> I'm good
19:21:32 <fungi> solving future problems is akin to premature optimization, agreed
19:21:51 <fungi> #topic New etherpad.o.o server and migration (clarkb)
19:21:56 <clarkb> ohai
19:22:00 <fungi> that happened, ja?
19:22:04 <clarkb> it did
19:22:28 <fungi> any new fun there?
19:22:51 <pleia2> it's working great
19:22:52 <clarkb> we are now running etherpad.o.o and etherpad-dev.o.o on almost the latest versions of etherpad-lite with the latest nodejs stable release on 2GB nodes using trove as the backend
19:23:22 <pleia2> clarkb: I do have some bugs in the bug day list that I need your eyeballs on related to this (I bolded your nick in the etherpad)
19:23:30 <clarkb> pleia2: I will look
19:23:38 <pleia2> just one for etherpad :)
19:23:47 <clarkb> but yes overall the move went smoothly and we did an emergency nodejs upgrade Friday night as well
19:23:58 <fungi> clarkb: and the old etherpad server still exists for the moment, right?
19:24:31 <clarkb> yes it does, because it has old DB backups that I didn't want ot have to juggle. I plan on deleting the old servers after the summit
19:25:14 <fungi> #action clarkb decommission old etherpad server eventually (after the summit)
19:25:16 <clarkb> please let us know if you see etherpad acting weird, but it seems to have done just fine
19:25:18 <fungi> just so we don't frget
19:25:41 <fungi> i've been using it fairly heavily for things since the upgrade, no sign of broken
19:26:12 <fungi> i wish the etherpad the foundation uses for staff meetings were so nice and responsive as this one
19:26:39 <sdague> fungi: their pads > 700 lines?
19:26:53 <sdague> that's been an issue for me on my installation, and a know bug
19:26:55 <fungi> sdague: we need to truncate the main one we use, but almost certainly
19:27:19 <sdague> yeh, we rotate out pads every couple of weeks for that reason, keep them < 700 lines
19:27:43 <fungi> though i also discovered that part of the issue i was having with theirs was due to timeouts reaching google analytics (gag)
19:27:58 <sdague> also big +1 for ep_headings add by clarkb :)
19:28:15 <sdague> https://etherpad.openstack.org/p/icehouse-qa-session-planning - example
19:28:18 <clarkb> sdague: I like the headings plugin too, wish I had dealt with it sooner :)
19:28:23 <sdague> heh
19:28:27 <fungi> #link https://etherpad.openstack.org/p/icehouse-qa-session-planning
19:28:59 <anteaya> nice
19:29:28 <fungi> are we all set on etherpad talk for the moment? anyone have anything else for that?
19:30:01 <fungi> #topic Third-party documentation editors (fungi)
19:30:26 <fungi> just a quick update from a call i had with annegentle and a group of editors from o'reilly press
19:30:59 <fungi> the foundation has a contract, as i understand it, to get one or more of the manuals bookified
19:31:27 <fungi> so we're trying to figure out a workflow feedback loop between their editors and our authors
19:32:01 <fungi> current plan is that they're going to clone from git branch tip and at the same time the docs program will announce a freeze
19:32:23 <fungi> tentative schedule for the first iteration is to freeze from october 28 through november 5
19:32:47 <clarkb> fungi: what will the pushes back to gerrit look like?
19:32:54 <fungi> they will publish their edits in a git repo which we can import and turn into a gerrit review
19:33:26 <fungi> that can either happen manually initially or we can script it
19:34:02 <fungi> i wanted to bring it up here mostly to talk through possible implementation details on our end
19:34:24 <fungi> they are open to evolving the process over time as well, so none of this is set in stone
19:35:23 <clarkb> worth mentioning the reason that they don't use gerrit directly is they haev their own set of tools backed by git for editing things
19:35:29 <fungi> the main issue we were worried about was merge conflicts, but annegentle felt that the documentation community would be amenable to a periodic freeze on specific documents
19:35:32 <clarkb> so they will edit in that world then push changes back to us
19:35:38 <fungi> right
19:36:04 <anteaya> sounds like a very interesting direction
19:36:10 <fungi> it's called "atlas" but since it's proprietary and we won't need to interact with it (per the current plan) that's somewhat immaterial
19:36:18 <clarkb> so the freeze period is to avoid merge conflicts? do we think that manually resolving the conflicts will be too difficult?
19:36:18 <anteaya> will they be joining us in -infra and asking questions?
19:36:47 <anteaya> so I can recognize them and get a sense of how to help?
19:37:03 <fungi> clarkb: apparently they feel that the way docbook/xml works, diffs become massively painful to properly resolve merge conflicts on
19:37:11 <fungi> anteaya: probably not, but you never know
19:37:41 <clarkb> fungi: well, maybe we should be arguing for sane markup >_>
19:37:42 <anteaya> okay, just if I get a brand new question, it helps to have context
19:37:54 <clarkb> fungi: but that is a different battle. If the doc team is ok with freezing content I am fine with it
19:38:13 <clarkb> I think it is a lot easier on them now that they are further ahead of the releases
19:38:33 <fungi> clarkb: yeah, for the time being i think the desire is to try this out and see where it leads, then adjust if necessary, refine, and semi-automate
19:38:52 <clarkb> wfm
19:39:00 <anteaya> I think it is a great idea
19:39:04 <fungi> my remaining concern is that they heavily use github
19:40:04 <fungi> it sounds like they're going to want to push to a private github fork (to avoid spiders picking up their edits and making them look official when they're not), so automation will probably mean authenticating to github to pull their patch or patch series, at least at first
19:40:24 <clarkb> uhm, hmm
19:41:04 <dhellmann> are they going to want to preserve the history of those imports? or are they going to squash the commits?
19:41:05 <fungi> i'd love to push them in a direction along the lines of pushing directly to gerrit, but that's probably a down-the-road thing since they want to get rolling on this asap
19:41:27 <clarkb> private github repos aren't very open...
19:41:45 <clarkb> and while APL2 doesn't prevent it :/
19:41:53 <fungi> dhellmann: i suspect a squashed commit will be fine in this case since it's work for hire
19:42:32 <clarkb> maybe push to a dev branch instead of master? in any case we can let it evolve. I think the important bit is getting something working
19:42:35 <dhellmann> ok
19:42:38 <fungi> clarkb: yes, my concerns as well. however on the call it sounded like they had existing automation around github (its no more proprietary than their editing system after all) and they need t publish their commits somewhere
19:42:40 <clarkb> particularly with the freeze coming up so quickly
19:43:51 <fungi> so while i don't like the thought of depending on github for this, we're also depending on their proprietary commercial editing services for this work anyway
19:44:23 <clarkb> fungi: its less the proprietary stuff and more that the dev is closed
19:44:44 <dhellmann> it's open to the dev team, right?
19:44:49 <dhellmann> I mean the docs team
19:44:54 <dhellmann> it's just not open to the world?
19:45:03 <clarkb> I assume it depends on how the repo is configured
19:45:13 <clarkb> or org, I am not super familiar with github ACLs
19:45:19 <dhellmann> presumably the doc folks are going to need to send them changes
19:45:54 <dhellmann> but in any case, the publishing toolchain is going to turn into a black box at some point, so I'm not sure it matters whether github is involved or not
19:46:08 <dhellmann> using it should actually  make it easier to have a few people with access to pull changes back out
19:46:14 <fungi> the end result will land in gerrit. i don't think the interim state where it happens to be temporarily published to $some_proprietary_system will necessarily be accessible except to the editors at o'reilly and automation or whoever's grabbing the patch to stuff into gerrit
19:46:14 <dhellmann> and put them into our open system
19:46:43 <dhellmann> how will they be handling copyedits?
19:47:17 <fungi> heh. i live with a copyeditor and i still don't understand your question ;)
19:47:25 <fungi> iterative work?
19:47:49 <dhellmann> yes
19:48:12 <fungi> the idea is that by the end of the freeze their change is reviewed and merged
19:48:18 <dhellmann> the o'reilly editors and compositors are going to want to make changes to the text (typos, phrasing, formatting, whatever)
19:48:35 <dhellmann> merged into our upstream repo?
19:48:39 <fungi> yes
19:49:06 <fungi> and then the document is unfrozen and docs editors go into authorship phase for a period before the next freeze
19:49:27 <fungi> at which point o'reilly updates their clone and starts editing again
19:49:35 <dhellmann> so oreilly will work in the private repo and something/one will push the changes back upstream
19:49:42 <dhellmann> ok, I think I've got it
19:49:45 <fungi> right
19:50:04 <fungi> this way we can reintegrate their edits
19:50:05 <dhellmann> ok, this sounds better than what I had to go through with my book :-)
19:50:15 <fungi> i can only imagine
19:50:32 <dhellmann> I still have a bunch of latex files with changes I need to merge by hand. So I'm +1 on this plan. ;-)
19:50:35 <clarkb> Ya I think it will work out and the proposed plan seems like a good place to start. I am just brainstorming around the trouble spots :)
19:50:55 <fungi> anything else on this? i think dhellmann wanted to come back to pecan/wsme testing during the open discussion portion of the meeting
19:51:12 <fungi> and we're running tight already
19:51:19 <dhellmann> I don't have much
19:51:38 <fungi> #topic Open discussion
19:51:49 <fungi> and before i forget
19:51:52 <fungi> #action jeblair move tarballs.o.o and include 50gb space for heat/trove images
19:51:55 <pleia2> bug day continues, don't fall asleep :) https://etherpad.openstack.org/p/cibugreview-october2013
19:52:08 <pleia2> at the top of the file I included a link to New bugs that should be triaged
19:52:20 <clarkb> quick FYI I upgraded logstash to 1.2.1 and elasticsearch to 0.90.3 yesterday after a week of planning :) and nothing seems to have fallen over. These upgrades better future proof us against the direction es and logstash are moving
19:52:26 <dhellmann> I just wanted to address the bi-directional gating (I think that's not needed) and mention that we're also going to add test config to pecan and wsme to let us test locally (in addition to the gates)
19:52:35 <pleia2> started the day with 190 bugs, down to 185, I'm hoping we can do better
19:52:49 <clarkb> pleia2: I am slowly working through that :) I am amazed at how much harder this is when jeblair, mordred, and jog0 are busy with other stuff
19:52:55 <anteaya> good work on bugs pleia2
19:53:00 <pleia2> clarkb: yeah, jeblair always did a lot :)
19:53:15 <anteaya> clarkb: did anything on this https://etherpad.openstack.org/p/elasticsearch-optimization-suggestions help or was it just noise?
19:53:17 <clarkb> dhellmann: cool thanks
19:53:18 <dhellmann> ryan has some changes in process to let us test the openstack incubated and integrated projects that use pecan already
19:53:21 <fungi> yeah, i feel bad that i've not contributed as much to today's bugtrawl as i had wanted
19:53:32 <anteaya> I couldn't pass up three experts on elasticsearch
19:54:11 <clarkb> anteaya: a lot of it was stuff that I already sorted out
19:54:15 <anteaya> k
19:54:25 <anteaya> that's good
19:54:36 <clarkb> anteaya: I think a lot of people don't quite understand the restrictions we have when it comes to available hardware, security model, and the amount of data we want to index
19:54:42 <anteaya> yes
19:55:02 <anteaya> that was what I kept hitting, because I don't have all that info either
19:55:06 <anteaya> just small pieces
19:56:18 <clarkb> anteaya: I can update that etherpad at some point for completeness with things like we already do X and can't do Y for reason Z
19:56:28 <anteaya> sure
19:56:37 <anteaya> since honza and alexb also have that url
19:56:48 <anteaya> so may respond if they have something to respond to
19:56:53 <clarkb> cool
19:57:14 <clarkb> fungi: we forgive you, I may roll bug stuff over into tomorrow depending on how the rest of today goes
19:57:17 <clarkb> :)
19:57:35 <pleia2> oh, I owe some nodepool documentation updates for running a dev version, need to bootstrap sphinx on the nodepool repo
19:57:38 <fungi> oh, don't forget i'm semi-afk the next couple days at the all things open conference
19:57:49 <fungi> but back in full force on friday of course
19:57:57 <anteaya> cool, happy open conference
19:57:58 <clarkb> have fun
19:58:03 <anteaya> is that in raliegh?
19:58:04 <fungi> (that rhymed!)
19:58:07 <fungi> yeah
19:58:19 <anteaya> hence why mordred is going there after chicago
19:59:15 <anteaya> great meeting, fungi
19:59:45 <pleia2> thanks fungi
19:59:45 <fungi> a-the-a-the-a-the-a-that's all, folks!
19:59:55 <fungi> #endmeeting