Thursday, 2011-05-19

*** dragondm has quit IRC00:06
*** westmaas_ is now known as westmaas00:54
*** adjohn has joined #openstack-meeting00:56
*** medberry is now known as med_out01:13
*** blamar__ has joined #openstack-meeting01:17
*** blamar__ has quit IRC01:50
*** blamar__ has joined #openstack-meeting03:02
*** santhosh has joined #openstack-meeting04:07
*** blamar__ has quit IRC04:17
*** ThePing has joined #openstack-meeting04:56
*** ThePing has left #openstack-meeting04:56
*** littleidea has quit IRC06:51
*** Binbin_ has joined #openstack-meeting06:53
*** Binbin_ is now known as Binbin06:53
*** nerens has joined #openstack-meeting07:36
*** katkee has joined #openstack-meeting08:34
*** Arminder has joined #openstack-meeting09:08
*** adjohn has quit IRC09:13
*** adjohn has joined #openstack-meeting10:26
*** littleidea has joined #openstack-meeting10:32
*** littleidea has quit IRC10:44
*** katkee has quit IRC11:00
*** littleidea has joined #openstack-meeting11:35
*** adjohn has quit IRC11:36
*** littleidea has quit IRC11:50
*** littleidea has joined #openstack-meeting12:07
*** dprince has joined #openstack-meeting12:12
*** adjohn has joined #openstack-meeting12:17
*** adjohn has quit IRC12:19
*** littleidea has quit IRC12:34
*** littleidea has joined #openstack-meeting12:49
*** littleidea has quit IRC12:50
*** santhosh has quit IRC12:55
*** littleidea has joined #openstack-meeting12:57
*** adjohn has joined #openstack-meeting13:03
*** adjohn has quit IRC13:15
*** adjohn has joined #openstack-meeting13:17
*** katkee has joined #openstack-meeting13:21
*** nerens has quit IRC13:34
*** med_out is now known as medberry13:46
*** edconzel has joined #openstack-meeting14:11
*** hub_cap has joined #openstack-meeting14:16
*** rnirmal has joined #openstack-meeting14:30
*** dendro-afk is now known as dendrobates14:32
*** jkoelker has joined #openstack-meeting14:39
*** adjohn has quit IRC15:02
*** katkee has quit IRC15:03
*** dragondm has joined #openstack-meeting15:03
*** nerens has joined #openstack-meeting15:25
*** katkee has joined #openstack-meeting15:25
*** littleidea has quit IRC15:35
*** dprince has quit IRC15:42
*** johnpur has joined #openstack-meeting15:58
*** dendrobates is now known as dendro-afk16:02
*** hub-cap has joined #openstack-meeting16:06
*** hub_cap has quit IRC16:06
*** hub-cap is now known as hub_cap16:06
*** katkee has quit IRC16:40
*** jbryce has joined #openstack-meeting17:13
*** hub-cap has joined #openstack-meeting17:29
*** hub_cap has quit IRC17:30
*** hub-cap is now known as hub_cap17:30
*** littleidea has joined #openstack-meeting17:42
*** dprince has joined #openstack-meeting18:02
*** katkee has joined #openstack-meeting18:19
*** littleidea has quit IRC18:33
*** dendro-afk is now known as dendrobates18:34
ttxjbryce: meeting ?19:00
jbrycewho all is here?19:01
*** hub_cap has quit IRC19:01
openstackMeeting started Thu May 19 19:03:33 2011 UTC.  The chair is jbryce. Information about MeetBot at
openstackUseful Commands: #action #agreed #help #info #idea #link #topic.19:03
jbryce= )19:03
jbryceagenda -
jbryce#topic previous actions19:04
*** openstack changes topic to "previous actions"19:04
ttxEric and I had to draft a project model description19:04
*** anotherjesse has joined #openstack-meeting19:04
jbrycettx and I sent out drafts19:04
*** ewanmellor has joined #openstack-meeting19:04
ttxVisible at
ttxyay, quorum19:05
jbryceI went ahead and added it to the page19:05
ttxjbryce: ok19:05
johnpurjbryce: i had a couple of comments, sent back on the list19:05
*** hub_cap has joined #openstack-meeting19:06
anotherjesseproject resources <- kinda confusing to say that - since code has its own license19:06
anotherjessemaybe defining resources as things like domains, ...?19:07
anotherjessestrike that19:07
ttxAnne suggests we add "documentation" as a Commonality?19:08
ttxI'll add it19:08
ewanmellorIs "should strive to use the same standards, in code" meant to imply the same programming language for all core projects?  I presume not, but it sounds like it does.19:08
annegentleI didn't put together a "doc shepherding guidelines" proposal in time for this meeting, but I can do so in time for next week's19:09
johnpurjbryce: the way you havethe page laid out it implies that the 5 bullets at the top apply to all 3 project types... is this what you mean?19:10
edayewanmellor: it's mainly about consistency when possible. For example, all Python projects should use similar libs/pep8/etc. Certainly doesn't imply the same language19:10
ttxjbryce: agree with johnpur that "incubation assets" needs a definition19:11
jbrycejohnpur: they seemed like broader concepts so i just stuck them at the top19:11
johnpurfor instance, related projects don't have the constraints or the supportgiven tot he other 2 classes19:11
*** jmckenty has joined #openstack-meeting19:11
ewanmelloreday: That's what I expected.  I think the language could do with some work.19:11
jbrycejohnpur: feel free to edit the page19:12
johnpurha ha... walked into that one!19:12
jbryceon the incubation assets i agree that it's fuzzy, but we haven't really defined what those are yet, so i was hoping to get some input19:12
ttxjohnpur: at least, you are free to try19:12
ttxwikis are not tha tgood at simuletaneous edits19:12
jbrycewe said they could get a subdomain, they could potentially use the build infrastructure....what else should go in there?19:13
johnpuri'll defer any edits until later to give others room to update19:13
jmckentyshould we pull that page into etherpad for some editing19:13
jmckentyjbryce: what about the mailing lists?19:13
ttxjmckenty: that's where my part was originally placed :)19:13
edayjmckenty: that's really a community thing, anyone can use the mailing list, incubated or not :)19:14
ewanmellor"approved for entry into the Incubator program": should that read "approved by the PPB"?19:14
jmckentyyes, although it's implied19:14
ttxok, stop editing, I'll push to etherpad19:14
johnpuri agree with where jmckenty is going... we just need to be very explicit about all aspects, on a per project class basis. Or else, folks will be very confused, etc.19:15
jmckentyeday: I think the fact that the mailing list is a community resource, if that's in fact the case, should be explicitly spelled out19:15
jmckentyotherwise I would be tempted to shout "off topic" occasionally19:15
edaymakes sense19:15
jmckentythe volume on that list means I rarely read it now19:15
jmckentyI only read 100% on the -poc list19:16
ttxplease edit on etherpad19:16
jbrycewhile the editing is happening there, last week we had a couple of actions as well: checking on the forums which are now live and johnpur was going to verify that QnA as a replacement for Launchpad Answers was the route we wanted to take19:19
jbrycerelated to that second item, we actually had a proposal:
johnpurrelated projects do or do not have the "right" to the channels, ml, etc.?19:20
ttxanotherjesse: does my new paragraph fit the bill for your concern ?19:21
jmckentyjbryce: looking at QnA now...19:21
anotherjesselooks good19:21
jbrycejohnpur: not sure how to define those rights19:22
edayjohnpur: I would say do, are we really going to moderate? We should avoid business advertising, but project announcements seem appropriate19:22
jmckentyeday: how do you differentiate those?19:22
johnpurjbryce: concensus is that Q&A style is preferable... the proposal looks fine... i advocate we use another open source project as the basis.19:22
jmckentye.g., if I have a freemium product, can I announce that?19:22
jbrycei think we have enough vocal people on the mailing list who will call a spade a spade if someone comes on and does shameless promotion that is annoyingly off topic19:23
jmckentyjbryce and johnpur - I would suggest that if we're going to proliferate community communication resources (forums, QNA, ML, etc), that we really drive forward an *integration* effort across those19:23
jmckentye.g., everyone who wants a new tool needs to step up and help moderate content ACROSS tools19:24
jmckentypulling discussions out of forums and adding them to QnA, etc19:24
edayjmckenty: I would say free as in beer and source code19:24
johnpurmy fear is that if the communication channels are wide open that we may have scoping issues19:24
jmckentyin my experience, more tools is not necessarily better, and I think we should push pretty hard on the ownership and management aspects of these - not just selection and install19:25
jmckentyjohnpur: I agree on the scoping issues as well19:25
vishyI'm pretty happy about the QnA site idea19:25
vishyi find launchpad questions to be pretty annoying19:25
jmckentyWho owns it, then - spector?19:25
ttxvishy: yes, we need something that allows the best questions and the best answers to be very apparent19:26
jmckentyor is that something that anne gentle can help with?19:26
johnpurjmckenty: for now spectorclan can be designated the owner. longer term i am looking to bring in a technical community manager that should pick this up.19:26
jmckentycan we take the most vocal proponents of both QnA and Forums, plus Spector, plus Gentle, and call that a "Community tools working group"?19:27
vishyttx: and allows questions and answers to be edited later when things change19:27
jmckentyjohnpur: I have an awesome candidate for you19:27
johnpursend the name along, with contact info!19:27
ttxjmckenty: we all have :)19:27
johnpurnext week i am going full court press on finding the right person19:27
jmckentyreally? If you have awesome candidates for ANYTHING, you should be emailing me ;)19:27
jmckentysorry, OT19:28
ttxjmckenty: heh19:28
jmckentyback, to my other point - anyone second calling this a working group?19:28
jmckentyI'm really concerned about an Ad-hoc approach here, I think we'll end up with shark tank19:28
ttxjmckenty: I think we can ask on the ML for QnA lovers19:28
ttxto set up the core moderator group19:29
ttxsomeone with experience with QnA would be a +19:29
jmckentyttx: +119:29
johnpurjmckenty: +1 to setting up some structure around community tools19:29
vishyI'm willing to contribute a lot to answers on the site19:30
johnpuri can take this and organize19:30
jbryce#action johnpur to organize a community tools working group19:30
* vishy is tired of being asked the same questions over and over19:30
jmckentyvishy: I'm much less worried about answers than I am about cross-tool collaboration19:30
jmckentye.g., pulling discussions from ML and Forum and turning them into QnA, and sending QnA pointers to the ML19:30
ttxjohnpur: you'll push an email to ML asking for volunteers to admin the QnA site ?19:30
johnpurjmckenty: define cross-tool collaboration?19:30
jmckentyalso making sure the THEMES / HEADERS for the various sites all link to each other19:31
anotherjessevishy: what do you want for lunch? vishy: want to get a drink,  .... ;)19:31
jmckentye.g., like having one schedule for the conferences19:31
ttxjmckenty: that can be a group of moderators from each media19:31
jbrycejohnpur: you might want to follow up directly with everett as well since he actually went to the effort to propose it19:31
jmckentyas long as they work together, yes <-- ttx19:31
johnpurjbryce: agree19:31
ttxI prefer several groups working with each other, rahter than a single group being expoert in forums+QnA19:31
vishyanotherjesse: probably, asking those questions would be more effective if you did them through the site19:31
johnpurttx: we will figure out the right structure19:32
jmckentyk, last request, then:19:32
jmckentycan we make sure the set of community tools is an openstack project19:32
jmckentywith a buglist19:32
jmckentya release schedule19:32
jbrycejmckenty: i'm going to hold you to that19:32
jmckentyand a PTL?19:32
jmckentyThere have been community complaints about not being able to get bugs on the .org site fixed19:33
jmckentyAnd I think a "patches-welcome" approach to these tools *might* help19:33
johnpurjmckenty: this becomes somewhat of a meta-project... specifically, getting changes to is a challenge, as it is not editable by the community.19:34
ttxhmm... not sure there is enough commonality on the tools19:34
johnpurlet me think about this, i will report back next week19:34
ttxrather have several separate ways to track requests19:34
jmckentywell, they're bug reports, not requests19:35
jmckentythat's the mindset issue that I'm bringing up19:35
jmckentyif you think of them as community resources, and the community wants to fix something, it's a bug19:36
jmckentynot a request to RAX19:36
johnpuri will say that some of this crosses over intot he realm of how the openstack assets are managed, who controls what, etc.19:36
jmckentyyes, exactly. But we're proliferating those assets19:36
johnpurwe need to provide more clarity here19:36
jmckentywithout having defined the controls19:37
johnpurjbryce: another action, for you and me to work on together?19:37
jmckentycan I again push back and suggest you include a non-RAX person in that?19:37
*** dprince has quit IRC19:38
jmckentyjust for outsider perspective19:38
jbryce#action jbryce, johnpur work on tracking/managment of and new community properties19:38
jmckentyI nominate ewanmellor ;)19:38
jmckentyBut I'll take it if he doesn't19:38
jbrycewe'll loop you in19:39
jbrycelet's keep moving19:39
jbryce#topic Pre-Announced vs. Dynamic milestone plan for core projects19:39
*** openstack changes topic to "Pre-Announced vs. Dynamic milestone plan for core projects"19:39
jbrycettx: want to lead this one?19:39
ttxI've been working on the release schedule for Diablo for approval by the PPB19:40
ttxIt can be seen at
ttxAs you can see we have a full milestone plan for Nova and Glance19:40
ttxBut just the "next milestone" for Swift.19:40
ttxThe question is: do we accept, for core projects, some restricted visibility on the milestone plan19:40
ttxnotmyname will probably elaborate on Swift team's position, which wants to be able to set the next milestone date and version number a few weeks before its delivery19:41
ttxI think this affects openness and transparency: potential contributors, as well as downstream users (other than rackspace) would get restricted information19:41
ttxIt also drifts from our principle of time-based milestones19:41
ttxso I was wondering if that was ok with the PPB, and we can ack the schedule as is19:42
ttxif yes, let me know if I can consider the release schedule, as presented, "confirmed" :)19:43
edayI thought we previously decided that PTLs can determine their own schedule as long as they may the large integration releases, so are you proposing we possibly remove that previous decision and push for more schedule governance?19:43
jbrycei know we have a principle of time-based releases, but did we have a principle of time-based interim milestones?19:44
vishyi don't really mind.  I think it makes sense for a project that is essentially feature complete19:44
notmynamewhew. sounds like I may not have to give my speech ;-)19:44
ttxeday: we decided that they could come with the plan they want, not that the plan could be dynamic19:44
ttxeday: but we can decide that dynamic milestone plan is ok :)19:45
edayahh, ok19:45
johnpurthe major issue with not declaring the plan up front is lack of direction tot he community19:45
johnpurmaking it hard for outside folks to contribute19:46
ttxjohnpur: right, it's not the best way to attract contributors19:46
jmckentythat sounds like a topic for the design summit19:46
notmynameplans for the entire release (eg diablo) are still announced19:46
ttxjohnpur: also makes yout roadmap a bit less readable19:46
jmckentye.g., I don't think we've been asked yet to provide more structure on per-project milestones, isn't that really a PTL ballywhak?19:46
jbrycei would expect most of the community to be planning around the releases anyway, especially on a more mature project19:46
ttxok, we can try that and see in 6 months how well it flew.19:47
johnpurjbryce: perhaps19:47
jbrycei think i'd prefer to leave it up to the PTL and see if it actually does create barriers to entry or contribution19:47
johnpurbut RAX is not following this on their production pushes. Why would we think that Internap or other SP's deploying Swift would not want to track interim features and push asap?19:48
ttxjohnpur: good point19:49
johnpurat least have an idea when features will show up in a stable version of trunk19:49
jbrycenotmyname: do you have any plan for handling the other milestones or the features that aren't in the first one?19:50
*** littleidea has joined #openstack-meeting19:50
notmynamewe plan to track features in diablo19:50
notmynameand as they near completion we will be able to better set dates for milestones19:51
ttxnotmyname: so it's feature-based milestones and time-based releases ?19:51
notmynamemy goal is to have milestones roughly every 4-6 weeks with an announcement of them 2-4 weeks ahead of time19:51
notmynamettx: yes19:52
jbryceis there a way for others to track that? to see what features are being worked/nearing completion?19:52
edayjbryce: status on blueprints targetted for diablo19:52
jbryceok...well perhaps we should take an actual vote on approving the diablo schedule as stands with dynamic milestones for swift19:55
ttxnotmyname: any reason why you can't use monthly milestones, and just let the features that are in be delivered in the next milestone ?19:55
ttxnotmyname: is it that it delays features delivery in milestones too much in corner cases ?19:55
notmynameI'd argue that it actually reduces transparency for the releases we have19:55
ttxnotmyname: explain?19:56
notmynameif the PPB declares, we can do time-based releases. we'd prefer not two. we have 2 reasons for this19:56
notmyname1) letting the project have more autonomy and more control over it's interim releases19:57
notmyname2) if we do time-based releases, it will not line up with the internal releases we do here. what that means is that we will be forced to have "Secret" releases19:58
dendrobatesdamn, the meeting is on my google calendar for now.  How did I get an hour off?19:58
johnpurnotmyname: can you explain your internal release rythym?19:59
jbrycedendrobates: it's been updated on the google calendar, but it seems like the invite did not get updated for some people19:59
notmynamefor example, we are currently running 1.3.0-7 right now. it's a release, but a "secret" one because it's not part of a milestone. we would like to be more open about the official releases and have them line up better with the milestones19:59
edaynotmyname: is it possible to adjust internal releases to the public openstack cycles?19:59
notmynamenot as much as I'd like because there are more people involved (ops, qa, product)20:00
ttxnotmyname: I fear that alignment with RS operational needs will ultimately lead to milestones being announced at the very last moment20:01
ttxnotmyname: though I understand your will to not duplicae QA20:01
notmynameI think it's a valid concern. and I don't want to tie swift to RAX. but I also think that we can commit to not doing that. working with these groups at rax and (hopefully) others outside of rax, i can get a good feel of what and when a release should be20:02
jbrycei'm still on the side of letting swift try the dynamic milestone plan for now20:03
jbrycelooking at the blueprint link, you can see that there's not an unending list of features to sift through20:03
notmynamehistorically, we have not fallen into the feature-based-releases-never-ship trap, so in part, I'd like to only solve that issue when/if we actually have it20:03
jbryceand if it becomes a problem, i'm sure we'll hear complaints about it and can adjust20:03
ttxI'm ok with trying this and reconsider at next design summit.20:04
ttxWe'll see how well it flew by then.20:04
notmynameagreed. ttx and I talked for a while about bridging the RAX-openstack release cycle gap before coming to this plan. I like it more that ttx does, but I think it will work20:04
ttxjbryce: can the PPB approve the release schedule as it stands ?20:05
jbryce+1 from me20:05
ttxthat means setting Sep 22 as the release date20:06
ttx+1 from me, obviously :)20:06
eday(and lets revisit after release to see how things worked out)20:06
johnpur+1 on setting Sep 22 as the date, +0 on having core projects that cannot project timelines over the course of the next announced release (6 month window)20:07
jbryce#agreed Diable release schedule approved:
jbryce#topic Other topics20:08
*** openstack changes topic to "Other topics"20:08
* ttx sets status to "approved"20:08
johnpurwhat is going to happen when i go to the ptl's and ask for a 12 month roadmap projection? or ask about a +12m vision for their project? BTW, this is coming at you guys... :)20:08
* jbryce hears crickets20:09
* vishy hides20:09
jbrycethat's going to be hard to do with time-based milestones or not20:09
johnpuran action that came out of the ds was a strong desire for guidance past the upcoming release...20:10
vishynot sure how to approach that exactly20:10
jbryceright, but i don't know that time-based milestones is a solution for that. you're looking at multiple 6-month releases at that point20:10
vishyI don't really see the value of planning outside of customer feedback for > 6 months20:10
johnpurpeople are betting their businesses on openstack, they deserve some visibility into the future, business does not run with 6 month visibility windows20:11
jbrycewhich will be fuzzy, for sure, but also i would say we try to connect as much as possible to releases rather than milestones20:11
vishywe haven't come accross any features that need more than six months unless you count slippage20:11
johnpurvishy: federation?20:11
dendrobatesjohnpur: they want influence not visibility20:11
johnpurvishy: workload portability?20:11
johnpurvishy: advanced networking?20:12
ttxjohnpur: will be difficult to get with 6-month elected PTLs20:12
johnpurdendrobates: visibility implies discussion, ie influence20:12
vishythose are all not available in this 6 month window20:13
vishybut i don't think they require > 6 months to implement20:13
johnpurvishy: my point!20:13
vishyI don't think we can maintain our idea of design summits planning for next release if we are planning features out at that scale20:13
ttxIt's difficult already to get a clear feature plan for diablo... ;)20:13
edayI wonder how useful a feature list beyond diablo would be? trying to take into account current task slippage, no discussions around those featuers until E design summit, etc.  Even if I had that list, I wouldn't bet any business on it :)20:14
johnpurit is important that we give guidance to the vision and direction, even if we need to wait 1 or 2 ds cycles to get to the implementation20:14
vishyeday: I agree.  It is just imaginary feature planning20:14
jbrycei think it would be impossible to give people dates on any of that, but the thing that people are looking for is direction and some approximation20:14
johnpuri will stop now :)20:14
johnpurbut ptls... you are forwarned!20:15
jbrycethey'd like to know if thing X is even something people are thinking about20:15
vishyjohnpur: we can make stuff up and call it "marketing" but i don't see any real value from an implementation perspective20:15
jbryceand something like the networking services is definitely going to extend beyond diablo20:15
notmynamein that case, make a blueprint for it and don't target it to a series yet20:15
ttxjohnpur: each dev group can have their own +12m roadmap20:16
ttxbut the project, in itself, would be hard-pressed to guarantee it20:16
jbryceblueprints that aren't targeted are fine20:16
johnpurvishy: agree to disagree. if we do not succeed in federating os clouds it will be a fail. this is not imaginary, just not being implemented currently.20:16
ttxjohnpur: I think "Ozone" for example, can have a +12m plan. They know their resources and what they want to work on20:17
vishyjohnpur: what value does saying that it is a planned feature if we can't implement it though outside of marketing?20:17
ttx"OpenStack" ? not so much20:17
vishyLarge features are dependent on an actual implementation team/group20:17
ttxI mean, nobody knows what will be in the Linux kernel in one year.20:18
ttxthough lots of companies are betting their business on it.20:18
vishyI can say that we plan on federating in 12 months, but without a team to back it up, it is kind of useless imo...20:18
vishyvishy: I'm happy to do it for marketing reasons though :)20:18
jbryceit's not just marketing20:18
*** jmckenty has quit IRC20:18
johnpurvishy: it gives direction to current implementations, if there are dependencies or potential side effects20:18
jbryceit will encourage people to pitch in on the things they care about20:19
ttxjbryce: I need to go now...20:19
johnpuri believe the networking effort is a good example of this20:19
jbrycettx: ok20:19
jbryceactually i have to head off as well20:19
vishyjohnpur: I am much more confident in fast iterations in an agile style, but we can try to come up with a rough 12m+ roadmap20:20
jbrycethanks for joining everyone20:20
johnpurvishy: thx20:20
*** openstack changes topic to "Openstack Meetings: | Minutes:"20:20
openstackMeeting ended Thu May 19 20:20:57 2011 UTC.  Information about MeetBot at . (v 0.1.4)20:20
openstackMinutes (text):
johnpurto be clear, beyond n and n+1 releases we leave the realm of "roadmaps" and start talking about "vision"20:22
*** dendrobates is now known as dendro-afk20:29
*** katkee has quit IRC20:52
*** hub_cap has quit IRC21:46
*** troytoman-away is now known as troytoman21:59
*** ovidwu_ has joined #openstack-meeting22:08
*** _0x44 has quit IRC22:13
*** ovidwu has quit IRC22:13
*** anotherjesse has quit IRC22:14
*** _0x44 has joined #openstack-meeting22:18
*** _0x44 has quit IRC22:19
*** _0x44 has joined #openstack-meeting22:19
*** edconzel_ has joined #openstack-meeting22:26
*** edconzel has quit IRC22:29
*** edconzel_ has quit IRC22:30
*** rnirmal has quit IRC22:43
*** dendro-afk is now known as dendrobates22:43
*** troytoman is now known as troytoman-away22:45
*** jkoelker has quit IRC22:59
*** nerens has quit IRC23:02
*** dendrobates is now known as dendro-afk23:08

Generated by 2.14.0 by Marius Gedminas - find it at!