I feel like I have squashed this discussion with my potential approach to handling this. Maybe we should just pickup this discussion assuming I didn't post that. :P
Regarding the docs. I have considered building a stubbed example network plugin and then documenting how you would take that stub and build on it. Would that be interesting? *Will STEVENS* Lead Developer *CloudOps* *| *Cloud Solutions Experts 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|* tw @CloudOps_ On Fri, Sep 23, 2016 at 12:15 AM, Murali Reddy <muralimmre...@gmail.com> wrote: > Matthew, > > Please see https://cwiki.apache.org/confluence/display/CLOUDSTACK/ > Extending+CloudStack+Networking > > Thanks, > Murali > > > > > > On 22/09/16, 11:23 PM, "Matthew Smart" <msm...@smartsoftwareinc.com> > wrote: > > >Hey Murali, > > > >I have been reading through the API and other documentation to try to > >get a basic understanding of the network service offering abstraction > >methodology in CS. I have not dove into the code yet but before I did I > >thought I would try a different approach. > > > >Imagine I were to come to this list and say that I have a network > >offering that I sell and that I wanted to write whatever I needed to in > >order to integrate it as an offering in CloudStack. Is there some > >specific documentation and guidelines you would direct me to read in > >order to gather the knowledge necessary to create a cloudstack > >compatible interface for my product? > > > >I don't know the history but I see several products that have navigated > >this process (Nuage, Nicira, ...etc) and am wondering how a new provider > >would work with you guys to navigate that process. If this is too vague, > >we can pretend my new offering is a hardware firewall device. > > > >My goal here is to gain an understanding of how CS interacts with third > >party offerings underneath the hood. I have some thoughts (I think > >inline with Will Steven's brain dump and diagram) but want to make sure > >I am not suffering some misapprehensions about the architecture and, > >short of tracing code, was not successful at finding the information I > >needed to satisfy myself that I know how it is designed. > > > >Thanks, > > > >Matthew Smart > >President > >Smart Software Solutions Inc. > >108 S Pierre St. > >Pierre, SD 57501 > > > >Phone: (605) 280-0383 > >Skype: msmart13 > >Email: msm...@smartsoftwareinc.com > > > >On 09/20/2016 04:54 AM, Murali Reddy wrote: > >> Configuration management of network appliances particularly for Cloud > and NFV scenarios is still evolving area. Programmability is the not the > strength for even the most popular network operating systems like IOS, > JunoS etc. So its not surprising why CloudStack integrates in a archaic way > with stock linux for the VR. > >> > >> VR was never integral/hardcoded option in CloudStack. Its always been a > plugin. CloudStack network orchestration is well abstracted and designed > with vision to compose a network with different set of providers for > different services. Yes that vision is not fully realised yet, and we don’t > have true service function chains. That would be different discussion topic. > >> > >> I tend to agree with Simon, as alternate/interim option we can take > hard look whats causing the problems with current VR integration. > Personally, I think it would be easier we take a cue from configuration > managers and network configuration solutions out there (for e.g promise > theory based Cisco ACI) move to more declarative model of expressing > desired state of network configuration. Infact current VR from 4.6, > actually holds the desired state per service basis, seems to be in that > direction. > >> > >> It does make sense to evaluate new appliances which can provide rich > semantics (like programmable API, declarative configuration, versioning, > commit/rollback etc), but will need significant engineering effort and time > to stabilise. We may make same mistakes with integration of other appliance > as well, if we fully don’t understand the nature of the current problems > with CloudStack core and service provider interaction and current VR > integration. > >> > >> > >> On 16/09/16, 11:59 PM, "Simon Weller" <swel...@ena.com> wrote: > >> > >>> I think our other option is to take a real look at what it would take > to fix the VR. In my opinion, a lot of the problems are related to the > monolithic python code base and the fact nothing is actually separated. > >>> > >>> Secondly, the python scripts (and bash scripts) don't use any > established libraries to complete tasks and instead shell out and run > commands that are both hard to track and hard to parse on return. > >>> > >>> > >>> If we daemonized this, used a real api for Agent to VR communication, > used common already existing libraries for the system service and network > interactions and spent a bit of time separating out code into distinct > modules, everything would behave a lot better. > >>> > >>> > >>> The pain and suffering is due to years and years of patches and > constant shelling out to complete tasks in my opinion. If we spend time to > rethink how we interact with the VR in general and we abstract the systems > and networking stuff and use well known and stable libraries to do the > work, the VR would be much easier to maintain. > >>> > >>> > >>> - Si > >>> > >>> > >>> > >>> > >>> ________________________________ > >>> From: Marty Godsey <ma...@gonsource.com> > >>> Sent: Friday, September 16, 2016 12:24 PM > >>> To: dev@cloudstack.apache.org > >>> Subject: RE: [DISCUSS] Replacing the VR > >>> > >>> So based upon this discussion would it be prudent to wait on VyOS 2.0? > The current VR is giving us issues but would the time invested in another > "solution" be wasted especially if by the time another option is chose, > then coded, then tested, then implemented and right as that time happened > to be when VyOS 2.0 is released. Of course you said they are just in the > scoping range so this could still be a year or more out. > >>> > >>> Thoughts? > >>> > >>> Regards, > >>> Marty Godsey > >>> nSource Solutions > >>> > >>> -----Original Message----- > >>> From: williamstev...@gmail.com [mailto:williamstev...@gmail.com] On > Behalf Of Will Stevens > >>> Sent: Friday, September 16, 2016 10:31 AM > >>> To: dev@cloudstack.apache.org > >>> Cc: dan...@baturin.org > >>> Subject: Re: [DISCUSS] Replacing the VR > >>> > >>> I just had a quick chat with a couple of the guys over on the VyOS > chat. > >>> I have CC'ed one of them in case we have more licensing questions. > >>> > >>> So here is the status with the license "the code inherited from Vyatta > and our modifications from it is GPLv2 (strict, not v2+). The config > reading library is GPLv2 too, so anything that links to is is GPLv2. > >>> Some auxiliary components we made after the fork are more permissive, > >>> LGPLv2+ or MIT." > >>> > >>> They are currently in the process of scoping a redesign (VyOS 2.0), > "we are planning a clean rewrite that will solve issues of the current > config system". > >>> This will include the ability to configure via the API. > >>> > >>> If we have more questions for VyOS, they are very friendly and > responsive, so we should be able to get answers. > >>> > >>> *Will STEVENS* > >>> Lead Developer > >>> > >>> *CloudOps* *| *Cloud Solutions Experts > >>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|* tw > @CloudOps_ > >>> > >>> On Fri, Sep 16, 2016 at 9:37 AM, Syed Ahmed <sah...@cloudops.com> > wrote: > >>> > >>>> I agree with Will Ilya. There are so many problems with the VR right > now. > >>>> Most of the outages we've had recently have somehow involved the VR. > >>>> We set custom iptables rules on the VR which can and have easily gone > wrong. > >>>> Openswan is broken, Strongswan replacement still needs to be tested. > >>>> VVRP with redundant router still needs work, and not to mention the > >>>> problems we will have when we introduce IPv6 into the whole picture. > >>>> > >>>> I think the spirit of the discussion is to rely on a 3rd party to do > >>>> the networking for us (eg VyOS) and have us handle just the > >>>> orchestration. All the problems that I've described have already been > >>>> solved in VyOS. We also get the advantage of a potential wider > >>>> community to fix and maintain the VR and given our current development > >>>> velocity, it think it totally makes sense to look for a 3rd party > option. > >>>> > >>>> -Syed > >>>> > >>>> > >>>> On Fri, Sep 16, 2016 at 9:18 AM, Will Stevens <wstev...@cloudops.com> > >>>> wrote: > >>>> > >>>>> The VR has been biting us far too often recently, which is why we > >>>>> have started looking into alternative implementations. > >>>>> > >>>>> One of the things that is nice about potentially using the VyOS is > >>>>> that > >>>> it > >>>>> is based on Debian, so we should be able to run the other services > >>>>> that > >>>> we > >>>>> currently have like the password server and userdata on the VyOS. > >>>>> This means we would not have to change our architecture initially > >>>>> and could focus on only replacing the networking paths. > >>>>> > >>>>> *Will STEVENS* > >>>>> Lead Developer > >>>>> > >>>>> *CloudOps* *| *Cloud Solutions Experts > >>>>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|* > >>>>> tw @CloudOps_ > >>>>> > >>>>> On Fri, Sep 16, 2016 at 6:20 AM, Nux! <n...@li.nux.ro> wrote: > >>>>> > >>>>>> The more this is discussed the more I think we should stick with > >>>>>> our > >>>> VR. > >>>>>> All these other options either seem unfinished or with > >>>>>> incompatible license. > >>>>>> > >>>>>> VyOS looks the most promising so far, it's a serious, mature > project. > >>>>>> Adopting it though means we'll have to microservice our way out of > >>>>>> it > >>>>> with > >>>>>> extra machines for DNS/USERDATA/etc, unless we can make VyOS serve > >>>> those > >>>>>> too. Imho this adds complexity we should void. > >>>>>> > >>>>>> -- > >>>>>> Sent from the Delta quadrant using Borg technology! > >>>>>> > >>>>>> Nux! > >>>>>> www.nux.ro > >>>>>> > >>>>>> ----- Original Message ----- > >>>>>>> From: "Will Stevens" <wstev...@cloudops.com> > >>>>>>> To: dev@cloudstack.apache.org > >>>>>>> Sent: Thursday, 15 September, 2016 17:21:28 > >>>>>>> Subject: Re: [DISCUSS] Replacing the VR > >>>>>>> Ya, we would need to add a daemon for VPN as well. Load > >>>>>>> balancing is another aspect which we will need to consider if we > went this route. > >>>>>>> Something like https://traefik.io/ could potentially be a good > >>>>>>> fit > >>>> due > >>>>>> to > >>>>>>> its API driven configuration, but it may be more than what we need. > >>>>>>> > >>>>>>> We should probably try define which pieces make sense to be > >>>>>>> solved > >>>>>> together > >>>>>>> and which pieces would be best suited to be broken out. > >>>>>>> > >>>>>>> I think the network connectivity, routing and firewalling should > >>>>> probably > >>>>>>> all stay together since the majority of the tools we would > >>>> potentially > >>>>>> use > >>>>>>> would handle all of that together in a single implementation. > >>>>>>> > >>>>>>> The password server and userdata seems like a good option for > >>>>>>> being > >>>>>> broken > >>>>>>> out and handled independently (and probably rewritten completely > >>>> since > >>>>>> they > >>>>>>> currently have some issues). > >>>>>>> > >>>>>>> Load balancing is another that could warrant splitting out, but > >>>>>>> that depends on what direction we go and how we would be managing > it. > >>>> DHCP > >>>>>> and > >>>>>>> DNS are others which could go either way. > >>>>>>> > >>>>>>> If we do split out services, I think we should consolidate as > >>>>>>> much as > >>>>> we > >>>>>>> can into each service we break out. Ideally a network packet > >>>>>>> would > >>>>> never > >>>>>>> hit more than one, maybe two, services. I don't think we should > >>>>>>> be splitting services 'just because', I think we need a valid > >>>>>>> case for splitting any service out because it adds complexity. > >>>>>>> Our project is already complex enough, we need to avoid adding > >>>>>>> complexity unless it > >>>> is > >>>>>>> really needed. > >>>>>>> > >>>>>>> Some more of my thoughts on this anyway... > >>>>>>> > >>>>>>> *Will STEVENS* > >>>>>>> Lead Developer > >>>>>>> > >>>>>>> *CloudOps* *| *Cloud Solutions Experts > >>>>>>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com > >>>>>>> *|* tw @CloudOps_ > >>>>>>> > >>>>>>> On Thu, Sep 15, 2016 at 10:28 AM, Simon Weller <swel...@ena.com> > >>>>> wrote: > >>>>>>>> I do agree with you that this probably isn't the right place > >>>>>>>> the > >>>>>> password > >>>>>>>> service and user data. > >>>>>>>> > >>>>>>>> > >>>>>>>> Having said that, after taking a cursory look at the dev docs, > >>>>>>>> it > >>>>>> doesn't > >>>>>>>> seem that difficult to add new daemons: > >>>> https://opensnaproute.github. > >>>>>>>> io/docs/developer.html#creating-new-component > >>>>>>>> > >>>>>>>> <https://opensnaproute.github.io/docs/developer.html# > >>>>>>>> creating-new-component> > >>>>>>>> > >>>>>>>> > >>>>>>>> They've definitely build it with a microservices architecture > >>>>>>>> in > >>>> mind, > >>>>>> so > >>>>>>>> each individual feature is abstracted into it's own small > >>>>>>>> daemon > >>>>>> process. > >>>>>>>> We could just create a daemon for the password server and the > >>>> userdata > >>>>>>>> components if we really had to. > >>>>>>>> > >>>>>>>> > >>>>>>>> - Si > >>>>>>>> > >>>>>>>> > >>>>>>>> ________________________________ > >>>>>>>> From: williamstev...@gmail.com <williamstev...@gmail.com> on > >>>>>>>> behalf > >>>>> of > >>>>>>>> Will Stevens <wstev...@cloudops.com> > >>>>>>>> Sent: Thursday, September 15, 2016 9:17 AM > >>>>>>>> To: dev@cloudstack.apache.org > >>>>>>>> Subject: Re: [DISCUSS] Replacing the VR > >>>>>>>> > >>>>>>>> A big part of why I know about it is because it is written in Go. > >>>> :P > >>>>>>>> Yes, it is definitely interesting for the routing and traffic > >>>> handling > >>>>>>>> aspects of the VR. We will likely have to rethink some of the > >>>> pieces > >>>>> a > >>>>>>>> little bit like the password server and userdata if we are to > >>>>>>>> adopt > >>>> a > >>>>>>>> different VR approach. This is where I think some of JohnB and > >>>>>> Chiradeep's > >>>>>>>> ideas make sense. In many ways, it does not make sense for the > >>>> device > >>>>>>>> handling routing and network traffic to also be responsible for > >>>>>> passwords > >>>>>>>> and userdata. > >>>>>>>> > >>>>>>>> *Will STEVENS* > >>>>>>>> Lead Developer > >>>>>>>> > >>>>>>>> *CloudOps* *| *Cloud Solutions Experts > >>>>>>>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com > >>>>>>>> *|* tw @CloudOps_ > >>>>>>>> > >>>>>>>> On Thu, Sep 15, 2016 at 9:10 AM, Simon Weller <swel...@ena.com> > >>>>> wrote: > >>>>>>>>> I hadn't heard of Flexswitch until you mentioned it. It looks > >>>> pretty > >>>>>>>> cool! > >>>>>>>>> It even supports ONIE install. > >>>>>>>>> > >>>>>>>>> To be honest, the ipsec feature could be added, or we could > >>>> offload > >>>>>> it to > >>>>>>>>> separate vm if we needed to. The fact it is so feature rich > >>>>>>>>> from a > >>>>>>>> routing > >>>>>>>>> perspective (and all API driven) is really nice. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> Based on the roadmap, it looks like they plan to also support > >>>>>>>> capabilities > >>>>>>>>> such as BGP-MPLS based L3VPN, EVPN, VPLS in the future. This > >>>>>>>>> will > >>>> be > >>>>>> huge > >>>>>>>>> for our carrier community that rely on these technologies to > >>>>>>>>> do > >>>>>> private > >>>>>>>>> gateway and inter-VPC interconnections today. We handle this > >>>>>>>>> stuff > >>>>> on > >>>>>> our > >>>>>>>>> ASRs right now with a vlan interconnect into the VR. Being > >>>>>>>>> able to > >>>>> do > >>>>>>>> MPLS > >>>>>>>>> all the way to the VR would be awesome. > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> It also seems to be written in GO (a language here at ENA we > >>>>>>>>> know > >>>>> very > >>>>>>>>> well). > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> - Si > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> > >>>>>>>>> ________________________________ > >>>>>>>>> From: Will Stevens <williamstev...@gmail.com> > >>>>>>>>> Sent: Thursday, September 15, 2016 7:06 AM > >>>>>>>>> To: dev@cloudstack.apache.org > >>>>>>>>> Subject: RE: [DISCUSS] Replacing the VR > >>>>>>>>> > >>>>>>>>> Ya. I don't think it covers our whole use case, but what it > >>>>>>>>> does > >>>>>> cover is > >>>>>>>>> all api driven... > >>>>>>>>> > >>>>>>>>> On Sep 15, 2016 1:48 AM, "Marty Godsey" <ma...@gonsource.com> > >>>>> wrote: > >>>>>>>>>> Though I don’t see VPN in Snaproute.. Makes sense since it > >>>>>>>>>> was > >>>> not > >>>>>>>>>> intended to do IPSec. > >>>>>>>>>> > >>>>>>>>>> It seems as though VyOS is starting to look like the best > >>>> option. > >>>>>>>>>> Regards, > >>>>>>>>>> Marty Godsey > >>>>>>>>>> nSource Solutions > >>>>>>>>>> > >>>>>>>>>> -----Original Message----- > >>>>>>>>>> From: williamstev...@gmail.com > >>>>>>>>>> [mailto:williamstev...@gmail.com > >>>> ] > >>>>> On > >>>>>>>>>> Behalf Of Will Stevens > >>>>>>>>>> Sent: Wednesday, September 14, 2016 11:06 PM > >>>>>>>>>> To: dev@cloudstack.apache.org > >>>>>>>>>> Subject: Re: [DISCUSS] Replacing the VR > >>>>>>>>>> > >>>>>>>>>> Or we could go completely crazy and go with something like > >>>>>> FlexSwitch > >>>>>>>>> from > >>>>>>>>>> SnapRoute > >>>>>>>>>> - http://www.snaproute.com/ > >>>>>>>>>> - https://opensnaproute.github.io/docs/apis.html > >>>>>>>>>> > >>>>>>>>>> *Will STEVENS* > >>>>>>>>>> Lead Developer > >>>>>>>>>> > >>>>>>>>>> *CloudOps* *| *Cloud Solutions Experts > >>>>>>>>>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w > >>>>>>>>>> cloudops.com > >>>>> *|* > >>>>>> tw > >>>>>>>>>> @CloudOps_ > >>>>>>>>>> > >>>>>>>>>> On Wed, Sep 14, 2016 at 10:55 PM, Will Stevens < > >>>>>> wstev...@cloudops.com> > >>>>>>>>>> wrote: > >>>>>>>>>> > >>>>>>>>>>> I tend to agree with Syed and Marty. I am not sure what > >>>>> problems > >>>>>> are > >>>>>>>>>>> solved by splitting up the function of the VR into a > >>>>>>>>>>> bunch of > >>>>>>>> separate > >>>>>>>>>>> services. As Syed points out, the complexity added is > >>>>>> non-trivial. > >>>>>>>>>>> We now have to manage all the intercontainer networking > >>>>>>>>>>> as > >>>> well > >>>>> as > >>>>>>>> the > >>>>>>>>>>> orchestrated ACS networking. > >>>>>>>>>>> > >>>>>>>>>>> VyOS is interesting to me because it covers the majority > >>>>>>>>>>> of > >>>> our > >>>>>> use > >>>>>>>>>>> case with a single unified control plane. It also has > >>>>>>>>>>> good > >>>>>> support > >>>>>>>>>>> for extending features we care about, like IPv6, VXLAN, > >>>>>>>>>>> VRRP, transactions, etc... > >>>>>>>>>>> > >>>>>>>>>>> *Will STEVENS* > >>>>>>>>>>> Lead Developer > >>>>>>>>>>> > >>>>>>>>>>> *CloudOps* *| *Cloud Solutions Experts > >>>>>>>>>>> 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w > >>>> cloudops.com > >>>>>> *|* > >>>>>>>> tw > >>>>>>>>>>> @CloudOps_ > >>>>>>>>>>> > >>>>>>>>>>> On Wed, Sep 14, 2016 at 9:49 PM, Syed Ahmed < > >>>>> sah...@cloudops.com> > >>>>>>>>> wrote: > >>>>>>>>>>>> Agree with Marty, adding Docker containers to the > >>>>>>>>>>>> picture > >>>>>> although > >>>>>>>>>>>> can make the VR more flexible but the added complexity > >>>>>>>>>>>> is > >>>> just > >>>>>> not > >>>>>>>>>>>> worth it. Not to mention we would need to take care of > >>>>> networking > >>>>>>>>>>>> each container manually and given that our iptable rules > >>>>>>>>>>>> are > >>>>> very > >>>>>>>>>>>> unstable at the moment I don't see a big value add. > >>>>>>>>>>>> > >>>>>>>>>>>> Vyos looks like a better solution to me. I know that it > >>>>>>>>>>>> does > >>>>> not > >>>>>>>>>>>> provide an api but it does fit the bill quite well > >>>> otherwise. I > >>>>>>>>>>>> specially like the fact that it has a transaction based > >>>>>>>>>>>> model > >>>>> and > >>>>>>>> you > >>>>>>>>>>>> can rollback changes if something goes wrong. > >>>>>>>>>>>> On Wed, Sep 14, 2016 at 9:06 PM Marty Godsey < > >>>>>> ma...@gonsource.com> > >>>>>>>>>> wrote: > >>>>>>>>>>>>> Licensing aside, I think splitting the various > >>>>>>>>>>>>> functions > >>>> into > >>>>>>>>>>>>> containers is not a good route either. This will force > >>>> users > >>>>> to > >>>>>>>>>>>>> have to maintain > >>>>>>>>>>>> and > >>>>>>>>>>>>> use containers and adds complexity to the networking > >>>> aspects > >>>>> of > >>>>>>>> ACS. > >>>>>>>>>>>>> Complexity decreases stability. Now I understand the > >>>> argument > >>>>>> that > >>>>>>>>>>>>> a monolithic approach also brings its own set of > >>>>>>>>>>>>> issues but > >>>>> it > >>>>>>>> also > >>>>>>>>>>>>> simplifies it. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Regards, > >>>>>>>>>>>>> Marty Godsey > >>>>>>>>>>>>> nSource Solutions > >>>>>>>>>>>>> > >>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>> From: Chiradeep Vittal [mailto:chirade...@gmail.com] > >>>>>>>>>>>>> Sent: Wednesday, September 14, 2016 5:37 PM > >>>>>>>>>>>>> To: dev@cloudstack.apache.org > >>>>>>>>>>>>> Subject: Re: [DISCUSS] Replacing the VR > >>>>>>>>>>>>> > >>>>>>>>>>>>> I rather doubt that the Cloudrouter will fit the needs > >>>>>>>>>>>>> of > >>>> the > >>>>>>>>>>>>> CloudStack project > >>>>>>>>>>>>> - it is AGPL licensed. Many enterprises will not > >>>>>>>>>>>>> touch > >>>>>> anything > >>>>>>>>>>>>> that > >>>>>>>>>>>> has > >>>>>>>>>>>>> AGPL > >>>>>>>>>>>>> - the github repo shows rather infrequent updates. > >>>>>>>>>>>>> Quite > >>>>>> likely > >>>>>>>>>>>>> they aren't considering the use cases of the > >>>>>>>>>>>>> CloudStack > >>>>>> community > >>>>>>>>>>>>> I'd back John B's comments on disaggregating the VR. > >>>>>>>>>>>>> Split > >>>> it > >>>>>> into > >>>>>>>>>>>>> many docker containers > >>>>>>>>>>>>> - password server > >>>>>>>>>>>>> - userdata server > >>>>>>>>>>>>> - DHCP / DNS > >>>>>>>>>>>>> - s2s VPN > >>>>>>>>>>>>> - RA VPN > >>>>>>>>>>>>> - intra-VPC routing and ACL > >>>>>>>>>>>>> - Port forwarding + NAT > >>>>>>>>>>>>> - FW > >>>>>>>>>>>>> - LB (public) > >>>>>>>>>>>>> - LB (internal), > >>>>>>>>>>>>> - secondary storage > >>>>>>>>>>>>> - agent > >>>>>>>>>>>>> Glue them together with docker compose files (one per > >>>>>>>>>>>>> use > >>>>>> case - > >>>>>>>>>>>>> basic zone, isolated, VPC, SSVM, etc). > >>>>>>>>>>>>> > >>>>>>>>>>>>> The VR image then becomes a JeOS + docker. You can > >>>>>>>>>>>>> test > >>>> each > >>>>> of > >>>>>>>> the > >>>>>>>>>>>>> components independently and fixing one bug in the > >>>>>>>>>>>>> field > >>>> (say > >>>>>>>> DHCP) > >>>>>>>>>>>>> is hitless to the other components. You don't need to > >>>>>>>>>>>>> build per-hypervisor VRs. You could even run on baremetal. > >>>>>>>>>>>>> > >>>>>>>>>>>>> Along the way you need to figure out how to > >>>>>>>>>>>>> - make the traffic traverse the containers that are > >>>>>>>>>>>>> needed > >>>>> to > >>>>>> be > >>>>>>>>>>>>> traversed (in most cases just 1) > >>>>>>>>>>>>> - bootstrap the router (how does it find its compose file? > >>>>>> where > >>>>>>>>>>>>> is the > >>>>>>>>>>>>> registry?) > >>>>>>>>>>>>> - rethink the command and control of the VR > >>>>>>>>>>>>> functions. SSH > >>>>>> works, > >>>>>>>>>>>>> but something more declarative, idempotent should be > >>>>> explored. > >>>>>>>>>>>>> As you do this, it becomes clearer which of the > >>>>>>>>>>>>> functions > >>>> can > >>>>>> be > >>>>>>>>>>>>> substituted by for example CloudRouter. Command and > >>>>>>>>>>>>> Control > >>>>> of > >>>>>> the > >>>>>>>>>>>> docker > >>>>>>>>>>>>> containers can be moved out to another container. Etc. > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> > >>>>>>>>>>>>> On Wed, Sep 14, 2016 at 12:59 AM, Marty Godsey > >>>>>>>>>>>>> <ma...@gonsource.com> > >>>>>>>>>>>>> wrote: > >>>>>>>>>>>>> > >>>>>>>>>>>>>> This one does look nice. My biggest concern is the > >>>>>>>>>>>>>> lack > >>>> of > >>>>>>>>>>>>>> VXLANs. It seems that any of the ones we mentioned > >>>>>>>>>>>>>> do not > >>>>>> have > >>>>>>>> an > >>>>>>>>>>>>>> API so we may be stuck at the SSH method. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Regards, > >>>>>>>>>>>>>> Marty Godsey > >>>>>>>>>>>>>> nSource Solutions > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> -----Original Message----- > >>>>>>>>>>>>>> From: Abhinandan Prateek > >>>>>>>>>>>>>> [mailto:abhinandan.prat...@shapeblue.com] > >>>>>>>>>>>>>> Sent: Wednesday, September 14, 2016 2:26 AM > >>>>>>>>>>>>>> To: dev@cloudstack.apache.org > >>>>>>>>>>>>>> Subject: Re: [DISCUSS] Replacing the VR > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> Cloudrouter looks promising. These have potential to > >>>>>>>>>>>>>> save > >>>>>> future > >>>>>>>>>>>>>> engineering effort for example on ipv6 routing, OSPF etc. > >>>>>>>>>>>>>> And the best part is they come with test automation > >>>>>> framework. > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> On 13/09/16, 4:22 PM, "Jayapal Uradi" > >>>>>>>>>>>>>> <jayapal.ur...@accelerite.com> > >>>>>>>>>>>>>> wrote: > >>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Hi, > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> Instead of replacing the VR in first place we > >>>>>>>>>>>>>>> should add VyOS/cloudrouter > >>>>>>>>>>>>>> as provider. Once it is stable, network offerings > >>>>>>>>>>>>>> (on > >>>>>> upgrade) > >>>>>>>>>>>>>> can be updated to use it and we can drop the VR if > >>>>>>>>>>>>>> we > >>>> want > >>>>> at > >>>>>>>>>>>>>> that release > >>>>>>>>>>>>> onwards. > >>>>>>>>>>>>>>> VR is stabilized over a period of time and some of > >>>>>>>>>>>>>>> them > >>>>> are > >>>>>>>>>>>>>>> running > >>>>>>>>>>>>>> without issues. When we replicate the ACS VR > >>>>>>>>>>>>>> features in > >>>>> new > >>>>>>>>>>>>>> solution it takes some to find the missing pieces > >>>>>>>>>>>>>> (hidden > >>>>>> bugs). > >>>>>>>>>>>>>>> Thanks, > >>>>>>>>>>>>>>> Jayapal > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> On Sep 13, 2016, at 2:52 PM, Nux! < > >>>>>>>>>>>>>>>> n...@li.nux.ro> wrote: > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Hi, > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> I like the idea. > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Cloudrouter looks really promising, I'm not too > >>>>>>>>>>>>>>>> keen > >>>> on > >>>>>> VyOS > >>>>>>>>>>>>>>>> (it > >>>>>>>>>>>>>> doesn't have a proper http api etc). > >>>>>>>>>>>>>>>> -- > >>>>>>>>>>>>>>>> Sent from the Delta quadrant using Borg technology! > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> Nux! > >>>>>>>>>>>>>>>> www.nux.ro > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>> > >>>>>>>>>>>>>> abhinandan.prat...@shapeblue.com > >>>>>>>>>>>>>> www.shapeblue.com<http://www.shapeblue.com> > >>>>>>>>>>>>>> 53 Chandos Place, Covent Garden, London WC2N 4HSUK > >>>>>> @shapeblue > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> > >>>>>>>>>>>>>> ----- Original Message ----- > >>>>>>>>>>>>>>>>> From: "Will Stevens" <williamstev...@gmail.com> > >>>>>>>>>>>>>>>>> To: dev@cloudstack.apache.org > >>>>>>>>>>>>>>>>> Sent: Monday, 12 September, 2016 21:20:11 > >>>>>>>>>>>>>>>>> Subject: [DISCUSS] Replacing the VR > >>>>>>>>>>>>>>>>> *Disclaimer:* This is a thought experiment and > >>>>>>>>>>>>>>>>> should > >>>>> be > >>>>>>>>>>>>>>>>> treated as > >>>>>>>>>>>>>> such. > >>>>>>>>>>>>>>>>> Please weigh in with the good and bad of this idea... > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> A couple of us have been discussing the idea of > >>>>>> potentially > >>>>>>>>>>>>>>>>> replacing the ACS VR with the VyOS [1] (Open > >>>>>>>>>>>>>>>>> Source > >>>>>> Vyatta > >>>>>>>>> VM). > >>>>>>>>>>>>>>>>> There may be a license issue because I think it > >>>>>>>>>>>>>>>>> is > >>>>>> licensed > >>>>>>>>>>>>>>>>> under GPL, but for the sake of discussion, let's > >>>> assume > >>>>>> we > >>>>>>>>>>>>>>>>> can overcome any > >>>>>>>>>>>>>> license issues. > >>>>>>>>>>>>>>>>> I have spent some time recently with the VyOS > >>>>>>>>>>>>>>>>> and I > >>>>> have > >>>>>> to > >>>>>>>>>>>>>>>>> admit, I was pretty impressed. It is simple and > >>>>>> intuitive > >>>>>>>>>>>>>>>>> and it gives you a lot more options for auditing > >>>>>>>>>>>>>>>>> the > >>>>>>>>>> configuration etc... > >>>>>>>>>>>>>>>>> Items of potential interest: > >>>>>>>>>>>>>>>>> - Clean up our current VR script spaghetti to a > >>>> simpler > >>>>>> more > >>>>>>>>>>>>>>>>> auditable configuration workflow. > >>>>>>>>>>>>>>>>> - Gives a cleaner path for IPv6 support. > >>>>>>>>>>>>>>>>> - Handles VPN configuration via the same > >>>> configuration > >>>>>>>>>> interface. > >>>>>>>>>>>>>>>>> - Support for OSPF & BGP. > >>>>>>>>>>>>>>>>> - VPN support through OpenVPN & StrongSwan. > >>>>>>>>>>>>>>>>> - Easily supports HA (redundant routers) through > >>>> VRRP. > >>>>>>>>>>>>>>>>> - VXLAN support. > >>>>>>>>>>>>>>>>> - Transaction based changes to the VR with > >>>>>>>>>>>>>>>>> rollback > >>>> on > >>>>>>>> error. > >>>>>>>>>>>>>>>>> Items that could be difficult to solve: > >>>>>>>>>>>>>>>>> - Userdata password reset workflow and > >>>> implementation. > >>>>>>>>>>>>>>>>> - Upgrade process. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> The VyOS is not the only option if we were to > >>>> consider > >>>>>> this > >>>>>>>>>>>> approach. > >>>>>>>>>>>>>>>>> Another option, which I don't know as well, > >>>>>>>>>>>>>>>>> would be CloudRouter (AGPL > >>>>>>>>>>>>>>>>> license) [2] which is purely API driven. > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Anyway, would love to hear your thoughts... > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> Will > >>>>>>>>>>>>>>>>> > >>>>>>>>>>>>>>>>> [1] https://vyos.io/ [2] > >>>>>>>>>>>>>>>>> https://cloudrouter.org/ > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> > >>>>>>>>>>>>>>> DISCLAIMER > >>>>>>>>>>>>>>> ========== > >>>>>>>>>>>>>>> This e-mail may contain privileged and confidential > >>>>>> information > >>>>>>>>>>>>>>> which is > >>>>>>>>>>>>>> the property of Accelerite, a Persistent Systems > >>>> business. > >>>>>> It is > >>>>>>>>>>>>>> intended only for the use of the individual or > >>>>>>>>>>>>>> entity to > >>>>>> which > >>>>>>>> it > >>>>>>>>>>>>>> is addressed. If you are not the intended recipient, > >>>>>>>>>>>>>> you > >>>>> are > >>>>>> not > >>>>>>>>>>>>>> authorized to read, retain, copy, print, distribute > >>>>>>>>>>>>>> or > >>>> use > >>>>>> this > >>>>>>>>>>>>>> message. If you have received this communication in > >>>> error, > >>>>>>>> please > >>>>>>>>>>>>>> notify the sender and delete all copies of this message. > >>>>>>>>>>>>>> Accelerite, a Persistent Systems business does not > >>>>>>>>>>>>>> accept > >>>>> any > >>>>>>>>>>>>>> liability for virus > >>>>>>>>>>>>> infected mails. > >>>>>>>>>>> > > > >
