22:02:41 #startmeeting 22:02:42 Meeting started Tue May 3 22:02:41 2011 UTC. The chair is dendrobates. Information about MeetBot at http://wiki.debian.org/MeetBot. 22:02:42 dendrobates: it would be good to have meeting minutes 22:02:43 Useful Commands: #action #agreed #help #info #idea #link #topic. 22:03:00 #topic LP project placement 22:03:24 Ok, as most of you know I created the Network-service project on Launchpad 22:04:00 My idea was to make it a project group that all of us could own and create subprojects below it 22:04:20 I thin there is value to us staying as a group during the early stages 22:04:26 agreed 22:04:30 +1 22:04:33 +1 22:04:36 +1 22:04:38 +1 22:04:43 agreed 22:04:47 but there is also the option of joining futurestack 22:04:57 all the incubation projects 22:05:06 What's futurestack? 22:05:10 Is network-service incubation project? 22:05:13 are they mutually exclusive? 22:05:14 er, I mean pre incubation projects 22:05:22 I was asked if we could keep the IPAM work in Nova, any objection for that component? 22:05:26 ramd: no it isn't 22:05:31 Can Network-service be in futurestack? 22:05:47 somikbehera: no, LP cannot do nested groups 22:05:57 I think that network will likely have a lot of touch points with other projects 22:06:11 would future stack give our work better exposure to other groups? 22:06:11 AlexNeef: agreed 22:06:12 Quantuma nd Donabe is a go for Diablo, right? 22:06:22 jlm^: https://launchpad.net/futurestack 22:06:40 ramd: they are not official openstack projects yet 22:06:42 I think melange as well is lined up for diablo 22:06:52 Melange is a lined up for Diablo as well 22:07:01 Melange == IPAM, right? 22:07:05 yes 22:07:09 troytoman: wouldn't IPAM be useful as a standalone project? Or are there reasons for that being in nova? 22:07:09 jlm^: yes 22:07:10 jlm^: yes 22:07:20 we need to be careful to follow the process correctly 22:07:46 there has been some push back from other projects not doing it correctly and I want to avoid that 22:08:02 adjohn: it would still be a separate service(s) but anotherjesse wanted to see it worked on within the nova project 22:08:11 so, what's the timeframe for the nova-related stuff: ipam and network refactoring? 22:08:13 still diablo? 22:08:28 troytoman: will it be a separate branch? 22:08:35 dendrobates: if we were in futurestack, is the idea that we would have separate projects within futurestack for quantum and donabe that would appear at the same level as something like atlas? 22:08:52 dendrobates: working out that detail (repo, branch) etc. 22:08:53 danwent: yes 22:09:26 romain_lenglet: since Diablo was extended to 6 months, I would hope so. 22:09:32 romain_lenglet: yes. we probably need to land the refactoring in an early milestone thought 22:09:41 I probably have a slight preference for using futurestack if it makes it easier for other people to see what we are doing. 22:09:42 ^though 22:09:42 troytoman: Error: "though" is not a valid command. 22:09:55 danwent: I am not sure that it does 22:10:18 and we can share some resources between us if we use our own project group 22:10:20 if melange stays is nova, I think there is no much sense in having Network-Service as a project group 22:10:22 dendrobates: I don't feel strongly here. 22:10:31 as melange will not be in it 22:11:04 It would also be a better fit for donabe, as it will include non-networking stuff eventually 22:11:07 I see, does future stack mean we wouldn't have our own bug system, etc? 22:11:08 I would imagine melange will have a lot of interaction with quantum right? 22:11:30 salv-orlando: that is a good point, but I don;t want to cede IPAM without discussing it more 22:11:36 danwent: each repo has it's own system 22:11:38 as would donabe - we really want to keep the source close 22:11:47 dendrobates: agreed 22:11:50 quantum and donabe will be tightly coupled 22:11:52 adjohn: ok, thanks. 22:12:07 anyway, we are not locked in to any decision 22:12:07 danwent dendrobates: Agreed....Quantum/Donabe/etc are more inter-related than, say, Atlas and RedDwarf. Might make sense to have them in a separate "container" rather than added in to FutureStack. But I also don't feel strongly. 22:12:12 To be honest, even though Melange won't be in it I like the idea of having a rallying point for all network stuff. This should make it easier for others to contribute ideas without everyone working in the dark. 22:12:31 carlp_: +1 22:12:40 Having a network-service help as we add more network related services 22:12:43 carlp_: +1 22:12:44 I expect the networking services to be added all the time 22:12:50 I think there is value in keeping a network focused project 22:12:58 dendrobates: +1 22:13:09 there is a lot to sort out there and a focused group is important. look what we were able to do in 1 week 22:13:15 sounds like consensus for a separate project? 22:13:15 ok, it seems we have a consensus, anyone strongly disagree 22:13:21 +1 22:13:25 can you sumarize the consensus 22:13:26 +1 22:13:30 I agree on a focussed group. +1 22:13:30 +1 22:13:39 +1 22:13:55 +1 22:13:58 That we will have a project group named Network services where we can put network services 22:14:05 proposed consensus is that we will have a separate lp 'network-service' group, as rick already created, rather than use futurestack. 22:14:06 great +1 22:14:25 I created it as a project, the LP admins will have to change it to a group 22:14:42 got it. 22:14:52 sorry if this is basic, but can you explain difference between project and group 22:14:57 I have much to learn about launchpad, i see :) 22:15:08 AlexNeef : +1 22:15:10 AlexNeef: groups can have sub projects 22:15:15 #action change network services to a group and create projects under it 22:15:39 #topic admin team 22:15:46 openstack is a group for example, nova is a project 22:15:52 we need to create a basic team to own the resources 22:16:28 I suggest we try to have one person from each group involved on the team 22:16:41 "group" ? 22:16:49 Are all others ready to seed a team today or we should wait till next week. 22:16:52 company 22:17:18 dendrobates: are you suggesting one team for the whole network service project? 22:17:22 this is not for development, just for ownership of the LP resources 22:17:31 I volunteer BTW what is the admin role 22:17:42 I volunteer too 22:17:49 romain_lenglet: we can have many teams 22:18:08 ok 22:18:09 this team is mostly about Launchpad maintainance 22:18:13 can we talk more about what resources need to be owned? 22:18:18 what are the responsibilities of this group? 22:18:53 the admins can edit the text of the project group, add new projects, and maybe a few other things 22:19:20 We will also need to create drivers 22:19:33 "drivers"? 22:19:44 is that a launchpad term? 22:19:48 drivers are responsible for approving blueprints and setting milestones and releases 22:19:51 you mean project drivers not the "drivers" ;) 22:19:51 yes 22:20:10 do we need a "network-service-core" team as well? 22:20:17 i see in futurestack it's the same group 22:20:26 it can be if we want 22:20:29 and the group can be as large as we want or there is a limitation? 22:20:54 we can also decide if we want separate or combined dev teams 22:21:06 it can be as large as we want 22:21:13 What I want to avoid is putting together some kind of structure just based on people volunteering vs. people contributing code :) 22:21:33 we can also just let openstack-admins own our project group 22:21:57 I think we have a rough outline of the blueprints we want to do from the summit and hopefully we can work together to refine the details. 22:22:07 danwent: I agree 22:22:33 we do have some things to setup, that have to have owners and maintainers 22:22:50 I want it to be owned by the group and not a single individual 22:23:05 dendrobates: agree 22:23:07 we can always add and subtract from the group later 22:23:50 I probably have the most LP knowledge because isetup a lot of the openstack groups and process. 22:24:01 Ok. I prefer to keep things as "flat" as possible for now. I think as people contribute real time and energy, work with each other and gain respect, etc. leadership will naturally emerge. 22:24:10 and in your knowledge we trust :-) 22:24:33 I'm fine with rick running things for LP for now.... he's a good guy :) 22:24:46 +1 ;) 22:24:48 +1 22:24:50 salv-orlando: +1 22:25:13 I would in the least like to create an admin team and add myself and Dan. 22:25:36 Or not me... I don't want this to look like anyone is "grabbing" anything. 22:25:44 Just in case I get hit by a bus 22:25:47 Rick at least has a history in the community. 22:26:04 I think you should add dan and others that are leading the sub-projects 22:26:05 danwent: more like volunteering you for more work ;) 22:26:12 we do need Fault tolerance 22:26:26 I'm fine either way. 22:26:35 it is both fault tolerance and volunteering. :) 22:26:51 somikbehera: for that we would need an admin in each continent to have 24/7 presence! 22:27:02 ok. i need to run to another meeting soon. other topics? 22:27:21 #topic next meeting 22:27:21 just want to give people a heads up that I have started adding blueprints along the lines of what we outlined on friday. 22:27:53 i think we should come to the next meeting prepared to discuss dev process and assignments 22:27:54 my goal is to have drafts up in advance of the next meeting so people can voice concerns and talk about what they want to work on. 22:28:01 ditto 22:28:09 sounds good 22:28:15 definitely want to keep the momentum going 22:28:17 agreed. 22:28:29 has everyone seen the wiki page I created? 22:28:44 http://wiki.openstack.org/Network/ 22:28:49 I have also started creating blueprints for melange and updating the the wiki with links 22:28:55 Adding few more BP palceholders as we speak 22:29:06 we can start adding info to the wiki 22:29:30 and there is a header with a link to a meeting agenda that we can all modify 22:29:38 great. 22:30:00 I will start all the LP magic. 22:30:16 Please use the wiki as much as possible 22:30:19 thanks dendrobates - the wiki is a good start to get everything ready for next week. 22:30:34 dan, which are the names for the blueprints you have registered? I can find the melange ones, but not the quantum blueprints 22:30:38 We can let danwent get to his meeting now. 22:30:59 Thanks for coming everyone, I am very excited to get to work. 22:31:10 do you guys see blueprints here: https://blueprints.launchpad.net/network-service 22:31:13 likewise! 22:31:22 perhaps its a permissions thing? Or i am putting them in the wrong place? 22:31:29 danwent: yep 22:31:31 quantum-api 22:31:33 I see them 22:31:35 is an example name 22:31:50 not done yet.... was just creating some during the main OS meeting :) 22:31:53 https://blueprints.launchpad.net/network-service/+addspec 22:32:01 I see them 22:32:07 that is the link to add a blueprint to network-service 22:32:19 ok. thanks guys. need to run. talk to you next week. 22:32:29 #endmeeting