20:04:09 <jbryce> #startmeeting
20:04:10 <openstack> Meeting started Tue Aug 23 20:04:09 2011 UTC.  The chair is jbryce. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:04:11 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:05:05 <jbryce> who's around?
20:05:09 <notmyname> hi
20:05:11 <johnpur> o/
20:05:13 <soren> o/
20:05:14 <jaypipes> o/
20:05:25 <danwent> hi jbryce, I'm here about quantum's incubation proposal
20:05:30 <jsavak> hi
20:05:31 <anotherjesse> not me
20:05:32 <zns> ziad
20:05:52 <jaypipes> danwent: denied. all done! ;P
20:05:59 <danwent> :P
20:06:02 <soren> aw.
20:06:23 <ttx> o/
20:06:33 <vishy> o/
20:06:38 <jbryce> ok
20:06:48 <jbryce> lots to cover today: http://wiki.openstack.org/Governance/PPB
20:07:06 <jbryce> #topic keystone update
20:07:17 <zns> 1. API spec published
20:07:19 <jbryce> zns: can you give us an update on the progress of the api lockdown?
20:07:27 <zns> Service (Public) API: https://github.com/openstack/keystone/blob/master/keystone/content/service/identitydevguide.pdf
20:07:27 <zns> Admin (Private/Privileged) API: https://github.com/openstack/keystone/raw/master/keystone/content/admin/identityadminguide.pdf
20:07:27 <zns> WADLs/XSD all available in the keystone/content folders in the source code
20:07:41 <zns> 2. I'm working with core teams on integration. Just got of the phone with SandyWalsh.
20:07:41 <jaypipes> anything in HTML? :)
20:07:41 <zns> 3. Issues list import into Launchpad is waiting on Launchpad to do the import.
20:07:57 <zns> We're working on refactoring to meet that spec now.
20:08:23 <jbryce> joshuamckenty_, ewanmellor: we just got started; talking about keystone right now
20:08:32 <zns> It compiles to HTML. But we don't have it published yet. We can work with Anne on that.
20:08:33 <ewanmellor> Namaste
20:09:18 <jbryce> anotherjesse: does the published api make you feel better about the external stability of keystone?
20:09:28 <zns> jaypipes: i.e. if you download the source from openstack-manuals, there is a webhelp folder with the HTML.
20:09:47 <anotherjesse> jbryce: browsing it
20:10:22 <jbryce> zns: thanks for the comprehensive update. you were ready! = )
20:10:31 <nati> o/
20:10:41 <zns> jbryce: You guys set a high bar :-)
20:10:49 <anotherjesse> zns: what is tate of implementation of it?
20:10:59 <anotherjesse> is the doc what is implemented?
20:11:39 <dendrobates> sorry I'm late
20:12:01 <zns> We're working on that now. Biggest change is the move from using username as identifier to supporting a UID. But the spec is now much smaller so implementation should be pretty quick.
20:12:23 <nati> Wow these docs helps me a lot!
20:12:32 <zns> And we need to move the management calls to RAX or OS extensions.
20:13:38 <zns> anotherjesse: Not sure I answered your question. What metric would you like?
20:14:20 <anotherjesse> zns: maybe a simple one - of when you think the core api will be finished implementation (and then maybe for extensions if reasonable to guestimate)
20:15:11 <vishy> we need a locked version for d4
20:15:42 <zns> We should have it working by the end of the week. Code compiles and passes tests now and will continue to do so throughout. What we need to coordinate is changes to the middleware with the other core projects (since the middleware is now in their code).
20:15:48 <jaypipes> zns: perhaps I'm missing something, but I'm not seeing API calls for POST /users/<ID>/roles? How does one add a user to a role through the admin API?
20:16:02 <jbryce> vishy, anotherjesse: is that a component of a core promotion decision? again, the core promotion is really saying it would be a core project for essex, not for diablo.
20:16:59 <anotherjesse> jbryce: but we can use these to put pressure on them to work faster ;)
20:16:59 <zns> jaypipes: if you use our reference implementation, you would either use an extension or keystone-manage. If you're using something else, like Active Directory, then that's managed using the Active Directory tools. We're leaving the management out of the core API...
20:17:24 <zns> jaypipes: the extension will be OS-KSADMIN. Separate WADL and XSDs.
20:17:39 <jaypipes> zns: KSADMIN?
20:17:47 <jaypipes> ah, Keystone...
20:17:47 <anotherjesse> keith stone?
20:17:49 <zns> Keystone Admin extensions.
20:17:59 <jaypipes> thought might be a typo for RSADMIN....
20:18:12 <jbryce> anotherjesse: +1, rename in order
20:18:25 <zns> anotherjesse: don't start that meme again!
20:18:35 <jsavak> lol
20:18:38 <anotherjesse> zns: sorry - haven't slept much
20:18:44 <jbryce> last week we decided to defer a vote and wait for an update on the feedback we'd given. we can either defer again to next week (last chance before 2011-09-05 deadline) or vote today
20:18:51 <jaypipes> ok, so jbryce are we voting for promotion again today?
20:19:00 <jaypipes> jinx.
20:19:02 <zns> We'll have RAX extensions as well.
20:19:31 <zns> … to support API key authentication
20:20:12 <jbryce> i'd prefer to vote unless anyone feels strongly they have specific items to block until next week on
20:20:42 <notmyname> indeed (and we have much else to discuss)
20:21:02 <jbryce> #info VOTE: Should Keystone be accepted as a core project for Essex release cycle?
20:21:08 <jaypipes> +1
20:21:11 <jbryce> +1
20:21:12 <jsavak> +1
20:21:14 <vishy> +1
20:21:19 <johnpur> +1
20:21:21 <ttx> +1
20:21:25 <dendrobates> +1
20:21:27 <soren> +1
20:21:30 <notmyname> +1
20:21:32 <anotherjesse> +1
20:21:44 <jaypipes> well that was easy...
20:21:58 <jbryce> #agreed Keystone will be core for Essex (9 +, 2 abstain)
20:21:59 <zns> Cool!
20:22:06 <zns> Thanks, guys.
20:22:10 <anotherjesse> zns: are you off to drink?
20:22:11 <jbryce> congrats zns!
20:22:15 <jbryce> #topic Security Group Proposal take 2
20:22:19 <jbryce> http://wiki.openstack.org/Governance/Proposed/OpenStack%20Security%20Group
20:22:19 <ttx> zns: now the pain begins.
20:22:24 <anotherjesse> zns: disneyland!
20:22:24 <zns> More like off to work!
20:22:33 <ttx> zns: I'll be your worst nightmare.
20:22:38 <jbryce> ttx worked with jarret to update with our feedback
20:23:07 <zns> ttx: I'll get to practice my French.
20:23:11 <jbryce> the gist is that it is now split into a small vulnerability management team and a larger security testing etc team
20:23:26 <ttx> basically it keeps the vulnerability treatment team small. Without preventing the set up of a large security interest group.
20:23:36 <notmyname> jbryce: are we discussing it in toto or the 2 parts separately?
20:24:06 <ttx> notmyname: we can do two parts, if there is a good reason to
20:24:11 <jbryce> if we only want to approve one part that's fine
20:24:24 <jbryce> i would like to discuss both though
20:24:28 <notmyname> I like the first part (management team) and would prefer to defer ont he second
20:24:39 <ttx> the first part is what's urgent
20:24:51 <jbryce> ok. let's vote on the first part, because i think that's more time sensitive and agreed to already
20:24:58 <ttx> (in order to have a team responsible for setting up the security info pages. quick)
20:25:07 <jbryce> the first part being the "Vulnerability Management Team" heading on the page
20:25:12 <jaypipes> I'm with notmyname
20:25:26 <nati> +1
20:25:34 <nati> Oh too late
20:25:35 <ttx> any issue with that first part ?
20:25:44 <soren> No, sounds good.
20:25:58 <jbryce> #info VOTE: Should we establish a vulnerability management team?
20:26:04 <ewanmellor> +1
20:26:04 <jaypipes> +1
20:26:05 <joshuamckenty_> +1
20:26:05 <jbryce> +1
20:26:06 <notmyname> as defined in that doc?
20:26:11 <jbryce> notmyname: yes
20:26:11 <ttx> note that core devs will have access to security bugs in LP.
20:26:13 <notmyname> +1
20:26:14 <nati> +1
20:26:14 <johnpur> +1
20:26:14 <jaypipes> a SMALL vulnerability management team...
20:26:19 <vishy> +1
20:26:21 <ttx> +1
20:26:22 <dendrobates> +1
20:26:23 <anotherjesse> -1 … we have no vulnerabilitys
20:26:27 <jaypipes> lol :)
20:26:29 <anotherjesse> joke - +1
20:26:31 <soren> +1
20:26:41 <johnpur> Jesse is in rare form!
20:26:49 <vishy> can we add jesse as a vulnerability?
20:26:55 <joshuamckenty_> No
20:26:59 <jbryce> #agreed Establish small vulnerability management team. (11 +)
20:27:15 <jbryce> #action jbryce split out the vulnerability management paragraph into a separate document
20:27:36 <jbryce> does anyone want to discuss the larger concept of the openstack security group now?
20:27:50 <ttx> that can wait if we have more pressing matters
20:27:52 <notmyname> I see no need
20:27:55 <soren> Nor do I.
20:28:03 <soren> People can form whatever groups they want.
20:28:09 <notmyname> soren: +1
20:28:12 <soren> THere's no need for ppb blessing.
20:28:15 <jbryce> are we fine if jarret moves forward along a path like he laid out there without official sanction
20:28:24 <jbryce> soren: i agree
20:28:24 <jaypipes> sure
20:28:27 <jbryce> ok
20:28:42 <notmyname> jbryce: as long as it's not presented as binding for openstack
20:28:45 <anotherjesse> jbryce: I would like to put a requirement that the website gets updated
20:28:47 <ttx> notmyname, soren: that's a fair point.
20:28:55 <anotherjesse> to have a security link at the obttom of openstack pages
20:28:57 <Daviey> I have been concerned that it seems nobody has been primarily tasked with just security auditing AIUI.
20:29:24 <jbryce> #action jbryce to make sure security link makes it into openstack web property footers
20:29:36 <jbryce> #info openstack security group can form informally with interested parties without official sanction
20:29:46 <jaypipes> Daviey: nothing stopping a working group from being formed.
20:29:58 <jbryce> Daviey: i think jarret is interested in forming that kind of group
20:29:59 <ttx> we don't want to set a precedent that any discussion group needs to go through PPB
20:30:08 <notmyname> ttx: +1000
20:30:20 <Daviey> jbryce: Good stuff.
20:30:22 <jbryce> devcamcar: you around?
20:30:52 <jbryce> danwent: still here?
20:30:54 <ttx> if the group gets any privilege or special power, I see why it needs to be blessed by PPB. If not, then just form it[tm]
20:30:58 <danwent> ready and waiting :)
20:31:26 <johnpur> ttx: how about a legal working group?
20:31:30 <jbryce> we'll circle back to dashboard if devcamcar is here
20:31:34 <jbryce> #topic Quantum incubation
20:32:04 <ttx> johnpur: if its decisions are not binding the rest of the community, they can gather and discuss all they want.
20:32:05 <jbryce> http://wiki.openstack.org/Projects/IncubatorApplication/Quantum
20:32:37 <jbryce> quantum would like to become an incubated project
20:32:44 <johnpur> ttx: i see it as an advisory group to ppb and governance issues
20:32:53 <dendrobates> since I have been involved with quantum. should I recuse myself?
20:33:21 <devcamcar> o/
20:33:59 <soren> dendrobates: I don't think so.
20:34:02 <anotherjesse> dendrobates: I was involved with keystone - and was a harsh critic of acceptance to core (sorry zns - just want it to be ready)
20:34:04 <jbryce> dendrobates: i don't have a problem with your involvement
20:34:19 <dendrobates> k
20:34:26 <danwent> we're happy to answer any questions about quantum
20:34:32 <anotherjesse> so - just put your opensource hat on and you will be a good person in the conversation
20:35:15 <dendrobates> anotherjesse: It's the only hat I own
20:35:21 <Daviey> dendrobates: Can you see a time when quantum is likely to become a required part of openstack networking?
20:35:44 <dendrobates> Daviey: I personally don't think it should ever be required
20:36:00 <anotherjesse> dendrobates / danwent quantum works as well as existing model - but can you just use quantum and not existing models (eg is there the overlap?)
20:36:01 <dendrobates> not for simple pilots or testing at least
20:36:10 <danwent> +1  quantum is really about being able to take advantage of more advanced network functionality.
20:36:32 <notmyname> danwent: so is it an abstraction of swift/router APIs?
20:36:37 <anotherjesse> dendrobates / danwent if nova devs want to deprecate nova-network what do we lose?
20:36:38 <notmyname> switch
20:36:55 <Daviey> dendrobates: What i am asking is, does it make sense for it to potentially superseed FlatManager and VlanManager ?
20:37:05 <Daviey> (in production enviroments)
20:37:07 <anotherjesse> dendrobates: what Daviey said
20:37:08 <danwent> anotherjesse:  if you're using quantum, we have a model that works well with the existing nova-manage commands (i.e., when you create a network with nova-manage, we create a quantum network on the backend).  But yes, you would either use quantum, or the old bridge model.
20:37:10 <dendrobates> anotherjesse: the ability to get test nova without installing quantum
20:37:24 <danwent> notmyname:  not related to swift at all.
20:37:39 <notmyname> danwent: ya, mistype. muscle memory. I meant switch
20:37:40 <dendrobates> Daviey: I think that is really a decision for Nova
20:37:45 <dendrobates> I think it could
20:38:00 <danwent> anotherjesse:  nova-network still handles some things that are not done by quantum (e.g., deciding which vNICs a VM gets)
20:38:17 <anotherjesse> dendrobates: for keystone integration we deprecated the existing user system and have a simple "noauth - eg trust whoever the user says they are"
20:38:31 <anotherjesse> dendrobates: could / should we do something like that for quantum as it matures
20:38:47 <danwent> in general, I think it would make sense to simplify nova networking in the future, to just support a simple standalone model similar to flatmanager
20:38:49 <dendrobates> anotherjesse: true, we did not want to assume that though
20:39:08 <danwent> notmyname:  yes
20:39:23 <anotherjesse> dendrobates: awesome
20:39:26 <danwent> model is basically that you can define "networks" that correspond to an L2 domain, and "ports" on those L2 domains.
20:39:43 <danwent> in the future we will explore L3, but right now the core API is only about L2 connectivity.
20:39:54 <Daviey> dendrobates / danwent: I've struggled to work out how much i should care about Quantum, would it be possible to make better docs (or screencast), and help with the visability of those?
20:39:59 <danwent> anotherjesse:  yes, I think that's the right approach.
20:40:16 <danwent> Daviey:  I have been meaning to do a screencast for some time.
20:40:20 <Daviey> rocking
20:40:29 <anotherjesse> danwent: PLEASE DO THAT! (screencast)
20:40:45 <jbryce> we're talking about incubation for quantum here, (not core) so the evaluation criteria are really around if we think this has a part as a potential core openstack project, is it at a point that it has code and developers and should start on the path for integration
20:40:48 <anotherjesse> danwent: we started using / giving feedback on keystone since the beginning - should nova core as part of incubation get serious about using/knowing qauntum?
20:40:52 <danwent> Daviey:  the real pain point is for customers that need to be able use advanced network capabilities, whereas the existing nova networking is pretty tied to basic linux bridge + vlan capabilities
20:41:26 <ttx> anotherjesse: if quantum gets in incubation before the design summit, we can set up sessions to discover the code base
20:41:36 <dendrobates> Quantum has a very healthy and diverse dev community and a good leader in danwent
20:41:47 <ttx> danwent++
20:41:58 <danwent> anotherjesse: so far we've been focused on building the core quantum service, just in the d4 timeline have we started focusing on nova integration in earnest.   We've prototyped that with a QuantumManager class that replaces FlatManager, etc.
20:42:21 <danwent> we're definitely happy for input from any nova team members.
20:42:24 <anotherjesse> dendrobates: for dashboard we thought that having the openstack apis in place was important for incubation
20:42:40 <anotherjesse> dendrobates: is there anything you think should be done before incubation with quantum?
20:43:00 <anotherjesse> danwent: to kick the tires do I need anything more than a cluster?
20:43:07 <notmyname> danwent: how autonomous is quantum? is it possible to deploy quantum without nova (or another openstack project)?
20:43:28 <jaypipes> yes, I'm interested in the answer to that, too... notmyname's question...
20:43:32 <danwent> anotherjesse: its pretty simple.  for example, you can check out the tutorial demo I sent out to the the list (I will dig up the link)
20:43:43 <Daviey> This is screaming for a "how to test" blog post :)
20:43:45 <dendrobates> anotherjesse: I think it is in pretty good shape for incubation
20:43:47 <devcamcar> anotherjesse: quantum ui for dashboard is in code review right now
20:43:57 <Daviey> danwent: Anyone driving dashboard integration?
20:43:59 <devcamcar> will land probably in next few days
20:44:12 <devcamcar> Daviey: ^^^
20:44:16 <Daviey> bah
20:44:17 <markvoelker> Daviey: yes, asomya from my team is leading that
20:44:23 <anotherjesse> devcamcar: saw that .. jake said it didn't use the extension model at first - is that important? (we can discuss in #dev)
20:44:27 <jbryce> it actually seems like it is pretty mature for just entering incubation
20:44:35 <devcamcar> anotherjesse: no
20:44:35 <danwent> Daviey: yes, mark voelkers team from cisco is working on dashboard integration
20:44:39 <dendrobates> jbryce: we held it out early on
20:44:54 <dendrobates> jbryce: while the pbb wrestled with the policies
20:45:00 <danwent> on being stand-alone, yes, quantum is a separate process that can run with nova.  but nova is the only openstack service that we have integrated with so far.
20:45:25 <anotherjesse> danwent: does the api follow a similar rest with openstack auth approach?
20:45:35 <danwent> Daviey:  I actually sent a link out for that to the list last week.  will dig it up.
20:45:43 <danwent> anotherjesse:  yes, very much so
20:45:55 <dendrobates> other iaas solutions have expressed interest in using quantum as well, so nothing to nova specific has been done
20:46:03 <danwent> http://wiki.openstack.org/QuantumAPISpec
20:46:10 <anotherjesse> looks squeeky clean to me - /me is excited to test it out once diablo is shipped
20:46:15 <jbryce> i'm not hearing any huge blockers here and we're running low on time, so unless anyone objects, i'd like to vote
20:46:23 <anotherjesse> agree
20:46:24 <anotherjesse> +1
20:46:27 <jaypipes> indeed. ++ for wiki API docs.
20:46:29 <vishy> +1
20:46:31 <dendrobates> +1
20:46:31 <danwent> here's the link to a tutorial based on vish's script: http://wiki.openstack.org/QuantumOVSDemo
20:46:32 <jbryce> #info VOTE: Should Quantum be accepted as an OpenStack Incubation project
20:46:38 <jaypipes> +1
20:46:39 <johnpur> +1
20:46:43 <ewanmellor> +1
20:46:44 <jbryce> +1
20:46:48 <notmyname> -1
20:46:57 <soren> +1
20:47:00 <ttx> +1
20:47:03 <anotherjesse> notmyname: reason?
20:47:17 <jmckenty_> +0
20:47:26 <notmyname> I've been burned by sitting on the fence before. I'd prefer not to +0
20:47:33 <anotherjesse> heh
20:47:38 <jbryce> #agreed Quantum will be accepted for OpenStack incubation (9+, 1 abstain, 1-)
20:47:44 <ewanmellor> #link Quantum dashboard integration: http://wiki.openstack.org/QuantumClientGUI
20:47:47 <danwent> notmyname:  definitely let me know if you have suggestions for improving the project
20:48:05 <danwent> great, on behalf of the quantum team, thanks!
20:48:06 <jbryce> thanks danwent, dendrobates
20:48:13 <jbryce> #topic Dashboard core promotion
20:48:22 <ttx> in 12 min :)
20:48:27 <devcamcar> i'll type fast :)
20:48:30 <jmckenty_> nice
20:48:47 <jbryce> devin would like us to consider promoting Dashboard to a core project for the Essex release cycle
20:49:03 <jbryce> if we can't get through it all today, we have one more week to vote on it before the deadline
20:49:22 <jbryce> but does anyone have any questions objections for devcamcar to start with?
20:49:38 <devcamcar> i can give a quick overview of where it's at now as well if that would help
20:49:41 <dendrobates> devcamcar: do you know of any other competing dashboard initiatives for openstack?
20:49:42 <notmyname> what's the status of using standard tools/processes?
20:49:53 <devcamcar> dendrobates: no
20:49:59 <notmyname> devcamcar: what's the status of using standard tools/processes?
20:50:20 <notmyname> LP, gerrit, etc
20:50:24 <devcamcar> notmyname: we use launchpad for release management, bug tracking, blueprints, github for code, but we have not moved to gerrit but plan to do so soon
20:50:38 <jmckenty_> test coverage?
20:50:50 <anotherjesse> devcamcar: you already do +1 for code reviews before merge though right?
20:50:51 <devcamcar> notmyname: and follow milestones and release dates according to openstack proper
20:50:53 <anotherjesse> err +2
20:51:02 <devcamcar> anotherjesse: yes
20:51:14 <devcamcar> jmckenty: test coverage has been -greatly- improved in past few months
20:51:17 <anotherjesse> devcamcar: I still think the name needs to be cooler for promotion to core
20:51:20 <devcamcar> we have coverage reports as well
20:51:27 <anotherjesse> nova, glance, swift, quantum keystone .. and dashboard?
20:51:36 <termie_> dishrack
20:51:39 <devcamcar> anotherjesse: i always have called it dash but that was taken on lp ;)
20:52:06 <ttx> "dash" is pretty overloaded.
20:52:20 <johnpur> anotherjesse:  +1
20:52:31 <vishy> hud!
20:52:40 <zns> windows :-)
20:52:44 <Daviey> Currently the dashboard is OSAPI centric, is anyone (and is it viable) to support ec2 elements?
20:52:47 <jaypipes> mrs. dash?
20:52:49 <Daviey> Such as differeing crednetials?
20:52:49 <anotherjesse> devcamcar: I'm going to owe you a whiskey if I get dashboard voted down due to naming ...
20:52:56 <soren> instrumentbræt
20:53:09 <soren> (dashboard in Danish)
20:53:25 <devcamcar> Daviey: OS API vs EC2 API is more about what the guts of it use to communicate with the nova and glance pieces
20:53:27 <vishy> trifle
20:53:32 <jaypipes> pinch
20:53:34 <jmckenty_> braet is hard to type
20:53:35 <vishy> smidge!
20:53:44 <jmckenty_> amudge?
20:53:51 <soren> jmckenty_: You just hit the æ key. Easy.
20:53:53 <devcamcar> Daviey: its more about feature support, and OS API has caught up to EC2 API in diablo
20:53:54 <ewanmellor> soren: you don't even bother to spell your own name properly most of the time!
20:53:59 <jbryce> does this mean we have no more substantive issue to discuss with it? = )
20:54:01 <anotherjesse> can we accept but with a new name to be determined later ?
20:54:02 <soren> jmckenty_: Or compose+a+e.
20:54:08 <Daviey> devcamcar: But the OSAPI doesn't expose EC2 credentials, (yet) :)
20:54:09 <anotherjesse> if so - vote
20:54:12 <jbryce> correct
20:54:14 <soren> ewanmellor: Fair point :)
20:54:19 <ttx> �
20:54:21 <anotherjesse> Daviey: we are still adding those to nova & keystone
20:54:24 <anotherjesse> Daviey: it will
20:54:29 <Daviey> Ah, good stuff.
20:54:33 <jbryce> #info VOTE: Should Dashboard be promoted to core for Essex release cycle?
20:54:35 <vishy> Daviey: yes that should be a bug
20:54:39 <anotherjesse> if there is a ec2 extension in keystone
20:54:40 <jmckenty_> devcamcar: is there a commitment
20:54:42 <ewanmellor> +1
20:54:48 <soren> +1
20:54:50 <jmckenty_> to keep dashboard up to partiy with the full OS API?
20:54:55 <jbryce> +1
20:54:57 <vishy> +1
20:55:00 <anotherjesse> +1
20:55:01 <devcamcar> jmckenty_: that is absolutely the goal
20:55:05 <jmckenty_> +1 then
20:55:08 <johnpur> +1
20:55:09 <ttx> +1
20:55:13 <anotherjesse> with a qualification that dash(board) isn't the name
20:55:21 * vishy hopes that these things becoming core will make them much easier to install
20:55:21 <jmckenty_> +1 on a better name
20:55:25 <jaypipes> -1
20:55:27 <anotherjesse> swift and dash are too close
20:55:27 <devcamcar> anotherjesse: agreed! we will name it while drinking whiskey
20:55:33 * jmckenty_ promises to give vishy his installer
20:55:45 <vishy> wait
20:55:49 <vishy> can we call it whiskey?
20:55:50 <jmckenty_> devcamcar: add a session for boston for naming?
20:55:52 <jmckenty_> OOH
20:55:53 <devcamcar> oo
20:55:53 <jmckenty_> bourbon
20:55:59 <vishy> that is genius
20:56:00 <devcamcar> haha
20:56:03 <jmckenty_> bourbon is the official drink of cloud, though
20:56:06 <ttx> jaypipes: rationale ?
20:56:11 <devcamcar> jmckenty_: +1
20:56:16 <jbryce> #agreed Dashboard will be promoted to OpenStack core for Essex release cycle (8+, 2 abstain, 1-)
20:56:24 <jaypipes> ttx: same as my rationale for voting -1 for incubation to core :)
20:56:34 <jaypipes> ttx: I don't think it's a core project ;)
20:56:42 <ttx> jaypipes: you hate css ?
20:56:44 <jaypipes> ttx: it's awesome, just don't consider it in the same vein.
20:56:49 <jaypipes> ttx: just being consistent.
20:56:51 <jbryce> congrats, devin
20:56:56 <ttx> jaypipes: ack
20:56:58 <bengrue> (whiskey would get confused with wsgi in conversation; bourbon is unambiguous.)
20:57:03 <jbryce> #topic open discussion
20:57:08 <jaypipes> bengrue: hehe, good point.
20:57:10 <ttx> devcamcar: welcome to hell too.
20:57:11 <anotherjesse> summit registration!
20:57:14 <devcamcar> hooray!
20:57:14 <jbryce> anyone want to hit on anything in the last 2 minutes, 30 seconds?
20:57:15 <notmyname> jaypipes: +1
20:57:20 <bengrue> summit registration!
20:57:23 <ttx> anotherjesse: dude, don't steal my effects :)
20:57:32 <anotherjesse> ttx: sorry - just excited about http://summit.openstack.org/
20:57:36 <jbryce> haha
20:57:45 <jbryce> anotherjesse: that's kind of wrong
20:57:46 <jmckenty_> jbryce: I've got a FITs framework doc coming together
20:57:53 <soren> jaypipes: Would it be a fair summary to say that in your terminology "core" means (near) bottom of the stack?
20:57:56 <jmckenty_> Will have a draft on the wiki for next week
20:57:57 * ttx must resist sudo apache2ctl stop
20:58:07 <jaypipes> soren: yes, I guess os.
20:58:08 <jaypipes> so.
20:58:15 <jbryce> jmckenty_: cool, sounds good
20:58:21 <soren> ttx: There you have it ^
20:58:24 <vishy> can we put api discussion on the docket for next time
20:58:27 <jmckenty_> yes please
20:58:32 <jmckenty_> +1 for API discussion
20:58:38 <anotherjesse> jmckenty_: with the FITs - is it online already?
20:58:43 <jbryce> #action jbryce to add API discussion to next week's agenda
20:58:53 <jmckenty_> google doc, I'll share it when I'm sure it's not inflammatory
20:58:54 <jmckenty_> :)
20:59:12 <anotherjesse> jmckenty_: hmm - next month or ?
20:59:29 <jbryce> he said next week
20:59:46 <jbryce> thanks, everyone!
20:59:46 <jmckenty_> yup
20:59:48 <jbryce> #endmeeting