20:00:13 <jbryce> #startmeeting
20:00:14 <openstack> Meeting started Tue Jun 21 20:00:13 2011 UTC.  The chair is jbryce. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:15 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:00:20 <johnpur> ttx: job security?
20:00:35 <jbryce> i see notmyname, ttx, johnpur ... who else is here?
20:00:40 <jbryce> http://wiki.openstack.org/Governance/PPB - Agenda
20:00:45 <ttx> johnpur: who needs job security ? This is cloud, you know :)
20:00:45 <soren> o/
20:00:56 <vish1> o/
20:01:32 <zns> ziad
20:01:42 <heckj> o/
20:01:42 <devcamcar> hey all
20:01:55 <ttx> sebastianstadil: around ?
20:02:40 <johnpur> how about Ziad or any of the Keystone guys?
20:02:42 <sebastianstadil> ttx: yep
20:02:48 <soren> johnpur: 20:01 < zns> ziad
20:02:52 <jbryce> johnpur: zns = ziad
20:02:54 <zns> Yes!
20:02:54 <jaypipes> o/
20:03:00 <ttx> missing ewan, jesse, josh, dendrobates
20:03:06 <jesse__> here
20:03:07 <notmyname> just to throw this out there....answering item 5 on the agenda may in fact answer some of the earlier items on the agenda
20:03:20 <ttx> eday: ?
20:03:21 <jbryce> ok cool...that gives us enough. let's get started
20:03:38 <soren> notmyname: How do you figure that?
20:03:41 <jbryce> notmyname: not sure i follow?
20:04:06 <jbryce> there were no previous action items from last time except for sebastianstadil and devcamcar to catch up and see if there were opportunities to collaborate
20:04:41 <devcamcar> so to that end, my team spent several days evaluating scalr with the goal of being able to use it as a backend within dashboard
20:05:07 <devcamcar> we spent a great deal of time comparing both scalr and canonical's ensemble project
20:05:12 <jbryce> notmyname: i know you'd like to knock #5 out more urgently, but i think we owe it to devcamcar to review dashboard. i think #5 could easily take up the entire meeting... what if we do dashboard and then #5 before keystone?
20:05:27 <devcamcar> in the end, we decided not to move forward with scalr as a backend for a number of technical reasons
20:05:49 <sebastianstadil> most of them valid, I might add
20:05:54 <jaypipes> devcamcar: could you elaborate a bit on that?
20:06:28 <notmyname> jbryce: I think there are issues about accepting projects that answering questions of project autonomy help solve (the autonomy issue is more pressing to me than code hosting)
20:06:32 <johnpur> jbryce: i think keystone may be a slam dunk... i would like to get to it this week if possible... so we can get the openstack packaging and other resources working on it
20:06:48 <devcamcar> jaypipes: mostly architectural, scalr is designed to be a standalone system and it would require a large effort to refactor it to separate its various components
20:07:00 <devcamcar> at the end of the day, it's just not designed to work the way dashboard would need it to
20:07:01 <jaypipes> sebastianstadil: you concur with that?
20:07:16 <devcamcar> i have a document with a lot of detail that i sent to sebastian
20:07:19 <sebastianstadil> jaypipes: Sort of
20:07:37 <johnpur> wow /me is disappointed
20:07:59 <jaypipes> devcamcar: is that document available online? or will it be?
20:08:00 <sebastianstadil> jaypipes: Scalr is designed to make the management of web applications on IaaS easy
20:08:08 <devcamcar> jaypipes: i can make it available now
20:08:51 <sebastianstadil> jaypipes: As such, there are a lot of pieces that need to be tightly integrated. For example mysql failure -> dns update
20:09:04 <johnpur> are we back to evaluating scalr on its own merits as a project?
20:09:15 <sebastianstadil> johnpur: I would assume so
20:09:20 <jaypipes> johnpur: I believe so.
20:09:27 <ttx> johnpur: wit hpotential overlap in, say, launching instances
20:09:44 <jesse__> ttx: many things have overlap with that :)
20:09:49 <sebastianstadil> ttx: Launching instances is the least of our concerns
20:10:05 <jaypipes> jesse__: like what?
20:10:05 <devcamcar> i will share the doc momentarily
20:10:16 <ttx> jesse__, sebastianstadil: right, but two separate web UIs to do "stuff".
20:10:18 <sebastianstadil> jaypipes: console
20:10:26 <jesse__> ttx: different use cases - dashboard is low level
20:10:28 <sebastianstadil> ttx: correct
20:10:35 <sebastianstadil> jesse__: correct
20:10:55 <jbryce> the request last week from several was to go ahead and have devin present before voting on either. i think we should proceed with that.
20:10:57 <jaypipes> sebastianstadil: ok.
20:11:14 <johnpur> ttx: the dashboard is example UI... most deployments will update/replace it to present their view of UX
20:11:15 <sebastianstadil> jbryce: agreed
20:11:46 <jbryce> #topic Dashboard incubation review
20:11:52 <jbryce> http://wiki.openstack.org/Projects/IncubatorApplication/OpenStackDashboard - Dashboard's application
20:12:00 <johnpur> whereas the scalr UI would be used out of the box, i assume
20:12:05 <ttx> johnpur: dashboard is a django lib with a ref implementation. I expetc most deployments to replace the UI, but still use the django lib
20:12:15 <devcamcar> ttx: correct
20:12:28 <ttx> johnpur: and I admit I kinda like that split.
20:12:51 <ttx> "do one thing and do it well"
20:13:04 <johnpur> ttx: right. that is why having the linkage at the lib level with the autoscaling and service restart, etc. functions of scalr is interesting.
20:13:31 <sebastianstadil> ttx: "one thing" can actually be many things, but yes, you are right
20:13:36 <ttx> johnpur: would have been interesing, yes.
20:13:49 <jesse__> the design of the dashboard will allow extensions (panels) to be added ... so someone could add a panel for cloudpipe or scalr technically
20:13:49 <johnpur> ttx: this assumes some level of guest integration
20:14:09 <sebastianstadil> jesse__: I don't follow
20:14:16 <jaypipes> my vote on dashboard is the same as last week, for reasons I stated last week. I love it, but I don't believe it should be a core project, because it does not provide it's own service API. It uses the APIs of other core projects.
20:14:16 <devcamcar> hate to be a stickler
20:14:20 <devcamcar> but can we choose a topic?
20:14:46 <sebastianstadil> jaypipes: Very good point
20:14:51 <jbryce> does anyone have specific questions for devcamcar around dashboard?
20:14:57 <sebastianstadil> jaypipes: something to build more on top of
20:15:19 <jesse__> jaypipes: it doesn't have HTTP apis, but it does have django apis
20:15:33 <jesse__> jaypipes: and can be built on top of
20:15:39 <jaypipes> devcamcar: this is NOT to say I don't care for the dashboard. Quite the opposite. I simply feel that "OpenStack core project" isn't the right place for it. And, yes, I know I'm in the minority :)
20:15:51 <johnpur> the question is: shouls OpenStack have an example UI and supporting library that shows how to build UX on top of the core components?
20:16:01 <johnpur> i think yes
20:16:39 <ttx> I see value in having dashboard tightly copled to the rest of core projects, so that it exhibits the latest features
20:16:43 <ttx> coupled*
20:16:46 <jaypipes> johnpur: I guess I feel that it should *not*. That service APIs should be in the core of OpenStack, and OpenStack applications build on those core projects by using the service APIs to construct applications (GUI or non-GUI)
20:16:54 <jbryce> johnpur, ttx: ++
20:16:56 <ttx> htat should be facilitated by having it as a core project, I think
20:16:58 <sebastianstadil> johnpur: My concern is that OpenStack is late to the game, AWS has a huge head start in mindshare, marketshare, and development velocity
20:17:03 <vishy> I don't think openstack is complete without an example web dashboard
20:17:04 <devcamcar> the dashboard is referenced in a number of places, and has been the unofficial face of openstack for some time
20:17:09 <sebastianstadil> johnpur: I personally would like to avoid a repeat of the Microsoft hegemony of the 90s, and would like to see FLOSS succeed as an alternative. If possible even a superior choice.
20:17:16 <soren> I understand jaypipes' concern, but we lack a way to let the world know "this is the canonical web ui for openstack", don't we?
20:17:21 <soren> ...other than making it core.
20:17:28 <jbryce> i think that having a dashboard is critical to make all the projects accessible and more usable to the majority of people who would be deploying it
20:17:34 <johnpur> jaypipes: don't disagree, but OS is already hard enough to approach
20:17:41 <sebastianstadil> johnpur: Scalr is a rather mature software project, tested over by thousands of users, hundreds of thousands of instances, tens of millions of instance hours, and over a billion events
20:17:43 <jaypipes> soren: yes, that is true enough.
20:17:54 <devcamcar> and by closely coupling the development of dashboard to core projects, we can have something that is guaranteed to work, follow core project milestones, etc.
20:18:13 <ttx> devcamcar: yep.
20:18:13 <soren> jaypipes: That's really what I want to address. For dashboard. The discussion around scalr was completely different.
20:18:25 <jaypipes> jbryce: I don't disagree that dashboard is critical. I guess I'm stuck on the term "core" for it.
20:18:26 <sebastianstadil> jbryce: entirely agree. Ease of use will help OpenStack adoption faster
20:18:51 <vishy> jaypipes: how do you feel about 'incubated'? :)
20:18:56 <devcamcar> jaypipes: i can make the argument that the dashboard itself isn't a "core" compoment, but django-openstack is
20:18:56 <jaypipes> sebastianstadil: and I don't disagree with any of that.
20:19:01 <devcamcar> which is what the dashboard is built on
20:19:02 <ttx> jaypipes: think "products that need to evolve in parallel" more than "APi providers"
20:19:02 <johnpur> soren: i quibble a bit with the term "canonical" web UI... the expectation is that deployments will differentiate at this leel. they do, however, need to be shown how to integrate with the core systems.
20:19:06 <sebastianstadil> jaypipes: my bad
20:19:26 <jaypipes> vishy: well, since the only end game of incubation is currently "OpenStack core project", I'm a bit turned off by it.
20:19:26 <devcamcar> and it exposes apis for people or organizations to build their own sites using openstack-dashboard as a reference/example implementation
20:19:46 <jaypipes> perhaps I'm just advocating for a separation of core services from core applications? not sure...
20:20:08 <soren> johnpur: Poor choice of words. "reference" would probably be more accurate.
20:20:12 <johnpur> jaypipes: disagree! all incubated projects do not have an end goal of being core.
20:20:17 <devcamcar> jaypipes: i'd also argue that having a UI that represents all of openstack's features and is closely aligned is of great benefit
20:20:21 <jbryce> jaypipes: the other end game is not being promoted to core and discontinuing incubation
20:20:25 <jaypipes> I guess I have to get past my mind's connotation that core == building block.
20:20:28 <jbryce> incubation is not a guarantee to core
20:20:31 <sebastianstadil> When you want to run a web app, you don't want to deal with the "muck" of apis, you want to get your site running
20:20:43 <devcamcar> jaypipes: django-openstack is a building block for openstack UI
20:20:44 <jaypipes> devcamcar: I'm not disagreeing with anything you're saying :)
20:20:45 <jbryce> from the sound of it, if we were to vote on should we have ANY type of ui as a core project, it seems like the majority falls on the affirmative side. but i think the real question is should we pick one/the other/neither now or incubate multiple competing projects and pick at a core promotion time?
20:20:47 <sebastianstadil> That's what will get Rackspace an advantage over AWS
20:20:47 <johnpur> incubation opens up the resources of openstack in terms of CI, packaging, integration.
20:20:49 <ttx> jaypipes: Good core candidates for me are things that integrate well with other core projects (no overlap), that are central to OpenStack ("product view") and need to evolve in parallel (same release cycle).
20:21:03 <sebastianstadil> and same for any openstack offering
20:21:04 <soren> jbryce: No, but surely it's the goal? It may fail to make it through incubation, but I never thought of incubation as a permanent place for anything.
20:21:10 <notmyname> jbryce: please don't assume the outcome of a vote before it happens
20:21:16 <jaypipes> devcamcar: I'm partly being devil's advocate, partly being a semantic purist (you KNOW I have a tendency to do that!)...
20:21:58 <jbryce> notmyname: not even a hypothetical vote that wasn't going to happen. = )
20:22:01 <devcamcar> jaypipes: hah, i know
20:22:22 <temple17> quit
20:22:28 <jaypipes> heh
20:22:33 <jesse__> is jaypipes question the only question?  or are their other questions to address?
20:22:57 <devcamcar> are there any questions about vision or roadmap?
20:22:58 <jaypipes> devcamcar, sebastianstadil: I have an easier time seeing dashboard as a building block than scalr, to be fair.
20:23:00 <jbryce> soren: i'm in agreement with you
20:23:44 <soren> The way I'm thinking of it right now is that something like that dashboard is something I think at least some people expect to be part of the "package" when they install Nova, and the fact that it's maintained separately is really just a quirk of some sort.
20:23:48 <ttx> devcamcar: no, I thin kthey are pretty clear.
20:24:10 <devcamcar> soren: agreed, in fact dashboard is installed with a number of tools, including nova.sh, stackops, etc already
20:24:19 <devcamcar> it is probably already confusing things
20:24:19 <johnpur> devcamcar: if the vision is that django-openstack is directed on a path to be core, and the UI is presented as an example for deployments to modify/replace, i agree.
20:24:22 <jaypipes> soren: when they install Nova, or when they install OpenStack (the set of core projects)?
20:24:28 <soren> jaypipes: Nova.
20:24:29 <ttx> devcamcar: I think it boils down to "should an openstack client be part of openstack core"
20:24:32 <nati> OpenStack core and UI should be installed easy.
20:24:33 <jbryce> soren: agreed. this is what i hear when i talk to people who are actually trying to use openstack for real things in various companies
20:24:47 <soren> jaypipes: Does it do stuff with !nova? I've not used it for a long time, tbh.
20:24:52 <devcamcar> johnpur: exactly, the biggest question here may simply be a question of what the project name should be
20:24:56 <jaypipes> soren: which leads to the inevitable question: what the heck is openstack if it isn't a cohesive set of projects that can be installed together to form an IaaS solution?
20:25:14 <jaypipes> soren: yes, glance (at least. not sure about swift)
20:25:15 <jesse__> soren: it already talks with glance directly, keystone and swift is in progress
20:25:26 <soren> jaypipes: I just don't think anyone would be surprised if they found the dashboard shipped in the nova tarball. It just so happens that it's shipped separately.
20:25:41 <jesse__> jaypipes: since the auth process returns a service catalog, we can show the modules in dashboard that work with the services the token has access to
20:25:53 <johnpur> given devcamcar's definition, i am +1.
20:25:58 <jaypipes> jesse__: right, and that's brilliant.
20:26:22 <jaypipes> what is "stackops"?
20:26:25 <soren> jaypipes: You lost me there, I'm afarid.
20:26:27 <soren> afraid, even.
20:26:32 <ttx> jaypipes: A distribution.
20:26:35 <jbryce> jaypipes: stackops is a distro
20:26:37 <devcamcar> jaypipes: a bit off topic, but it's an openstack distribution
20:26:37 <jaypipes> oh.
20:26:40 <johnpur> jaypipes: stay on point, please!
20:26:44 <jaypipes> sorry...
20:26:53 <johnpur> :)
20:27:08 <ttx> I feel like I'm ready to vote on Dashboard.
20:27:11 <jaypipes> soren: I'll elaborate shortly, when we get into discussion of #5.
20:27:11 <johnpur> vote?
20:27:12 <jbryce> so does anyone have any other specific dashboard questions for devin?
20:27:22 <soren> jaypipes: cool beans
20:27:27 * soren is ready to vote
20:27:47 <jesse__> soren: ++
20:27:50 <jbryce> let's vote on scalr first
20:27:58 <soren> Whuh?
20:28:02 <sebastianstadil> devcamcar: Lets say you have 100 instances running, how do you plan on making that manageable?
20:28:06 <ttx> jbryce: or the two at the same time ?
20:28:09 <johnpur> to be clear, the vote is to take dashbaord into incubated stage
20:28:26 <jbryce> ttx, soren: i just want to do both votes to have a clear record
20:28:39 <soren> I'm ready to vote on dashboard. I even think it's an easy vote. I'm not sure about scalr at all yet.
20:28:41 <johnpur> jbryce: let's do dash the scalr
20:28:45 <jbryce> ok
20:28:48 <johnpur> s/teh/then
20:28:49 <ttx> jbryce: my vore on scalr depends on the outcome of the vote on Dashboard :)
20:28:50 <devcamcar> sebastianstadil: we're looking at ensemble
20:29:00 <jbryce> #topic Vote: Should Dashboard be added as an officially incubated project
20:29:10 <soren> +1
20:29:13 <johnpur> +1
20:29:14 <notmyname> -1
20:29:25 <jaypipes> -1
20:29:26 <vishy> +1
20:29:33 <jesse__> +1
20:29:46 <jbryce> +1
20:29:51 <jbryce> ttx: ?
20:30:50 <ttx> +1
20:30:52 <ttx> srry
20:30:57 <jbryce> any other lurking ppb members?
20:31:15 <jaypipes> jbryce: no need. quorum reached.
20:31:29 <soren> notmyname: Seeing as you didn't really participate in the discussion, would you care to elaborate on why you -1'ed? I understand why jaypipes did, I just want to make sure I understand what other motivations there might be.
20:31:29 <jbryce> #agreed Dashboard will enter the OpenStack incubation program: 6  +1, 2  -1
20:31:30 <jaypipes> jbryce: 6 to 2.
20:31:36 <vishy> joshua had +1 via email if it matters
20:31:55 <jbryce> #info Joshua McKenty voted +1 on email list
20:32:17 <soren> There's 12 of us, right? If the remaining 4 -1'ed, it would habve been a tie, so yes, it matters.
20:32:37 <soren> If can still count, that is.
20:32:44 <jaypipes> soren: sorry, yes, you are correct. my bad.
20:32:54 <jbryce> we've got 7 - 2 with josh's absentee ballot
20:32:58 <soren> jaypipes: np :)
20:33:38 <jaypipes> who is missing? this is kinda important to be here for... other than ewan, who?
20:33:50 <johnpur> jbryce: scalr discussion?
20:33:54 <soren> Eric and Rick.
20:33:59 <ttx> jaypipes: dendrobates, eday, josh, ewan
20:34:08 <jaypipes> ok.
20:34:14 <jbryce> all right....scalr
20:34:22 <jaypipes> -1
20:34:28 <jbryce> #topic VOTE: Should Scalr be added as an officially incubated OpenStack project
20:34:36 <notmyname> -1
20:34:55 <soren> Did we at some point agre that if we rejected a project, we had to give a clear rationale as to why so that they could work on fixing whatever we thought was broken? Or did I just make that up?
20:35:17 <jbryce> soren: i think that was for moving into core
20:35:25 <soren> jbryce: Ah. Yes, that makes sense.
20:35:38 * soren is still deliberating
20:35:52 <johnpur> +1, with the same vision/definition as the dashboard. separte the UI, make it example, and consider the guest agent (and API) as incubated.
20:36:24 <ttx> -1 until it's complementary to dashboard in some way
20:36:46 <soren> ttx: Not sure what that means?
20:36:53 <sebastianstadil> ttx: What do you mean
20:36:56 <jesse__> sebastianstadil: does it already use openstack APIs?
20:36:59 <soren> ttx: Do you mean "until it doesn't do any of the stuff that dashboard does"?
20:37:03 <sebastianstadil> jesse__: yes
20:37:05 <soren> ttx: To avoid overlap?
20:37:06 <ttx> soren: I don't like the idea of having two web UIs as a core project
20:37:23 <johnpur> ttx: we are not voting on core
20:37:53 <sebastianstadil> ttx: I think that's missing the point. Trying to come up with an analogy
20:37:53 <ttx> johnpur: I still see incubation as "we would like it to become core if it can integrate with the release process"
20:38:43 <vishy> -0 I would vote +1 for guest agent apis but as an entire project i don't think it meshes properly with the other components
20:38:48 <jbryce> josh mckenty voted -1 by email previously
20:38:50 <sebastianstadil> From my experience, a web UI is only half of the problem
20:38:53 <johnpur> ttx: i am still hopeful that by the time we consider a UI/UX for core status that we have worked out how to integrate all of the underlying functionality. including autoscaling...
20:39:05 <ttx> i.e. for incubation I judge if it is complementary to the rest of core+incubated
20:39:55 <soren> I'm +0. My primary reservation is the language. Had it all been Python, I'd have been all over it.
20:39:59 <ttx> johnpur: i.e. I'd probably not consider an alternative to swift for incubation. At least not as long as swift is a core project...
20:40:18 <soren> ttx: What about lunr? They both store things?
20:40:23 <jesse__> sebastianstadil: i'm confused how this is openstack if it is really a layer above that can talk with many clouds ..
20:40:29 <soren> I know and understand that they're different.
20:40:30 <creiht> ttx: I would disagree, if something better than swift comes along, it should certainly be incubated
20:40:33 <soren> So are scalr and the dashboard.
20:41:07 <johnpur> ttx: hmmm, bold statement... we may see advanced object storage at some time that could replace the current swift implementation.
20:41:07 <ttx> creiht: hmm.
20:41:07 <jaypipes> creiht: ++
20:41:17 <soren> jesse__: Several of the existing core components are able to speak to other clouds.
20:41:25 <soren> jesse__: Glance, for instance, can be backed by S3.
20:41:35 <creiht> and that should be true for all of core
20:41:40 <ttx> creiht: you're right, might make it easier to pick the "best" projects
20:41:44 <soren> jesse__: ...so there's certainly prior art to that sort of thing.
20:41:50 <sebastianstadil> jesse__: Customers want that, so we added it
20:42:10 <soren> Begin extensible is a *good* thing.
20:42:11 <soren> :)
20:42:16 <soren> s/Begin/Being/
20:42:29 <ttx> ok, reverting my vote to -0, same as vishy
20:42:33 <jesse__> I'm with vish then ... -0
20:42:34 <jaypipes> this is why I've been saying that PPB should focus its blessing approval on APIs before implementations... ;)
20:42:42 <sebastianstadil> soren: It's not like it can't be done...
20:42:51 <johnpur> ha ha, jbryce what does the vote stand at?
20:42:53 <soren> sebastianstadil: What? Rewrite in Python?
20:43:05 <ttx> sorry if I'm adjusting my incubation-acceptance metrics live :)
20:43:06 <creiht> lol, what are even valid voting options?
20:43:09 <sebastianstadil> soren: That, and many of the other concerns
20:43:25 <creiht> my vote doesn't count, so I vote +LOL
20:43:26 <jbryce> johnpur: haha...i was just trying to calculate
20:43:46 <jbryce> -1: 3
20:43:51 <jbryce> +1: 1
20:43:57 <jbryce> +0: 1
20:44:02 <jbryce> -0: 3
20:44:29 <johnpur> the cheese stands alone i guess!
20:44:32 <notmyname> what are the valid voting options? (what does +-0 even mean)
20:44:33 <jbryce> so 3 against, 1 for, 4 abstentions with varying degrees of positivity
20:44:45 <notmyname> abstain. ok
20:45:43 <sebastianstadil> Question: since Scalr has been voted not to be incubated, how can we still help OpenStack succeed?
20:45:49 <jbryce> and john's +1 was conditional
20:46:01 <soren> notmyname: You did not answer my question earlier. Was that intentional?
20:46:27 <ttx> sebastianstadil: you can prove how useful and complementary you are by being an associated project... and force us to reconsider our opinion.
20:46:33 <jbryce> sebastianstadil: I think there was some feedback here where it seems like some members would reconsider a vote under certain conditions
20:46:33 <notmyname> soren: yes
20:46:45 <soren> notmyname: ok
20:46:52 <johnpur> sebastianstadil: i encourage you to take the feedback and look at how Scalr could be "updated" or slightly changed to fit into the OpenStack charter/vision. I believe that UX will be critical to acceptance going forward.
20:47:12 <jbryce> sebastianstadil: and getting users/community members clamoring for it would influence the thinking
20:47:16 <soren> sebastianstadil: One thing that would definitely be helpful is providing feedback on API's.
20:47:19 <ttx> sebastianstadil: and decouple scale logic from presentation so that it's easier to integrate ?
20:47:26 <johnpur> jbryce: ++
20:47:46 <johnpur> jbryce: Keystone?
20:48:04 <jbryce> #agree Scalr is not approved for incubation. 3 against, 1 for, 4 abstentions
20:48:10 <ttx> I don't think we have enough time to attack #5 today, so yes, keystone++
20:48:16 <soren> sebastianstadil: Scalr is an important use case. If there's anything in the existing openstack components that makes your life needlessly difficult, we should address that, since you're likely not alone.
20:48:20 <jbryce> #topic Keyston incubation discussion
20:48:36 <jbryce> http://wiki.openstack.org/Projects/IncubatorApplication/Keystone - Keystone incubation application
20:49:12 <sebastianstadil> soren: of course
20:49:28 <johnpur> zns: any words?
20:49:43 <zns> Any questions?
20:50:06 <jaypipes> zns: how close are you to finalizing the KeyStone API?
20:50:22 <jaypipes> zns: I saw today that groups are being removed and made into an extension?
20:50:47 <zns> jaypipes: pretty close. They have not changed much since June 10th. We'll aim to lock down last minutea when jesse and team are down here next week,
20:51:10 <jaypipes> zns: ok.
20:51:27 <jesse_> zns: before incubation I think we should clean up the implementation - separating rax extensions, user/tenant extensions, and the core api
20:51:42 <zns> jaypipes: correct. Groups are out of scope for v1. We wanted to keep to minimal scope as we initially stated; which was to focus on existing functionality in nova and Swift. Groups are therefore out and should be proposed as extensions.
20:51:46 <jaypipes> jesse_: knowing the code, I would agree with that assessment.
20:52:00 <vishy> jesse_, jaypipes: does that need to be done 'before' incubation?
20:52:13 <jaypipes> jesse_: though those things are not necessarily something that can't be done during incubation
20:52:14 <vishy> if so then I vote we push the vote for 1-2 weeks
20:52:22 <johnpur> jaypipes, jesse_: this delays the CI and packaging integration of keystone, are you ok with that?
20:52:31 <zns> jesse: the docs and API clearly state what is not core. We can update the implementation.
20:52:46 <jaypipes> johnpur: yes. it's already slipped to D3 for Glance anyway.
20:53:11 <jaypipes> but as vishy implies, these things can be done in incubation status.
20:53:21 * jaypipes is ready to vote now on keystone
20:53:50 <jbryce> any additional questions?
20:53:56 <jesse_> zns: I'm just concerned if a bunch of folks start helping before the clean (I did rough removal of groups and it removed 3k lines) it might get confusing
20:54:22 <jaypipes> jesse_: don't be concerned about people helping. ;)
20:54:30 <zns> jesse_: you're almost as familiar with the code as I am. I defer...
20:54:34 <jaypipes> jesse_: early and often. embrace with hug. :)
20:54:49 <zns> jesse: (as in defer to you, not differ).. just being clear.
20:55:02 <jesse_> jaypipes: I'm concerned that people still assume that the backend and api are what keystone is
20:55:05 <johnpur> i will vote with jesse_ on this
20:55:26 <jaypipes> jesse_: I'm not quite sure I follow you...
20:55:45 <jbryce> jesse_: what is your position? that we should delay a vote?
20:56:24 <jesse_> jbryce: I personally think the API is important to get finalized - and now that dashbaord is incubating, there are things that we should address in the API
20:56:48 <jbryce> i think i'm with jaypipes. i don't expect a rush of people to come try contributing to the code just because it gets a new label.
20:57:28 <jesse_> my concern is that people focusing on the implementation instead of the API and interfaces between keystone and projects
20:57:38 <zns> jesse_: the API for other projects are being finalized still. I don't think that's a criteria for incubation...
20:58:04 <jaypipes> jesse_: personally, I've *only* been focused on the API (and thus the slew of reported bugs about it ;)
20:58:11 <zns> jesse_: that's no different than any other core project forming an API or changing an implementation.
20:58:34 <jbryce> time check: we have 2 minutes
20:58:46 <jaypipes> jesse_: incubation will give more eyeballs on both the API and the implementation. I think that is a good thing.
20:58:59 <jesse_> let's vote then?
20:58:59 <jbryce> vote or delay?
20:59:07 <jbryce> vote it is
20:59:08 <zns> jaypipes: +1
20:59:12 <jaypipes> keystone fits what I consider to be a core service better than anything else so far.
20:59:19 <jaypipes> +1 from me.
20:59:21 <vishy> +1
20:59:24 <jbryce> #topic VOTE: Should Keystone be added as an officially incubated OpenStack project
20:59:24 <notmyname> +1
20:59:33 <ttx> +1: since we already have resources working on integrating it in core projects, sounds like incubation is the right place for it
20:59:44 <jbryce> +1
20:59:57 <johnpur> jesse?
20:59:58 <jesse_> -1 just because I feel we need to do more before we join incubation ... but I'm going to be helping with it either way
21:00:15 <johnpur> -1
21:00:17 <vishy> notmyname: your strategy of saying as little as possible so we could make it to number 5 almost worked... :)
21:00:19 <jaypipes> soren: ?
21:00:34 <soren> +1
21:00:37 <jbryce> ok
21:00:48 <jbryce> #agreed Keystone is approved for incubation: 6 +1's, 2 -1's
21:00:54 <jbryce> ok...that's time
21:00:54 <ttx> jbryce: endmeeting :)
21:00:55 <jbryce> thanks guys
21:01:01 <creiht> vishy: the opposite could be said as well ;)
21:01:02 <jbryce> notmyname: you're the top agenda item for next week
21:01:07 <jbryce> #endmeeting