19:01:00 #startmeeting infra 19:01:01 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 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:01:05 The meeting name has been set to 'infra' 19:01:13 #link https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting 19:01:48 #link http://eavesdrop.openstack.org/meetings/infra/2013/infra.2013-10-15-19.02.html 19:02:14 o/ 19:02:28 #topic Actions from last meeting 19:02:35 zaro around today? 19:02:47 I think he is travelling to jenkins conf 19:02:49 ah 19:02:58 jeblair move tarballs.o.o and include 50gb space for heat/trove images 19:03:10 o/ 19:03:34 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 that's all we had on action items 19:04:05 #topic Trove testing (mordred, hub_cap) 19:04:21 hub_cap said he knows how it's going to work and someone else is going to do it rsn 19:04:39 but that he's on a call right now, so not making the meeting 19:04:46 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 yay for a plan 19:05:21 #topic Tripleo testing (lifeless, pleia2) 19:05:29 you have the floor 19:05:36 we have a super basic experimental test now 19:05:45 * anteaya applaudes 19:05:46 it just runs a simple echo script on a tripleo cloud system 19:06:24 those new images worked out for you then? 19:06:26 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 Launchpad bug 1217815 in openstack-ci "Tripleo ci service account in gerrit" [Undecided,New] 19:06:35 fungi: yes! thank you 19:06:38 fungi: pleia2 lifeless ^ but I am not sure of all the details 19:07:03 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 #link https://etherpad.openstack.org/p/tripleo-test-cluster 19:07:35 lifeless: I don't know the status on https://bugs.launchpad.net/openstack-ci/+bug/1217815 - any insights? 19:07:37 Launchpad bug 1217815 in openstack-ci "Tripleo ci service account in gerrit" [Undecided,New] 19:08:21 maybe he's sleeping in the middle of the night for a change 19:08:32 he's running the tripleo meeting in -alt :) 19:08:35 he is chairing in the other channel 19:08:39 oh, or that :/ 19:08:49 maybe we come back to this bug later/after meeting 19:08:55 that's all the updates I have 19:09:05 great work, pleia2 19:09:20 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 #topic Wsme / pecan testing (sdague, dhellman) 19:10:04 pleia2: clarkb made one. 19:10:08 i know a little about this, but would be better if one of them wants to go into detail 19:10:11 lifeless: bug done? 19:10:16 I didn't make an account 19:10:16 saw a the review for this trickle in this morning https://review.openstack.org/#/c/53136/ 19:10:26 pleia2: oh, then mordred did 19:10:28 clarkb: ^ 19:10:34 thanks I will update the bug 19:10:42 anyhow, bug can be closed, we have a suitable account. 19:10:49 tripleo-cd-bot IIRC. 19:11:28 okay, well, in absence of sdague and dhellmann, i'll attempt a tl;dr on the current topic 19:12:13 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 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 oh, sorry, stepped out for a sec 19:13:45 there is an additional desire to gate them against stable branches of devstack-integrated projects to avoid breaking stable released versions 19:13:51 oh! sdague can take over 19:14:12 well, I think you are basically completely on target 19:14:57 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 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 that will make pecan / wsme part of the big happy family 19:15:45 I am excited for what comes out of this. Is there any concern that we are massively overengineering the whole thing? 19:16:01 #link https://review.openstack.org/#/c/53136/ 19:16:04 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 I did however also propose a session about a bigger vision 19:16:17 http://summit.openstack.org/cfp/details/340 19:16:31 #link http://summit.openstack.org/cfp/details/340 19:16:33 excellent 19:16:40 because I think we might want to build something to more generically attack this for libraries beyond our control 19:16:53 but that's summit material 19:17:15 i hope it makes it into the schedule, because i want to talk about it too 19:17:22 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 anything else on the current topic then? 19:17:49 not from me 19:17:49 yes 19:18:23 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 but we shouldn't be gating openstack on wsme 19:18:40 something to think about at least 19:18:43 clarkb: how would openstack break wsme? 19:18:58 I actually think there is a direction flow in dependencies 19:19:13 so I'm not actually concerned that we could break wsme 19:19:19 sdague: if openstack were to continue using deprecated interfaces then wsme can't deprecate them and so on 19:19:55 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 symetric gating wouldn't solve that though 19:20:11 sdague: right I think they are both wrong :) 19:20:18 but need to think about it more 19:20:41 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 wfm 19:20:51 wfm 19:21:02 anything else on the current topic then? 19:21:05 I think the emergent behavior of these interconnections has shown we often poorly predict the future problems :) 19:21:27 I'm good 19:21:32 solving future problems is akin to premature optimization, agreed 19:21:51 #topic New etherpad.o.o server and migration (clarkb) 19:21:56 ohai 19:22:00 that happened, ja? 19:22:04 it did 19:22:28 any new fun there? 19:22:51 it's working great 19:22:52 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 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 pleia2: I will look 19:23:38 just one for etherpad :) 19:23:47 but yes overall the move went smoothly and we did an emergency nodejs upgrade Friday night as well 19:23:58 clarkb: and the old etherpad server still exists for the moment, right? 19:24:31 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 #action clarkb decommission old etherpad server eventually (after the summit) 19:25:16 please let us know if you see etherpad acting weird, but it seems to have done just fine 19:25:18 just so we don't frget 19:25:41 i've been using it fairly heavily for things since the upgrade, no sign of broken 19:26:12 i wish the etherpad the foundation uses for staff meetings were so nice and responsive as this one 19:26:39 fungi: their pads > 700 lines? 19:26:53 that's been an issue for me on my installation, and a know bug 19:26:55 sdague: we need to truncate the main one we use, but almost certainly 19:27:19 yeh, we rotate out pads every couple of weeks for that reason, keep them < 700 lines 19:27:43 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 also big +1 for ep_headings add by clarkb :) 19:28:15 https://etherpad.openstack.org/p/icehouse-qa-session-planning - example 19:28:18 sdague: I like the headings plugin too, wish I had dealt with it sooner :) 19:28:23 heh 19:28:27 #link https://etherpad.openstack.org/p/icehouse-qa-session-planning 19:28:59 nice 19:29:28 are we all set on etherpad talk for the moment? anyone have anything else for that? 19:30:01 #topic Third-party documentation editors (fungi) 19:30:26 just a quick update from a call i had with annegentle and a group of editors from o'reilly press 19:30:59 the foundation has a contract, as i understand it, to get one or more of the manuals bookified 19:31:27 so we're trying to figure out a workflow feedback loop between their editors and our authors 19:32:01 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 tentative schedule for the first iteration is to freeze from october 28 through november 5 19:32:47 fungi: what will the pushes back to gerrit look like? 19:32:54 they will publish their edits in a git repo which we can import and turn into a gerrit review 19:33:26 that can either happen manually initially or we can script it 19:34:02 i wanted to bring it up here mostly to talk through possible implementation details on our end 19:34:24 they are open to evolving the process over time as well, so none of this is set in stone 19:35:23 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 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 so they will edit in that world then push changes back to us 19:35:38 right 19:36:04 sounds like a very interesting direction 19:36:10 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 so the freeze period is to avoid merge conflicts? do we think that manually resolving the conflicts will be too difficult? 19:36:18 will they be joining us in -infra and asking questions? 19:36:47 so I can recognize them and get a sense of how to help? 19:37:03 clarkb: apparently they feel that the way docbook/xml works, diffs become massively painful to properly resolve merge conflicts on 19:37:11 anteaya: probably not, but you never know 19:37:41 fungi: well, maybe we should be arguing for sane markup >_> 19:37:42 okay, just if I get a brand new question, it helps to have context 19:37:54 fungi: but that is a different battle. If the doc team is ok with freezing content I am fine with it 19:38:13 I think it is a lot easier on them now that they are further ahead of the releases 19:38:33 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 wfm 19:39:00 I think it is a great idea 19:39:04 my remaining concern is that they heavily use github 19:40:04 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 uhm, hmm 19:41:04 are they going to want to preserve the history of those imports? or are they going to squash the commits? 19:41:05 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 private github repos aren't very open... 19:41:45 and while APL2 doesn't prevent it :/ 19:41:53 dhellmann: i suspect a squashed commit will be fine in this case since it's work for hire 19:42:32 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 ok 19:42:38 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 particularly with the freeze coming up so quickly 19:43:51 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 fungi: its less the proprietary stuff and more that the dev is closed 19:44:44 it's open to the dev team, right? 19:44:49 I mean the docs team 19:44:54 it's just not open to the world? 19:45:03 I assume it depends on how the repo is configured 19:45:13 or org, I am not super familiar with github ACLs 19:45:19 presumably the doc folks are going to need to send them changes 19:45:54 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 using it should actually make it easier to have a few people with access to pull changes back out 19:46:14 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 and put them into our open system 19:46:43 how will they be handling copyedits? 19:47:17 heh. i live with a copyeditor and i still don't understand your question ;) 19:47:25 iterative work? 19:47:49 yes 19:48:12 the idea is that by the end of the freeze their change is reviewed and merged 19:48:18 the o'reilly editors and compositors are going to want to make changes to the text (typos, phrasing, formatting, whatever) 19:48:35 merged into our upstream repo? 19:48:39 yes 19:49:06 and then the document is unfrozen and docs editors go into authorship phase for a period before the next freeze 19:49:27 at which point o'reilly updates their clone and starts editing again 19:49:35 so oreilly will work in the private repo and something/one will push the changes back upstream 19:49:42 ok, I think I've got it 19:49:45 right 19:50:04 this way we can reintegrate their edits 19:50:05 ok, this sounds better than what I had to go through with my book :-) 19:50:15 i can only imagine 19:50:32 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 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 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 and we're running tight already 19:51:19 I don't have much 19:51:38 #topic Open discussion 19:51:49 and before i forget 19:51:52 #action jeblair move tarballs.o.o and include 50gb space for heat/trove images 19:51:55 bug day continues, don't fall asleep :) https://etherpad.openstack.org/p/cibugreview-october2013 19:52:08 at the top of the file I included a link to New bugs that should be triaged 19:52:20 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 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 started the day with 190 bugs, down to 185, I'm hoping we can do better 19:52:49 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 good work on bugs pleia2 19:53:00 clarkb: yeah, jeblair always did a lot :) 19:53:15 clarkb: did anything on this https://etherpad.openstack.org/p/elasticsearch-optimization-suggestions help or was it just noise? 19:53:17 dhellmann: cool thanks 19:53:18 ryan has some changes in process to let us test the openstack incubated and integrated projects that use pecan already 19:53:21 yeah, i feel bad that i've not contributed as much to today's bugtrawl as i had wanted 19:53:32 I couldn't pass up three experts on elasticsearch 19:54:11 anteaya: a lot of it was stuff that I already sorted out 19:54:15 k 19:54:25 that's good 19:54:36 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 yes 19:55:02 that was what I kept hitting, because I don't have all that info either 19:55:06 just small pieces 19:56:18 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 sure 19:56:37 since honza and alexb also have that url 19:56:48 so may respond if they have something to respond to 19:56:53 cool 19:57:14 fungi: we forgive you, I may roll bug stuff over into tomorrow depending on how the rest of today goes 19:57:17 :) 19:57:35 oh, I owe some nodepool documentation updates for running a dev version, need to bootstrap sphinx on the nodepool repo 19:57:38 oh, don't forget i'm semi-afk the next couple days at the all things open conference 19:57:49 but back in full force on friday of course 19:57:57 cool, happy open conference 19:57:58 have fun 19:58:03 is that in raliegh? 19:58:04 (that rhymed!) 19:58:07 yeah 19:58:19 hence why mordred is going there after chicago 19:59:15 great meeting, fungi 19:59:45 thanks fungi 19:59:45 a-the-a-the-a-the-a-that's all, folks! 19:59:55 #endmeeting