Apologies for the incorrect link, the link should be: http://wiki.openstack.org/l3-service?action=AttachFile&do=view&target=qu antum-nova-parity-SumitNaiksatam-v3.pdf
From: Sumit Naiksatam (snaiksat) Sent: Tuesday, October 18, 2011 2:46 PM To: 'Dan Wendlandt'; netstack@lists.launchpad.net Subject: RE: [Openstack] Announcing Nova subteams Hi, Following up on the topic of nova-network parity, we also wanted to continue the discussion around how the proposed L3 service can be leveraged to achieve this. We have posted a very preliminary flow in the document here: http://wiki.openstack.org/quantum-multi-switch-plugin?action=AttachFile&; do=view&target=quantum-multiswitch-plugin-SumitNaiksatam.pdf Kindly take a look and comment, we can also bring this up during the IRC meeting today. Thanks, ~Sumit. From: openstack-bounces+snaiksat=cisco....@lists.launchpad.net [mailto:openstack-bounces+snaiksat=cisco....@lists.launchpad.net] On Behalf Of Dan Wendlandt Sent: Monday, October 17, 2011 6:08 PM To: Trey Morris Cc: openstack (openst...@lists.launchpad.net) Subject: Re: [Openstack] Announcing Nova subteams On Mon, Oct 17, 2011 at 3:14 PM, Trey Morris <trey.mor...@rackspace.com> wrote: I notices a gap -> networking Noticed that as well :) During Essex the Quantum team will be making some non-trivial changes to the nova network manager code to work better with Quantum (in fact, the first review should hit tonight, I believe). See below for more info. We definitely want to coordinate with anyone else who may be making changes in this area. I believe some of the work by the "Nova Feature Parity Team" may fall in this bucket as well. Dan Two main goals with Quantum in Essex are: 1) create/improve functional, integration, and scale testing to support targeted production deployments. 2) provide "nova network parity" in that any use case possible with nova networking should be possible with Quantum as well (there are currently large gaps). The basic model of integrating with Nova will be the same as in Diablo: running Nova with a standard Network Manager will continue to work, but running it with QuantumManager will leverage Quantum + Melange. To start, Quantum will just leverage the existing Nova "gateway" implementation (DHCP, Floating IP, NAT, etc). , allowing them to be "plugged" into Quantum networks just like Nova vNICs. Major areas for nova parity include: - DHCP integration: pretty simple, but requires some small changes to generalize functionality in linux_net.py and changes to QuantumManager - Floating IPs: the quantum manager class needs to implement the floating IP python interface. may need to tweak floating IP code in manager.py to generalize it a bit so quantum can leverage it with melange. I think there's a good amount of work here, particularly if we plan on using melange to store floating IP info. - L3 gateway + NAT: similar to what is required for DHCP. - Security groups: security groups as implemented with iptables or libvirt won't work with either of the existing Quantum plugins. We'll actually need a way of letting Quantum implement security groups as well. This will likely amount to generalizing the ec2 api implementation to either be able to use a Nova implementation of security groups, or forward requests to a Quantum security groups API. - cloudpipe VPN: now that tenants can have multiple networks, with QuantumManager we'll need to add an optional flag to specify that a VPN VM should be spun up on a particular network. I don't see a ton of work here. On Mon, Oct 17, 2011 at 12:56 AM, Vishvananda Ishaya <vishvana...@gmail.com> wrote: Hello Everyone, I've been assimilating the plans from the design summit into blueprints. In the process i've noticed that we have a lot planned for the next few months. Some of these changes are quite large and involve people from many different companies that are working on openstack. In order to facilitate feature work over the next few months, I've decided to create a number of subteams. There is too much work going on in nova to manage everything in one large group, so for sanity's sake, I'm attempting to break the work up into manageable chunks. The subteam idea is experimental. We will try it for the first two milestones and re-evaluate after e2 whether we need to make some further changes. My vision is that each subteam is an open group where interested parties can communicate and plan features. Some of the teams will initially be more research oriented, but ultimately these teams will be focused on implementation. Each team will have a 'lead' which will function as a point of contact for the nova PTL. I'm currently on all of the teams, and I will do my best to keep track of work going on in all parts, but I may need to depend on the lead for help with scheduling and planning. A rough outline of the teams responsibilities are: * Planning new features related to the specific area of focus * Congealing plans into specific blueprints * Targeting blueprints to milestones * Assigning blueprints to specific individuals or groups * Triaging bugs related to the specific area of focus * Reviewing any code submissions related to the specific area of focus I want to keep these teams very lightweight; we don't need more unnecessary process and overhead. I've created launchpad teams for all of the major areas, and each of these teams has a mailing list. I'm not sure that communication over these mailing lists is the best option, but we need a way to get things started. The launchpad teams are all open, so if any of the areas interest you, please join the team and subscribe to the mailing list. I'm going to start by assigning all related blueprints to each team. The teams will then re-assign blueprints to individuals as needed. I will work with all of the teams to target these blueprints to specific milestones. Any blueprints that don't fit under a particular team I will manage separately. I'm also going to attempt to do the same with bugs as they come in. Help triaging bugs is of course always appreciated. Here is a list of teams, including a link to the launchpad page and a short description: Nova API Team https://launchpad.net/~nova-api All things api related, with special focus on additional features and cleanup of the openstack api. lead - bcwaldon Nova Database Team https://launchpad.net/~nova-database Cleanup of the db layer, DB testing, alternative backends lead - _0x44 (unconfirmed) Nova Scaling Team https://launchpad.net/~nova-scaling Distributed zones, aggregation, geographically diverse zones. lead - comstud Nova Orchestration Team https://launchpad.net/~nova-orchestration Orchestration, workflow management for requests, state machine for recovery lead - sandywalsh Nova Upgrades Team https://launchpad.net/~nova-upgrades Seamless upgrades for nova. Some research and planning still needs to be done here. lead -rjh Nova Feature Parity Team Full feature parity for xenapi and libvirt/kvm. Includes user facing parity issues like common images. https://launchpad.net/~nova-feature-parity lead - sleepsonthefloor Openstack Volumes Team https://launchpad.net/~openstack-volume Volumes api, drivers, scheduling, zone support. lead - renuka Nova Auth Team https://launchpad.net/~nova-auth Code for Authorization checking in nova and integration with Keystone. Planning is pretty much done here, but it will touch a lot of the code, so we could use a few people focusing on it. Team is primarily to help collect volunteers. lead - vishy Nova Security Improvements Team Planning for security improvements to nova. Due to the large number of code changes being worked on in essex, we aren't planning on locking things down completely in the next six months. This will likely be mostly planning in the essex time frame, with actual implementations to hit in F. https://launchpad.net/~nova-security-improvements Security lead - rjh Nova Operational Support Team https://launchpad.net/~nova-operations Collecting requirements from operational groups and generating tooling and admin apis for operations. This seems like a very important team, but I don't have someone to head it up yet. Volunteers requested lead - (no lead yet) Nova Testing Cleanup Team https://launchpad.net/~nova-testing We have discussed cleaning up the unit tests and separating out integration tests for a while, but this needs a specific team to focus on it. We need volunteers and a lead. lead - (no lead yet) Once again, please join any teams that you have a stake in. If you are contributing code to one of these areas, please communicate with the team to make sure that you are not duplicating work. Each team is more than welcome to find other ways of communicating, but please keep discussions open as much as possible. The Openstack Volumes team, for example, is meeting regularly in irc. Expect to see all relevant blueprints assigned to teams over the next day or two. Good luck and thanks to everyone for the hard work. Vish _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openst...@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp _______________________________________________ Mailing list: https://launchpad.net/~openstack Post to : openst...@lists.launchpad.net Unsubscribe : https://launchpad.net/~openstack More help : https://help.launchpad.net/ListHelp
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
