20:00:01 #startmeeting 20:00:03 Meeting started Tue Oct 25 20:00:01 2011 UTC. The chair is jbryce. Information about MeetBot at http://wiki.debian.org/MeetBot. 20:00:05 Useful Commands: #action #agreed #help #info #idea #link #topic. 20:00:07 roll call? 20:00:10 here 20:00:11 o/ 20:00:16 here 20:00:28 here 20:01:20 o/ 20:01:21 o/ 20:01:54 ewanmellor, johnpur, vishy, anotherjesse: around? 20:02:14 o/ 20:02:38 all right...that's enough to get started 20:02:52 http://wiki.openstack.org/Governance/PPB - agenda has 1 thing on it 20:02:54 Here 20:02:57 #topic Status on vulnerability management team setup 20:02:58 here 20:03:03 hey 20:03:05 ttx: want to take it away? 20:03:09 yes, wanted to do a quick update 20:03:16 we recently made progress in setting up proper security teams 20:03:33 The proposed plan is to have a very small team of vulnerability management people (that will just be reponsible for tracking the fix and disclosure process)... 20:03:43 ...and a large (open) team of security-concerned folks to discuss auditing and security improvements to OpenStack. 20:03:52 For the first team, see http://wiki.openstack.org/VulnerabilityManagement 20:04:08 #info Proposal is that the small vuln-mgmt team would be set as "security contact" for all the core projects 20:04:21 Note that the affected PTL is getting involved as the very first step to vulnerability resolution. 20:04:37 You can also see the proposed openstack.org/security page contents at: 20:04:43 #link http://etherpad.openstack.org/8hWNQwkWf9 20:04:55 here 20:05:15 Let me know if you see anythign wrong in there 20:05:54 ttx: says to join https://launchpad.net/~openstack-security but the group does not exist. 20:06:17 zns: sure, the contents needs t obe approved first 20:06:35 basically I'm not sure we should have a common openstack group, or should we have project-oriented groups 20:06:47 like the nova-security-improvements subgroup that vishy set up 20:06:49 ttx: ah. OK. 20:07:00 is there any benefit to having per-project security groups? 20:07:13 ttx: that subgroup was meant for improving the security of the code as opposed to responding to vulnerabilities 20:07:24 vishy: the same for ~openstack-security 20:07:28 seems like openstack group is the easier to maintain - and I'd think that doing that and then moving to more complex if needed would make sense 20:07:29 ah ok 20:07:37 vishy #openstack-vuln-mgmt is the team for responding to vuln 20:07:43 ah 20:07:44 i think there are big benefits to only have one team and i don't expect the volume to be extremely high 20:07:44 s/#/~ 20:08:16 especially in the area of simplifying the process 20:08:23 vishy: would you mind if we refunded ~nova-security-improvements into ~openstack-security ? 20:08:29 one team for improvements seems kind of silly to me 20:08:31 (that one is an open security interest group) 20:08:41 they are very project specific 20:08:51 sorry...i'm talking one team for vulnerabilities 20:09:04 jbryce: we need one team for vuln 20:09:10 why would anyone who works in glance or swift care about reimplementing a nova-db worker to lock down the database? 20:09:15 i agree that improvements probably make more sense as separate teams 20:09:16 (for example) 20:09:17 vishy: the http://wiki.openstack.org/VulnerabilityManagement seems to say it is about processes not code fixes 20:09:23 for handling security issues 20:09:37 one team for process seems fine 20:09:43 separate teams for implementation though 20:09:43 for just security issues, I would think 1 team would work . 20:09:45 On the vuln side, I would like to see a statement that "responsible disclosure" includes disclosing to downstream products and distros in a private, co-ordinated fashion, so that we can get patches to our customers on the day of the public disclosure. 20:09:55 vishy: agree for implementation 20:10:00 ewanmellor: see http://wiki.openstack.org/VulnerabilityManagement 20:10:10 ewanmellor: it states it a bit more clearly 20:11:04 #info one team for vulnerability management across all openstack projects 20:11:05 ttx: OK, I would like to see one page with this stuff written down, not two ;-) 20:11:21 #info separate teams by project for general security improvements 20:11:25 anotherjesse: the question is whether a common "openstack-security" group (to discuss security improvements) is better or worse than separate ~nova-security and others 20:12:05 ttx: imo, security improvements are code specific and a shared group would just get bogged down in theory 20:12:25 vishy: yes, I have no string opinion either way 20:12:50 vishy: the security folks kinda prefer a common group, but I agree that a project-focused group would deliver more results 20:13:02 ewanmellor: will make sure that is written down in both places ! 20:13:15 ttx: who are "the security folks"? 20:13:30 ewanmellor: (the etherpad is the static website content, the wiki is much more controllable) 20:13:58 vishy: people that came to Ray and I at the end of the nova security meeting and with which we brainstormed this so far 20:14:11 vishy: mostly code auditors 20:14:15 we should also close the list openstack-security 20:14:27 reed: close ? list ? 20:14:50 ttx: What is the meaning of the term "downstream users"? I would expect a company like Citrix, as a downstream software vendor, to be notified before e.g. Disney, as a downstream deployer. 20:14:54 I don't think it's used at the moment http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-security 20:15:03 <_0x44> I think in general it makes more sense for there to be project level sub-teams that can serve as the single-point of contact for the openstack-security team when it actually is formed. 20:15:14 <_0x44> They're complementary 20:15:23 vishy: I'll discuss the split with them 20:16:03 ewanmellor: downstream users = distributions and public cloud providers 20:16:44 ttx: OK, worth clarifying. Private cloud users may wonder whether they are in that category, or why they are not. 20:16:44 ewanmellor: we will refine the process once the team is in place. 20:17:14 ewanmellor: we badly need some process set up. it won't be set in stone once it's in place 20:17:32 ewanmellor: but I see what you mean. 20:17:33 ttx: +1 20:17:57 let's get it in place and then we will really find out where we need to improve it 20:17:59 OK, so we'll proceed in setting up the vuln-mgmt team and make progress on vuln management process 20:18:00 ttx: Also, does the Coordinated Disclosure section imply that those phases happen in strict order? I would want to be notified that a vuln was known even before a fix was ready, because I usually need to get a QA slot reserved. 20:18:14 and I'll discuss splitting the security interest groups per project 20:18:58 ewanmellor: the problem is to balance disclosure with speed of fix 20:19:27 ewanmellor: once downstream users (with my definition) know about it, it's all downhill from there 20:19:40 ewanmellor: you need to coordinate release fast 20:20:04 ttx: fixes hit the "stable" branch quickly? 20:20:07 ewanmellor: that's why the current proposed process gets a fix first 20:20:20 the stable branch would be one of the downstreams. 20:20:43 ttx: Not true. The aim is to be co-ordinated and careful, not necessarily fast. Citrix would handle any vuln with strict non-disclosure rules (we have a team that does this). 20:20:47 ewanmellor: and then coordinates the fix down 20:21:38 ewanmellor: the "downstream users" group will be large. You can't keep a secret long with such a group 20:22:03 in my experience with 20+ people in the loop you can't embargo for more than one week. 20:22:08 ttx: based on the foundation announcement, seems that we can't keep a secret in the PPB either ;-) 20:22:23 it should be assumed that secrets are impossible to keep 20:22:34 agreed 20:22:38 mtaylor: indeed, that's why time is of the essence 20:22:40 ttx: That's why I asked what the definition of "downstream users" was. You said that is was distros and public cloud providers, by which I assumed you meant the professional security teams of said companies. 20:24:00 I bet the moment the vulnerability is known, some affected people will start deploying fixes. 20:24:44 ewanmellor: I see your point. I guess we can discuss that when we'll have a list for the "downstream users" :) 20:24:52 ttx: So I would expect that the existence of a vuln, disclosed to professionals, would be treated with the professionalism, respect, and secrecy that we would all expect. We _have_ to be able to keep a secret for more than a week, because we may need to do more than a week's QA on it. 20:24:57 see if we can reorder the process 20:25:03 for users in production, it may be critical to get the fixes, get through QA, and pushed to production 20:25:22 ewanmellor: I guess a few years on vendor-sec has left me a bit pessimistic 20:26:49 johnpur: that's agreed. ewan is proposing that all downstream users know about the vulnerability as early as possible, even with no fix available yet 20:27:10 so where do we sit on this? we think the proposal is good but we need to determine exactly when a broader group is notified that a vulnerability exists vs. that it exists and has a fix? 20:27:20 ewanmellor: I guess we could say something is coming up, without too much detail 20:27:21 ttx: Know about the _existence_ of a vuln. Not necessarily what it is. 20:27:28 ewanmellor: oh, I see 20:27:33 ewanmellor: sure, that's acceptable 20:27:38 (I think) 20:27:44 ttx: agree. need to define downstream crisply, particularly the branches that have deployed systems 20:28:04 "something affecting that and that, severity High, coming up, patch on its way" 20:28:12 ttx: that makes sense to me 20:28:41 ewanmellor: I'll roll that in the process 20:28:55 ewanmellor: or you can. hey, it's a wiki :) 20:28:56 ttx: Sounds good. 20:29:27 jbryce: I think I'm done, will keep you posted with more progress next week 20:29:28 Security processes documented on wikis *shudder* 20:29:47 ok 20:29:49 ewanmellor: hehe 20:29:56 #topic open discussion 20:30:10 anyone have anything else they'd like to discuss? 20:31:02 I'd like to propose making the core dev infrastructure (CI, gerrit, jenkins, whatnot) an openstack project with a ptl who's voted in by its devs rather than just something everything depends on and happens to be there 20:31:46 here now btw 20:31:51 especially now that we're starting to get more contributions in that space from non-rackspace folks 20:32:01 mtaylor: I would keep "openstack projects" to pure user-facing code. Make up a team and hold elections if you want ? 20:32:14 mtaylor: I like that idea 20:32:37 ttx: well yes - I essentially just want to make it a thing we recognize and manage, rather than merely something we count on 20:32:39 i.e. don't reuse the word PTL but copy the idea 20:33:07 ttx: i agree. i wouldn't consider that "administrative" type thing to be part of the shipped openstack software 20:33:08 "Team lead" 20:33:09 mtaylor: i like it as well. we're working on a lot of the core dev infrastructure stuff right now and will definitely contribute it back if we can 20:33:36 team leads should be elected as soon as people don't agree who should be the lead, basically 20:33:53 I like the idea of the packaging/integration piece being an equal voice and managed the same as the other projects. and we all integrate with the 6 month releases 20:34:05 i think set it up as a project and elect a team lead if you want and encourage contributions, but it's not really part of a cloud software stack 20:34:23 it's not going to get get shipped in a downstream distribution or deployed at a service provider 20:34:24 i.e. it's not incubating or core or whatever 20:34:45 jbryce: no, but it's an essential piece of openstack itself 20:34:47 totally not part of the cloud software stack ... but I think notmyname put it well ... it's about explicit governance/managment/ppb oversight 20:35:02 notmyname: I'm not sure mtaylor includes packaging in that 20:35:11 ttx: he should ;-) 20:35:13 mtaylor: do you consider the openstack-qa effort part of this? 20:35:32 ttx: well... I would include packaging in that if the openstack project decided it wanted to provide packaging :) 20:35:32 johnpur: I would 20:35:43 mtaylor: my point :) 20:35:52 johnpur: interesting question - one consumes the output of the other in my head 20:36:13 mtaylor: right 20:36:17 I actually think that openstack-qa should similarly be an administrative managed grouping that also doesn't produce shipped code 20:36:21 I get encouraged to do the same for Docs - PTL for docs, but I think it's not necessary as doc doesn't create/maintain clouds 20:36:25 So we might need some area for "official team" or something 20:36:37 I don't want all teams to go through PPB for formation* 20:36:56 Would this be something the "foundation" would own? 20:36:57 though some teams, owning some critical central stuff, would benefit from PPB oversight 20:36:58 or rather, not necessarily unnecessary, but the wrong governance model 20:37:13 ++ 20:37:15 i'm fine if we want these things to have some kind of oversight/governance, but i think that we should not confuse it with the "product" that we're building 20:37:19 these things, IMO, are all part of a meta-project. I'd consider all of the support pieces (including docs) to be part of it 20:37:31 so we need to "define" how we handle automation, qa, and docs? 20:37:46 zns: IMO, no more than the foundation "owns" swift, nova, or keystone 20:37:46 jbryce: sure. Not project, but "official team" or "meta-project", or whatever new name we can come up with 20:37:56 throwing all the support projects into one lump doesn't seem wise 20:38:00 for a team that own s a part of openstack that the PPB still should have oversight over 20:38:20 ttx: +1 20:38:59 devcamcar: I agree it should not be a single "janitor meta-project", but rather a category of stuff. 20:39:00 ++ 20:39:07 IMO, it's not about oversight but consistency. allow each of the projects (including this yet-to-be-defined meta-project) to do things according to their needs and integrate with every major release. this means packaging, etc too 20:39:12 I can think of two teams that fit that description 20:39:17 doc and CI 20:39:40 ttx: qa? 20:39:45 I think qa is the third. it's currently working on producing openstack-integration-tests 20:39:51 johnpur: I don't think so. 20:39:58 which will be pretty stinking important to the project 20:40:04 hopefully :) 20:40:06 We could have multiple competing QA projects, no ? 20:40:12 god I hope not 20:40:29 why? 20:40:29 devcamcar: got time for some questions regarding nova & db in #..-dev ? 20:40:29 notmyname: own wasn't the best word. I mean would this come under PPB and technical oversight or would it become infrastructure that is not directly governed by the PPB? 20:40:37 let's put it this way - the CI system will not use multiple competing QA projects to tests openstack 20:40:49 ttx: I think QA and Doc could help each other. 20:41:07 I really see QA as a team thing. You don't need permission to do QA 20:41:19 and all QA is good 20:41:27 contrast with CI -- you only have one CI. 20:41:30 you don't need permission to do qa - you do need permission to check in new tests to the tests suite that is used for trunk gating 20:41:45 zykes: I will be able to in a min 20:41:45 mtaylor: CI can choose to use whatever team's tests they want 20:41:56 anngentle: Doc provides concrete deliverables that ship with the stack (PDF, webhelp, RST, etc..). QA/CI does not - what it delivers is quality but you don't download, install, and run that... 20:42:03 mtaylor: just choose to use the ones from the super-QA team 20:42:06 so the test suites that are the output of the QA team's work 20:42:15 ttx: getting a coherent and consistent qa effort amongst the community is super important 20:42:27 ttx: so, that's a business I do not want to be involved in - choosing _which_ qa product I prefer 20:42:50 there is currently a defined super-QA team for openstack, and I will use what they hand me - since that affects trunk gating, I think it should be managed 20:42:54 is all I'm saying 20:42:56 johnpur: my point is that if someone can't bear Jay and still wants to do QA, he should be able to 20:43:12 ttx: and if someone can't bear vishy and still wants to hack on nova? 20:43:21 ttx: lol, who doesn't love jay? 20:43:44 ttx: the benefits would be in consistency (for all three teams) 20:43:47 or doesn't like me and wants to help run the CI system? ;) (that's the more believable example) 20:44:11 mtaylor: my point -- QA is something you can do in multiple ways. While CI or Nova are unique 20:44:16 all doc is good, but it's better if it's consistent and trustworthy 20:44:26 ttx: I think you and I are using the word QA differently 20:44:57 ttx: you are referring to the act of QA - I am referring to the concrete set of test code produced by the team who is doing testing activities 20:45:01 mtaylor: imagine a group calling themselves "the-fuzzers" wanting to do some code analysis and file bugs based on their results 20:45:04 ttx: so we might need an additional word 20:45:11 ttx: right. I don't give a shit about that :) 20:45:15 mtaylor: do you want to prevent them from forming a group ? 20:45:20 mtaylor: that's QA too 20:45:24 god not. but that's not what I'm talking about 20:45:39 ok. so let's call what I'm talking about "openstack integration test developers" 20:45:48 mtaylor: so I think you're not after "QA", you are after "the ones producing my test suite" which is quite different 20:45:53 right 20:46:31 so in my view - we have three of this style of currently unmanaged group - CI, Docs, and "the ones producing my test suite" - and I think we should come up with something slightly more official for them :) 20:46:33 mtaylor: agreed, that should be unique :) 20:46:48 ttx: i see it as more than that. consistent test frameworks, hooks to the ci mesh, gating trunk, etc. 20:47:55 mtaylor: are you looking for a name or formal policy? 20:48:04 mtaylor: sure, just don't call them "projects" and don't call their lead "PTL". 20:48:09 code coverage, bare metal provisioning and deployment, etc. 20:48:23 ttx: -1 20:48:43 johnpur: sounds like we just had our first major scope creep 20:49:03 some of the things you described are proposed for satellite 20:49:10 johnpur: well, that's sort of why jim and I like to refer to ourselves as "core dev infrastructure" rather than just CI 20:49:15 devcamcar: it is part of the on-going openstack-qa discussion 20:49:46 scope creep devcamcar ? 20:49:49 johnpur: since we currently manage all of those things in the set of systems that are relyed on by the project 20:49:54 i think set it up as a project and elect a team lead if you want and encourage contributions, but it's not really part of a cloud software stack 20:49:54 it's not going to get get shipped in a downstream distribution or deployed at a service provider 20:50:07 there is a difference between software we're shipping to our users and things that help us produce that software 20:50:25 jbryce: Exactly 20:50:27 i agree with ttx that we shouldn't call the latter exactly the same thing as the former 20:50:39 notmyname: if they don't have release code deliverables, they shoudn't be a core project 20:50:47 qa and ci arw closely coupled, but docs? 20:50:50 service providers (being part of the community) will be setting up and running CI and QA systems (hopefully). 20:50:57 but i think if we want to come up with some more official mechanism for oversight we can do that 20:51:01 and if they can't be a core project... then calling them "projects" is confusing 20:51:03 integration with packaging, CI, docs, etc (whatever this group is called) should be the same as eg integration between nova+glance+swift+keystone 20:51:11 ttx: it's about consistency 20:51:28 notmyname: i think they're too different to try to enforce artificial consistency 20:51:37 jbryce: what's artificial? 20:51:49 their output has very different purposes 20:51:59 ttx: I thought we only had one deliverable: Openstack ;-) 20:52:21 I don't have strong feelings either way, but calling them all "projects" while they are all different things doesn't really help 20:52:39 ttx: I think you've used the word "component" in the past :-) 20:53:03 so, I guess the thing that I'm on about is that currently there are a set of us doing the tasks to get these things done, and we respond to the needs and wishes of the ppb... but the relationship of the people doing the jobs to the openstack project is happenstance rather than explicit 20:53:05 notmyname: yes...the projects are components of the open source cloud system we are trying to build.... 20:53:08 notmyname: the word "project" unfortunately survived ! 20:53:13 I think the areas themselves are actually working pretty well 20:53:19 ci software would not be a component of that 20:53:46 mtaylor: so are you in search of a problem here? 20:53:55 notmyname: possibly 20:53:58 :) 20:54:01 mtaylor: maybe wait for it to fail 20:54:25 * mtaylor likes having failover systems in place _before_ failure ... but perhaps spent too much time doing HA consulting 20:54:31 mtaylor: the PPB (currently) has the power to fix things going wrong... not sure it should be involved in things that work well 20:55:01 jbryce: ttx: this may poison my whole argument for a separate project, but I really like this idea because it's part of what I originally wanted with with project autonomy. each project (including the meta-project) choosing for themselves their best things and integrating with every major openstack release 20:56:13 I guess I don't like the idea of a single meta-project with one true lead. I think Anne should lead docs, whoever happens to lead CI. 20:56:31 i'm not sure there's an action to take right now unless someone wants to try to put together a real proposal 20:56:32 and if there is more than one, you need a category 20:56:42 where i see ppb involvement is enforcing that the ci and qa processes are required of projects. that we use common processes and utilize the same mechanisms to gate trunck, etc. trying to push a consistent approach. 20:56:46 ttx: no different that nova and lieutenants 20:57:10 notmyname: we don't call lieutenants areas "projects". They are called "subteams" 20:57:11 johnpur: enforcing integration across the projects 20:57:24 ttx: sounds good to me 20:57:58 ttx: a doc subteam of the openstack integration project 20:58:02 etc 20:58:04 notmyname: but who could lead a single frankenstein meta-project ? I don't think such a PTL would make sense 20:58:16 vishy is doing well ;-) 20:58:21 j/k j/k 20:58:26 lol 20:58:26 1 minute 20:58:35 ITS ALIVE!!!! 20:58:36 parting thoughts? 20:58:46 notmyname: wait - are you now saying that vishy is _not_ doing well? ;) 20:59:01 mtaylor: you're putting words in my mouth :-) 20:59:10 mtaylor: that's what I heard ! 20:59:15 Burn the witch ! 20:59:31 on that note.... 20:59:40 we're out of time 20:59:45 #endmeeting