20:12:01 <jbryce> #startmeeting
20:12:02 <openstack> Meeting started Tue Aug 16 20:12:01 2011 UTC.  The chair is jbryce. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:12:03 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:12:15 <jbryce> agenda - http://wiki.openstack.org/Governance/PPB
20:12:33 <jbryce> is ziad present?
20:12:39 <zns> Yes
20:12:45 <zns> zns=ziad
20:12:54 <jbryce> #topic Keystone review
20:13:12 <jbryce> ziad said he'd like to have keystone considered for promotion to core during this cycle
20:13:43 <jbryce> this wiki page had some of the criteria we had previously laid out as the things we would want to evaluate new projects on: http://wiki.openstack.org/Governance/Approved/NewProjectProcess
20:13:43 <zns> Part of the exercise is to figure out what are the requirements for inclusion in core...
20:14:38 <jbryce> zns: i think an update of how you feel the project is maturing from a development and deployment standpoint is a start
20:14:59 <zns> Item #1. DONE. Code is out there.
20:15:05 <zns> Item #2 is to gather feedback.
20:15:15 <zns> I'd like your feedback. Status right now is...
20:15:33 <zns> We're finalizing the API and aim to get a stable release out by Diablo.
20:15:53 <zns> We have production deployments (although, I admit, I have not been part of setting them up!)
20:16:31 <zns> Integration with other projects is moving along well (I'd say Swift integration is the toughest and still needs work).
20:16:48 <jaypipes> zns: I've been impressed with Keystone devs learning the new Gerrit processes and working with Monty and Jim to integrate with the CI infrastructure.
20:16:49 <notmyname> zns: I've been able to get it to work (however, the docs are completely wrong)
20:17:05 <zns> We have interested parties outside Rackspace submitting code (LDAP backend is one example).
20:17:20 <zns> notmyname: yes, docs are bahind.
20:17:25 <jbryce> do people feel like finalizing the api is an important milestone for core promotion?
20:17:27 <zns> behind
20:17:41 <anotherjesse> jbryce: I'm torn - since it is a high bar
20:18:08 <anotherjesse> but when we know that the api *WILL* change soon, it feels like it should be finalized before promotion
20:18:12 <ttx> zns: when do you plan to move your issues to LP bugs ?
20:18:13 <jaypipes> zns: one thing I'd like to see, though, is a little more restraint on +2'ing code reviews... it seems there is a bit of a "just wing it" thing going on there :) I think working with mtaylor to set up a param builder for Keystone would help to alleviate some of the issues.
20:18:59 <zns> ttx: working with jay/monty and team on that. They have a script. We're ready to do that as soon as we get the api done (focusing on that this week).
20:19:09 * jaypipes doesn't think finalizing 2.0 API should be a requirement for core promotion...
20:19:17 <ttx> zns: cool
20:19:18 <zns> jaypipes: agreed.
20:19:36 <jaypipes> zns: on the API front or the code review comment? :)
20:19:43 <ttx> jaypipes: do we have Keystone ubuntu/debian packaging under control ?
20:19:45 <notmyname> I don't think a final API is key. using the same processes as the other projects (like issues moving to LP) and establishing community involvement seem the important things top me
20:19:48 <zns> In fairness, we need to get more aggressive on following the LP workflow (Blueprint, approval, code, etc…).
20:20:02 <jaypipes> ttx: one sec, checking blueprint.
20:20:05 <vishy> i am split as well.  I think we need auth in core ASAP, but keystone is still highly volatile, and it might be sending a bad message to promote it right now.
20:20:16 <zns> jaypipes: on the review part.
20:20:24 <ttx> vishy: it will be promoted for the next release.
20:20:26 <anotherjesse> jaypipes: as someone who helps with implementation, deployed it and consumed it - it is a *required* part of openstack
20:20:29 <ttx> i.e. be in core for Essex
20:20:41 <johnpur> agree that we need to have a core auth project
20:20:43 <anotherjesse> jaypipes: but we need to get API settled ?
20:20:43 <ttx> it won't be part of "Diablo".
20:21:08 <ttx> so it needs to be stable in 6 months. Not now.
20:21:10 <anotherjesse> jaypipes: i'm concerned if it isn't, once it becomes core does it become harder to settle?
20:21:16 <mtaylor> ttx: I'm going to be attacking soren's keystone packaging work probably tomorrow (and zul's doing some work tonight_ so we should have it well under hand soon
20:21:22 <jbryce> ttx: that is a good point. we are talking about it being a core project for essex in ~7 months
20:21:31 <johnpur> there is a reality that core projects depend on it today and going forward
20:21:31 <anotherjesse> ttx: the problem with that statement is that nova is removing its user system to REQUIRE keystone
20:21:37 <jaypipes> anotherjesse: not sure. I don't feel that it becomes harder to settle, but that's an opinion, nothing more...
20:21:39 <anotherjesse> this milestone
20:22:13 <soren> anotherjesse: Wait, what?
20:22:18 <ttx> anotherjesse: I think that's a mistake.
20:22:25 <ttx> anotherjesse: I thought it was to be an option.
20:22:27 <anotherjesse> it is what was discussed at the last summit
20:22:36 <anotherjesse> and is what vishy has been talking about in blueprints, ...
20:22:36 <notmyname> anotherjesse: but that's not a big issue, is it? we all depend on other things (eg eventlet) that aren't in openstack core
20:22:55 <zns> If it helps, the API and implementation will be done by Diablo. Our goal is to have no changes after diablo feature freeze (9/6) and, in fact, have the API locked down this week (we're a few days behind our self-set deadline of 8/14).
20:22:59 <anotherjesse> notmyname: I am talking to the statement that stabliity of keystone api isn't important
20:23:04 <anotherjesse> notmyname: it is very important
20:23:21 <notmyname> anotherjesse: indeed. but is it a requirement for core inclusion?
20:23:32 <notmyname> anotherjesse: I tend to think not
20:23:37 <johnpur> what we need to do here is set a precedent/policy around the usage of keystone across projects.
20:23:39 <anotherjesse> notmyname: I wasn't sure
20:23:51 <jaypipes> anotherjesse: yes, agreed with notmyname. I don't think anyone is saying it's not important... just that it's not a blocker for core promotion.
20:23:57 <johnpur> i feel we are implicitly moving in the direction of "coreness"
20:24:04 <anotherjesse> johnpur: ya
20:24:23 <notmyname> johnpur: there are some important discussions around how/if it is integrated
20:24:26 <johnpur> shouldn't we make it official, and require the project follow the core project rules/guidelines?
20:24:50 <anotherjesse> johnpur: even if it isn't core, if dash, glance, nova all integrate with it
20:24:50 <anotherjesse> if in order to have a multi-tenant cloud you need keystone, then keystone is de-facto core ;)
20:25:02 <johnpur> anotherjesse: right
20:25:11 <jaypipes> anotherjesse: glance integrates with it, but doesn't *require* it...
20:25:19 <anotherjesse> jaypipes: right
20:25:21 <notmyname> johnpur: same with swift
20:25:33 <ttx> anotherjesse: ...and it is my opinion it should be the same for nova
20:25:35 <notmyname> err jaypipes:
20:25:44 <johnpur> i guess dash isn't core, but it requires it i believe
20:25:54 <jaypipes> notmyname: I got ya :)
20:25:58 <ohnoimdead> johnpur: yeah, dash requires keystone currently
20:25:58 <anotherjesse> notmyname: without keystone or swauth (both external auth to swift) then swift accepts any query right?
20:26:10 <ttx> dash requiring it is not an issue -- it's not in core
20:26:19 <notmyname> anotherjesse: yes, but we include a tempauth stub to do simple stuff
20:26:31 <johnpur> for folks that rae integrating authn/authz systems it is pretty important to have a consistent framework to hang openstack off of
20:26:51 <anotherjesse> notmyname: which is saying that "an auth system" needs to be added - even if simple
20:26:51 <ttx> vishy: do we *have to* rip out the current auth from nova ?
20:27:05 <alekibango> hmm so if i understand it correctly,  without auth  it will be possible to anonymously upload whatever images into glance for next 6 months ?    or i missed something...
20:27:06 <anotherjesse> ttx: and so that is what we have been talking about for nova
20:27:13 <johnpur> ttx: separate discussion
20:27:17 <anotherjesse> ttx: remove auth from inside nova to being external
20:27:19 <jbryce> so the questions that have been raised so far are around api stability, merge acceptance process, bug tracker and rate of change of the codebase. is there anything distinct for keystone specifically?
20:27:22 <anotherjesse> provided by a component
20:27:42 <anotherjesse> jbryce: what is the level of stability that we require
20:27:48 <anotherjesse> I want it to be core
20:28:00 <johnpur> anotherjesse +1
20:28:15 <anotherjesse> but I want it to have some level of stability by being in core
20:28:26 <anotherjesse> currently the mutation rate is HIGH
20:28:29 <creiht> Is there any level of scalability that is required (of any core project added)?
20:28:36 <notmyname> jbryce: zns: how does it handle scale? that is one of the core openstack principles. (just making sure it's on the list too)
20:28:51 <johnpur> notmyname: good q
20:28:55 <jbryce> it will be core for the essex cycle, so not official until next april. so i would say a level of stability and a trajectory that we feel comfortable it can be solid and production ready, deployable, not out-of-control by the essex timeframe
20:29:07 <ttx> jbryce: +1
20:29:09 <jbryce> it will be core for essex if approved now, i mean
20:29:18 <notmyname> anotherjesse: I may be wrong, but isn't nova's codebase pretty volatile too? (or at lest it used to be)
20:29:21 <vishy> ttx: My plan is to rip out unused parts, to deprecate the core stuff in diablo, and pull it out in essex
20:29:38 <zns> notmyname: we have not tested at scale. We support LDAP and MySQL as backends for more *scalable* deployment, but we still need to validate load-balancing multiple nodes.
20:29:38 <anotherjesse> notmyname: there is a difference between external volatility and internal
20:29:40 <ttx> vishy: ok
20:29:42 <vishy> ttx: so you should be able to configure nova to use old auth, but it will not be the default
20:29:45 <johnpur> jbryce: by being a core component, what do we say is the "policy" around required use by core/inubated/associated projects?
20:29:58 <notmyname> anotherjesse: ok. that's true. but one leads to the other, no?
20:30:00 <vishy> ttx: my plan is default: no multitenant auth
20:30:17 <anotherjesse> notmyname: right - hence i was asking if the api settling down would be a good thing to happen first
20:30:18 <jbryce> Integration Each project should use as many of the others' features as possible and provide the requested integration points
20:30:25 <jbryce> http://wiki.openstack.org/ProjectTypes
20:30:30 <vishy> ttx: with options for keystone or old auth, with keystone heavily favored
20:30:47 <anotherjesse> so - reason for this concenr: when keystone is added to core - other projects should work hard to make sure we all play well together
20:30:49 <notmyname> nd if keystone isn't accepted today, it can still be accepted up to halfway throught he essex cycle, right?
20:30:52 <ttx> anotherjesse: I think you need less mutation because of the integration with components, not because it will be in core for Essex
20:30:59 <ttx> notmyname: no
20:31:07 <ttx> notmyname: we need it in core before the design summit
20:31:12 <notmyname> ttx: ah
20:31:14 <anotherjesse> if the api is still in flux, then swift+nova+glance saying we all play with keystone
20:31:17 <johnpur> ttx: agree
20:31:30 <anotherjesse> will be complicated - since it changes daily due to being actively reworked
20:31:32 <ttx> notmyname: so that we can have the PTL involved in prep and give it the place it deserves in the summit
20:31:33 <vishy> can we reeval in a few weeks then?
20:31:45 <ttx> vishy: deadline is Sep5
20:31:55 <jbryce> anotherjesse: it sounds like zns is saying the api will be done very soon
20:31:56 <ttx> (based on a recent PPB decision)
20:31:59 <johnpur> vishy: what will you leatn in a couple of weeks?
20:32:07 <johnpur> learn
20:32:13 <anotherjesse> jbryce: yes - they were locked in a room all day friday and are working on it
20:32:22 <alekibango> vishy:  +1
20:32:23 <jaypipes> sounds like fun
20:32:24 <jbryce> we have 3 weeks basically to approve it
20:32:27 <zns> johnpur: API stable. That's big for integration and *comfort* around integration.
20:32:30 <anotherjesse> I'd rather that finish, not focus on integration into core (whatever that entails)
20:32:51 <jbryce> so what if we defer for now and get another update next week
20:32:51 <vishy> johnpur: I'm convinced it should go in, but I think it sends a better message to wait for stability before promoting
20:32:57 <johnpur> zns: will it be done by then?
20:33:02 <anotherjesse> vishy: ++
20:33:05 <alekibango> vishy: ++
20:33:08 <johnpur> vishy: i get it
20:33:13 <johnpur> and agree
20:33:17 <heckj> vishy++
20:33:37 <jaypipes> vishy: ++
20:33:37 <zns> johnpur: Sept5 or next week? Yes to Next week=API documented. Sept 5th implemented.
20:33:37 <jbryce> johnpur: if not, we can defer until the week after. we have 3 weeks (minus a day) before the deadline.
20:33:54 <jaypipes> remember, next week we have to review quantum for incubation...
20:34:07 <johnpur> i am hearing that (assuming the right level of work) that Keysone will be core for Essex, just a matter of timing?
20:34:35 <zns> vishy: I agree with the message to set the bar high. I would like to be clear on what the bar is so we can work towards that...
20:34:42 <notmyname> johnpur: well, the timing is depending on the level of work :-)
20:34:48 <johnpur> and we can have a lot of discussion at the DS :)
20:35:02 <jbryce> zns: i think the main component is api definition stable. correct me if i'm wrong, anyone
20:35:24 <johnpur> zns: who is giving input on the api dfn?
20:35:44 <jbryce> so that integrating projects will not have to worry about a moving target and we are establishing a precedent of external stability before core promotion
20:35:59 <zns> johnpur: many inputs from mailing list, blueprints, etc...
20:36:03 <jaypipes> jbryce: correct
20:36:28 <johnpur> zns: how are you arbitrating the inputs?
20:36:39 <jbryce> i propose we defer decision on keystone promotion until next week. review again with the primary focus for the team to be api stability. thoughts?
20:37:07 <jaypipes> jbryce: #agreed
20:37:08 <zns> johnpur: right now, the bar has been easy given our first goal: support existing Nova, swift, Rackspace use cases.
20:37:15 <anotherjesse> johnpur: I think they are focusing on making the core api as small as possible, until friday core was 2 api calls
20:37:43 <johnpur> ah, ok
20:38:09 <anotherjesse> johnpur: authenticate(user, pass, optional tenant) -> token, catalog
20:38:21 <anotherjesse> johnpur: validate(token) -> user/tenant/role info
20:38:40 <johnpur> it is critical that not only are the api calls stable and defined, but that all of the concepts are consistent, right? tenancy, project, user, account, etc.
20:38:43 <anotherjesse> there are extensions about how users/tenants/roles can be managemed
20:39:01 <johnpur> across projects
20:39:12 <vishy> * and get_tenants no?
20:39:19 <anotherjesse> vishy: oh ya ;)
20:39:25 <anotherjesse> johnpur: ++ - it is critical that the concepts of tenant (projects in nova, accoutns at rax), user, roles
20:39:35 <anotherjesse> and what the response from validate (the roles, ...)
20:39:47 <johnpur> right
20:40:01 <anotherjesse> zns: I think having a document with just core would be helpful to send to the list
20:40:14 <anotherjesse> zns: the user/tenant management is extensions
20:40:23 <zns> anotherjesse: working on that… will send out this week.
20:40:44 <anotherjesse> zns: i wouldn't mind help etherpading the core doc
20:40:46 <anotherjesse> if you have time
20:40:50 <zns> anotherjesse: yes, non-core is either OS extensions or RAX extensions.
20:40:51 <anotherjesse> moving to sidechannel
20:41:00 <jbryce> ok. so, defer until next week?
20:41:07 <ttx> jbryce: sure
20:41:07 <anotherjesse> heh - ya - sorry
20:41:20 <notmyname> jbryce: +1
20:41:33 <jbryce> #info defer promotion decision 1 week. keystone team to focus on external api stability and definition.
20:41:49 <jbryce> http://wiki.openstack.org/Governance/Proposed/OpenStack%20Security%20Group
20:41:49 <jbryce> #topic security group proposal
20:41:54 <johnpur> anotherjesse, zns: let me know if there are discussions/etherpadding, etc.
20:42:14 <jbryce> we've had a fair amount of discussion on this already on the mailing list
20:42:41 <jbryce> how does everyone feel about the state of the proposal currently?
20:42:53 <notmyname> jbryce: my thoughts are that this proposal seems...ponderous. a defined process to submit bugs and alert the right dev teams seems all we need
20:44:09 <notmyname> I don't think there needs to be a separate group responsible for "Security". If we all arent' aware of it while we're writing/reviewing the code we're going to end up in a world of hurt.
20:44:27 <ttx> I share Soren's concern on the group size
20:44:34 <zns> johnpur: will do
20:44:41 <johnpur> thx
20:44:54 <notmyname> ttx: as do i
20:44:59 <ttx> notmyname: yes -- we need nothing like something of the size of MSG
20:45:01 <dendrobates> ttx: me too
20:45:19 <soren> I'm thinking 2 people. Maybe 3.
20:45:33 <jaypipes> I think having a group focused on testing OpenStack (the entire project, not just a subproject) for security vulnerabilities is a worthy goal.
20:45:35 <ttx> I mean, I've yet to see a serious vulnerability that would have neede embargo.
20:45:46 <johnpur> jbryce: i would like to see the proposal broken into 2 pieces: 1) process for setting up openstack working groups, and 2) the specific around a security wg
20:45:47 <soren> jaypipes: That's not what this is, though.
20:45:50 <notmyname> soren: agreed. and those people IMO really only need to be responsible for getting the bug reports to the right people
20:45:53 <ttx> jaypipes: that's an auditor group -- that's different
20:45:55 <soren> jaypipes: At least, that's not what I read into it all.
20:46:07 <creiht> perhaps another way of stating notmyname's position (which I share) is it would be better to start small and expand as the need requires rather than create a huge bureaucracy to start with
20:46:24 <jaypipes> creiht: ++
20:46:25 <ttx> creiht: +1
20:46:34 <johnpur> i think there are at least 2 working groups we could initiate, besides the security group
20:46:50 <letterj> jaypipes: are any of the current tests focused on security?
20:46:51 <termie> wgwg
20:47:00 <vishy> I think there are six or seven working groups here :)
20:47:09 <johnpur> termie: lol!
20:47:10 <termie> seconded
20:47:29 <anotherjesse> termie: pbb = wgwg
20:47:31 <jaypipes> letterj: not that I know of.. what about for swift?
20:47:38 <johnpur> my 2 are 1) legal and 2) strategy
20:48:33 <notmyname> johnpur: that's getting a little off topic, isn't it? ;-)
20:48:46 <notmyname> it's not like we have a lot of time here
20:48:48 <letterj> jaypipes: Not specific security tests I know of not related to auth
20:48:48 <ttx> letterj: I'm adding some security-related tests together with my new privsep stuff
20:48:54 <anotherjesse> johnpur: both groups need to talked about but ping jbryce about those?
20:49:09 <johnpur> notmyname: probably, but if we have a process to define the groups, then the security group is just one of some
20:49:30 <johnpur> i'll table it now
20:49:48 <jbryce> johnpur: we can follow up on it later
20:49:54 <johnpur> jbryce: ok
20:50:02 <jaypipes> all I was saying was that having a team looking at security testing/validation for openstack as a whole would be a laudable effort, nothing more.
20:50:16 <jbryce> so on this it sounds like most people are in favor of a small group to start with to handle vulnerability identification and handoff
20:50:28 <letterj> Is there a list floating around somewhere of what specific sercurity tests people have in mind?
20:50:30 <jaypipes> and if Jarret is already offering to lead such an effort, that might be a good start...
20:50:44 <jbryce> separate from that possible a testing/validation group for all of openstack
20:50:57 <jaypipes> letterj: I'm thinking that an app security person like Jarret would probably have some ideas on that :)
20:50:58 <ttx> jaypipes: I can work with Jarret.
20:51:04 <johnpur> we need an escalation as well for when a problem is found inthe community, an escalation of a bug report
20:51:24 <notmyname> johnpur: I think that's all that's needed now
20:51:29 <letterj> jaypipes: What about a test enviornment?
20:51:34 <johnpur> many folks are doing security, penetration, etc. testing
20:51:38 <creiht> it just needs to be well defined, and published
20:51:47 <creiht> I don't think most people know about the feature in launchpad
20:51:50 <heckj> creiht: published ++
20:52:02 <letterj> jaypipes: I didn't know if a list of proposed tests or things to look for had been proposed
20:52:16 <jaypipes> letterj: ya, no worries :)
20:52:30 <ttx> creiht: yes + publish a couple individual email addresses with GPG keys, in case someone wants to send an encrypted report
20:52:57 <creiht> ttx: certainly, or at least publish those for all the PTLs and publish the fact that they are the main points of contact
20:52:59 <ttx> that's all we urgently need. Doc on how to submit a security vulnerability
20:53:05 <creiht> agreed
20:53:08 <notmyname> ttx: ++
20:53:35 <anotherjesse> ttx: I think there should be page on openstack.org and it linked at the footer of every community page
20:54:05 <jbryce> so we are rejecting the larger proposal for now and setting up a small team to route reports, plus publishing the process for submitting security reports
20:54:12 <ttx> anotherjesse: that's part of what Jarret proposes -- maybe we should skip the "security group" setup for now, and concentrate on doc ?
20:54:50 <creiht> If you have the security process well established, then it makes it easy for multiple groups to do their testing
20:54:52 <johnpur> jbryce: having Jarret be a point of contact seems like a good thing... we can point people to him?
20:55:30 <letterj> Is there a blueprint started on security tests yet?
20:56:03 <jbryce> we've got 4 minutes left so i'd like to get at least some resolution on this one before we run out of time
20:56:03 <ttx> jbryce: i can take the action of discussing a bit more with Jarret and come up with a proposed security.openstack.org page contents.
20:56:12 <jbryce> ttx: +1
20:56:21 <jaypipes> letterj: not that I know of. please feel free to create one.
20:56:34 <jaypipes> letterj: in the openstack-ci project maybe?
20:57:06 <jbryce> anyone opposed to ttx's proposal?
20:57:18 <jaypipes> nope, sounds good to me.
20:57:24 <jbryce> ok
20:57:25 <notmyname> jbryce: +1 to rejecting the larger proposal and publishing the security reports process
20:57:44 <jbryce> #action ttx to discuss more with jarret and come up with the content to publish a process for security reporting
20:58:15 <jbryce> anything else?
20:58:51 <jbryce> thanks everyone
20:58:58 <jaypipes> ty jbryce
20:59:02 <jbryce> #endmeeting