Dan, I think the distinction between ‘shiny’ and ‘community’ is just fantastic!
I would like to join Dan in stressing the important of the ‘community’ list, adding that most of the things in the list below are probably “conditio sine qua non” for getting into core. During the Folsom release cycle we will definitely see many teams work on the ‘shiny’ things, but it would be great to see the same teams contributing also to ‘community’ activities, which include not only the task list reported below, but also code reviews, and writing documentation. 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/) So it might be a good idea to register blueprints and write a summarized specification for each community project that does not yet have one, and tag them appropriately (something like quantum-community). Our goal would be to make sure that by the Folsom summit, each of these blueprints has an assignee. I can volunteer for this task. Some comments on community projects: - improve system test / devstack / tempest - quantum authn + authz (yes, we still do not have basic API auth) This is killing me ☹. We had the middleware pushed in keystone source tree, but then it went away, and unfortunately I lost track of it. At a first glance (no pun intended) we can now be good just with the basic auth middleware. I know Deepak is working on it, hopefully we will hear from him soon. - 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) Our CLI is not bad, but we have been doing things in our own way, which is quite unacceptable if we are going into Openstack core. Do not underestimate this task, as it will probably turn out to be quite a rewrite of quantum-pythonclient! - reworking of quantum / nova integration (remove dependence on nova db, etc.) My gut feeling on this is will not be trivial at all, and will probably have melange integration as a requirement. Also, it would be great to see if we could further loose the coupling between nova and quantum, by finding a solution for not having plugin-specific VIF drivers for instance. This is probably less important anyway. - better model for learning what extensions are supported by the currently running plugin. I actually looked at the extension framework at the beginning of the Essex release cycle, and noted down several things that were in need of improvement/alignment with the current API framework. I will put this down in writing as it might hopefully help devs which will pick this task. - quantum + horizon GUI flow (and framework for widgets that use API extensions). - melange / quantum integration - DHCP API / service As much as I loved the spec I saw for the DHCP service a while ago, I would probably put this in the shiny things list. And I reckon this other tasks need to make the list of the community projects: - API usability improvements: We did not went as far as expected in the Essex release cycle towards getting fully RESTified. We did non merge the pagination feature, because we realized it broke the client, and we would like to see ATOM links to Quantum resources in responses. These things, despite not adding any functionality to the API itself, simplify writing clients for Quantum, and are therefore very valuable. - API Rate limiting (or similars). This can be as easy as borrowing the rate limiting middleware from other Openstack projects, or we could just work on it in the framework of Openstack-common Regards, Salvatore From: netstack-bounces+salvatore.orlando=eu.citrix....@lists.launchpad.net [mailto:netstack-bounces+salvatore.orlando=eu.citrix....@lists.launchpad.net] On Behalf Of Duncan McGreggor Sent: 13 March 2012 03:23 To: Dan Wendlandt Cc: netstack@lists.launchpad.net Subject: Re: [Netstack] quantum community projects & folsom summit plans Great stuff, Dan -- thanks! I've added the bug link from below to the PyCon sprint wiki page -- Mark McClain might be able to start hitting some of those tomorrow ... d Sent from my iPhone On Mar 12, 2012, at 4:10 PM, Dan Wendlandt <d...@nicira.com<mailto: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<mailto: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
