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 > >
-- Mailing list: https://launchpad.net/~netstack Post to : netstack@lists.launchpad.net Unsubscribe : https://launchpad.net/~netstack More help : https://help.launchpad.net/ListHelp
