OpenStack Havana Design started this morning, and eNovance team is here to attend it.
First of all, I was not surprised by the huge number of newcomers at the Summit since the community has grown so fast. For the first time, eNovance has a booth to present what we are doing. Thanks to Raphael (CEO & Co-founder), we have great pictures of today that you can see here.
Our engineers have followed most of the sessions today, and here are some reports that we want to share as we did for last summit in San Diego.
Upgrade from Grizzly to Havana
No magic here, either painful BIG upgrade or easy small hops, but needs strong (continuous) testing & automation.
It’s still currently hard to upgrade Openstack (even when following trunk) without some service interruptions.
Goals:
• allow to have components from version N coexist with components from version N+1 (APIs, message bus, etc. …)
• have minimal downtime during database migrations
Nova and Quantum : Gap status
I was happy to meet the new PTL of Quantum : Mark McClain working at Dreamhost.
A big part of the conversation was concerning Multi-host feature which is the most wanted in Quantum but not ready yet. Grizzly provides scheduling for getting multiple L3 & DHCP agents, but they are not working on the same way like the multi-host in nova-network. People is the room was wondering how things are going in Havana. No decision has been taken at this time and we still don’t know how to scale L3 in Quantum. The second part was focusing on the DNS part of Nova (which is actually not working quite good) : do we need it in Quantum ? Can we connect it to the existing project “Moniker” ? That’s those kind of questions that core developers were wondering today.
Quantum API Updates
The topics which have been mentioned are :
- Backward compatibility with OpenStack N-1 version
- Moving some extensions to core ? (i.e. L3) and also improving framework to optimize code
- New features : XML support, Pagination and Sorting
- New extensions : VPN, Edge firewalling
-
API transaction support
-
Proposal : for each service, have a core API for which we apply the same strict rules :Example: current core –> L2 corerouter, floating ips –> L3 corevips, pools, etc –> LB core <– (aaS dropped intentionally)
- Improve API documentation
What’s next for SDN ?
This session was a panel in which we had some participant from main SDN companies of today : BigSwitch, Midokura, NTT, NEC and Cisco.
About Overlay :
- Overlay and OpenFlow can coexist
- Customers need automation, OpenFlow stays an option
- Physical networks are still important. Overlay doesn’t solve all problematics
- We need switchs able to communicate with virtual network
- If you pick a plugin, you choose a SDN solution
- Plugins are changing, since Quantum and SDN solutions are growing
- We will be able to use different plugin at the same time with “metaplugin” in Quantum.
That’s it for today, I would like to thank Mirantis and Red Hat for the parties !
By the way, if you are at the summit, don’t forget to come at the booth to catch the official eNovance duck !
bonjour !merci pour le tuto :pour moi j’ai travaille9e avec les meame e9tapes sauf que j’ai eu le meame proble8me que Xbz Le pauqet openvswitch-datapath-source n’a pas pu eatre construit, │ voir /var/cache/modass/openvswitch-datapath-source*buildlog* pour plus de de9tailsje ne sais pas comment proce9der ?merci d’avance