On 11 mrt. 2014, at 21:51, Chiradeep Vittal <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> 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 >
