Karl, thanks. This is very clear and I was missing something entirely. I misled myself by interpreting CRUD as db action exclusively. You have cleared my mind and make a lot of sense.
On Thu, Mar 6, 2014 at 4:29 PM, Karl Harris <karl.har...@sungard.com> wrote: > 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. > > Let me know if the above is a bit clearer. > > > > Karl > > > > > On Thu, Mar 6, 2014 at 8:02 AM, Daan Hoogland <daan.hoogl...@gmail.com>wrote: > >> Not very much, unless i am missing something. The redundancy can not >> be enabled on a per network basis as the router needs to be in the air >> twice anyway. I would not like to save data that has no use. What CRUD >> are you thinking of? Or are you maybe putting some effort into keeping >> VPC and standalone networks alligned? >> >> On Thu, Mar 6, 2014 at 1:13 PM, Karl Harris <karl.har...@sungard.com> >> wrote: >> > Redundancy will be on a vpc basis. I'm attempting to add CRUD >> functionality >> > on a network basis. Does this make sense? >> > >> > On Thursday, March 6, 2014, daan Hoogland <daan.hoogl...@gmail.com> >> wrote: >> >> >> >> >> >> ----------------------------------------------------------- >> >> >> >> This is an automatically generated e-mail. To reply, visit: >> >> https://reviews.apache.org/r/18795/#review36352 >> >> ----------------------------------------------------------- >> >> >> >> >> >> >> >> 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. >> >> >> >> - daan Hoogland >> >> >> >> >> >> 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 >> >> > >> >> > >> >> >> > >> > >> > -- >> > Karl O. Harris >> > Cloud Software Engineer >> > Sungard Availability Services >> > >> > >> >> >> >> -- >> Daan >> >> > > > -- > Karl O. Harris > Cloud Software Engineer > Sungard Availability Services -- Daan
