openstack team mailing list archive

[Dan Wendlandt <dan@xxxxxxxxxx>]

On Mon, Oct 17, 2011 at 3:14 PM, Trey Morris <trey.morris@xxxxxxxxxxxxx>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 <
> vishvananda@xxxxxxxxx> 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     : openstack@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~openstack
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
> _______________________________________________
> Mailing list: https://launchpad.net/~openstack
> Post to     : openstack@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~openstack
> More help   : https://help.launchpad.net/ListHelp
>
>