22:00:25 <dendrobates> #startmeeting
22:00:26 <openstack> Meeting started Wed May 11 22:00:25 2011 UTC.  The chair is dendrobates. Information about MeetBot at http://wiki.debian.org/MeetBot.
22:00:27 <openstack> Useful Commands: #action #agreed #help #info #idea #link #topic.
22:00:34 <somikbehera> Hello all, this Somik Behera from Nicira
22:00:43 <hisaharu> Hi, Hisaharu Ishii from NTT
22:00:52 <AlexNeef> Alex Neefus from Mellanox
22:00:58 <salv-orlando> Salvatore Orlando from Citrix
22:00:58 <ryu25> Ryu Ishimoto from Midokura
22:01:01 <dendrobates> Rick from Cisco
22:01:23 <NottaSeal> Jeff Timbs from Dell
22:01:27 <danwent> Is troy here?
22:01:45 <dendrobates> danwent: he said he might not make it
22:02:04 <danwent> ah, that's right.
22:02:19 <danwent> Erik C. is still out-of-office as well.
22:02:43 <danwent> sounds like a quorum?
22:02:58 <dendrobates> #topic Launchpad update
22:03:07 <dendrobates> We now have a project group
22:03:32 <dendrobates> it is called netstack, because the LP team objected to our original name
22:03:51 <dendrobates> I converted network-service to the quantum project
22:04:03 <dendrobates> I also created a couple of teams
22:04:12 <danwent> ok.  i think donabe blueprints are currently still under network-service
22:04:21 <dendrobates> netstack-admins and netstack
22:04:27 <dendrobates> I'll move them
22:04:27 <danwent> hopefully ram can move them.  Ram, you here?
22:04:30 <danwent> ah, ok.
22:04:48 <dendrobates> Dan and I are admins on the teams
22:04:49 <salv-orlando> network-service is quantum now, is that correct?
22:04:54 <dendrobates> yes
22:05:06 <danwent> I think the melange code is currently under network-service ... will talk with him about what he wants to do with that.
22:05:14 <dendrobates> We need everyone Launchpad IDs so we can add you to the main team
22:05:49 <dendrobates> danwent: I agree, pehaps that should be on the mailing list
22:05:52 <somikbehera> dendrobates: lets do LP ids by email after meeting?
22:06:10 <AlexNeef> are we getting a seperate email list
22:06:23 <dendrobates> so if you could send your launchpad id's to rick@openstrack.org
22:06:28 <AlexNeef> filtering throught he primary openstack one for netwrok related items is difficult
22:06:29 <danwent> plan is to stay on main one until week get kicked off for talking to much
22:06:52 <dendrobates> The openstack team wants all new projects to stay on the main list.
22:06:54 <danwent> yeah, agree, but we have to balance that with openness and communication with the nova folks.
22:07:05 <dendrobates> I think they will be moving nova off shortly
22:07:07 <danwent> (my comment was directly at Alex)
22:07:44 <dendrobates> I also added a few of the openstack infrastructure team members to netstack-admins
22:07:52 <dendrobates> modred, ttx, and Soren
22:08:07 <dendrobates> they will setup all the integration stuff for us
22:08:22 <danwent> great
22:08:43 <dendrobates> I did not create a netstack-core team yet
22:08:54 <dendrobates> I felt we needed to discuss it more
22:09:00 <danwent> agreed
22:09:05 <dendrobates> and how to seed it
22:09:10 <somikbehera> one correction: rick's email is rick@openstack.org not "openstrack.org" for folks who jus t copied and pasted email that was just mentioned.
22:09:16 <dendrobates> :)
22:09:27 <dendrobates> It's midnight here
22:09:46 <salv-orlando> oh and they serve good beer in budapest ;-)
22:09:55 <dendrobates> :)
22:10:24 <danwent> I think membership of the core team should be driven by who has dedicated time to the project, which is a bit hard to tell when we don't have code yet.
22:10:36 <dendrobates> Is there anyone else that would like to be on the admin team?  It is mostly to configure LP
22:10:57 <dendrobates> I agree, but we need to seed it, we did the same with Nova and swift
22:10:57 <danwent> I'm in favor of waiting a bit to define the core until we really need one.  At this point, if there is a disagreement on code, we'll have to sort it out like we did at the summit.
22:11:46 <danwent> is this a launchpad requirement or do you just feel its the right thing to do?
22:12:20 <dendrobates> not a LP requirement, but would keep us following the same process as the rest of openstack
22:12:48 <danwent> I guess I feel that we're a little different in that most other projects arrived with an existing team and codebase (at least nova did)
22:13:02 <dendrobates> the only difference between devs and core devs, is that their reviews count for merging
22:13:09 <dendrobates> true
22:13:15 <danwent> my guess is that by the time we actually have quantum up and running, everyone will know who put time in and there will be consensus on who the "core" is.
22:13:37 <adjohn> In that case, who would be responsible for approving merges?
22:14:12 <dendrobates> and all the integration tools are written with that framework in mind.
22:14:16 <danwent> I would expect that we assign blueprints to responsible people and the person in charge with a blueprint manages changes to that code.
22:14:25 <adjohn> makes sense
22:15:08 <dendrobates> I see a problem with that
22:15:14 <salv-orlando> I agree it is too early to properly define a core, but we probably need a minimal one in order to identify the people who will approve the first branches landing in the trunks
22:15:48 <dendrobates> Since there can be multiple blueprints for code base with multiple approvers...
22:16:03 <dendrobates> we would have different stds for the code
22:16:09 <danwent> sure.  all I'm saying is that practically speaking for a project like quantum there will be 5-10 people coding to start.
22:16:30 <dendrobates> if we have multiple core devs and an an agreed upon std, things will get less out of control
22:16:39 <danwent> If other people aren't happy with your branch, you probably shouldn't push it.
22:17:29 <dendrobates> I prefer that we seed, core-devs, but if other want to proceed differently, I'm ok with that.
22:17:54 <salv-orlando> how will be the review process without core-devs?
22:17:59 <dendrobates> We need to be sure we enforce coding stds though
22:18:04 <danwent> agreed.
22:18:23 <dendrobates> salv-orlando I am not sure
22:19:19 <danwent> I'd say you send it out for review both others registered on the blueprint.
22:19:26 <dendrobates> I would probably just say we all know our orgs, let's just make our sr devs core-devs and trust each other.   That is what we had to do with nova
22:19:53 <dendrobates> None of us really knew the other devs
22:19:54 <danwent> I'm all for trust + open communication.
22:20:17 <danwent> and avoiding situations were we try to push code we think/know someone else will not like
22:20:45 <danwent> if we can get the base network service out by collaborating, this project won't succeed :)
22:20:58 <danwent> (oops, didn't mean to say "network service", that's a bad word now)
22:21:28 <dendrobates> We need to figure out code review and merging if we do not ave core devs, but I am willing to put some thought into it.
22:22:17 <dendrobates> Let me ask mordred to make sure it will not break tany of the infrastructure stuff
22:22:24 <danwent> sounds good.
22:22:42 <salv-orlando> sounds a good plan to me.
22:22:50 <dendrobates> basically no core-devs == everyone is core dev
22:23:03 <danwent> yup, everyone will doing do fun things like reviews :)
22:23:04 <salv-orlando> at least until we gain enough critical mass
22:23:12 <romain_lenglet> it doesn't seem practical / desirable to have a large core dev team right now, so how about appointing a small number of core devs right now, but have them review code in the open, with help from everyone
22:23:15 <danwent> and discussions and write code.
22:23:21 <dendrobates> We should still require 2 approve reviews to merge code
22:23:35 <danwent> dendrobates: that sounds good.
22:23:40 <adjohn> non-core devs are always welcome to do reviews in nova
22:23:55 <dendrobates> adjohn: even encouraged
22:23:59 <danwent> definitely
22:24:43 <danwent> We have a lot of blueprints to implement == lots of changes to prove you want to be a core-dev :)
22:24:45 <dendrobates> So I prefer seeding a core dev group, but will happily bow to the will of the group
22:24:47 <romain_lenglet> so start with a small team of core devs who just delegate code reviews to everyone else can do it?
22:25:10 <snaiksat> why not start with the people who have done the most number of code-commits/reviews till date (in openstack) as the core-reviewers/approvers?
22:25:37 <snaiksat> I meant in OpenStack and and who are part of this group
22:26:06 <danwent> I think everyone is welcomed to review code... as we said.
22:26:14 <snaiksat> I believe they would be in a better position to handle this at least to begin with
22:26:24 <snaiksat> given their prior experience
22:26:43 <danwent> Definitely happy to use their experience for reviews
22:26:55 <dendrobates> We will have to decide at some point how to add core devs.  I don't think it will get any easier.
22:27:24 <danwent> I think the point is that we need to make sure everyone has a chance to approve/disapprove of the code.  Eventually that won't scale, but for now I think its where we need to start.
22:27:26 <dendrobates> But we can work on a policy over the next few months
22:27:50 <dendrobates> danwent: why do you think that won't scale
22:28:09 <danwent> sorry, let me rephrase.
22:28:22 <AlexNeef> are the core-devs for the entire netstack project or per subproject?
22:28:55 <danwent> everyone will always have the opportunity to do reviews.  At some point, the review burden becomes larger and you need core devs who have a focused responsibility on reviewing.
22:29:07 <dendrobates> AlexNeef: I would suggest for the entire subproject
22:29:18 <danwent> AlexNeef: subproject, i agree
22:29:36 <AlexNeef> entire subproject meaning all of netstack?
22:29:37 <adjohn> danwent: that's when you add more core devs, right?
22:29:44 <salv-orlando> "entire subproject" is a bit ambiguous
22:29:46 <AlexNeef> or seperate core-devs for quantum, dunabe, etc
22:29:59 <danwent> subproject == quantum
22:30:04 <danwent> subproject == donabe
22:30:05 <danwent> I think
22:30:47 <dendrobates> I suggest that we have one core dev group to encourage cross pollination
22:31:11 <debo_os> +1
22:31:17 <salv-orlando> +1
22:31:17 <danwent> adjohn:  yup.  I think the point is that once a project is bootstrapped, the responsibility for reviewing is not just on "everyone" but falls particularly on the "core-devs".
22:31:41 <adjohn> +1
22:31:47 <dendrobates> another option is that we make all initial participants core-devs
22:32:10 <dendrobates> that is basically what nova did
22:32:35 <dendrobates> we then culled the list later as some people did not want the responsibility
22:32:40 <AlexNeef> that sounds nice and democratic to me
22:32:53 <salv-orlando> dendrobates: that would probably be the only viable one if it comes up that LP requires a core team for the review process
22:33:29 <dendrobates> That worked for nova with no issues
22:33:45 <danwent> I'm fine with that, as long as people don't try to "pack" core-devs :)
22:34:11 <danwent> my assumption would be that if you're a core dev, you're actively working on a blueprint defined on the project?
22:34:20 <dendrobates> also, after the seeding new devs weren;t automatically core devs, regardless of what company they wotrked for
22:34:22 <danwent> or reviwing code?
22:34:30 <salv-orlando> danwent: I think the "seeding" dendrobates referred to was to avoid "packing"
22:34:38 <dendrobates> danwent: I agree
22:35:08 <danwent> great.  my only real concern here is that people are primarily concerned with getting code written, not "status" :)
22:35:19 <dendrobates> danwent: and they should be actual developers, not managers, or architects that will not conrtibute
22:35:36 <danwent> yes, code
22:35:54 <dendrobates> danwent: hopefully people will realize that it is a responsibility not a status
22:36:12 <danwent> yes, reviews are a great way to encourage this view
22:36:40 <dendrobates> nova has mandatory review days for core devs to remind them
22:37:26 <danwent> Great.  I'm fine for starting with everyone in as a core or no one in as a core, as long we keep this list closely in sync with reality
22:37:27 <AlexNeef> I think that's a good idea, a forcing function
22:37:57 <dendrobates> so can one person from each org make a list of the devs that should be added?
22:38:04 <dendrobates> I can take Cisco
22:38:11 <danwent> sure
22:38:20 <dendrobates> we should also keep it small
22:38:43 <danwent> agreed
22:38:44 <dendrobates> i.e Cisco should not list 50 dev
22:38:51 <debo_os> :)
22:38:52 <dendrobates> I think we should have a limit
22:38:55 <salv-orlando> I'd say: max(number_org,subprojects*2)
22:39:29 <somikbehera> so these devs should be reviewing as well as coding? if they are doing that I assume the list should be small...
22:39:45 <dendrobates> somikbehera: yes
22:40:07 <danwent> Ok, are we good on this topic?
22:40:14 <dendrobates> salv-orlando: can you take Citrix
22:40:23 <salv-orlando> dendrobates: yes
22:40:30 <dendrobates> and troy rackspace
22:40:37 <dendrobates> and who for midokura
22:40:49 <danwent> I'd love to get a chance to talk about some of the blueprints so people can get cracking on code.
22:40:56 <AlexNeef> I will do Mellanox
22:41:03 <hisaharu> I can take NTT
22:41:13 <AlexNeef> should we send names to rick again?
22:41:24 <romain_lenglet> dendrobates: at least me (romain_lenglet on LP)
22:41:52 <dendrobates> How about me and Dan
22:42:23 <dendrobates> That way if I fall into the Danube tomorrow dan can still make thechanges
22:42:32 <romain_lenglet> dendrobates: (actually my LP login is "romain-lenglet", sorry)
22:42:41 <danwent> I'm still a launchpad newbie, so please be careful rick :)
22:43:16 <dendrobates> danwent: you;ll get the hang of it  :)
22:43:46 <dendrobates> I think we can start asking ttx for admin help as well
22:44:11 <dendrobates> crap we talked about that for a long time.
22:44:11 <danwent> Ok, can we talk about blueprints really quick?  I want to give people a status update on the quantum stuff.
22:44:20 <dendrobates> #topic blueprints
22:44:27 <danwent> https://blueprints.launchpad.net/network-service
22:44:47 <danwent> We've defined a set of quantum blueprints, mainly based on discussions at the summit.
22:45:07 <danwent> troy from rackspace extracted a lot of "starter code" from glance for melange.
22:45:28 <danwent> we're looking to leverage that for quantum as well.  this is base code for wsgi, unit tests, etc.
22:45:42 <salv-orlando> Woops, I was doing the same thing :-)
22:46:19 <danwent> salv-orlando:  let's sync up on this.
22:46:35 <danwent> vish had some specific instructions about what to take/not take.
22:46:54 <dendrobates> I would like to revisit that with vish
22:47:03 <dendrobates> and make a case to take more
22:47:25 <dendrobates> danwent: oops, I'm talking about mellange
22:47:30 <danwent> for reference: https://code.launchpad.net/~rajarammallya/network-service/melange_framework
22:47:44 <danwent> this is the branch of what troy borrowed from glance.
22:47:53 <salv-orlando> where Vishy's instructions sent on the ML?
22:48:02 <danwent> somik is taking a crack as changing names, etc.
22:48:15 <danwent> most of them were at the summit on friday.
22:48:43 <danwent> rick, this was also discussed at the PTL meeting, right?
22:49:04 <vishy> termie and jaypipes are working on skeleton frameworks
22:49:05 <dendrobates> Not sure, I did not attend.  I'll ask ttx
22:49:06 <danwent> not sure if anything useful came out of that though.
22:49:13 <vishy> but I don't think they will be ready soon enough
22:49:22 * vishy is lurking :)
22:49:24 <danwent> :)
22:49:28 <danwent> much appreciated
22:49:58 <vishy> i would suggest getting started and if the skeletons make it soon, you can convert code over
22:50:06 <danwent> sounds good.
22:50:40 <danwent> salv-orlando: can you take a look at the stuff in the branch i sent out and see if it is compatible with what you were thinking?
22:51:03 <danwent> (its for melange, but we were planning on using much the same logic for quantum)
22:51:40 <danwent> I'd suggest we first focus on getting the API spec solid and make sure everyone is on board.
22:51:44 <salv-orlando> danwent: at a first glance all the common stuff (db, test, wsgi) is in that branch
22:51:52 <danwent> http://wiki.openstack.org/QuantumAPIBase#preview
22:52:14 <debo_os> for the API to be solidified it would be good to align with the use cases ...
22:52:27 <danwent> that's the current blueprint spec.  Basically copied from summit slides.  Salvatore's proposal is attached.  I think its a good place to start the feedback process.
22:52:49 <danwent> salv-orlando: do you have use cases in the doc?
22:53:21 <danwent> I remember some sample use cases at the end?
22:53:29 <salv-orlando> yes, they are still there
22:53:56 <danwent> hopefully we can expand on that as questions arise.
22:54:11 <danwent> I created a etherpad to track some feedback on had on the doc: http://etherpad.openstack.org/PbTpgXnnZZ
22:54:30 <danwent> not sure if there is a better way to do this (launchpad whiteboard did not seem to have a good notion of identify)
22:54:46 <danwent> identify -> identity
22:55:00 <AlexNeef> I asked salv for a word copy of the doc and was going to embed my ideas and comments
22:55:04 <dendrobates> danwent: no etherpad is better
22:55:22 <danwent> ok, let's go with etherpad.  Nice and public :)
22:55:27 <AlexNeef> is there a better way to do the review, i agree the white board is tricky
22:55:43 <danwent> AlexNeef: is etherpad ok?
22:56:02 <danwent> not as easy as MS word comments, i agree, but its hard for MS word comments to be public.
22:56:07 <AlexNeef> it's hard to refer to certain parts fo the document
22:56:28 <salv-orlando> I can convert the doc in a wiki page with anchors
22:56:29 <danwent> yeah, anyone have a good solution?  does google docs do comments?  could make it a public document?
22:56:41 <danwent> or that works.
22:56:45 <salv-orlando> so in the ehterpad you can put a link to the point of the doc you are referring to
22:57:02 <AlexNeef> The wiki route sounds good to me
22:57:02 <debo_os> http://docs.google.com/support/bin/answer.py?hl=en&answer=65129 It does
22:57:02 <dendrobates> salv-orlando: I think that will work well
22:57:15 <AlexNeef> then we are already generating documentation
22:57:21 <danwent> salv-orlando: if you're willing to do the work, it seems like a good solution.
22:57:56 <danwent> I think our API spec should eventually grow into a developer doc like http://docs.rackspacecloud.com/servers/api/v1.0/cs-devguide-20110415.pdf
22:58:07 <danwent> If you can only have to create it once, that might be a win.
22:58:25 <dendrobates> we should volunteer Eric to own that, he's good at it.
22:58:38 <danwent> Erik Carlin?
22:58:54 <danwent> or another eric/k?
22:58:57 <dendrobates> yes
22:59:09 <dendrobates> sorry, Erik C
22:59:25 <danwent> sounds reasonable.
22:59:42 <danwent> I'm also looking for people to stand up and take on additional blueprints.
22:59:53 <danwent> keystone integration, api extension model, etc.
23:00:10 <danwent> api clients (CLI + GUI), etc.
23:00:11 <dendrobates> danwent: cisco will probably take on some of that
23:00:29 <dendrobates> just let us know where the gaps are
23:00:35 <danwent> dendrobates: great, much appreciated.
23:00:58 <danwent> So please let you interest in working on areas be known, and I'll try to track what gaps still need to be filled.
23:01:26 <danwent> looks like we're about out of time.... I have a 4 o'clock meeting.
23:01:41 <danwent> other topics to discuss?
23:01:53 <dendrobates> by the way,  you can join the netstack team yourselves
23:01:55 <dendrobates> https://launchpad.net/netstack
23:02:05 <dendrobates> so everyone go and join
23:02:13 <dendrobates> it is open
23:02:36 <dendrobates> It's 1AM here, so nothing from me
23:02:44 <somikbehera> cool! team members gotta code and review code.. right? ;)
23:02:45 <AlexNeef> i don't see that option
23:03:02 <dendrobates> somikbehera: no this is the general team, anyone can join
23:03:09 <danwent> Thanks folks!
23:03:20 <dendrobates> https://launchpad.net/~netstack
23:03:21 <somikbehera> ah.. ic
23:03:24 <dendrobates> wrong URL
23:03:27 <dendrobates> sorry
23:03:34 <dendrobates> #endmeeting