19:01:16 #startmeeting infra 19:01:16 Meeting started Tue Oct 1 19:01:16 2013 UTC and is due to finish in 60 minutes. The chair is jeblair. Information about MeetBot at http://wiki.debian.org/MeetBot. 19:01:17 Useful Commands: #action #agreed #help #info #idea #link #topic #startvote. 19:01:19 The meeting name has been set to 'infra' 19:01:28 agenda: https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting 19:01:44 last meeting: http://eavesdrop.openstack.org/meetings/infra/2013/infra.2013-09-24-19.00.html 19:01:48 #link https://wiki.openstack.org/wiki/Meetings/InfraTeamMeeting 19:01:50 #link http://eavesdrop.openstack.org/meetings/infra/2013/infra.2013-09-24-19.00.html 19:02:09 #topic actions from last meeting 19:02:13 #action jeblair move tarballs.o.o and include 50gb space for heat/trove images 19:02:17 i did not do that 19:02:22 as it turns out, friday was very busy. 19:02:51 i'll try again later when things are a bit calmer. 19:03:53 the other action item we can handle in a different topic 19:04:02 #topic Trove testing (mordred, hub_cap) 19:04:15 mordred: you were going to understand and explain the mysterious caching issue with the heat/trove test plan 19:04:44 heyo 19:04:48 mordred: what's the latest there? and what is trove testing blocked on? 19:04:52 o/ 19:04:54 sorry I'm late 19:05:16 jeblair: I have not achieved my task. I still need to understand and explain the mysterious caching issue 19:05:19 lifeless: around? 19:05:34 jeblair: i have achieved my task of waiting 19:05:46 mordred: he's running the tripleo meeting 19:06:00 ah. wow. what a poorly timed meeting overlap 19:06:03 :) 19:06:14 jeblair: I will raise sorting that on my tdl 19:06:53 mordred: in the tripleo meeting 19:07:13 clearly a popular meeting time 19:07:14 mordred: is it true that we can't or should not proceed with anything in https://etherpad.openstack.org/testing-heat-trove-with-dib until you understand this issue? 19:07:18 mordred: it's not mysterious, we want to cache further along than just 'we downloaded stuff' 19:08:56 lifeless: the details are a thing we want to dig more in to - because dib is not going to make use of pre-downloaded base images in the way that we would pre-download them right now 19:09:33 lifeless: I believe there is a dib task identified to be able to be pointed at a locally downloaded pre-cached base image 19:10:12 jeblair: if we proceed without the sorting thing, each build job will download a base image from canonical and redhat directly 19:10:18 without sorting the caching thing 19:10:23 depending on what you mean we either already have that 19:10:28 or there is no task identified. 19:10:37 you did the work we talked about in Seattle already? 19:11:08 there may be confusion 19:11:17 great. we will convene to sort it out 19:11:21 mordred: when? 19:11:26 when we can do it with higherbandwidth 19:11:33 jeblair: how about right after tripleo and infra stop meeting 19:11:37 lifeless: ? 19:12:22 * mordred assumes silence to be assent 19:12:34 mordred: I have the OSRB then 19:12:38 mordred: but today, certainly. 19:12:42 ok 19:12:54 jeblair: we will sort that out today 19:12:57 #action mordred understand and explain the mysterious caching issue with the heat/trove test plan 19:13:16 hub_cap: any further thoughts? 19:14:16 #topic Tripleo testing (mordred, clarkb, lifeless) 19:14:55 mordred, lifeless: any progress on plan C? 19:15:25 or otherwise anything we should chat about? 19:15:52 jeblair: nothing really to chat about - plans are underway to get plan C moving 19:16:00 jeblair: your thoughts on the tripleo mail I sent yesterday would be appreciated 19:16:11 jeblair: from a 'implications to the openstack project' perspective 19:16:28 jeblair: also, lifeless sent an email yesterday to openstack-dev outlining a plan around plan c related things 19:16:29 jeblair: nosir 19:16:51 jeblair: tl;dr we're proposing a group of people running a production cloud deployed tripleo style, per commit, with atc's getting credentials 19:17:04 jeblair: and the use of kanban to manage wip and changes to that environment 19:17:32 jeblair: (the tie-in to plan C is that this is common infrastructure to the proposed cloud-test setup 19:20:43 having a non-proprietary kanban would be high up the list of preferences, i think 19:21:09 * fungi is not a huge fan of trello for this, but i guess it's a stopgap 19:22:16 perhaps that's something which would eventually meld well with storyboard 19:22:26 yah. lifeless and I had a chat about that where I expressed concerns about trello - he said (and says at the bottom of the email in the footnote) the idea with the kanban is to experiment to see if it's worth pursing in an infra way and with infra 19:22:38 before asking infra to provide a thing which may actually not be something that's helpful 19:22:54 we should be careful with that 19:23:09 and yes, I agree -might give good feedback on storyboard features 19:23:13 jeblair_: I could not possibly agree more 19:23:39 we've asked projects to stop using trello and similar services before because tool proliferation is not helpful to a unified project 19:23:43 but experimentation is important 19:23:52 we're probably on the same page. just reiterating. 19:23:58 ++ 19:24:28 slippery slope 19:24:46 unified project template w/ all tools like kanbans and etc. is a dream for all new projects 19:24:48 I think it's clear that trello is a non-starter long term 19:24:54 and not for only new 19:25:07 so, for the record 19:25:35 the existing tools in the openstack suite are a poor fit for visualising wip and operational status 19:25:47 we don't /like/ trello 19:26:03 and will be delighted, if the experiment concludes with 'yes, kanban solves the issues we're trying to solve' 19:26:13 to work closely with infra to get an openstack-suitable kanban in place. 19:26:19 no argument from me, i understand it's a pragmatic choice for the moment 19:27:03 so to bring this back on topic; how does this interact with the tripleo test plan? 19:27:06 lifeless, mordred: ? 19:27:25 the tripleo test plan has a big handwave of 'tripleo will provide a cloud' 19:27:26 jeblair: the cloud they are planing to spin up is part of the first steps of plan c 19:27:29 this is an enabler for that 19:27:50 we don't need anything from infra at this point, but wanted you to be aware of how we're structuring things 19:29:27 lifeless: makes sense. i like the general direction of open ops. 19:30:04 anything else on this topic? 19:30:07 jeblair: and *if* you have concerns about e.g. reliability of the test results etc from the open ops setup, we'd rather know sooner than later 19:30:25 jeblair: the other aspect is once we're a bit more mature 19:30:35 we'll have an OpenStack cloud infra can use if they want. 19:30:57 We will let you know when it's reliable enough that you wouldn't be crazy to put stuff in it. 19:31:25 lifeless: that would be great. we're, uh, happy to help drive load. :) 19:32:44 we are a lean-mean-load-generating-machine 19:33:01 more mean than lean 19:33:02 emphasis on mean 19:33:06 heh 19:33:14 #topic Savanna migration from stackforge to openstack org 19:33:15 * mordred is getting pudgy 19:33:23 SergeyLukjanov: hi there 19:33:27 hi 19:33:44 I've prepared https://review.openstack.org/#/c/48491/ 19:33:51 #link https://review.openstack.org/#/c/48491/ 19:34:05 * ttx breaks for 13 min 19:34:50 so we just need to schedule a downtime for the gerrit renaming 19:35:38 * mordred is in north carolina this weekend at a wedding 19:35:52 my event coordinator says i'm free all weekend 19:36:14 i think i should be available sat/sun morning 19:36:22 I _may_ be able to help on Saturday, but don't really know specific schedule. I'll certainly help if I'm not off being weddinged 19:36:25 it'll be good for us (savanna team) to do it this weekend 19:36:40 we're in the middle of the rc window... 19:36:54 but based on last weekends load, i think we can handle having a bit of weekend downtime 19:37:03 yah. most of last weekend was me 19:37:11 trying to get wheels working 19:37:43 and versioning 19:38:00 could I help with smth from my side? 19:38:27 SergeyLukjanov: your change wraps puppet-savanna in with the rest of the work... is that part of the savanna project or part of the openstack-puppet group's work on stackforge? 19:39:00 fungi, we're working on puppet manifests for savanna and I hope that we'll publish them soon 19:39:03 so how about saturday 'morning'? oct 5 1600 utc? 19:39:17 * mordred believes puppet-savanna should stay in stackforge - we don't have any precedence in the project for chef or puppet things being considered core project code 19:39:18 jeblair: wfm 19:39:22 it's not a part of openstack-puppet group 19:39:54 mordred, good point, I'll move it back 19:40:11 SergeyLukjanov: thanks! (obviously, you can keep savanna-core having core on it if that makes sense for you guys) 19:40:26 jeblair, wfm too 19:40:29 SergeyLukjanov: sounds good. i think puppet or chef deliverables would be a scope expansion for the tc to consider 19:40:51 SergeyLukjanov: cool, it'll be good to have you around to help make sure everything works after the move 19:40:57 wait, puppet or chef? 19:41:08 jeblair, it's just puppet manifests for savanna installation 19:41:26 SergeyLukjanov: I thought savanna used disk-image-builder? 19:41:38 yah. but we've deliberately kept those non-openstack so far 19:41:49 lifeless: I believe he means to deploy savanna, not for use by savanna 19:41:59 mordred: that would be heat then 19:42:09 lifeless, yep 19:42:30 we're using dib to build images used by savanna 19:42:31 yeah, puppet-savanna seems like something which could also benefit from closer work with the stackforge/puppet-.* devs long term, for added ecosystem consistency 19:42:35 and puppet to install savanna 19:42:46 fungi: ++ 19:42:55 SergeyLukjanov: makes sense to me 19:42:59 I think it's ok to keep puppet-savanna in stackforge for now 19:43:05 bye it's empty now 19:43:09 btw* 19:43:09 :) 19:43:12 heh 19:43:52 we already have worked manifest but it depends on some mirantis internal stuff 19:44:01 #action jeblair announce gerrit downtime oct 5 1600 utc for savanna rename 19:44:11 I have a question about docs 19:44:19 fungi, mordred: can you think of any other maint we should do during then? 19:44:22 is it ok to publish them to docs.o.o? 19:44:24 annegentle_ loves docs questions 19:44:42 I do!!! 19:44:47 I believe so - I think we've been publishing incubated tocs to doc.o.o so far yeah? 19:44:49 jeblair: none springs to mind. maybe things will come up between now and then we can glom onto it 19:44:53 mordred: i think so 19:45:06 jeblair: unless we want to move melange to stackforge, no 19:45:10 (I've added it due to the marconi config) 19:45:41 (and delete openstack-dev/openstack-qa which is a dead fish) 19:45:42 SergeyLukjanov: In the past we've published to docs.o.org/incubation but it's kind of a case-by-case 19:45:45 but I don't care about either really 19:46:29 annegentle_: for developer docs too? 19:46:43 mordred: we can probably do those two additional things without needing to announce them, if we feel like it 19:46:45 annegentle_: (eg, project docs rather than manuals) 19:46:51 jeblair: nah we haven't had it come up for project docs/ dev docs 19:47:02 I mean dev docs 19:47:14 jeblair: it was for API specs, user info, deployer info, and we've grown SO much since, I say we should probably come up with a set of guidelines 19:47:38 annegentle_: i love guidelines. ESPECIALLY published guidelines. :) 19:47:44 jeblair: I'm not super comfortable with incubated projects getting an openstack.org domain, if I'm honest 19:47:50 jeblair: it feels like getting to use the brand 19:48:26 review.o.o and git.o.o are the same way for using brand) 19:48:44 annegentle_: i know, though they are projects that have been accepted into a program by the tc, which is why we have been putting them in the openstack github org 19:48:56 on the other hand it's unfortunate if we don't have any way to publish their documentation during incubation, other than to tell them to use rtfd or something 19:49:01 jeblair: oh well if that's the case, they're not incubating 19:49:08 jeblair: they're integrated 19:49:20 jeblair: sorry need more context :) 19:49:28 fungi: I'm fine with rtfd 19:49:34 annegentle_: nope. ingerated means they're part of the release - incubated means they get to be a thing we as a project are actually working on 19:49:40 but... it's possible ... 19:49:54 that the infra meeting is the wrong place to dig in to integrated/incubated branding semantics 19:50:04 mordred: I know that, what's SergeyLukjanov's project that we're talking about? 19:50:07 (other than the fact that all of us like talking about things) 19:50:10 annegentle_: savanna 19:50:23 annegentle_: recently voted in as incubated and we're scheduling the move to the openstack/ git org 19:51:02 mordred: Incubating -- my outline for docs would be quite conserving of resources 19:51:40 mordred: wiki and rtfd likely but would entertain other ideas 19:51:44 annegentle_: yah. I would not expect incubated projets to be covered by the docs team. you guys are busy enough as it is 19:51:53 mordred: we don't even cover integrated that well 19:52:04 but that's separate from whether they are permitted to publish their own docs to docs.o.o.... 19:52:07 but I think the question here is about docs.openstack.org/developer 19:52:16 to push the in-tree sphinx docs 19:52:20 mordred, yep 19:52:29 http://docs.openstack.org/developer/ironic/ 19:52:32 for instance 19:52:53 if that's not ok, we should probably circle back and make a plan 19:53:30 based on past practice, other currently incubated projects, the way that the git repos are organized, and i think the spirit of the incubation process, we should continue to let incubated projects publish to docs.o.o/developer.... 19:53:54 ++ 19:53:56 jeblair, it looks consistent I think 19:54:06 (by spirit of incubation process, i believe the common understanding is that the incubation period is when a project is expected to bring themselves inline with how openstack projects operate) 19:54:08 clarkb: you're alive! 19:54:17 barely 19:54:44 lunch happened. is now over 19:55:36 mordred: I'm thinking /developer/ironic got in by us just saying 'don't publish to rtfd and docs.o.o"? 19:55:41 mordred: do I remember it wrong? 19:55:59 jeblair: good point 19:56:46 and honestly I can't argue long or hard on a hard line for docs.o.org/developer -- the jobs and content aren't maintained by docs team but there are still perceptions about docs 19:57:21 so it feels like a slippery slope 19:57:48 annegentle_: I have almost no memory of anything - and I don't like slippery slopes 19:57:56 mordred: heh. me too 19:58:10 the alternative risk, also a slippery slope, is that we wind up with other places the project publishes documentation not covered by the docs team 19:58:32 i'd hate to think we're making it harder for projects to integrate, right as we're pushing them to be more proative in integrating before they become incubated 19:58:44 can we move them to developer.openstack.org so they aren't associated with the docs team? 19:58:47 before they become integrated, rather. 19:59:10 dhellmann: might be useful but we get doc bugs on the wiki so who knows :) 19:59:23 annegentle_: welcome to the internet? ;-) 19:59:30 dhellmann: and, I'd kinda like to have that domain for devs building cool stuff on openstack 19:59:38 dhellmann: not developing openstack itself? 19:59:40 dhellmann: but yeah 19:59:45 well, i think all projects get more than their share of miscategorized bugs, so that's probably not something we'll be able to put a stop to regardles 19:59:47 s 19:59:49 sure, that was just a suggested domain, there could be another 19:59:56 fungi: +1 19:59:56 dhellmann: ok sure 20:00:03 what about annegentle.openstack.org ? 20:00:04 * mordred ducks 20:00:08 mordred: ha 20:00:09 haha 20:00:21 how about a gated garden like facebook or google+ (facepalm) 20:00:22 on that note 20:00:26 #endmeeting