20:00:01 <jbryce> #startmeeting
20:00:03 <openstack> 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 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:00:07 <jbryce> roll call?
20:00:10 <notmyname> here
20:00:11 <ttx> o/
20:00:16 <zns> here
20:00:28 <bencherian> here
20:01:20 <mtaylor> o/
20:01:21 <jk0> o/
20:01:54 <jbryce> ewanmellor, johnpur, vishy, anotherjesse: around?
20:02:14 <pvo> o/
20:02:38 <jbryce> all right...that's enough to get started
20:02:52 <jbryce> http://wiki.openstack.org/Governance/PPB - agenda has 1 thing on it
20:02:54 <ewanmellor> Here
20:02:57 <jbryce> #topic Status on vulnerability management team setup
20:02:58 <anotherjesse> here
20:03:03 <johnpur> hey
20:03:05 <jbryce> ttx: want to take it away?
20:03:09 <ttx> yes, wanted to do a quick update
20:03:16 <ttx> we recently made progress in setting up proper security teams
20:03:33 <ttx> 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 <ttx> ...and a large (open) team of security-concerned folks to discuss auditing and security improvements to OpenStack.
20:03:52 <ttx> For the first team, see http://wiki.openstack.org/VulnerabilityManagement
20:04:08 <ttx> #info Proposal is that the small vuln-mgmt team would be set as "security contact" for all the core projects
20:04:21 <ttx> Note that the affected PTL is getting involved as the very first step to vulnerability resolution.
20:04:37 <ttx> You can also see the proposed openstack.org/security page contents at:
20:04:43 <ttx> #link http://etherpad.openstack.org/8hWNQwkWf9
20:04:55 <vishy> here
20:05:15 <ttx> Let me know if you see anythign wrong in there
20:05:54 <zns> ttx: says to join https://launchpad.net/~openstack-security but the group does not exist.
20:06:17 <ttx> zns: sure, the contents needs t obe approved first
20:06:35 <ttx> basically I'm not sure we should have a common openstack group, or should we have project-oriented groups
20:06:47 <ttx> like the nova-security-improvements subgroup that vishy set up
20:06:49 <zns> ttx: ah. OK.
20:07:00 <mtaylor> is there any benefit to having per-project security groups?
20:07:13 <vishy> ttx: that subgroup was meant for improving the security of the code as opposed to responding to vulnerabilities
20:07:24 <ttx> vishy: the same for ~openstack-security
20:07:28 <mtaylor> 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 <vishy> ah ok
20:07:37 <ttx> vishy #openstack-vuln-mgmt is the team for responding to vuln
20:07:43 <mtaylor> ah
20:07:44 <jbryce> 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 <ttx> s/#/~
20:08:16 <jbryce> especially in the area of simplifying the process
20:08:23 <ttx> vishy: would you mind if we refunded ~nova-security-improvements into ~openstack-security ?
20:08:29 <vishy> one team for improvements seems kind of silly to me
20:08:31 <ttx> (that one is an open security interest group)
20:08:41 <vishy> they are very project specific
20:08:51 <jbryce> sorry...i'm talking one team for vulnerabilities
20:09:04 <ttx> jbryce: we need one team for vuln
20:09:10 <vishy> why would anyone who works in glance or swift care about reimplementing a nova-db worker to lock down the database?
20:09:15 <jbryce> i agree that improvements probably make more sense as separate teams
20:09:16 <vishy> (for example)
20:09:17 <anotherjesse> vishy: the http://wiki.openstack.org/VulnerabilityManagement seems to say it is about processes not code fixes
20:09:23 <anotherjesse> for handling security issues
20:09:37 <vishy> one team for process seems fine
20:09:43 <vishy> separate teams for implementation though
20:09:43 <pvo> for just security issues, I would think 1 team would work .
20:09:45 <ewanmellor> 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 <pvo> vishy: agree for implementation
20:10:00 <ttx> ewanmellor: see http://wiki.openstack.org/VulnerabilityManagement
20:10:10 <ttx> ewanmellor: it states it a bit more clearly
20:11:04 <jbryce> #info one team for vulnerability management across all openstack projects
20:11:05 <ewanmellor> ttx: OK, I would like to see one page with this stuff written down, not two ;-)
20:11:21 <jbryce> #info separate teams by project for general security improvements
20:11:25 <ttx> 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 <vishy> ttx: imo, security improvements are code specific and a shared group would just get bogged down in theory
20:12:25 <ttx> vishy: yes, I have no string opinion either way
20:12:50 <ttx> vishy: the security folks kinda prefer a common group, but I agree that a project-focused group would deliver more results
20:13:02 <ttx> ewanmellor: will make sure that is written down in both places !
20:13:15 <vishy> ttx: who are "the security folks"?
20:13:30 <ttx> ewanmellor: (the etherpad is the static website content, the wiki is much more controllable)
20:13:58 <ttx> 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 <ttx> vishy: mostly code auditors
20:14:15 <reed> we should also close the list openstack-security
20:14:27 <ttx> reed: close ? list ?
20:14:50 <ewanmellor> 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 <reed> 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 <ttx> vishy: I'll discuss the split with them
20:16:03 <ttx> ewanmellor: downstream users = distributions and public cloud providers
20:16:44 <ewanmellor> ttx: OK, worth clarifying.  Private cloud users may wonder whether they are in that category, or why they are not.
20:16:44 <ttx> ewanmellor: we will refine the process once the team is in place.
20:17:14 <ttx> ewanmellor: we badly need some process set up. it won't be set in stone once it's in place
20:17:32 <ttx> ewanmellor: but I see what you mean.
20:17:33 <jbryce> ttx: +1
20:17:57 <jbryce> let's get it in place and then we will really find out where we need to improve it
20:17:59 <ttx> OK, so we'll proceed in setting up the vuln-mgmt team and make progress on vuln management process
20:18:00 <ewanmellor> 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 <ttx> and I'll discuss splitting the security interest groups per project
20:18:58 <ttx> ewanmellor: the problem is to balance disclosure with speed of fix
20:19:27 <ttx> ewanmellor: once downstream users (with my definition) know about it, it's all downhill from there
20:19:40 <ttx> ewanmellor: you need to coordinate release fast
20:20:04 <johnpur> ttx: fixes hit the "stable" branch quickly?
20:20:07 <ttx> ewanmellor: that's why the current proposed process gets a fix first
20:20:20 <ttx> the stable branch would be one of the downstreams.
20:20:43 <ewanmellor> 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 <ttx> ewanmellor: and then coordinates the fix down
20:21:38 <ttx> ewanmellor: the "downstream users" group will be large. You can't keep a secret long with such a group
20:22:03 <ttx> in my experience with 20+ people in the loop you can't embargo for more than one week.
20:22:08 <notmyname> ttx: based on the foundation announcement, seems that we can't keep a secret in the PPB either ;-)
20:22:23 <mtaylor> it should be assumed that secrets are impossible to keep
20:22:34 <bencherian> agreed
20:22:38 <ttx> mtaylor: indeed, that's why time is of the essence
20:22:40 <ewanmellor> 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 <ttx> I bet the moment the vulnerability is known, some affected people will start deploying fixes.
20:24:44 <ttx> ewanmellor: I see your point. I guess we can discuss that when we'll have a list for the "downstream users" :)
20:24:52 <ewanmellor> 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 <ttx> see if we can reorder the process
20:25:03 <johnpur> for users in production, it may be critical to get the fixes, get through QA, and pushed to production
20:25:22 <ttx> ewanmellor: I guess a few years on vendor-sec has left me a bit pessimistic
20:26:49 <ttx> 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 <jbryce> 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 <ttx> ewanmellor: I guess we could say something is coming up, without too much detail
20:27:21 <ewanmellor> ttx: Know about the _existence_ of a vuln.  Not necessarily what it is.
20:27:28 <ttx> ewanmellor: oh, I see
20:27:33 <ttx> ewanmellor: sure, that's acceptable
20:27:38 <ttx> (I think)
20:27:44 <johnpur> ttx: agree. need to define downstream crisply, particularly the branches that have deployed systems
20:28:04 <ttx> "something affecting that and that, severity High, coming up, patch on its way"
20:28:12 <jbryce> ttx: that makes sense to me
20:28:41 <ttx> ewanmellor: I'll roll that in the process
20:28:55 <ttx> ewanmellor: or you can. hey, it's a wiki :)
20:28:56 <ewanmellor> ttx: Sounds good.
20:29:27 <ttx> jbryce: I think I'm done, will keep you posted with more progress next week
20:29:28 <ewanmellor> Security processes documented on wikis *shudder*
20:29:47 <jbryce> ok
20:29:49 <ttx> ewanmellor: hehe
20:29:56 <jbryce> #topic open discussion
20:30:10 <jbryce> anyone have anything else they'd like to discuss?
20:31:02 <mtaylor> 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 <devcamcar> here now btw
20:31:51 <mtaylor> especially now that we're starting to get more contributions in that space from non-rackspace folks
20:32:01 <ttx> mtaylor: I would keep "openstack projects" to pure user-facing code. Make up a team and hold elections if you want ?
20:32:14 <notmyname> mtaylor: I like that idea
20:32:37 <mtaylor> 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 <ttx> i.e. don't reuse the word PTL but copy the idea
20:33:07 <jbryce> ttx: i agree. i wouldn't consider that "administrative" type thing to be part of the shipped openstack software
20:33:08 <ttx> "Team lead"
20:33:09 <bencherian> 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 <ttx> team leads should be elected as soon as people don't agree who should be the lead, basically
20:33:53 <notmyname> 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 <jbryce> 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 <jbryce> it's not going to get get shipped in a downstream distribution or deployed at a service provider
20:34:24 <ttx> i.e. it's not incubating or core or whatever
20:34:45 <notmyname> jbryce: no, but it's an essential piece of openstack itself
20:34:47 <mtaylor> 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 <ttx> notmyname: I'm not sure mtaylor includes packaging in that
20:35:11 <notmyname> ttx: he should ;-)
20:35:13 <johnpur> mtaylor: do you consider the openstack-qa effort part of this?
20:35:32 <mtaylor> ttx: well... I would include packaging in that if the openstack project decided it wanted to provide packaging :)
20:35:32 <notmyname> johnpur: I would
20:35:43 <ttx> mtaylor: my point :)
20:35:52 <mtaylor> johnpur: interesting question - one consumes the output of the other in my head
20:36:13 <johnpur> mtaylor: right
20:36:17 <mtaylor> I actually think that openstack-qa should similarly be an administrative managed grouping that also doesn't produce shipped code
20:36:21 <annegentle> 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 <ttx> So we might need some area for "official team" or something
20:36:37 <ttx> I don't want all teams to go through PPB for formation*
20:36:56 <zns> Would this be something the "foundation" would own?
20:36:57 <ttx> though some teams, owning some critical central stuff, would benefit from PPB oversight
20:36:58 <annegentle> or rather, not necessarily unnecessary, but the wrong governance model
20:37:13 <mtaylor> ++
20:37:15 <jbryce> 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 <notmyname> 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 <johnpur> so we need to "define" how we handle automation, qa, and docs?
20:37:46 <notmyname> zns: IMO, no more than the foundation "owns" swift, nova, or keystone
20:37:46 <ttx> jbryce: sure. Not project, but "official team" or "meta-project", or whatever new name we can come up with
20:37:56 <devcamcar> throwing all the support projects into one lump doesn't seem wise
20:38:00 <ttx> for a team that own s a part of openstack that the PPB still should have oversight over
20:38:20 <johnpur> ttx: +1
20:38:59 <ttx> devcamcar: I agree it should not be a single "janitor meta-project", but rather a category of stuff.
20:39:00 <devcamcar> ++
20:39:07 <notmyname> 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 <ttx> I can think of two teams that fit that description
20:39:17 <ttx> doc and CI
20:39:40 <johnpur> ttx: qa?
20:39:45 <mtaylor> I think qa is the third. it's currently working on producing openstack-integration-tests
20:39:51 <ttx> johnpur: I don't think so.
20:39:58 <mtaylor> which will be pretty stinking important to the project
20:40:04 <mtaylor> hopefully :)
20:40:06 <ttx> We could have multiple competing QA projects, no ?
20:40:12 <mtaylor> god I hope not
20:40:29 <ttx> why?
20:40:29 <zykes-> devcamcar: got time for some questions regarding nova & db in #..-dev ?
20:40:29 <zns> 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 <mtaylor> let's put it this way - the CI system will not use multiple competing QA projects to tests openstack
20:40:49 <annegentle> ttx: I think QA and Doc could help each other.
20:41:07 <ttx> I really see QA as a team thing. You don't need permission to do QA
20:41:19 <ttx> and all QA is good
20:41:27 <ttx> contrast with CI -- you only have one CI.
20:41:30 <mtaylor> 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 <devcamcar> zykes: I will be able to in a min
20:41:45 <ttx> mtaylor: CI can choose to use whatever team's tests they want
20:41:56 <zns> 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 <ttx> mtaylor: just choose to use the ones from the super-QA team
20:42:06 <mtaylor> so the test suites that are the output of the QA team's work
20:42:15 <johnpur> ttx: getting a coherent and consistent qa effort amongst the community is super important
20:42:27 <mtaylor> ttx: so, that's a business I do not want to be involved in - choosing _which_ qa product I prefer
20:42:50 <mtaylor> 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 <mtaylor> is all I'm saying
20:42:56 <ttx> 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 <mtaylor> ttx: and if someone can't bear vishy and still wants to hack on nova?
20:43:21 <johnpur> ttx: lol, who doesn't love jay?
20:43:44 <annegentle> ttx: the benefits would be in consistency (for all three teams)
20:43:47 <mtaylor> or doesn't like me and wants to help run the CI system? ;) (that's the more believable example)
20:44:11 <ttx> mtaylor: my point -- QA is something you can do in multiple ways. While CI or Nova are unique
20:44:16 <annegentle> all doc is good, but it's better if it's consistent and trustworthy
20:44:26 <mtaylor> ttx: I think you and I are using the word QA differently
20:44:57 <mtaylor> 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 <ttx> mtaylor: imagine a group calling themselves "the-fuzzers" wanting to do some code analysis and file bugs based on their results
20:45:04 <mtaylor> ttx: so we might need an additional word
20:45:11 <mtaylor> ttx: right. I don't give a shit about that :)
20:45:15 <ttx> mtaylor: do you want to prevent them from forming a group ?
20:45:20 <ttx> mtaylor: that's QA too
20:45:24 <mtaylor> god not. but that's not what I'm talking about
20:45:39 <mtaylor> ok. so let's call what I'm talking about "openstack integration test developers"
20:45:48 <ttx> 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 <ttx> right
20:46:31 <mtaylor> 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 <ttx> mtaylor: agreed, that should be unique :)
20:46:48 <johnpur> ttx: i see it as more than that. consistent test frameworks, hooks to the ci mesh, gating trunk, etc.
20:47:55 <devcamcar> mtaylor: are you looking for a name or formal policy?
20:48:04 <ttx> mtaylor: sure, just don't call them "projects" and don't call their lead "PTL".
20:48:09 <johnpur> code coverage, bare metal provisioning and deployment, etc.
20:48:23 <notmyname> ttx: -1
20:48:43 <devcamcar> johnpur: sounds like we just had our first major scope creep
20:49:03 <devcamcar> some of the things you described are proposed for satellite
20:49:10 <mtaylor> 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 <johnpur> devcamcar: it is part of the on-going openstack-qa discussion
20:49:46 <zykes-> scope creep devcamcar ?
20:49:49 <mtaylor> johnpur: since we currently manage all of those things in the set of systems that are relyed on by the project
20:49:54 <ttx> <jbryce> 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 <ttx> <jbryce> it's not going to get get shipped in a downstream distribution or deployed at a service provider
20:50:07 <jbryce> there is a difference between software we're shipping to our users and things that help us produce that software
20:50:25 <devcamcar> jbryce: Exactly
20:50:27 <jbryce> i agree with ttx that we shouldn't call the latter exactly the same thing as the former
20:50:39 <ttx> notmyname: if they don't have release code deliverables, they shoudn't be a core project
20:50:47 <devcamcar> qa and ci arw closely coupled, but docs?
20:50:50 <johnpur> service providers (being part of the community) will be setting up and running CI and QA systems (hopefully).
20:50:57 <jbryce> but i think if we want to come up with some more official mechanism for oversight we can do that
20:51:01 <ttx> and if they can't be a core project... then calling them "projects" is confusing
20:51:03 <notmyname> 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 <notmyname> ttx: it's about consistency
20:51:28 <jbryce> notmyname: i think they're too different to try to enforce artificial consistency
20:51:37 <notmyname> jbryce: what's artificial?
20:51:49 <jbryce> their output has very different purposes
20:51:59 <notmyname> ttx: I thought we only had one deliverable: Openstack ;-)
20:52:21 <ttx> 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 <notmyname> ttx: I think you've used the word "component" in the past :-)
20:53:03 <mtaylor> 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 <jbryce> notmyname: yes...the projects are components of the open source cloud system we are trying to build....
20:53:08 <ttx> notmyname: the word "project" unfortunately survived !
20:53:13 <mtaylor> I think the areas themselves are actually working pretty well
20:53:19 <jbryce> ci software would not be a component of that
20:53:46 <notmyname> mtaylor: so are you in search of a problem here?
20:53:55 <mtaylor> notmyname: possibly
20:53:58 <mtaylor> :)
20:54:01 <ttx> 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 <ttx> 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 <notmyname> 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 <ttx> 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 <jbryce> 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 <ttx> and if there is more than one, you need a category
20:56:42 <johnpur> 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 <notmyname> ttx: no different that nova and lieutenants
20:57:10 <ttx> notmyname: we don't call lieutenants areas "projects". They are called "subteams"
20:57:11 <notmyname> johnpur: enforcing integration across the projects
20:57:24 <notmyname> ttx: sounds good to me
20:57:58 <notmyname> ttx: a doc subteam of the openstack integration project
20:58:02 <notmyname> etc
20:58:04 <ttx> notmyname: but who could lead a single frankenstein meta-project ? I don't think such a PTL would make sense
20:58:16 <notmyname> vishy is doing well ;-)
20:58:21 <notmyname> j/k j/k
20:58:26 <vishy> lol
20:58:26 <jbryce> 1 minute
20:58:35 <vishy> ITS ALIVE!!!!
20:58:36 <jbryce> parting thoughts?
20:58:46 <mtaylor> notmyname: wait - are you now saying that vishy is _not_ doing well? ;)
20:59:01 <notmyname> mtaylor: you're putting words in my mouth :-)
20:59:10 <ttx> mtaylor: that's what I heard !
20:59:15 <ttx> Burn the witch !
20:59:31 <jbryce> on that note....
20:59:40 <jbryce> we're out of time
20:59:45 <jbryce> #endmeeting