On Wed, Mar 21, 2012 at 8:31 AM, Salvatore Orlando < salvatore.orla...@eu.citrix.com> wrote:
> > > As regards new features, there has been plenty of proposals on this > threads! I think the first step here is the integration with Melange; then > we should review the L3 service API proposed by Sumit. I would also like to > see an API proposal for L2/L3 service insertion, if any. Going to the > summit with a concrete API proposal is probably the most important step for > ensuring that particular thing will be in trunk by the end of the release > cycle. We should probably consider having a pre-summit meeting over the > phone/IRC or even F2F as we did for the diablo summit, what's your opinion? > Definitely agree that coming to the summit with concrete proposals is key. I'm trying to identify one or more "drivers" for each of these topics, and that driver will be responsible for coming to the summit with a concreate proposal. I think it would be hard to organize a F2F meeting, but I am definitely planning on using our IRC meetings to help refine the set of topics and make sure people are covering all of the important items. IRC is less well suited to actual design discussions though... My goal on that end is to have people send proposals to the ML prior to the summit, so hopefully we can at least review them ahead of time and try to get familiar with key differences. At the summit, of course the trick is to quickly identify key differences between proposals and try to hash out the differences : ) > Also, I haven't seen much proposals around a security group / distributed > firewall API. I reckon this is a rather interesting feature, spanning > several layers of the ISO/OSI stack, and open to an indefinite number of > design alternatives. Also the current implementation of security groups in > nova is managed by nova-compute rather than nova-network, and that makes > things even more interesting? Will there be any team coming up with an API > spec for security groups at the Folsom summit? > Yup, definitely. I mistakenly left that off the list, but Vish and I have talked about the need for this to move from Nova to Quantum. Given that we need to at least have parity with Nova's features in Folsom, I prefer to separate out security groups (which are a pretty well defined entity) from generic firewalling discussions. > Also, another thing I would to bring to your attention is that once > Quantum will extend beyond basic connectivity, we are likely to have > several plugins. How can we ensure they are all compatible? For instance > how can I know the "Foobar" L3 plugin will work with the LinuxBridge L2 > plugin but not with the OVS plugin? > I've actually been thinking about this a bit as well. I think one of the key discussion points on the L3-forwarding discussion is whether separate pluggability makes sense. I was originally a big fan, but I'm worried it may significantly increase complexity for users, for exactly the reason you mention. > > For the overall architecture of Quantum, there are still a few > outstanding issues that needs to be addressed. Some of them, such as > becoming independent from the nova db, have already been mentioned. > Other aspects we might want to improve: > * The Quantum Manager: I think there's general agreement that most > of the features it currently provides should progressively be moved into > Quantum. In the long run, the Quantum manager should probably be regarded > more as a proxy for the Quantum API. > Yup, this will be covered by the nova/quantum integration section. Based on input from Vish, I think the integration may not even use nova-network anymore, and instead have nova-computes network.API() calls go directly to Quantum. > * VIF drivers: they are currently hypervisor-specific and > plugin_specific. It would be probably smoother if we just instructed the > compute service to plug its vif(s) in some specific bridge(s), and letting > Quantum perform all the necessary configuration on such bridges. > Yeah, this is a sticky issue, and I'm not sure there's a simple answer here. I wouldn't say that vif-drivers are plugin specific. For example, there are several plugins that all use the same OVS-driver. They are really specific to the type of vswitch (or lack there of in the case of VEPA/VNTag) that is being used. I completely agree that plugin-specific logic should be avoided here when possible, but if libvirt permits lots of different ways of creating VIFs and attaching them to vswitches, users will want that configurability. > * Internal APIs interfaces: this used to be quite a hot topic in the > first days of Quantum. The question basically is whether Quantum needs to > interact with the 'interface service' (nova compute in this case). We are > currently avoiding this with VIF drivers and plugin agents. While I find > the latter very useful (altough their current implementation does not look > scalable at all to me), I would consider studying a solution for getting > rid of the former, and maybe have nova-compute expose some APIs (more at > the RPC layer rather than at OS/EC2 layer) that Quantum might use. > I'm glad you raised this. A while back I chatted with folks on the nova side about how to expose things like creating and adding interfaces to VMs. My feeling on this is that there really isn't a need to have a separate notion of a vNIC and a Quantum port, or to have the explicit "plug" in the API. Instead, the connection between a Nova virtual server and a Quantum network could just be represented by a port. This is inline with what Amazon does for elastic network interfaces (ENI). I'll create a note that we should talk about this at the summit. Either way, there's still a need for nova + quantum to communicate, but it simplifies the problem, as Quantum no longer needs to determine who "owns" an interface. Instead, its just that Nova needs to communicate the vswitch port that corresponds to a particular quantum port. You're correct that right now this is tied to vif-plugging, but we could definitely consider making a standard API to have a service like Nova report the location. I think such information would be generally useful (e.g., for debugging). > > And finally, refactoring. The current split between quantum and > python-novaclient is not really optimal. It is my opinion the first goal > should be to ensure python-quantumclient is not anymore a dependency for > quantum. > Yup, I have that as a community project already, and couldn't agree more :) > > Oh, and then there's the whole testing story... > So far I have items for: - system test / devstack / tempest testing for Quantum - scale testing. Are there major improvements to the unit testing that we need? Might be cool to do a quick session on code coverage and areas where we need better coverage. Thanks for all the great input! Dan > > Regards, > Salvatore > > > -----Original Message----- > > From: netstack- > > bounces+salvatore.orlando=eu.citrix....@lists.launchpad.net > > [mailto:netstack- > > bounces+salvatore.orlando=eu.citrix....@lists.launchpad.net] On Behalf > Of > > Troy Toman > > Sent: 21 March 2012 15:05 > > To: netstack@lists.launchpad.net > > Subject: Re: [Netstack] quantum community projects & folsom summit plans > > > > We would also like to cover some topics that relate to running Quantum at > > scale. This would include API rate limiting and caching, understanding > the > > models for scaling out the service and where we should make things more > > asynchronous (or not) to enable increased throughput. > > > > As far as votes for items already on Dan's list - Quantum/Melange > > integration, Quantum/Nova rework, authn/authz are very important from a > > Rackspace perspective. We would love to dig into these further at the > > summit. We'll be increasing our dev participation across the board. So, > we'll > > have several people engaging on these topics. > > > > Troy > > > > On Mar 20, 2012, at 11:18 PM, Sumit Naiksatam (snaiksat) wrote: > > > > > Hi Deepak, and All, > > > > > > I feel this is very good dimension to factor in while prioritizing > which tasks > > to take up for Folsom - what are the consumers of the Quantum service > > asking for? Not to say that any, or all of what has already been > mentioned in > > this thread is not driven by requirements; I am sure everything is very > well > > thought out and merits consideration. But just trying to make a point > that it > > would be nice to hear more from current/potential Quantum users as to > > what their burning needs are (probably restating the obvious, and pardon > > me! :-)). > > > > > > Thanks, > > > ~Sumit. > > > > > > > > > > > >> -----Original Message----- > > >> From: netstack-bounces+snaiksat=cisco....@lists.launchpad.net > > >> [mailto:netstack-bounces+snaiksat=cisco....@lists.launchpad.net] On > > >> Behalf Of Deepak Garg > > >> Sent: Tuesday, March 20, 2012 8:09 PM > > >> To: Edgar Magana (eperdomo) > > >> Cc: netstack@lists.launchpad.net > > >> Subject: Re: [Netstack] quantum community projects & folsom summit > > >> plans > > >> > > >> HI All, > > >> > > >> I didn't find IPv6 support in Dan's list of community and shiny > > >> projects. > > >> > > >> a. Do we have complete IPv6 support -> all features working well in > > >> IPv6 with appropriate tests written for the same ? > > >> b. If not where does it lie in the priority list ? > > >> > > >> I know that there is some demand for IPv6 in the cloud industry. > > >> > > >> > > >> Deepak > > >> > > >> > > >> > > >> > > >> On Wed, Mar 21, 2012 at 2:06 AM, Edgar Magana (eperdomo) > > >> <eperd...@cisco.com> wrote: > > >>> Hi Folks, > > >>> > > >>> > > >>> > > >>> Last summit we presented a session about Network Services Insertion > > >> were the > > >>> community supported the fact of having some orchestration > > mechanisms > > >> to > > >>> incorporate L2 services within Quantum. In Essex our team > > >>> implemented > > >> a > > >>> library to insert "In-path" network services under the Cisco PlugIn > > >>> (quantum/plugins/cisco/services). We would like to extend this > > >>> implementation covering the following aspects: > > >>> > > >>> > > >>> > > >>> - Service insertion utility supporting all available PlugIns > > >> and > > >>> coming L3 features > > >>> > > >>> - Moving the code from Quantum Server to Quantum Client > > >>> > > >>> - Include "Out of path" network services (It could include > > >> some L3 > > >>> functionality or not and that is the part that we would like to > > >> discuss) > > >>> > > >>> - Any open ideas from the community. > > >>> > > >>> - Removing the DB dependency (or not?) > > >>> > > >>> > > >>> > > >>> I already registered a brainstorming session to go over this points > > >> and find > > >>> out if the community is interested on this and how we can include > > >> more > > >>> available open services. > > >>> > > >>> This is the link of the proposal: > > >>> http://wiki.openstack.org/QuantumServicesInsertion > > >>> > > >>> > > >>> > > >>> I would like to hear your points of view about this and hopefully > > >> have a > > >>> great discussion during the summit if that is the case. > > >>> > > >>> > > >>> > > >>> Thanks, > > >>> > > >>> > > >>> > > >>> Edgar > > >>> > > >>> > > >>> > > >>> From: netstack-bounces+eperdomo=cisco....@lists.launchpad.net > > >>> [mailto:netstack-bounces+eperdomo=cisco....@lists.launchpad.net] > > On > > >> Behalf > > >>> Of Dan Wendlandt > > >>> Sent: Tuesday, March 20, 2012 11:52 AM > > >>> To: hitesh wadekar > > >>> Cc: netstack@lists.launchpad.net > > >>> Subject: Re: [Netstack] quantum community projects & folsom summit > > >> plans > > >>> > > >>> > > >>> > > >>> Hi folks, I'd like to see some more responses to this thread, so we > > >> can make > > >>> sure that we as a community collectively decide on what are the most > > >>> important topics to cover at the summit. Having buy-in from the > > >> whole team > > >>> is important, as we'll really need to focus our resources to > > >> accomplish what > > >>> we need to do to become core in Folsom. Thanks! > > >>> > > >>> > > >>> > > >>> Dan > > >>> > > >>> On Tue, Mar 13, 2012 at 6:19 PM, hitesh wadekar > > >> <hitesh.wade...@gmail.com> > > >>> wrote: > > >>> > > >>> Hi Dan, > > >>> > > >>> I completely agree with Salvatore comments on (Quantum has an awful > > >> lot of > > >>> potential, but to put in Dell's Rob Hirschfeld words: "potential > > >> means > > >>> you've got to keep working on it." (see his post on Quantum: > > >>> http://robhirschfeld.com/2012/02/08/quantum-network-virtualization- > > >> in-the-openstack-essex-release-2/)) > > >>> > > >>> I would like to join NetStack team for fixing bugs and community > > >> projects > > >>> > > >>> As I am new to Quantum, hence I will start first to fix low hanging > > >> fruit > > >>> bugs. so that I will be acclimatized Quantum environment. once I > > >> build a > > >>> rapo then I will fully involve in you listed community projects. > > >>> > > >>> > > >>> Along this I would like to explore OVS and feature enhancement for > > >>> it > > >> in > > >>> Quantum-plug in and agent. While installing Quantum using DevStack > > >>> I > > >> have > > >>> been encountering with OVS packaging issue for Ubuntu oneiric and > > >> this is > > >>> the existing bugs reported on Ubuntu launchpad. I feel we should > > >> handle such > > >>> issues in DevStack. > > >>> > > >>> Quantum is truly networking project, while working on this, I am > > >>> 100% > > >> sure > > >>> that I will be enjoying to brush up and improve my networking skills. > > >>> > > >>> Thanks all for support. I am looking forward to guidance and > > >> encourage from > > >>> Netstack as well as OpenStack community. > > >>> > > >>> I am looking forward challenging and excitement work from Folsom. > > >>> > > >>> Thanks Dan and NetStacker, > > >>> Hitesh Wadekar > > >>> > > >>> On Mon, Mar 12, 2012 at 4:10 PM, Dan Wendlandt <d...@nicira.com> > > >> wrote: > > >>> > > >>> Hi team, > > >>> > > >>> > > >>> > > >>> As we start to look forward to Folsom, I know there will be a lot of > > >>> excitement around shiny new directions we can take Quantum (L3, > > >> VPN/DCI, > > >>> etc.). This is great, and we will be moving in this direction > > >>> during Folsom. I know many people are looking to participate here. > > >>> > > >>> > > >>> > > >>> But I also want to stress the importance of also focusing on less > > >> shiny > > >>> tasks that are central to building a solid and usable platform. To > > >> this > > >>> end, I wanted to highlight a link I sent out during last weeks > > >>> meeting: http://wiki.openstack.org/QuantumStarterBugs > > >>> > > >>> > > >>> > > >>> This page has a pointer to low-hanging fruit bugs as well as a list > > >> of > > >>> "community projects" that are not necessarily shiny, but are > > >>> critical > > >> to the > > >>> progress of the project. This includes things like improving the > > >> CLI, > > >>> integrating with Horizon/Keystone, building a system test > > >> infrastructure, > > >>> updating documentation, multi-host devstack, etc. > > >>> > > >>> > > >>> > > >>> In many cases, these are items that we targeted for Essex, but > > >>> didn't > > >> have > > >>> sufficient core dev resources to tackle. With Quantum becoming core > > >> in > > >>> Folsom, we can't afford to have that happen again, as expectations > > >> around > > >>> Quantums usability, robustness and integration with other projects > > >> will be > > >>> much higher in Folsom than it was for Essex. > > >>> > > >>> > > >>> > > >>> I encourage others to add items to this page as well. My general > > >> rule is > > >>> that something is a community project if its unlikely that someone > > >>> is > > >> doing > > >>> the work to enable something for their platform/company. As a hint, > > >> if a > > >>> bunch of people who express interesting in working on something, its > > >>> probably not a community project. If people have been saying "hey, > > >> someone > > >>> should really fix/improve X" for a while, the fix would help just > > >> about > > >>> everyone, but no one has yet stepped forward, its probably a > > >> community > > >>> project :) > > >>> > > >>> > > >>> > > >>> So in sum, as an open source project, we must make sure everyone is > > >>> encouraged and rewarded for working on core community projects. I > > >> also want > > >>> to make sure sufficient time at the summit is dedicated to how we > > >> will > > >>> progress on both community projects. > > >>> > > >>> > > >>> > > >>> Since we will soon be able to register sessions for the Folsom > > >> summits, I'd > > >>> like people to chime in on the list for what they think are the most > > >>> important "community projects", as well as "shiny objects" for us to > > >> discuss > > >>> at the summit. Hopefully this will make the process of designing > > >> sessions > > >>> more collaborative and community-driver, rather than a game of "I > > >> better try > > >>> and register the session on X before someone else does". > > >>> > > >>> > > >>> > > >>> Here are some initial thoughts: > > >>> > > >>> > > >>> > > >>> community projects: > > >>> > > >>> - improve system test / devstack / tempest > > >>> > > >>> - quantum authn + authz (yes, we still do not have basic API auth) > > >>> > > >>> - better integration with openstack CI team (we want automated > > >> smoketests to > > >>> run on each check-in) > > >>> > > >>> - quantum CLI / client improvements. (many changes needed to be > > >>> more > > >> inline > > >>> with other core projects) > > >>> > > >>> - reworking of quantum / nova integration (remove dependence on > > nova > > >> db, > > >>> etc.) > > >>> > > >>> - better model for learning what extensions are supported by the > > >> currently > > >>> running plugin. > > >>> > > >>> - quantum + horizon GUI flow (and framework for widgets that use API > > >>> extensions). > > >>> > > >>> - melange / quantum integration > > >>> > > >>> - DHCP API / service > > >>> > > >>> > > >>> > > >>> shiny objects: > > >>> > > >>> - L3 API > > >>> > > >>> - VPN / data-center-interconnect > > >>> > > >>> - firewalling / security groups. > > >>> > > >>> > > >>> > > >>> Please reply with your own input. Thanks, > > >>> > > >>> > > >>> > > >>> Dan > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> -- > > >>> Mailing list: https://launchpad.net/~netstack > > >>> Post to : netstack@lists.launchpad.net > > >>> Unsubscribe : https://launchpad.net/~netstack > > >>> More help : https://help.launchpad.net/ListHelp > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> > > >>> -- > > >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > >>> Dan Wendlandt > > >>> > > >>> Nicira Networks: www.nicira.com > > >>> > > >>> twitter: danwendlandt > > >>> ~~~~~~~~~~~~~~~~~~~~~~~~~~~ > > >>> > > >>> > > >>> > > >>> > > >>> -- > > >>> Mailing list: https://launchpad.net/~netstack > > >>> Post to : netstack@lists.launchpad.net > > >>> Unsubscribe : https://launchpad.net/~netstack > > >>> More help : https://help.launchpad.net/ListHelp > > >>> > > >> > > >> > > >> > > >> -- > > >> > > >> Deepak Garg, > > >> Data Center and Cloud Div. > > >> Citrix R&D, India > > >> Skype-id: deepakgarg.iit > > >> > > >> -- > > >> Mailing list: https://launchpad.net/~netstack > > >> Post to : netstack@lists.launchpad.net > > >> Unsubscribe : https://launchpad.net/~netstack > > >> 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 > > > > > > -- > > Mailing list: https://launchpad.net/~netstack > > Post to : netstack@lists.launchpad.net > > Unsubscribe : https://launchpad.net/~netstack > > 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 > -- ~~~~~~~~~~~~~~~~~~~~~~~~~~~ Dan Wendlandt Nicira Networks: www.nicira.com twitter: danwendlandt ~~~~~~~~~~~~~~~~~~~~~~~~~~~
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
