cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Daan Hoogland <daan.hoogl...@gmail.com>
Subject Re: Review Request 18795: Sanity code review for: JIRA CloudStack-764 nTier Apps 2.0 : Redundant Virtual Router for VPC
Date Thu, 24 Apr 2014 19:41:34 GMT
One answer inline...

mobile bilingual spell checker used

Op 24 apr. 2014 16:54 schreef "Karl Harris" <karl.harris@sungardas.com>:
....
> A related question is should the vrr
> protocol<http://en.wikipedia.org/wiki/Virtual_Router_Redundancy_Protocol>
> used
> by Keepalived <http://www.keepalived.org/> be passed on the Cloudstack
> Management network or an isolated network between the master and
> backup router?
On all the networks that should be served redundantly, e.g. all.

>
>
> On Tue, Apr 22, 2014 at 5:57 AM, Daan Hoogland <daan.hoogland@gmail.com
>wrote:
>
> > Sounds like a single guru should do the job.
> > Also I would think of some offerings that contain affinity so that the
> > guru has a guideline as to where to deploy the pair of routers. For a
> > certain type of network design a admin may already know where the
> > routers should be deployed and in that case it makes no sense to let
> > the guru do any calculations on that. The admin should be able to
> > specify it with tags or the likes. Of course the criteria you mention
> > must not conflict but I think it makes sense to have a admin created
> > offering override the standard algorithm.
> >
> > regards,
> > Daan
> >
> > On Mon, Apr 21, 2014 at 9:21 PM, Karl Harris <karl.harris@sungardas.com>
> > wrote:
> > > The functional spec for Redundant Virtual Router for VPC's states:
> > > Deployment for RvR
> > >
> > >    - Mgmt server would try to deploy two VR in the physical devices as
> > far
> > >    apart as possible. It would try different pod, different cluster,
> > different
> > >    storage, different host first, until there is none of above
condition
> > can
> > >    be met, it would deploy both of them in the same host.
> > >
> > >
> > >
> > > Is a design method in a PrivateRedundantNetworkGuru NetworkGuru
class(es)
> > > the most appropriate place to put this code?
> > >
> > > Separate Guru's for each of the pod,cluster,storage, host entities or
a
> > > single Guru that "designs" using the above criteria?
> > >
> > > Karl
> > >
> > >
> > > On Wed, Mar 5, 2014 at 3:20 PM, Karl Harris <karl.harris@sungard.com>
> > wrote:
> > >
> > >>
> > >> -----------------------------------------------------------
> > >> This is an automatically generated e-mail. To reply, visit:
> > >> https://reviews.apache.org/r/18795/
> > >> -----------------------------------------------------------
> > >>
> > >> 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
> > >>
> > >>
> >
> >
> >
> > --
> > Daan
> >
> >

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message