What is the structure of the bridge URI? I might be interested in specifying the split of IP addresses across the bridge (e.g., 10.1.1.2-10.1.1.100 on the overlay, 10.1.1.101-10.1.1.254 on the VLAN). Will there be separate DHCP providers for the 2 segments? How about multiple bridged segments? Are there VMs controlled by CloudStack on the physical network ? (I assume this is a VLAN)
From: Hugo Trippaers <h...@trippaers.nl<mailto:h...@trippaers.nl>> Reply-To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" <dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>> Date: Thursday, March 13, 2014 at 2:32 AM To: "dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>" <dev@cloudstack.apache.org<mailto:dev@cloudstack.apache.org>> Subject: Re: [PROPOSAL] Bridge functionality On 11 mrt. 2014, at 21:51, Chiradeep Vittal <chiradeep.vit...@citrix.com<mailto:chiradeep.vit...@citrix.com>> wrote: Is there a more detailed writeup? I am interested in the api and Œflow’ No, no more details at the moment. Still thinking a lot on how i want it to work. I’m trying to get this as generic as possible so other SDN solution can benefit from the framework. The main components are : BridgeService (much like the FirewallService) that js responsible for handing the API commands and making sure that users can on attach a bridge to a network that has been whitelisted by an Admin. BridgeProvider (network element extension) that is responsible for implementing a bridge on a network, either triggered by the api (createBridgeCmd) or by an event (implement()). The elements would also be responsible for gathering the details for their specific bridge implementations, for example in the VMware NSX environment a bridge would need a gateway service ID. An internal OVS implementation would need an ovs bridge name. Admin api ======== AddBridgeUri( zone, domain, account, uri) <id> RemoveBridgeUri ( id) <success> User api ======= AddBridge(network, destination uri) <id> DeleteBridge(id) <success> Cheers, Hugo On 3/11/14, 7:12 AM, "Hugo Trippaers" <h...@trippaers.nl<mailto:h...@trippaers.nl>> wrote: Hey all, I¹ve been working on adding Bridge support to CloudStack. The use case is that with the introduction of SDN there is a need for us to link logical networks to physical hosts or physical networks. A typical use case would be to connect legacy infrastructure to cloud infrastructure, or to support cloud bursting from an existing infrastructure to a network in the cloud. Routing can sometimes be used to accomplish the same effect (for example the private gateway option in a VPC), but in some cases a L2 connection is preferred. The functionality would a central bridge manager in CloudStack. The bridge manager would have a number of admin only commands that link a number of networks to a specified domain or account. The user commands would allow an account to link a logical network to an external physical network. This separation is done to ensure users are never able to configure a bridge to a network they shouldn¹t have access to. Admins will have to make an external network available as a bridge destination and a user can select it. The network implementation will consists of a BridgeProvider element extension which elements can implement. It¹s up to the elements to configure the particulars of their bridge implementation. Initial implementation will cover the admin commands, user commands and an implementation in the VMware NSX plugin. UI is out of scope for the first implementation. Any feedback is welcome :D Cheers, Hugo
