CLOUDSTACK-8799 fixed the defalut routes #784
Conversation
CLOUDSTACK-8799 made changes to fix CsRedundant.py
|
cloudstack-pull-rats #539 SUCCESS |
|
Hi @bvbharatk couple of questions regarding your changes:
I would expect at least the following tests to be executed:
Thanks in advance. Cheers, |
|
cloudstack-pull-analysis #473 SUCCESS |
There was a problem hiding this comment.
There is a typo here. Could you fix that?
Also, the logging could be more verbose. To what is the default route pointing? We should log that as well.
|
Hi @bvbharat , Any news on this PR? Cheers, |
|
will update once i am done testing against vpc networks. |
|
Okay, @bvbharat ... thanks for the update. :) Cheers, |
bvbharatk
force-pushed
the
CLOUDSTACK-8799
branch
from
37fd7b7 to
e2835ff
Compare
|
cloudstack-pull-rats #564 SUCCESS |
|
cloudstack-pull-rats #565 SUCCESS |
|
cloudstack-pull-analysis #499 SUCCESS |
|
cloudstack-pull-analysis #500 UNSTABLE |
There was a problem hiding this comment.
I still think that we should do the splitting in Python.
Execute ip with the -o flag so it is a one-liner and split with Python afterwards.
There was a problem hiding this comment.
If you only want the state, why not simply do this? No magic needed.
cat /sys/class/net/eth0/operstate
There was a problem hiding this comment.
Hi,
just out of curiosity why should we do the splitting in python and what is wrong in doing it this way.
There was a problem hiding this comment.
We should keep as much logic in Python as possible. The performance difference is small, but with tr and grep you spawn subprocessess again.
But as @remibergsma says. Try to open that file in /sys and parse the contents. You can use the simple Python file functions.
No need to execute IP. The less subprocesses we execute, the better.
There was a problem hiding this comment.
Hi,
we have used the subprocess command to find the state of the device in two more places. I have created a improvement ticket(CLOUDSTACK-8837) to track this. I will work on this later, until then
i guess the current changes will do.
bvbharatk
force-pushed
the
CLOUDSTACK-8799
branch
from
e2835ff to
da17c14
Compare
|
cloudstack-pull-rats #568 ABORTED |
|
cloudstack-pull-analysis #504 ABORTED |
|
After applying patch, was able to create VPC successfully. 2015-09-11 15:59:15,169 DEBUG c.c.a.t.Request Seq 297-1810728525179650071: Processing: { Ans: , MgmtId: 233845178473044, via: 297, Ver: v1, Flags: 110, [{"com.cloud.agent.api.StartAnswer":{"vm":{"id":34,"name":"r-34-VM","type":"DomainRouter","cpus":1,"minSpeed":500,"maxSpeed":500,"minRam":268435456,"maxRam":268435456,"arch":"x86_64","os":"Debian GNU/Linux 5.0 (64-bit)","platformEmulator":"Debian GNU/Linux 5","bootArgs":" vpccidr=10.5.1.0/24 domain=cs2cloud.internal dns1=4.2.2.2 template=domP name=r-34-VM eth0ip=169.254.1.43 eth0mask=255.255.0.0 type=vpcrouter disable_rp_filter=true baremetalnotificationsecuritykey=s67s-w0ooifUaTiCWhF24OUfj8JSRhTKTs6N-2rlWY2tkkPo-F0nZOv1lKTIyXXs0ir4vv0hatiUHFaddZxiDw baremetalnotificationapikey=c9SUcsu8zctnSQmy43yhQB0HJM2HTDsRjEXd85s9IJOobOBRLaGZBa22vDH4IozJpIW8PHXVAFWu_W9qtdvYIA host=10.147.28.47 port=8080","enableHA":true,"limitCpuUse":false,"enableDynamicallyScaleVm":false,"vncPassword":"UOXbgiNACZU3NN8Rv6uvNg","vncAddr":"10.147.28.43","params":{},"uuid":"4da3b373-17bc-4b4a-8b34-f32459faf341","disks":[{"data":{"org.apache.cloudstack.storage.to.VolumeObjectTO":{"uuid":"5e291e11-8043-4b67-9b41-aa55e71e8236","volumeType":"ROOT","dataStore":{"org.apache.cloudstack.storage.to.PrimaryDataStoreTO":{"uuid":"954526cd-d0f1-4a9e-b80a-902baad3faa2","id":3,"poolType":"Filesystem","host":"10.147.28.43","path":"/var/lib/libvirt/images","port":0,"url":"Filesystem://10.147.28.43/var/lib/libvirt/images/?ROLE=Primary&STOREUUID=954526cd-d0f1-4a9e-b80a-902baad3faa2"}},"name":"ROOT-34","size":3145728000,"path":"5e291e11-8043-4b67-9b41-aa55e71e8236","volumeId":34,"vmName":"r-34-VM","accountId":2,"format":"QCOW2","provisioningType":"THIN","id":34,"deviceId":0,"hypervisorType":"KVM"}},"diskSeq":0,"path":"5e291e11-8043-4b67-9b41-aa55e71e8236","type":"ROOT","_details":{"managed":"false","storagePort":"0","storageHost":"10.147.28.43","volumeSize":"3145728000"}}],"nics":[{"deviceId":0,"networkRateMbps":-1,"defaultNic":false,"pxeDisable":true,"nicUuid":"588f728c-9de8-4b04-8fd4-7b03226c9ef2","uuid":"4c825977-669f-4777-9a44-a312952321c8","ip":"169.254.1.43","netmask":"255.255.0.0","gateway":"169.254.0.1","mac":"0e:00:a9:fe:01:2b","broadcastType":"LinkLocal","type":"Control","isSecurityGroupEnabled":false}]},"result":true,"wait":0}},{"com.cloud.agent.api.check.CheckSshAnswer":{"result":true,"wait":0}},{"com.cloud.agent.api.GetDomRVersionAnswer":{"templateVersion":"Cloudstack Release 4.6.0 Sun Jul 26 22:08:05 UTC 2015","scriptsVersion":"d6222468f4f35d173be74954631b18d2\n","result":true,"details":"Cloudstack Release 4.6.0 Sun Jul 26 22:08:05 UTC 2015&d6222468f4f35d173be74954631b18d2\n","wait":0}},{"com.cloud.agent.api.PlugNicAnswer":{"result":true,"details":"success","wait":0}},{"com.cloud.agent.api.routing.GroupAnswer":{"results":["null - success: null","null - success: [INFO] update_config.py :: Processing incoming file => ip_associations.json\n[INFO] Processing JSON file ip_associations.json\n"],"result":true,"wait":0}},{"com.cloud.agent.api.Answer":{"result":true,"details":"Nothing to do","wait":0}},{"com.cloud.agent.api.NetworkUsageAnswer":{"routerName":"r-34-VM","bytesSent":0,"bytesReceived":0,"result":true,"wait":0}}] } |
|
This one was merged, but it wasn't closed since something went wrong with the commit to master. @remibergsma, help? Any idea on how to close this PR? |
|
@wido you can ask @bvbharatk to close it or add the message |
|
@bvbharatk or @ke4qqq something went wrong with the auto-close (wasn't merged properly) Could either of you close this PR please? Thanks! |
|
This broke VPC default gateways, which was fixed in #738. Looking into a solution now. |
[BLOCKER] Combined PRs that fix VR issuesTonight I worked with @wilderrodrigues to figure out what is wrong with the virtual router. As we couldn't test single PRs any more (because of other issues with them causing tests to fail) we added all VR related PRs in a separate branch and started testing from there. We combined the following PRs into this PR: #836 #851 #867 #870 #881 #882 #842 After that, one issue remains: the VPC does not get a default gateway. Which is strange, because we already solved it in PR #738. When I look back, it was fixed again in PR #784. It could very well be that either one fixed one specific case, but also breaking the other. We need to investigate this, and make sure there will be a fix that works both for VPCs and VRs. When we manually add the default gateway on the VPC, most tests pass and also spinning up two VPCs with one tier each, having a VM and them using s2s to VPN them together works fine. See for more details the report Wilder sent earlier. Tomorrow we'll try to figure out how to fix the default gateway and merge this. Then we should have a base to work from again. Any PR that fixes another blocker, should at least then be rebased against the fixed master so we can run the tests against the PR branch. I'm not saying everything is fixed, I'm just saying that we can spin up a cloud that has working VMs. When, in the mean time, someone has the time to checkout this branch and make the default route work for both VPC and VR that would be awesome. After that we should double check and verify the test results. Pinging @karuturi to let her know the current status. Regards, Wilder / Remi * pr/887: Fixing the index out of bounds error in the check_if_link_up() function small cleanups Fixing the defaut route for VPC routers Formatting the get_gateway() method in the CsDatabag.py file Fixing the dhcpsrvr iptables file Formatting the router_proxy.sh script CLOUDSTACK-8881: Fixed Static and PF configuration issue CLOUDSTACK-8905: Fixed hooking egress rules CLOUDSTACK-8891: Fixed default iptables rules on VR for guest traffic Configured dnsmasq to listen on all interfaces so that vpn client gets dns CLOUDSTACK-8864: Not able to add TCP port forwarding rule in VPN for specific ports CLOUDSTACK-8863: VM doesn't reconnect to internet post VR RESTART/STOP-START/RECREATE CLOUDSTACK-8843: Fixed issue in default iptables rules on shared network VR Signed-off-by: Remi Bergsma <[email protected]>
* submit button when pressing Space on confirm modal * removed console * add auto-focus into switch & remove keyup function * revert message on storagejs Signed-off-by: Rohit Yadav <[email protected]>
9 participants
CLOUDSTACK-8799 made changes to fix the default routes
modified the CsRedundant.py to configure default routes correctly when rvr changes state from backup to master.