19:59:59 <jbryce> #startmeeting
20:00:00 <openstack> Meeting started Tue Feb 21 19:59:59 2012 UTC.  The chair is jbryce. Information about MeetBot at http://wiki.debian.org/MeetBot.
20:00:01 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
20:00:07 <danwent> o/
20:00:08 <pvo> o/
20:00:16 <ttx> o/
20:00:28 <jbryce> agenda: http://wiki.openstack.org/Governance/PPB
20:00:32 <anotherjesse> \o/
20:00:46 <reed> o/
20:00:52 <ttx> 5/14
20:01:05 <ttx> or is it 12?
20:01:19 <ttx> no.. 14.
20:01:21 <jbryce> 14
20:01:22 <jbryce> yep
20:01:30 <jbryce> we need 2 more
20:01:31 <vishy> o/
20:01:32 <notmyname> here
20:01:37 <ttx> 7/14
20:01:40 <jbryce> devcamcar, ewanmellor, jmckenty: around?
20:01:43 <ewanmellor> Yep
20:01:46 <jmckenty> yep
20:01:54 <jbryce> #topic Quantum core promotion
20:01:55 <ttx> 9/14, yay
20:02:13 <jbryce> so picking up from where we left off last week with quantum, did everyone see dan's email?
20:02:39 <anotherjesse> Dan - "The existing nova-network manages will remain supported for Folsom, but no feature work will be done on them (only bug fix work)" - is refining of the APIs considered feature work?
20:02:39 <jmckenty> yeah, vaguely
20:03:04 <danwent> anotherjesse:  tenant APIs, or internal network API abstraction?
20:03:05 <vishy> anotherjesse: which apis?
20:03:33 <anotherjesse> vishy: the work bcwaldon and others have been doing on revising the openstack api (for 3.0 or whatever it is called)
20:03:38 <danwent> ultimately, I think what work is done on existing managers is vishy's call.  I think his goal is to minimize it.
20:04:01 <vishy> anotherjesse: we discussed trying to move those apis into a network-api
20:04:10 <vishy> the same way we are for volume
20:04:22 <vishy> but we could leave the extensions in compute and deprecate them
20:04:46 <anotherjesse> vishy: ok, I read the document dan sent as: we will have a quantum API and the exising nova APIs would "proxy" to quantum
20:05:11 <vishy> initially yes, but the goal is to get to a standard openstack network api i think
20:05:35 <anotherjesse> independent of that there is the work on taking some of the extensions in nova and making them core in the next version
20:05:48 <anotherjesse> if those are still proxying to quantum would we be able to do that
20:05:53 <anotherjesse> or is that considered feature work?
20:06:11 <vishy> anotherjesse: do you think nova v3 will be done in folsom?
20:06:17 <vishy> that seems like a G think to me
20:06:27 <anotherjesse> it seemed F before essex ;)
20:06:38 <danwent> I think having network API in both nova + quantum API long-term is a mistake.
20:06:45 <vishy> i don't think floating ips and security groups (for example) should be in the compute core api
20:06:55 <johnpur> danwent: agree
20:07:12 <anotherjesse> I think we need to be explicit about that in the plan document
20:07:38 <pvo> vishy: I'd agree with that.
20:07:41 <anotherjesse> so - *no* further progress on nova network api-s … at the release of essex they are frozen in time
20:07:46 <anotherjesse> (modulo bug fixes)
20:08:01 <pvo> anotherjesse: on 2.0 api, you mean?
20:08:03 <danwent> anotherjesse:  OK.  I had considered the nova network apis part of the existing nova network managers.  I will make the explicit in a revised version of the doc.
20:08:11 <anotherjesse> pvo - they aren't in the 2.0 api - they are only in extensions
20:08:18 <vishy> why cant we update ext?
20:08:47 <pvo> right, no further progress on 2.0. they're locked and 3.0 opens for dev estimated by F/G?
20:08:56 <anotherjesse> vishy: that's what I'm trying to ask - the document doesn't make a statement on what we do with the nova-network APIs (that are currently extensions)
20:09:05 <zns> o/
20:09:29 <anotherjesse> are they frozen, are they considered for inclusion with core, can they evolve as long as the feature set doesn't change, ...
20:09:44 <anotherjesse> the document talks about feature work & the managers, not the API
20:09:45 <vishy> i think we can make minor changes as necessary
20:11:28 <danwent> anotherjesse:  I would expect that those nova-apis would be handled along with the existing nova-network managers.  They would be largely frozen, and not planned to be promoted from extensions to part of the core nova API.  I would not expect Quantum functionality to be exposed via those Nova APIs.
20:12:11 <jbryce> i also think we shouldn't tie the evaluation of quantum only to that decision. if quantum is functional and has matured and is on the path right now, i don't want to delay it an entire additional 6-month release cycle before it's core
20:12:43 <jmckenty> I worry about integration, though
20:12:45 <vishy> we absolutely have to define a network v1 api
20:13:10 <vishy> that would include quantum/melange features as well as network related functionality in nova
20:13:14 <jmckenty> regardless of quantum's quality and functionality, if it's not well-integrated with the rest of core, we could easily end up with problems
20:13:14 <danwent> jmckenty: can you elaborate?  I know you expressed some concerns last week via email.
20:13:43 <jmckenty> sure - do existing simple behaviours work out of the box?
20:14:05 <anotherjesse> summary about APIs: nova's network extensions (floating ips, sec groups, …) will remain extensions and no work should be done to promote them core. any work done to networking extensions should be minimal
20:14:10 <jmckenty> E.g., do launched instances end up with working network connectivitiy
20:14:29 <danwent> jmckenty: yes
20:14:47 <danwent> jmckenty:  assuming you've setup a quantum plugin and are running QuantumManager for you network manager
20:14:48 <jmckenty> do sec groups work with quantum?
20:14:52 <jbryce> it seems like there's a plan for integration that vishy and danwent have come up with and both agreed on, but it's going to be hard to know every detail right now no matter how long we spend talking through it
20:15:00 <anotherjesse> the difference between this and the glance integration - nova has an "image-list" functionality that we didn't remove that proxies to core and is expected to be there.
20:15:01 <vishy> jbryce: +1
20:15:04 <jmckenty> right - can we gate on trystack?
20:15:07 <ttx> jbryce: +1
20:15:18 <danwent> jmckenty:  that is one of the APIs we're planning on moving over from Nova to Quantum.
20:15:31 <devcamcar_> +1
20:15:34 <anotherjesse> anyone who wants any networking apis will need to use quantum since extensions shouldn't be assumed to be there
20:15:37 <danwent> but existing nova security groups work if your plugin supports them.
20:15:44 <danwent> sorry, two threads at once...
20:16:01 <vishy> anotherjesse: yes, we aren't forcing the issue in folsom
20:16:06 <anotherjesse> jmckenty: trystack is a deployment of the *last* stable release - doesn't make sense to gate on it
20:16:15 <vishy> anotherjesse: so folsom will ship with deprecated network and old extensions
20:16:18 <jmckenty> right, so what's the integration CI environment?
20:16:20 <anotherjesse> vishy: the doc says the default is quantum
20:16:40 <jmckenty> e.g., can we make promotion to core dependent on successful integration testing?
20:16:41 <vishy> anotherjesse: doc says goal is to default to quantum
20:16:45 <devcamcar_> it should be the default
20:16:55 <vishy> anotherjesse: but we're leaving old stuff in as a fallback
20:16:55 <anotherjesse> vishy: :)
20:16:57 <jbryce> it's status quo for folsom in capability with the upside potential of extra functionality in quantum
20:17:11 <danwent> jmckenty:  we're integrated with devstack, though no one is running automated smoketests yet.  This is something I'm really pushing for.
20:17:26 <vishy> anotherjesse: we wil have to decide around FF time if the integration is complete enough to switch the default, but I think we should strive to make it that way.
20:17:28 <danwent> jmckenty:  these are all good points, and items we need to take care off.
20:17:45 <ttx> vishy: sounds like a good plan.
20:17:51 <jmckenty> So I would be worried about promoting to core if it's not ready to be the default
20:18:01 <danwent> jmckenty: I'm not trying to say that we're fulling integrated yet, just trying to get a better sense of your concerns.
20:18:01 <jmckenty> I think it ends up being a confusing message for the user community
20:18:22 <jbryce> how do other people feel about conditional promotion?
20:18:25 <jbryce> upon integration testing?
20:18:26 <johnpur> i believe the project (Quantum) is ready to be promoted to core and that all of the issues being raised can be worked by dan, vish, etc.
20:18:49 <danwent> I think there's risk for confusion either way, as people are already starting to use Quantum because it solves a need, yet it is not core.
20:18:54 <jbryce> right
20:18:57 <ttx> jbryce: I think it's a bit of chicken-and-egg. I trust Dan and Quantum guys to get their Ci integrated
20:18:57 <anotherjesse> vishy: my concern is that if we don't state what we are doing with the nova api's then people will either want to make changes or we end up frozen with no progress if it doesn't land (eg, the lunr situation with volumes - where we didn't change anything for a long time with volumes — or the keystone situation where everything didn't land and it was assumed)
20:19:07 <johnpur> we need to step forward and set the direction for the networking in OpenStack
20:19:08 <jmckenty> danwent: right, that's what the incubation stage is for, though
20:19:23 <jbryce> ttx: that's my personal feeling too. especially seeing how mature they already were when they started incubation
20:19:27 <anotherjesse> if the document says we are freezing feature work for folsom, we should have a statement about api work too
20:19:32 <vishy> anotherjesse: I think we need to get a draft proposal for network api v1 out asap
20:19:43 <ttx> jbryce: and how efficiently they managed to align with release process around E3
20:19:48 <johnpur> vishy: +1
20:20:01 <vishy> anotherjesse: even if it means we do the same thing we did with volumes, separate it into its own endpoint
20:20:06 <jmckenty> I can't vote to promote to core without automated smoketests or a community-accessible integration environment
20:20:16 <jmckenty> even if that's a higher bar than any other project :)
20:20:33 <devcamcar_> I don't see a better way to reach the finish line than to try it. dan has done a great job integrating with rest of projects
20:20:33 <anotherjesse> jmckenty: there is already devstack support for quantum, and you can run tests against it
20:20:47 <danwent> jmckenty:  I'm a huge fan of getting that work done.
20:20:51 <ttx> promoting to core is always a bit of a leap of faith. This one seems less risky than others we did in the past.
20:20:56 <jbryce> jmckenty: it is a 6-month period before it's actually core in a release
20:21:06 <jmckenty> ttx: the previous ones were a bit of a train wreck, though
20:21:06 <jbryce> if we don't promote now, we're basically saying quantum won't be core for at least a year
20:21:09 <danwent> I think we have all of the pieces together, we just need someone to actually put us in the main CI environment.
20:21:11 <jmckenty> the goal should be to do better, right?
20:21:14 <jmckenty> k
20:21:17 <jbryce> jmckenty: absolutely
20:21:23 <jmckenty> so I'm still good with conditional promotion
20:21:47 <ttx> jmckenty: part of the issue is linked to the fact that 6 month is a long time to wait if you miss the boat. Working on fixing that :)
20:21:52 <jbryce> i'm fine approving and giving dan some things that we think are priorities. it sounds like he already agrees that they're priorities and from the way that quantum has gone to this point, i have a lot of faith that he'll get it done
20:22:04 <jmckenty> I'd also like to see a bit of a migration plan for existing deployments
20:22:09 <jmckenty> on the docs side
20:22:10 <danwent> I would agree that if quantum is not successfully integrated into the CI infrastructure, I wouldn't want it as core :)
20:22:31 <vishy> danwent made the point when we talked that there is no way they can get all of this done with the current team
20:22:48 <vishy> so the onus is on nova to start moving people over to focus on quantum
20:22:55 <jmckenty> gotcha
20:23:00 <pvo> vishy: thats part of our plan as well.
20:23:01 <danwent> jmckenty:  we have a pretty good start on docs: http://docs.openstack.org/incubation/openstack-network/admin/content/index.html
20:23:04 <vishy> they need to double the amount of people working on it
20:23:04 <jmckenty> and we need core status and a freeze on nova-network to do that
20:23:11 <johnpur> or recruiting more network savvy people from the community
20:23:12 <vishy> jmckenty: right
20:23:48 <jmckenty> danwent: I like the docs, but they don't have a "migrating from nova-network" section :)
20:24:05 <danwent> jmckenty:  fair :)
20:24:07 <jmckenty> I saw a lot of pain on the "switching to keystone" side, that I think docs could have helped with
20:24:27 <jmckenty> I'll see if Lloyd can help with that
20:24:57 <anotherjesse> some of the work will need to be devs fixing things like "Multi-host nova-network HA is not supported (i.e., running nova-network on each compute node for HA purposes). It is unlikely that Quantum Manager will support this mode in Essex."
20:25:01 <danwent> jmckenty:  definitely.  we'd really appreciate some help on that end.
20:25:24 <jbryce> for essex, quantum would still not be core, though
20:25:31 <jmckenty> anotherjesse: yeah, that would be a major regression
20:25:41 <jbryce> and not included or defaulted to in nova
20:26:08 <danwent> anotherjesse:  yes.  Quantum is actually going to have its own L3 abstraction that will support a multi-node deployment.
20:26:17 <danwent> those docs are for people using it right now.
20:26:27 <annegentle> I'd like to see migration plan plus detailed plans on doc updates for existing network info for nova
20:26:30 <danwent> but i agree providing a multi-host equivalent is important.
20:26:46 <annegentle> basically what all the rest of y'all are saying
20:27:01 <vishy> danwent: we can take this offline, but I think we need to discuss whether the network_api/v1 will live in nova for the time being
20:27:19 <jmckenty> I'd also like to see some commitment from the quantum vendors community to provide context around their products (Nicira, MidoNet, Cisco-whatever, etc)
20:27:29 <danwent> vishy:  ok.
20:27:35 <jmckenty> that's probably a separate concenr, though
20:27:36 <jbryce> todos for dan: migration docs, integration testing, ha mode
20:27:43 <vishy> basically promoting all the extensions and the mova.network.api to its own endpoint
20:27:48 <soren> jmckenty: Context?
20:27:55 <devcamcar_> multihost is essential
20:28:00 <jbryce> vishy: mova? is that a new fork?
20:28:06 <vishy> oh yeah
20:28:17 <vishy> its mo bettah
20:28:26 <reed> mova and rwift
20:28:29 <jk0> hehe
20:28:38 <anotherjesse> vishy: that is what I need to understand before I can say yes/no to core
20:28:39 <danwent> devcamcar:  I see the basic requirement being that there must be an open source quantum plugin that provides all of the capabilities of the existing nova network solution (and hopefully much more)
20:28:39 <jmckenty> soren: we'll need a blog post that says: "This is quantum. It replaces nova-network because of <x>. There are commercial versions of quantum from vendors <x,y,z> with features <a,b,c>"
20:28:52 <danwent> what other vendors choose to do in terms of HA strategies is up to them.
20:29:36 <jmckenty> soren: otherwise, I'm going to be on the phone with PCWorld explaining how CISCO has taken over OpenStack, or some such retardedness
20:29:44 <jmckenty> Ala what just happened with MSFT
20:30:19 <jmckenty> Oh, speaking of which - PCWorld called this morning and wants to talk about MSFT. I gave them Collier's cell #. Anyone else know anything concrete?
20:30:50 <jbryce> jmckenty: they're working on their plan. nothing concrete announced
20:30:52 <jbryce> other questions or should we vote on promotion?
20:30:57 <danwent> btw, who is best point of contact talked to about CI infrastructure integration?
20:30:59 * jmckenty apologizes for the segue
20:31:03 <anotherjesse> danwent / vishy - does this mean we need to define network api 1.0 strategy before a vote
20:31:13 <ttx> danwent: Ci infra integration: jeblair and mtaylor
20:31:24 <danwent> ok, usual suspects :)
20:31:25 <anotherjesse> danwent: mtaylor is sick, jeblair
20:31:39 <vishy> danwent: basically it just involves proposing defaults to devstack and opnstack-ci
20:31:45 <vishy> i turned on the volume tests doing that
20:31:57 <danwent> vishy: ok, then we may be good to go already.
20:32:05 <anotherjesse> I'm happy with +1 to core assuming we have a solid stance about what the API expectations are for nova with and without quantum
20:32:13 <johnpur> the ci piece should not be much trouble
20:32:16 <vishy> anotherjesse: +1
20:32:19 <jbryce> ok
20:32:40 <jbryce> #info VOTE: Should Quantum be promoted to core for the Folsom release cycle
20:32:41 <vishy> lets say a clear plan on network.api.v1 by the end of the summit
20:33:05 <johnpur> vishy: agree
20:33:15 <zns> +1
20:33:16 <jmckenty> add in a clear plan on integration testing, and docs for migration, and I'm +1
20:33:17 <ttx> +1
20:33:23 <johnpur> +1
20:33:33 <jbryce> +1
20:33:35 <jk0> +1 from me, and +1 from pvo (he had to run to another meeting)
20:33:36 <ewanmellor> +1
20:33:38 <notmyname> +0
20:33:41 <anotherjesse> +0
20:33:54 <devcamcar_> +1
20:33:54 <anotherjesse> until I know about what the nova api story is I can't +1
20:34:01 <vishy> can we document the requirements
20:34:02 <vishy> ?
20:34:16 <vishy> and have an option to reverse the decision if they aren't met?
20:34:23 <vishy> as in a contingency promotion?
20:34:30 <jmckenty> I think that's the plan, yes?
20:34:32 <ttx> vishy: we actually always have the option of reversing the decision.
20:34:36 <jbryce> vishy: we can always revoke core status
20:34:48 <jbryce> #info Quantum is approved for core promotion for Folsom release (8 - +1, 2 - +0)
20:35:00 <danwent> anotherjesse:  specifically, are you looking to understand what network-related APIs will be exposed by nova stand-alone in F?
20:35:11 <ohnoimdead> hooray!
20:35:23 <reed> congratulations danwent and the whole Quantum team
20:35:33 <heckj> Congrats Quantum crew!
20:35:36 <anotherjesse> danwent: it is mostly a nova question - not a quantum question
20:35:39 <jbryce> #info priorities for first core cycle: migration documentation, feature parity with nova-network, integration with CI/testing, network api plan coming out of folsom summit
20:35:51 <danwent> ok, thanks folks.  I think we had a lot of good suggestions during the meeting today.
20:36:07 <anotherjesse> danwent: there has been lots of thought going into the openstack APIs and I'm not sure they need to be in sync with this
20:36:14 <danwent> i'll appreciate you help working through these issues during the summit and beyond.
20:36:19 <jbryce> did i miss any priorities?
20:36:20 <johnpur> from a policy standpoint, jmckenty has brought up a good point in that we should blog/document how Quantum fits into the overall direction OpenStack is taking
20:36:24 <danwent> anotherjesse:  agreed
20:36:27 <jmckenty> random question - does this mean danwent is on the PPB now?
20:36:35 <jbryce> he would be after the next election cycle
20:36:45 <jbryce> that's how we have handled the previous core promotions
20:36:45 <anotherjesse> I think it can happen, I just don't want either what happened to volume api or keystone integration to occur again
20:36:47 <danwent> anotherjesse:  I've been talking to some folks, but it seems bcwaldon and some others may need to be in the mix
20:36:48 <jmckenty> danwent: if you can get it down to a couple of sentences, that would be awesome.
20:36:54 <zns> danwent: well done. The bar continues to rise for incubation. It's good :-)
20:37:09 <danwent> johnpur: +1
20:37:18 <zns> danwent: I meant for inclusion in core.
20:37:27 <jbryce> ok
20:37:32 <jbryce> #topic quantum + melange
20:37:42 <jmckenty> is this a status update?
20:37:45 <jbryce> anything we should discuss on quantum + melange?
20:37:56 <jbryce> it was on our list of things to review this week
20:37:59 <ttx> I read that Melange would get folded into Quantum in Folsom ?
20:38:21 <danwent> ttx:  that is what Troy is pushing for, and I think it makes sense.
20:38:42 <ttx> That Melange is unstable, always looking for a project to live in.
20:38:49 <jmckenty> Is it active?
20:38:57 <jmckenty> relatively?
20:39:16 <anotherjesse> danwent: does that mean sharing the same DB + queue + whatever internal datastores
20:39:17 <danwent> jmckenty:  I believe there is active development, but primarily from Rackspace
20:39:24 <jbryce> jmckenty: i think it's moderately active, but not a large pool of developers
20:39:30 <anotherjesse> danwent: or does that mean it is in the project but mostly stand-alone?
20:39:39 <danwent> anotherjesse:  not necessarily.  was talking with Trey Morris about this today.
20:39:57 <jmckenty> I don't like the name melange anyway, so I'm happy to see it merge with a project with a cool name :)
20:40:00 <devcamcar_> I've heard it'll go back into nova, that it'll go in quantum. Seems clear that it won't be a separate project long term
20:40:01 <danwent> probably would not fundementally change the back-end architectures of either.
20:40:27 <danwent> key motivation is: 1) single network API for tenants, 2) Melange is important to decoupling networking from Nova DB.
20:40:46 <danwent> for example, if you want a network that spans a nova zone.
20:40:55 <jmckenty> cell
20:40:56 <ttx> danwent: if Melange is needed for Quantum to work... it either needs to be included or file for core
20:41:02 <danwent> jmckenty: ahem… yes, sorry
20:41:03 <johnpur> perhaps we should have a topic on if/how to attract more active contributors across the OpenStack projects?
20:41:34 <jmckenty> johnpur: We'll need a longer slot for that - and AFTER we talk about design summit attendance
20:41:47 <johnpur> to help out Quantum, Melange, etc.
20:42:06 <danwent> ttx:  it is not strictly needed, as Quantum already works with Nova IPAM as well, but it is important to achieving the two goals I mentioned.
20:42:18 <ttx> danwent: ok
20:42:23 <soren> ttx: Well..
20:42:36 <soren> ttx: We have plenty of dependencies in Openstack on stuff that isn't core openstack.
20:42:53 <jmckenty> soren: but do we have dependencies on incubated projects?
20:42:55 <soren> ttx: If Melange had a thriving life on its own, that could still work.
20:42:59 <jmckenty> or just external ones
20:43:00 <danwent> johnpur:  yes, I think attracting developers, especially those interested in the "core" code, not plugins, is very important.  I've already been working at it.
20:43:04 <anotherjesse> danwent: I like the idea that IPAM lives inside quantum, but I think it would be nice if it could be deployed & operated separately (different db/endpoint/controller)
20:43:14 <soren> jmckenty: At the moment, only external ones (that I know of).
20:43:35 <jmckenty> yeah, same.
20:43:38 <ttx> jbryce: not sure there is that much to discuss about quantum+melange, then
20:43:44 <jbryce> ok
20:43:54 <jmckenty> jbryce: maybe get Trey to present if there's more to discuss?
20:44:06 <jbryce> #topic Design Summit attendance process
20:44:18 <jmckenty> Can I ask how we ended up with the process we have?
20:44:24 <jmckenty> E.g., who was involved in the decision?
20:44:25 <jbryce> ttx: do you want to just summarize the process and thinking behind it?
20:44:34 <ttx> I can ... try
20:45:09 <ttx> One goal of the events team was to have a single registration process
20:45:18 <jmckenty> sorry, who is the events team?
20:45:36 <ttx> jmckenty: lauren, markC, ToddM
20:45:39 <reed> me
20:45:43 <ttx> +reed
20:45:46 <jmckenty> ktnx
20:45:54 <reed> :)
20:46:21 <ttx> my goal was to make sure we could get the right people, i.e. have the developers we need without overflowing the rooms with too many people
20:46:44 <jmckenty> so there are three big issues with that
20:47:03 <jmckenty> first, it's not a community-inclusive process to make drastic changes to the biggest OpenStack event
20:47:06 <ttx> and somehow the limitations in cvent drove us to the invite-onnly situation
20:47:15 <jmckenty> second, you're defining the "Right People" without consultation
20:47:16 <reed> If I may add, the single reg process is a solution to the confusion created last time
20:47:55 <jmckenty> OpenStack's biggest advantage, historically, has been it's relatively business-friendly format
20:47:56 <ttx> jmckenty: so far we (RAX) always controlled who the "right people" were
20:48:02 <soren> jmckenty: Who do you believe are being excluded?
20:48:03 <ttx> through wait lists or invites
20:48:15 <jmckenty> I've had 6 people email me asking for invite codes in the past two days
20:48:24 <notmyname> I've got a list of 14 people to invite
20:48:25 <ttx> This time we decided to involve the PTLs in the process
20:48:26 <jmckenty> mostly new potential developers who I told to come to the summit to get involved
20:48:35 <jmckenty> ttx: when did that happen?
20:48:42 <jmckenty> And why the PTLs instead of the PPB?
20:48:47 <soren> Why not?
20:48:48 <ttx> i.e. anyone with a good reason can ask their PTL for an invite
20:48:58 <jbryce> ptls and release manager have always owned the schedule for the design summit
20:49:00 <reed> jmckenty, we had tens of requests from actual developers last time, after we filled the event with random people getting to the summit for a free conference pass
20:49:35 <jmckenty> We also had dozens of non-contributors who BECAME contributors after their attendance at the last summit
20:49:43 <jmckenty> The RedHat folks, the Yahoo folks, etc.
20:49:50 <ttx> I think the process this time is actually way more open than last time, where I handpicked people from the wait list myself
20:50:03 <jmckenty> Ah.
20:50:15 <ttx> jmckenty: and those were invited
20:50:21 <jmckenty> Where did the size constraint come from?
20:50:36 <ttx> jmckenty: you can't have a good discussion in a room with 100 people
20:50:51 <jmckenty> the UN would disagree with you
20:50:55 <reed> LOL
20:51:10 <reed> the UN is the worst example you could pick :)
20:51:12 <jmckenty> So the constraint was your idea
20:51:15 <notmyname> my issue is that ops and qa people (vital to the overall success) weren't included because they don't contribute lines of code. they still contribute to the process
20:51:17 <ttx> jmckenty: the UN has better AV equipment than we have
20:51:28 <jmckenty> The solution to the constraint was your idea
20:51:41 <jmckenty> and you decided who would be consulted about approving it, correct?
20:52:01 <jaypipes> notmyname: ++
20:52:14 <jbryce> jmckenty: it was basically moving from a single waitlist to managed by the release manager and ptls like the schedule
20:52:18 <jmckenty> notmyname: ++
20:52:18 <ttx> the size constraint is definitely my idea. the solution is not really mine
20:52:44 <ttx> notmyname: the invite code you get are supposed to solve that
20:52:46 <jmckenty> so what's the mission of the summit?
20:52:49 <ttx> it's like a distributed wait list
20:52:53 <notmyname> ttx: I've got 14 people for my 5 invites
20:53:08 <jbryce> design summit managed by ptls+release manager, conference managed by events team+programming committee, single registration to eliminate the number 1 complaint we had about getting to the events last time
20:53:21 <ttx> notmyname: you should probably get 15 more... as soon as some time passes to give existing contribtors a chance
20:53:28 <jmckenty> again, what's the mission of the summit
20:53:48 <ttx> Discuss design and development of the next release
20:54:03 <ttx> a developers gathering
20:54:07 <jbryce> after the initial invites are sent out, it will be opened up broadly again
20:54:07 <reed> it's a two step invitation: first the known developers, + others invited by PTLs and community, then everybody else until we fill the rooms
20:54:12 <jmckenty> you've prioritized discussion among existing code contributors over cross-disciplinary interactions
20:54:22 <jmckenty> you're making the mozilla mistake
20:54:32 <jmckenty> and you've left no room for users
20:54:33 <jbryce> last time we opened it up broadly first and had a ton of people sign up just to get free passes to the conference
20:54:45 <jmckenty> then don't make it a free pass to the conference
20:54:49 <notmyname> jmckenty: +1 to needing users/deployers
20:54:50 <jbryce> i agree that we need to make sure we have users and non-code committer technical people there
20:54:51 <jmckenty> hell, make the summit cost money!
20:55:14 <jmckenty> you're incentivized perverse behaviour
20:55:15 <ttx> jmckenty: I guess we chose the path of least changes
20:55:23 <ttx> from previous summits.
20:55:27 <jbryce> we've got 5 minutes left
20:55:28 <jmckenty> You chose the path of autocratic dictatorship
20:55:29 <ttx> since nobody complained /then.
20:55:38 <jaypipes> jmckenty: settle down please.
20:55:53 <ttx> jmckenty: mind you, I'd prefer not to have to organize the registration of the summit
20:56:03 <jmckenty> I just had my doc writers submit patches to nova, so I'm good
20:56:03 <jbryce> jmckenty: we've got 2 months left, no one has actually been denied yet, there will be more seats available
20:56:08 <jmckenty> they're in the authors file now
20:56:08 <ttx> jmckenty: and concentrate on my real tasks
20:56:33 <jmckenty> Can I propose that the PPB organize an events committee?
20:56:37 <jbryce> can we wait a couple of weeks and see if we're really keeping out good people? if we are, i'm sure we can find a way to fit them in
20:56:38 <ttx> jmckenty: so your main issue is with limiting the number of people attending ?
20:56:44 <jmckenty> with people that WANT to organize summits?
20:57:16 <jmckenty> A quote from my email this morning:
20:57:17 <ttx> jmckenty: you think we can have productive discussions with 150 people per room ? And nobody hearing anything ?
20:57:18 <jmckenty> "
20:57:18 <jmckenty> One thing that I could use your help on is getting my two new OpenStack-dedicated hires into the Folsom Design Summit. Any idea how I can get them invites? I think they'd be able to contribute a lot to the conversations, especially by the time the summit rolls around. Duncan will definitely be attending, and I'll be around as well, but I'd really like my new guys to be a part of it too."
20:57:47 <ttx> jmckenty: if everyone agrees with you, I'm more than happy to open the flood gates
20:57:56 <jbryce> we've got 2 minutes and another meeting starting after this
20:58:12 <jmckenty> can we vote on an events committee?
20:58:23 <jbryce> can we give the existing process a couple of weeks to get through this first phase and see how big the problem actually is?
20:58:32 <jbryce> we are literally 3 days into the process
20:58:33 <jaypipes> jbryce: ++
20:58:57 <johnpur> jbryce: sounds like a reasonable approach
20:59:00 <jmckenty> We've brought this issue up at every summit
20:59:16 <ttx> jbryce: I'd really want to know if jmckenty wants to have unlimited attendance to the summit or not
20:59:28 <jmckenty> That's totally not the point
20:59:39 <jmckenty> I'd like to have our "open community" involved in the decision
20:59:40 <soren> Is that a no?
20:59:49 <jmckenty> rather than have ttx's summit every 6 months
21:00:04 <jmckenty> There are a LOT of ways to manage attendance
21:00:11 <jmckenty> cap on headcount per company
21:00:11 <ttx> jmckenty: RAX organizes the summit and conference so far.
21:00:15 <jmckenty> charging MONEY
21:00:27 <jmckenty> Allocation of seats per attendee type
21:00:29 <johnpur> jmckenty: you are getting close tot he line, dial it back
21:00:31 <jbryce> we're out of time. we can take it to the ppb list if we want to keep going
21:00:38 <jmckenty> e.g. current dev, new dev, qa, etc
21:00:50 <jbryce> #endmeeting