Hi Dan 

 

Thanks for the *very* detailed/good starter list .... Gr8!

 

Initial thoughts 

·         For the nova integration (avoid db access) - maybe we should revisit 
the nova network API to see if the L3 and services API needs to be out there 
since nova is the ultimate consumer of both L2, L3, services (assuming nova is 
the only entity creating network elements in this case). If folks feel its 
important, we might want to add another bullet point. 

·         Isnt the mélange/quantum integration related to the shiny L3 bullet? J

·         Instead of VPN and DHCP as separate services, do you think it might 
make sense to have a single services work item where we figure out the common 
services API which are then implemented by both the DHCP and the VPN services 
(they would also have their specific API). This is also related to the nova 
integration. 

 

Regards

Debo~

 

From: netstack-bounces+dedutta=cisco....@lists.launchpad.net 
[mailto:netstack-bounces+dedutta=cisco....@lists.launchpad.net] On Behalf Of 
Dan Wendlandt
Sent: Monday, March 12, 2012 4:11 PM
To: netstack@lists.launchpad.net
Subject: [Netstack] quantum community projects & folsom summit plans

 

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

Reply via email to