20:02:45 #startmeeting 20:02:46 Meeting started Tue Jul 19 20:02:45 2011 UTC. The chair is jbryce. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:02:47 Useful Commands: #action #agreed #help #info #idea #link #topic. 20:02:56 agenda - http://wiki.openstack.org/Governance/PPB 20:03:10 jmckenty: are you around? 20:04:17 jmckenty added the trademark topic but i'm not sure exactly what he wanted to discuss around it so we'll move on 20:04:35 #topic Revisit project autonomy / project philosophy discussion 20:05:23 i sent an email out after the meeting a few weeks ago about the philosophy vote we had taken 20:05:33 hi 20:05:37 back, sorry I'm later 20:06:26 i think the 2 statements we chose between weren't particularly clarifying to come up with an overall philosophy 20:06:37 do you have some alternate? 20:06:48 jbryce: instead of rehashing the topic can we boil it down to the core issue/decision to be made? 20:07:33 jbryce: I think it was great progress to clarify we want a single product rather than a collection of products 20:07:40 +1 20:07:47 agree 20:07:48 jbryce: that doesn't mean it's the answer to life and everything 20:08:11 ttx: 42. 20:08:14 wow 20:08:43 so we can further precise what we mean by "single product, made of independant but cooperating subprojects" 20:08:54 if there are areas where clarification is needed 20:08:59 is there ? 20:09:08 well, I think there are two related statements 20:09:40 the first is that subprojects should use common frameworks, tools, policies and practices whenever possible 20:09:51 to support a single cohesive community 20:10:00 i think the core question is should every openstack project be identical in all aspects (processes, tooling), free to make all decisions on their own, or somewhere in the middle 20:10:00 my opinion is somewhere in the middle and i feel like our decisions to date have basically been along those lines 20:10:00 what defines "whenever possible"? 20:10:01 so then the harder thing to specify is what should be shared across projects and where does the latitude come in 20:10:40 jbryce: I don't think your view of what was decided is the same as jmckenty/ttx 20:10:59 can you clarify the difference 20:11:24 "whenever possible" == "do it the common way unless it is impossible to support the accepted community practices" 20:12:12 (for instance - if the community practice is "write in python" but the project is "java openstack api implementation" ... then it would be impossible to fulfill "write in python") 20:12:27 jbryce: I think we need a common set of tools. There can be some freedom of choice amongst a set of vetted options, though 20:12:33 definitely somewhere in the middle 20:12:35 mtaylor: right :) 20:12:50 sorry guys...i'm having some weird internet connection problems 20:12:51 jbryce: to me, independence should be about technical choices in the code, not in the tooling 20:13:11 right, but I think going forward, the number of "not according to community practice" flags will likely become a gating function on inclusion in openstack 20:13:18 for evaluation of incubation, etc 20:13:23 johnpur: different people have different ideas of what is "impossible to support the accepted community practices". In any case, the root of the issue is that subprojects want the autonomy to develop, manage and review code the way they wish, regardless of whether the way they want to do it is common to other subprojects. 20:13:43 I wouldn't say that all subprojects want that autonomu 20:13:49 i agree with ttx on the importance of common sets of tools. especially for things where the audience is likely to span multiple projects 20:13:52 I'd say that it's the topic of discussion 20:13:53 jbryce: each project is free to write the code they feel is the most appropriate 20:14:02 that's where the PTL rules 20:14:22 ttx: i fully agree and i think everyone agrees with that on the code front 20:14:27 ttx: I disagree 20:14:33 or maybe not 20:14:33 * mtaylor would like to toss in that, given the work of maintainng divergent tooling, there should be a pretty good reason for the set of vetted options being above one in most cases - although he does agree that at times a set of more than one is actually appropriate 20:14:34 = ) 20:14:34 if they decide to drop Carrot for Kombu, that's their choice, not ours to discuss 20:14:36 I think there's an openstack-wide expectation of unit tests 20:14:47 though we /should/ encourage smoe commonality where possible 20:15:19 mtaylor: as a follow-on to that, I would like to push a discussion of CI/packaging responsibilities back onto the agenda for a future meeting 20:15:30 specifically, relationship between RAX and OpenStack for CI, etc 20:15:33 When the tooling is not appropriate, we can select a set of vetted options, like the GitHub case shows. 20:15:42 Doesn't go as fast as some would like it to go, but it will happen 20:16:00 E.g., I'm standing up independent CI environments so that I can do things that I can't do within the current environment 20:16:36 jmckenty: perhaps you would come to the next openstack-ci meeting? It's tuesdays from 3pm-4pm EDT on this channel. 20:16:50 jmckenty: We also happen to set minimal expectations on code quality, true 20:16:53 jmckenty: anyways, for another day... 20:16:58 it's tough for me to make that - I have a standing 12-1pm PST lunch meeting on tuesdays 20:17:05 anyway 20:17:06 jmckenty: yes- I would love to avoid the need for you to have to do that, and yes, we should talk about it at some point 20:17:08 after we had the philosophy discussion, we talked about vetted set of options. i like the vetted set (could be a set with only a single option) as the way to have tooling that all ties in but gives latitude to teams to choose something that fits in their workflow. but it seemed like there was debate about the vetted set 20:17:23 are there additional resolutions we should consider? 20:17:36 ewan seemed in favor of a single option to limit the amount of retraining 20:18:23 jbryce: I'm definitely in favour of us choosing a single source control system, whichever it is. 20:18:30 ++ 20:18:34 ++ 20:18:36 * jaypipes in favour of a single solution so that the community can enhance a single platform instead of fracturing development time working on support for multiple platforms. 20:18:46 Also there are areas that fall in the cracks, like versioning. Should we align Swift with the rest of OpenStack, for example 20:18:58 versioning is separate from tools, though 20:19:02 can we finish on tools first? 20:19:09 I think we can discuss those areas separately when the need arises 20:19:26 jmckenty: sure :) 20:19:28 ttx: i agree, but i want to make sure we have clarity on the philosophy 20:19:49 if the philosophy is all projects are identical, then those discussions are basically about making a single decision for every project 20:20:34 jbryce: common tooling, freedom for technical choices, with some commonality/integration sense 20:21:16 ttx: I think that freedom needs to be within some reasonable guidelines - e.g., python unless there's no way to do it 20:21:20 projects should try to align, unless there is a valid reason not to (and "because i want to do it differently is not a valid reason) 20:21:20 with "common" potentially meaning a set of PPB-vetted options. 20:21:23 but generally yes 20:21:40 jmckenty: sure, and we might need to more clearly defie those guidelines. 20:21:42 define* 20:22:06 my overall objective is to have as few technologies and as few tools involved as possible 20:22:15 ++ 20:22:21 I have only 7 developers, and we're working on everything 20:22:46 so in terms of autonomy, openstack will have default tooling and processes that may include a vetted set of options that projects should use unless there is a pressing requirement to go outside of the established choices? 20:22:48 obviously from a security standpoint, fewer technologies == smaller strike surface 20:22:52 jmckenty: agree, let's keep it as simple and scalable as possible 20:22:54 what is good for OpenStack as a whole? 20:23:06 that is the question, no? 20:24:07 with the understanding that being non-standard is a potential barrier to incubation/core status 20:24:11 jbryce: what do you need to see clarified exactly ? Did he discussion already provide you the answer ? 20:24:12 jbryce: I think that is a good summary, yes. 20:24:38 the* 20:24:40 ttx: the problem is the previous statement gave no direction on if projects have any latitude to be different 20:25:25 jbryce: I think your definition is good. The "pressing requirement" should potentially be challenged by the PPB. 20:25:45 jbryce: as in "you're kidding, right ?" 20:25:59 ttx: :) 20:26:03 ++ 20:26:14 ttx: can I add a suggestion? 20:26:37 that we also suggest that the PTL formalize a bit the mechanism that they're proposing such an exception 20:26:43 e.g., do a project-internal vote 20:26:44 up to this point, ppb exceptions have been the mechanism for non-standard things 20:26:46 or a design summit session 20:26:49 i.e. the PPB decides tooling for core projects. If they walk out of the path, they better have a good reason or we'll force them back in ? 20:27:44 well, again I'd like to point out that having separate dev teams for swift and nova, while it's the RAX way, is probably going to be the exception in other organizations 20:28:02 jmckenty: so you'd rather have them ask before they differ ? Rather than being different and then challenged ? 20:28:25 I think it'll save churn 20:28:28 jmckenty: lots of RAX devs work on Glance, Nova and Keystone at the same time... 20:28:52 jmckenty: I think the latter is simpler, because projects don't necessarily know when they abuse their relative independence 20:28:56 jmckenty: and lots of companies have deployed swift independently of nova etc 20:29:15 notmyname: most of those that have, though, have plans to add nova to their roster 20:29:20 inap, kt, etc 20:29:29 jmckenty: if they are being different but nobody in the PPB cares enough to raise the issue, it's probably alright to be different 20:29:39 fair nuff 20:30:11 ok 20:30:25 In particular, projects should be free to add new tools in areas where we don't set any standard 20:30:31 ttx: the issues will be at the tooling, packaging, technology areas... it will be obvious where the ppb will care i think 20:30:38 I don't want them to be limited to our choices 20:30:56 and then, their choice is well set to become the standard 20:30:57 i think i'm going to try to take points of this discussion and add them to the previous one-line statement to see if we can publish something that clarifies project relationships and the stance on autonomy with projects 20:31:00 Can I start a wiki page of things I worry about? 20:31:09 so should the ppb define how "viable options" are vetted? 20:31:10 e.g., pinning to Python 3 features, 20:31:15 can I also suggest that when the vetted list of tools is made, each list item gets an abstract description as well, so it's clear what a tool is there for? for instance "the project has decided it wants a gate trunk and a patch queue manager" makes the tooling implementing that make more sense? 20:31:20 ttx: and we need to be open to evolving the openstack set 20:31:30 there has been very little visibility in to the vetting of github for example 20:31:32 johnpur: sure 20:31:54 github or the tooling around github? 20:31:56 I'd also like to look at pushing more of the PPB meetings out to the community blog, etc 20:32:00 github is probably a little bit of a special case as so many people are already familiar with it and many wanted to move to it 20:32:04 jbryce: both 20:32:19 creiht: I agree -- and popularity contest at design summits may not be the best way 20:32:27 jmckenty: i can help on blog stuff 20:32:33 since it was just recently announced that it will be github + gerrit 20:32:50 didn't see much in the way of community input there 20:33:03 well... a) I agree with creiht 20:33:23 Can I propose that we put packaging and CI into the openstack-common project 20:33:28 #action jbryce to put together a more detailed project autonomy statement and process for vetting options 20:33:29 I also don't think the whole thing was handled particularly well. 20:33:39 but b) I think the topic was so contentious from the get go, that most discussions around it quickly became completely useless - but it should be addressed and solved for the future 20:33:40 maybe i am slow, but when did gerrit come in? 20:33:48 mtaylor: ++ 20:33:49 and then look at core team membership, voting, etc 20:34:07 jmckenty: well, we've got openstack-ci project ... do you want to move CI? 20:34:22 mtaylor: that way we can isolate it from a whole-community discussion, to relevant and interested parties 20:34:33 johnpur: it was identified as a solution to the problem that GitHub's pull requests don't have sufficient statuses to meet existing review policy/process. 20:34:37 we've kind of transitioned into the next topic 20:34:39 I was suggesting including CI, packaging, source control, etc. as a single project 20:34:39 #topic Review progress on GitHub integration 20:35:19 we did kinda skip over the versioning issue. (but IMO it's the same as the tooling) 20:35:20 jmckenty: yeah - that's what the ci team meeting is there for - we could certainly add a mailing list (packaging is the only thing that isn't currently officially handled in the ci related stuff) 20:35:44 jmckenty: and we're doing our best to start rolling out docs and the like to get folks more involved in that effort 20:35:50 Is the GitHub stuff being addressed by the -ci team? 20:35:52 mtaylor: can you give an update on the github progress, please, including blockers. 20:35:53 yes 20:35:57 ah, k 20:36:37 notmyname: that's my view as well -- but I'd comply if the group decided otherwise. 20:36:54 so, currently we've got a gerrit server up and going, have migrated the openstack-ci related code to being managed by it (eating our own dogfood first to make sure it works) and are currently in the process of getting keystone onboarded 20:37:39 the tentative rollout plan is - use keystone as initial guinea pigs, then migrate a few other smaller projects (like glance) and sort out showstoppers, etc. 20:38:01 once that's happymaking - then we can look at the projects with larger sets of devs, like nova 20:38:09 mainly because ... 20:38:39 we had 1500 commits last month on nova? 20:38:40 :) 20:39:01 there are a few issues that jeblair and I are working on fixing/writing code for that will slightly alter workflow, but with the smaller teams of devs re-communicating those workflow changes is less of a pain point 20:39:17 mtaylor: so Glance would migrate from bzr to git, right ? Since LP/bzr is one of the "options", does that mean the Glance PTL decided to move to git ? 20:39:18 the current todo list issue that we want to get done before migrating nova is: 20:39:35 (trying to see the process a project must follow to move from one "option" to another) 20:39:39 ttx: it does ... and I would at some point like to bring up the continuation of lp/bzr as an option 20:39:48 ttx: very few Glance contribs want to move to GitHub/git, but we will follow the recommendations of monty and jim. 20:39:58 but I think that's perhaps out of scope for right now 20:40:20 any questions around gitub progress, tooling? 20:40:30 just scope 20:40:34 ttx: it's more important to be on a common infrastructure than personal preference for a set of tools. 20:40:40 we're moving code and review process, correct? 20:40:45 but not issues 20:40:45 jmckenty: yes 20:40:49 jmckenty: yes. 20:40:53 cool, thanks 20:41:05 Can we backport dashboard as well? 20:41:08 it's already on github 20:41:13 I'd love to 20:41:16 but not with gerrit 20:41:28 to jmckenty's earlier point, with smaller teams that are cross functional it would be really good if the projects had common repos, workflows, etc. 20:41:30 I would really love to get all of the 'smaller' projects and/or things that are already on github looped in 20:41:38 We need to get it into the official openstack account 20:41:46 right now there's a piston fork, and a 4p fork 20:42:02 jaypipes: I agree that if at one point all core projects happen to be on the same "option", the continuation of the other "option" should be questioned. 20:42:02 jmckenty: yup. 20:42:07 oh - speaking of that ... there's a policy thing I want to bring up regarding the official openstack account ... would now be the right time? 20:42:27 yes please 20:43:04 so - github does not have an option to remove push access from owners of an org ... but we have a project policy of gated trunks 20:43:17 right. 20:43:22 who are the org owners? 20:43:22 I would like to remove all of the regular dev accounts (mine and jim's included) from the owner list of the org 20:43:29 create another team? 20:43:46 and have special accounts that can be used if actual org owner bits are needed - mainly to prevent accidental pushing 20:43:50 So, not to be a pain, but back after we decided to give this a shot, we were going to put up a demo and let the wider community vote on the choice of gh/lp. it sounds like we're just moving everything without that vote. Did I miss the decision to not do that, or...? 20:43:51 mtaylor: shouldn't jenkins be the only owner of the trunk repo/branch? 20:44:09 jmckenty: mtaylor jeblair termie and myself 20:44:12 jaypipes: I would add one special admin account 20:44:13 jaypipes: yes. that's exactly the point I'm making - it's how to implement that 20:44:30 in case the whole CI infrastructure is broken 20:44:35 and we need to hot fix 20:44:41 although I guess we can change the teams at that time 20:44:49 eday: a valid point 20:45:06 well, we were talking about adding a special admin/owner account for each person who should be allowed to log in to the website and make owner-level changes 20:45:06 can we use keystone as that demo? 20:45:21 the github team structure for repo ownership is actually quite sufficient to model the other things I belive 20:45:52 eday: +1 20:46:28 jaypipes, mtaylor: do you have thoughts on eday's question about the gh/lp choice? 20:46:33 mtaylor: ok, so do you have your answer? 20:46:43 anyhow - I guess the thing is - does anyone have any objections to continuing to model the "jenkins" is the only one who can push approach 20:46:54 nope 20:46:58 great. 20:47:08 +1 to Jenkins being in charge. 20:47:10 that commit gate is the best part about our CI infrastructure 20:47:12 jbryce: about whether to put it to a community vote? 20:47:31 jbryce: I hear eday -and I think that what jmckenty said about keystone being the POC is pretty good 20:48:17 I wonder if there is really much need in an actual formal community vote at this point though - what _exactly_ they would be voting on, and whether it would just bring up more vitriol or not 20:48:39 jmckenty: +1 20:48:44 we should probably do subproject-by-subproject votes 20:48:44 mtaylor: the PPB should decide to add (or not add) github+gerrit as an "option" for code hosting 20:48:51 Better to be open and deal with the potential vitriol about the change. 20:48:55 ttx: yes. I believe that vote should happen 20:49:08 mtaylor: once the POC proves the benefit of that option. 20:49:13 * mtaylor wasn't saying no voting - just wanting to be clear about what was being assessed 20:49:19 ttx: how low for the POC - 5 days? 20:49:24 low == long 20:49:48 jmckenty: why? isn't the point that the subprojects disagree and that this whole discussion is about whether subprojects have the choice to do what they want or not? 20:50:19 jmckenty: I'd like to see a few review activity before making my mind... so if there is sufficient activity in those 5 days, maybe 20:50:38 can I suggest a slight alteration... 20:50:51 i think the ppb should vote on adding github+gerrit as a source code option based of a review of keystone as the poc 20:50:56 at that point, it's up to the individual projects 20:51:11 if the POC is ready and there's activity, we could add that on the agenda for next week 20:51:36 jbryce: fine by me 20:51:56 +1 20:52:01 8 minutes left. more discussion on this or do we want to tackle one of jmckenty's other topics? 20:52:04 +1 20:52:10 ok. yes. so it may be ready for a vote next week - or the week after (depending on how the testing actually goes - I'm sure there will be a few hitches we want to address after it gets some usage) 20:52:12 mtaylor: when will keystone be POCed ? 20:52:40 ttx: as soon as their devs actually sign up for accounts... we're waiting on them right now 20:52:46 mtaylor: let us know when it's ready to be evaluated 20:52:52 The academic discussion we can push to email for now - bascially, several organizations have offered PhD students and potentially money to work on OpenStack R&D 20:52:55 we could alternately make jaypipes the test case 20:53:14 jbarratt: will do 20:53:20 damn completion 20:53:22 jbryce: will do 20:53:42 Just wanted to see if it makes sense to divide the "Community" from simply "Companies" to a few classes of participating entities 20:53:50 mtaylor: that's fine if you want. bcwaldon, dprince, blamar and myself will give feedback to you on a Glance move to github. 20:53:50 and if the PPB as a whole is the right group to coordinate that, 20:53:53 #topic openstack trademark 20:53:58 jmckenty: which asks the question of the setup of an independent body financed by a set of contributor companies 20:54:10 wasn't going there yet 20:54:18 ha 20:54:25 jaypipes: ok. I'll chat with jeblair about that - you guys might actually be a better source of feedback from a POC perspective 20:54:29 jmckenty: if they offer money, that money needs to go somewhere. 20:54:33 in fact, I still think we should use the OCC for that if necessary 20:54:54 it's already running OpenStack, and already a 501(c)3 dedicated to cloud computing 20:54:59 plus, they're friends 20:55:04 and NASA is already a member 20:55:08 which is VERY hard to do 20:55:10 with a non-profit 20:55:16 OCC = Orange County Choppers? 20:55:22 Open Cloud Consortium 20:55:27 jmckenty: can you put something together in an email on it? 20:55:31 yes 20:55:38 The Qatar Foundation is interested 20:55:41 as a first org 20:55:49 but obviously the USC guys have been very active 20:56:01 K, trademark 20:56:04 in 4 minutes 20:56:19 on the trademark, summary is the ppb doesn't have authority over the trademark but we can certainly make recommendations 20:56:20 1. We need something akin to the Xen "FITs" definition to gate the use of "Built on OpenStack" 20:56:23 my understanding is that the OpenStack Advisory Board is being set up (prior to the Essex DS) and that body will adrees these sorts of issues (not the ppb). 20:56:37 that advisory board has been "real soon now" for 6 months 20:56:40 i think the area that really needs help is technical definition around requirements to be called openstack 20:56:42 I don't believe in it anymore 20:56:48 jbryce: exactly 20:56:50 that's FITS 20:56:54 Faithful Implementation 20:56:55 jmckenty: i still believe! 20:56:56 right 20:57:05 jbryce: this team should write the specs on FIT 20:57:14 i'd agree with that 20:57:20 2. We need some legal protection that the trademark policy can't be changed ad-hoc 20:57:31 jbryce: we should get some guidance here from the powers that be 20:57:38 I'm building my business on the right to say "Built On OpenStack" 20:58:04 jmckenty: I can bring in RACK lawyers on this if you need to have a discussion 20:58:04 I don't think that has to be as violent as granting the trademark to a third-party 20:58:14 Let's have a proposal first 20:58:20 lawyers slow everything down 20:58:31 jmckenty: i think that's a good piece of feedback 20:58:35 i will follow up on that one 20:58:50 also, next week i would like to bring up a topic of setting up working groups within OpenStack, one of which will be a legal working group to help with these sorts of issues 20:58:58 1 minute left. does anyone want to volunteer to lead up an openstack FITs effort? 20:59:07 I'll lead the charge on that 20:59:12 Ewan, wanna play in? 20:59:17 sorry, ewanmellor 20:59:18 #action jmckenty to send email on academic involvement and the occ 20:59:34 #action jmckenty to lead an openstack faithful implementation standard effort 20:59:53 thanks for the time everyone 21:00:08 jbryce: great time management :) 21:00:12 #endmeeting