> On March 6, 2014, 10:09 a.m., daan Hoogland wrote: > > Are you contemplating redundant routing on a per network basis? It would > > seem to me that the router, hence the whole vpc with all it networks is > > redundant or not.
The description below is what my initial code is working toward: Turn on VPC redundancy and allow user to do CRUD to the networks just as it is now.( Create guest networks:NICS, etc; Read guest networks:NICS,etc; Update guest networks:NICS,etc; Delete guest networks:NICS,etc) Because redundancy is turned on, the master AND backup router VM's, as well as services conntrackd and keepalived running on those router VM's are part of the creating, reading, updating and deleting of the guest networks. I am making these changes IN ADDITION to the existing functionality. I do not want to break what exists when the redundant routing to VPC's is added, so yes, in that sense I am trying to keep VPC's and standalone networks aligned. Currently, in a VPC, a SINGLE router is available without redundant routers. In a VPC, guest networks can be created, read, updated, deleted (CRUD) but without any redundancy only one router VM needs to be updated. With redundancy in VPC's both a master and backup router VM's need to be changed as well as supporting services conntrackd and keepalived need to be (re)configured when guest networks are created, read, updated and deleted. In contrast to VPC's the CloudStack standalone (public) networks currently offer a redundant network topology which is static so the redundant topology is created once. If CRUD changes need to be made the routers are deleted and created again with the changed configuration; individual networks are never created or deleted. A bit more detail: I understand redundancy is either in the VPC or not. In other words ALL guest networks within a VPC either have a redundant path or they do not. Currently there is CRUD for VPC guest networks, you can create, read, update and delete a guest network in a VPC, however VPC's do NOT have the ability to offer a redundant path to the guest networks. My additions to the code are an initial attempt to adapt the existing network CRUD functionality to a VPC which has a redundant path for all the guest networks. When the VPC has redundancy turned on and one creates, reads, updates or deletes a guest network, both the master and backup router configuration need to be altered based on what is being changed. When the VPC has redundancy turned on the conntrackd and keepalived services need to be reconfigured and possibly stopped and started when a guest network create, update or delete takes place. - Karl ----------------------------------------------------------- This is an automatically generated e-mail. To reply, visit: https://reviews.apache.org/r/18795/#review36352 ----------------------------------------------------------- On March 5, 2014, 8:20 p.m., Karl Harris wrote: > > ----------------------------------------------------------- > This is an automatically generated e-mail. To reply, visit: > https://reviews.apache.org/r/18795/ > ----------------------------------------------------------- > > (Updated March 5, 2014, 8:20 p.m.) > > > Review request for cloudstack. > > > Repository: cloudstack-git > > > Description > ------- > > Changes/additions to BASH scripts and .java files as well as pseudo code > comments. This posting is a sanity check review posting; before I get too far > along with making the changes required for this JIRA CloudStack-764 nTier > Apps 2.0 : Redundant Virtual Router for VPC I thought I'd publish my > intentions to the community to review and comment. > > > Diffs > ----- > > core/src/com/cloud/agent/api/SetupGuestNetworkCommand.java > 2cf5bf8ffaa2b0df122c69f047ee3f56982267e1 > > plugins/hypervisors/vmware/src/com/cloud/hypervisor/vmware/resource/VmwareResource.java > 03af0da51b1eec93eb878fd1ebeca2ff2e0802ce > > plugins/hypervisors/xen/src/com/cloud/hypervisor/xen/resource/CitrixResourceBase.java > 69b7c9e07c753c0f0c93197a809acfb3399cf555 > systemvm/patches/debian/config/opt/cloud/bin/vpc_guestnw.sh > e5da2e096b30f6fdb15226e889517537d04f2e3e > > Diff: https://reviews.apache.org/r/18795/diff/ > > > Testing > ------- > > None, yet still coding > > > Thanks, > > Karl Harris > >
