Github user karuturi commented on the issue:
https://github.com/apache/cloudstack/pull/1645
@kiwiflyer Noted. Looking at the code diff, I dont think it will cause any
regressions. But, just wanted to run the tests once.
---
If your project is set up for it, you can reply to this
Github user murali-reddy commented on the issue:
https://github.com/apache/cloudstack/pull/1666
@jburwell i have squashed the commit. Added two new test cased to test /32
CIDR for egress firewall rule. For some reason jenkins seems to have failed due
to unrelated unit test failure. I
Github user cloudmonger commented on the issue:
https://github.com/apache/cloudstack/pull/1645
### ACS CI BVT Run
**Sumarry:**
Build Number 99
Hypervisor xenserver
NetworkType Advanced
Passed=99
Failed=1
Skipped=4
_Link to logs Folder (search
Github user nnesic commented on the issue:
https://github.com/apache/cloudstack/pull/1624
@blueorangutan kick
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes
Github user asfgit closed the pull request at:
https://github.com/apache/cloudstack/pull/1645
---
If your project is set up for it, you can reply to this email and have your
reply appear on GitHub as well. If your project does not have this feature
enabled and wishes so, or if the feature
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
Github user murali-reddy commented on the issue:
https://github.com/apache/cloudstack/pull/1666
@karuturi i did not change the logic of how and what iptables rules were
added in the original patch. I just stream lined rule action deny/allow logic
for all the protocols.
I
Github user karuturi commented on the issue:
https://github.com/apache/cloudstack/pull/1645
Failure is not related. Looks like an environment issue(I am checking it).
Merging this PR.
---
If your project is set up for it, you can reply to this email and have your
reply appear on
Ya, your points are all valid Simon. The lack of standard libraries to
handle a lot of the details is a problem. I don't think it is an
unsolvable problem, but if we spend the time to do that, will we have
something that will work for us for the next 5 years? This may be the
shortest path to
Github user mike-tutkowski commented on the issue:
https://github.com/apache/cloudstack/pull/1642
Just a note that @syed and I discussed his idea and decided to open a
separate PR for it.
---
If your project is set up for it, you can reply to this email and have your
reply appear on
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
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
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
Github user cloudmonger commented on the issue:
https://github.com/apache/cloudstack/pull/1666
### ACS CI BVT Run
**Sumarry:**
Build Number 100
Hypervisor xenserver
NetworkType Advanced
Passed=76
Failed=15
Skipped=4
_Link to logs Folder
Ya, I hear ya Ilya. I have been trying not to focus on the license
initially in order to get as much input as possible.
I guess at this point we should start understanding what we need from a
license. On Wikipedia it has the license as "License Free software
licenses (mainly GPL)" for VyOS. If
Github user mike-tutkowski commented on the issue:
https://github.com/apache/cloudstack/pull/1642
@jburwell I changed the sleep/delay to a wait_until.
Here is the most recent test run for this integration test:
test_01_create_system_vms_on_managed_storage
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
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
18 matches
Mail list logo
