[jira] [Commented] (CLOUDSTACK-10317) In case of multiple-public ips, snat fails to work for addtional public nics/network for guest traffic
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16387196#comment-16387196 ] ASF GitHub Bot commented on CLOUDSTACK-10317: - blueorangutan commented on issue #2476: CLOUDSTACK-10317: Fix SNAT rules for additional public nics URL: https://github.com/apache/cloudstack/pull/2476#issuecomment-370646501 Trillian test result (tid-2315) Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7 Total time taken: 35308 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2476-t2315-kvm-centos7.zip Intermitten failure detected: /marvin/tests/smoke/test_deploy_virtio_scsi_vm.py Intermitten failure detected: /marvin/tests/smoke/test_internal_lb.py Intermitten failure detected: /marvin/tests/smoke/test_public_ip_range.py Intermitten failure detected: /marvin/tests/smoke/test_templates.py Intermitten failure detected: /marvin/tests/smoke/test_usage.py Intermitten failure detected: /marvin/tests/smoke/test_volumes.py Intermitten failure detected: /marvin/tests/smoke/test_vpc_redundant.py Intermitten failure detected: /marvin/tests/smoke/test_hostha_kvm.py Smoke tests completed. 64 look OK, 3 have error(s) Only failed tests results shown below: Test | Result | Time (s) | Test File --- | --- | --- | --- test_04_extract_template | `Failure` | 128.34 | test_templates.py ContextSuite context=TestISOUsage>:setup | `Error` | 0.00 | test_usage.py test_06_download_detached_volume | `Failure` | 138.71 | test_volumes.py This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > In case of multiple-public ips, snat fails to work for addtional public > nics/network for guest traffic > -- > > Key: CLOUDSTACK-10317 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10317 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Minor > Fix For: 4.12.0.0, 4.11.1.0 > > > If a VR has two+ public nics, traffic from guest VM fails to be NAT-ed > correctly for traffic towards additional public nics. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10268) Fix and enhance package script
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386911#comment-16386911 ] ASF GitHub Bot commented on CLOUDSTACK-10268: - khos2ow commented on issue #2433: CLOUDSTACK-10268: Fix and enhance package script URL: https://github.com/apache/cloudstack/pull/2433#issuecomment-370598448 I'm +1 on testing (may be individually on different environments). I don't think automated test would give us much needed information anyway (it helps regardless anyway). What I would do is: - build with `--use-timestamp` - once RPMs - once DEBs - build systemvm. preferably with ```bash VERSION=$(mvn -q -Dexec.executable="echo" -Dexec.args='${project.version}' --non-recursive org.codehaus.mojo:exec-maven-plugin:1.3.1:exec) TIMESTAMP=$(date +%s) VERSION=$(echo $VERSION | sed 's/\-SNAPSHOT/\-'${TIMESTAMP}'/g') ./build.sh systemvmtemplate $VERSION $BUILD_NUMBER ``` - manually deploy the whole thing What to look for: - .rpm or .deb file to have a name like `cloudstack-xxx-.[deb|rpm]` - when logged in the UI > About Cloudstack should have the full version `4.12.0.0-` - when ssh in the systemvm `cat /etc/cloudstack-release` should have the full version `4.12.0.0-` - from UI > Infrastructure > VR should detect correctly to upgrase - when upgraded should show the full version in the UI (`4.12.0.0-`) This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Fix and enhance package script > -- > > Key: CLOUDSTACK-10268 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10268 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Reporter: Khosrow Moossavi >Priority: Minor > Fix For: 4.12.0.0 > > > * new flag `-T, --use-timestamp` to use `timestamp` when POM version contains > SNAPSHOT > ** in the final artifacts (jar) name > ** in the final package (rpm, deb) name > ** in `/etc/cloudstack-release` file of SystemVMs > ** in the Management Server > About dialog > * if there's a "branding" string in the POM version (e.g. > `x.y.z.a-NAME[-SNAPSHOT]`), the branding name will be used in the final > generated pacakge name such as following: > ** `cloudstack-management-x.y.z.a-NAME.NUMBER.el7.centos.x86_64` > ** `cloudstack-management_x.y.z.a-NAME-NUMBER~xenial_all.deb` > * branding string can be overriden with newly added `-b, --brand` flag > * handle the new format version for VR version > * fix long opts (they were broken) > * tolerate and show a warning message for unrecognized flags > * usage help reformat -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10318) Bug on sorting ACL rules list in chrome
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386846#comment-16386846 ] ASF GitHub Bot commented on CLOUDSTACK-10318: - rafaelweingartner commented on issue #2478: [CLOUDSTACK-10318] Bug on sorting ACL rules list in chrome URL: https://github.com/apache/cloudstack/pull/2478#issuecomment-370587137 Thanks @DaanHoogland This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Bug on sorting ACL rules list in chrome > > > Key: CLOUDSTACK-10318 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10318 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > Fix For: 4.12 > > > There is a bug on ACL rules list when a user creates more than 10 rules. > #Steps to reproduce this issue > - Create more than 10 ACL rules. > - Access the ACL rules list page. > - You will see that they are not sorted as they should by the ACL rule number -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10268) Fix and enhance package script
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386845#comment-16386845 ] ASF GitHub Bot commented on CLOUDSTACK-10268: - rafaelweingartner commented on issue #2433: CLOUDSTACK-10268: Fix and enhance package script URL: https://github.com/apache/cloudstack/pull/2433#issuecomment-370586983 Well.. that version.java was changed, and I think that affects ACS rode when it deals with system VMs. What do you think? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Fix and enhance package script > -- > > Key: CLOUDSTACK-10268 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10268 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Reporter: Khosrow Moossavi >Priority: Minor > Fix For: 4.12.0.0 > > > * new flag `-T, --use-timestamp` to use `timestamp` when POM version contains > SNAPSHOT > ** in the final artifacts (jar) name > ** in the final package (rpm, deb) name > ** in `/etc/cloudstack-release` file of SystemVMs > ** in the Management Server > About dialog > * if there's a "branding" string in the POM version (e.g. > `x.y.z.a-NAME[-SNAPSHOT]`), the branding name will be used in the final > generated pacakge name such as following: > ** `cloudstack-management-x.y.z.a-NAME.NUMBER.el7.centos.x86_64` > ** `cloudstack-management_x.y.z.a-NAME-NUMBER~xenial_all.deb` > * branding string can be overriden with newly added `-b, --brand` flag > * handle the new format version for VR version > * fix long opts (they were broken) > * tolerate and show a warning message for unrecognized flags > * usage help reformat -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10274) L2 network refused to be designed on VXLAN physical network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386818#comment-16386818 ] ASF GitHub Bot commented on CLOUDSTACK-10274: - blueorangutan commented on issue #2448: CLOUDSTACK-10274: L2 network refused to be designed on VXLAN physical network URL: https://github.com/apache/cloudstack/pull/2448#issuecomment-370580552 Trillian test result (tid-2314) Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7 Total time taken: 29989 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2448-t2314-kvm-centos7.zip Intermitten failure detected: /marvin/tests/smoke/test_privategw_acl.py Intermitten failure detected: /marvin/tests/smoke/test_ssvm.py Intermitten failure detected: /marvin/tests/smoke/test_hostha_kvm.py Smoke tests completed. 66 look OK, 1 have error(s) Only failed tests results shown below: Test | Result | Time (s) | Test File --- | --- | --- | --- test_hostha_enable_ha_when_host_in_maintenance | `Error` | 1.12 | test_hostha_kvm.py This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > L2 network refused to be designed on VXLAN physical network > > > Key: CLOUDSTACK-10274 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10274 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0 >Reporter: Nicolas Vazquez >Priority: Major > Fix For: 4.11.1.1 > > > Issue reported by [~nuxro] while trying to add an L2 network on a VXLAN > physical network: > 2018-02-06 11:20:27,748 DEBUG [c.c.n.NetworkServiceImpl] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Found physical > network id=201 based on requested tags mellanoxvxlan > 2018-02-06 11:20:27,749 DEBUG [c.c.n.NetworkServiceImpl] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Found physical > network id=201 based on requested tags mellanoxvxlan > 2018-02-06 11:20:27,766 DEBUG [c.c.n.g.BigSwitchBcfGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network, the physical isolation type is not BCF_SEGMENT > 2018-02-06 11:20:27,766 DEBUG [o.a.c.n.c.m.ContrailGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,767 DEBUG [c.c.n.g.NiciraNvpGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,767 DEBUG [o.a.c.n.o.OpendaylightGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,767 DEBUG [c.c.n.g.OvsGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,769 DEBUG [o.a.c.n.g.SspGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) SSP not > configured to be active > 2018-02-06 11:20:27,769 DEBUG [c.c.n.g.BrocadeVcsGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,769 DEBUG [c.c.n.g.NuageVspGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design network using network offering 19 on physical network 201 > 2018-02-06 11:20:27,770 DEBUG [o.a.c.e.o.NetworkOrchestrator] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Releasing lock > for Acct[6af2875b-04fc-11e8-923e-002590474525-admin] > 2018-02-06 11:20:27,789 DEBUG [c.c.u.d.T.Transaction] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Rolling back > the transaction: Time = 38 Name = qtp788117692-390; called by > -TransactionLegacy.rollback:889-TransactionLegacy.removeUpTo:832-TransactionLegacy.close:656-Transaction.execute:43-Transaction.execute:47-NetworkOrchestrator.createGuestNetwork:2315-NetworkServiceImpl$4.doInTransaction:1383-NetworkServiceImpl$4.doInTransaction:1331-Transaction.execute:40-NetworkServiceImpl.commitNetwork:1331-NetworkServiceImpl.createGuestNetwork:1294-NativeMethodAccessorImpl.invoke0:-2 > 2018-02-06 11:20:27,798 ERROR [c.c.a.ApiServer] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) unhandled > exception executing api command: [Ljava.lang.String;@43b9df02 > com.cloud.utils.exception.CloudRunti
[jira] [Commented] (CLOUDSTACK-10268) Fix and enhance package script
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386790#comment-16386790 ] ASF GitHub Bot commented on CLOUDSTACK-10268: - khos2ow commented on issue #2433: CLOUDSTACK-10268: Fix and enhance package script URL: https://github.com/apache/cloudstack/pull/2433#issuecomment-370572358 @rafaelweingartner yes, that's correct. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Fix and enhance package script > -- > > Key: CLOUDSTACK-10268 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10268 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Reporter: Khosrow Moossavi >Priority: Minor > Fix For: 4.12.0.0 > > > * new flag `-T, --use-timestamp` to use `timestamp` when POM version contains > SNAPSHOT > ** in the final artifacts (jar) name > ** in the final package (rpm, deb) name > ** in `/etc/cloudstack-release` file of SystemVMs > ** in the Management Server > About dialog > * if there's a "branding" string in the POM version (e.g. > `x.y.z.a-NAME[-SNAPSHOT]`), the branding name will be used in the final > generated pacakge name such as following: > ** `cloudstack-management-x.y.z.a-NAME.NUMBER.el7.centos.x86_64` > ** `cloudstack-management_x.y.z.a-NAME-NUMBER~xenial_all.deb` > * branding string can be overriden with newly added `-b, --brand` flag > * handle the new format version for VR version > * fix long opts (they were broken) > * tolerate and show a warning message for unrecognized flags > * usage help reformat -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10268) Fix and enhance package script
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386787#comment-16386787 ] ASF GitHub Bot commented on CLOUDSTACK-10268: - DaanHoogland commented on issue #2433: CLOUDSTACK-10268: Fix and enhance package script URL: https://github.com/apache/cloudstack/pull/2433#issuecomment-370571231 No, I don't think production code has been touched. maybe test installs? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Fix and enhance package script > -- > > Key: CLOUDSTACK-10268 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10268 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Reporter: Khosrow Moossavi >Priority: Minor > Fix For: 4.12.0.0 > > > * new flag `-T, --use-timestamp` to use `timestamp` when POM version contains > SNAPSHOT > ** in the final artifacts (jar) name > ** in the final package (rpm, deb) name > ** in `/etc/cloudstack-release` file of SystemVMs > ** in the Management Server > About dialog > * if there's a "branding" string in the POM version (e.g. > `x.y.z.a-NAME[-SNAPSHOT]`), the branding name will be used in the final > generated pacakge name such as following: > ** `cloudstack-management-x.y.z.a-NAME.NUMBER.el7.centos.x86_64` > ** `cloudstack-management_x.y.z.a-NAME-NUMBER~xenial_all.deb` > * branding string can be overriden with newly added `-b, --brand` flag > * handle the new format version for VR version > * fix long opts (they were broken) > * tolerate and show a warning message for unrecognized flags > * usage help reformat -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10197) XenServer 7.1: Cannot mount xentool iso from cloudstack on VMs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386782#comment-16386782 ] ASF GitHub Bot commented on CLOUDSTACK-10197: - DaanHoogland commented on issue #2470: [CLOUDSTACK-10197] Update DisplayText of XenServer tools ISO entry in the database when it already exists URL: https://github.com/apache/cloudstack/pull/2470#issuecomment-370570524 Yes @rafaelweingartner , I've seen this one a lot and seen it pass as well. Your code here is not related to that test afaik. @rhtyd @PaulAngus can you give second and third opinions? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > XenServer 7.1: Cannot mount xentool iso from cloudstack on VMs > --- > > Key: CLOUDSTACK-10197 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10197 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0 > Environment: XenServer 7.0+ >Reporter: Khosrow Moossavi >Priority: Major > Fix For: 4.11.0.0 > > > In XenServer 7.0+ xentools iso has been renamed from *xs-tools* to > *guest-tools* so CloudStack fails to attach it to any VM. > {code} > (acs-admin) > attach iso > virtualmachineid=d13eeff1-2d99-46a9-8fc5-3510df6e9f5e > id=e8a56540-0fc3-44de-9911-635d2d8f25c4 > errorcode = 530 > errortext = Failed to attach iso > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CLOUDSTACK-10267) role template creator
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10267?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland updated CLOUDSTACK-10267: --- Security: (was: Public) > role template creator > - > > Key: CLOUDSTACK-10267 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10267 > Project: CloudStack > Issue Type: Wish >Reporter: Daan Hoogland >Priority: Major > Labels: gsoc2018 > > As a domain admin I want to be able to base a new role on an existing one > with or without keeping the link when the original is updated. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CLOUDSTACK-10263) A new ui framework that easier to extend for new APIs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10263?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland updated CLOUDSTACK-10263: --- Security: (was: Public) > A new ui framework that easier to extend for new APIs > - > > Key: CLOUDSTACK-10263 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10263 > Project: CloudStack > Issue Type: Wish >Reporter: Daan Hoogland >Priority: Major > Labels: gsoc2018 > > As a developer I want to have an easy entry to my new APIs from the UI on the > web. This now involves digging through tons of js code to find the right > place to add widgets for my call. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CLOUDSTACK-10265) Improved Mgmt Server Clustering and Agent Ownership management
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10265?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland updated CLOUDSTACK-10265: --- Security: (was: Public) > Improved Mgmt Server Clustering and Agent Ownership management > -- > > Key: CLOUDSTACK-10265 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10265 > Project: CloudStack > Issue Type: Wish >Reporter: Daan Hoogland >Priority: Major > Labels: gsoc2018 > > As a cloud provider I want my management server to have a workload > distribution to my liking. > * Dynamic addition of mgmt. servers and rebalancing > * Transfer of async job monitoring between mgmt servers > * Graceful withdrawl of a management server from active operation -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CLOUDSTACK-10264) Visibility into Mgmt Server Async Tasks
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10264?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland updated CLOUDSTACK-10264: --- Security: (was: Public) > Visibility into Mgmt Server Async Tasks > --- > > Key: CLOUDSTACK-10264 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10264 > Project: CloudStack > Issue Type: Wish >Reporter: Daan Hoogland >Priority: Major > Labels: gsoc2018 > > As a cloud admin I want to have a view on asynchronous tasks queued or > scheduled in the management server and management APIs for the jobs present. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CLOUDSTACK-10266) Less disruptive upgrades
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10266?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland updated CLOUDSTACK-10266: --- Security: (was: Public) > Less disruptive upgrades > > > Key: CLOUDSTACK-10266 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10266 > Project: CloudStack > Issue Type: Wish >Reporter: Daan Hoogland >Priority: Major > Labels: gsoc2018 > > As a cloud provider I want less diruptive upgrade procedures when my > operators need to update Apache CloudStack. > * Add more intelligence into upgrade process to detect when schema changes > would require mgmt restarts. Upgrade determines which services are affected > by db changes. > * Enable rolling upgrades driven by CloudStack. Host and async > jobs/monitoring are passed from mgmt server to be shut down to other mgmt > servers. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CLOUDSTACK-10262) create an API driven System VM upgrade posibility
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10262?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Daan Hoogland updated CLOUDSTACK-10262: --- Security: (was: Public) > create an API driven System VM upgrade posibility > - > > Key: CLOUDSTACK-10262 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10262 > Project: CloudStack > Issue Type: Wish >Reporter: Daan Hoogland >Priority: Major > Labels: gsoc2018 > > As a cloud admin I want a single call API to upgrade/upload a new System VM > template. The System VM template upgrade procedure is now largely manual and > error prone. An one ring to bind them all API call to replace the current > template for system VMs would help cloud admins world wide. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10197) XenServer 7.1: Cannot mount xentool iso from cloudstack on VMs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386693#comment-16386693 ] ASF GitHub Bot commented on CLOUDSTACK-10197: - rafaelweingartner commented on issue #2470: [CLOUDSTACK-10197] Update DisplayText of XenServer tools ISO entry in the database when it already exists URL: https://github.com/apache/cloudstack/pull/2470#issuecomment-370551424 @DaanHoogland is this "test_hostha_enable_ha_when_host_in_maintenance" an intermittent error? I have seen this on #2425, which is a very different PR. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > XenServer 7.1: Cannot mount xentool iso from cloudstack on VMs > --- > > Key: CLOUDSTACK-10197 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10197 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0 > Environment: XenServer 7.0+ >Reporter: Khosrow Moossavi >Priority: Major > Fix For: 4.11.0.0 > > > In XenServer 7.0+ xentools iso has been renamed from *xs-tools* to > *guest-tools* so CloudStack fails to attach it to any VM. > {code} > (acs-admin) > attach iso > virtualmachineid=d13eeff1-2d99-46a9-8fc5-3510df6e9f5e > id=e8a56540-0fc3-44de-9911-635d2d8f25c4 > errorcode = 530 > errortext = Failed to attach iso > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10197) XenServer 7.1: Cannot mount xentool iso from cloudstack on VMs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386648#comment-16386648 ] ASF GitHub Bot commented on CLOUDSTACK-10197: - blueorangutan commented on issue #2470: [CLOUDSTACK-10197] Update DisplayText of XenServer tools ISO entry in the database when it already exists URL: https://github.com/apache/cloudstack/pull/2470#issuecomment-370542094 Trillian test result (tid-2313) Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7 Total time taken: 29032 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2470-t2313-kvm-centos7.zip Intermitten failure detected: /marvin/tests/smoke/test_hostha_kvm.py Smoke tests completed. 66 look OK, 1 have error(s) Only failed tests results shown below: Test | Result | Time (s) | Test File --- | --- | --- | --- test_hostha_enable_ha_when_host_in_maintenance | `Error` | 1.03 | test_hostha_kvm.py This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > XenServer 7.1: Cannot mount xentool iso from cloudstack on VMs > --- > > Key: CLOUDSTACK-10197 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10197 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0 > Environment: XenServer 7.0+ >Reporter: Khosrow Moossavi >Priority: Major > Fix For: 4.11.0.0 > > > In XenServer 7.0+ xentools iso has been renamed from *xs-tools* to > *guest-tools* so CloudStack fails to attach it to any VM. > {code} > (acs-admin) > attach iso > virtualmachineid=d13eeff1-2d99-46a9-8fc5-3510df6e9f5e > id=e8a56540-0fc3-44de-9911-635d2d8f25c4 > errorcode = 530 > errortext = Failed to attach iso > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10268) Fix and enhance package script
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386566#comment-16386566 ] ASF GitHub Bot commented on CLOUDSTACK-10268: - rafaelweingartner commented on issue #2433: CLOUDSTACK-10268: Fix and enhance package script URL: https://github.com/apache/cloudstack/pull/2433#issuecomment-370528832 @DaanHoogland thanks for the update here. So, should we update for you to run the tests as well? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Fix and enhance package script > -- > > Key: CLOUDSTACK-10268 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10268 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Reporter: Khosrow Moossavi >Priority: Minor > Fix For: 4.12.0.0 > > > * new flag `-T, --use-timestamp` to use `timestamp` when POM version contains > SNAPSHOT > ** in the final artifacts (jar) name > ** in the final package (rpm, deb) name > ** in `/etc/cloudstack-release` file of SystemVMs > ** in the Management Server > About dialog > * if there's a "branding" string in the POM version (e.g. > `x.y.z.a-NAME[-SNAPSHOT]`), the branding name will be used in the final > generated pacakge name such as following: > ** `cloudstack-management-x.y.z.a-NAME.NUMBER.el7.centos.x86_64` > ** `cloudstack-management_x.y.z.a-NAME-NUMBER~xenial_all.deb` > * branding string can be overriden with newly added `-b, --brand` flag > * handle the new format version for VR version > * fix long opts (they were broken) > * tolerate and show a warning message for unrecognized flags > * usage help reformat -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10268) Fix and enhance package script
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386567#comment-16386567 ] ASF GitHub Bot commented on CLOUDSTACK-10268: - rafaelweingartner commented on issue #2433: CLOUDSTACK-10268: Fix and enhance package script URL: https://github.com/apache/cloudstack/pull/2433#issuecomment-370528832 @DaanHoogland thanks for the update here. So, should we wait for you to run the tests as well? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Fix and enhance package script > -- > > Key: CLOUDSTACK-10268 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10268 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Reporter: Khosrow Moossavi >Priority: Minor > Fix For: 4.12.0.0 > > > * new flag `-T, --use-timestamp` to use `timestamp` when POM version contains > SNAPSHOT > ** in the final artifacts (jar) name > ** in the final package (rpm, deb) name > ** in `/etc/cloudstack-release` file of SystemVMs > ** in the Management Server > About dialog > * if there's a "branding" string in the POM version (e.g. > `x.y.z.a-NAME[-SNAPSHOT]`), the branding name will be used in the final > generated pacakge name such as following: > ** `cloudstack-management-x.y.z.a-NAME.NUMBER.el7.centos.x86_64` > ** `cloudstack-management_x.y.z.a-NAME-NUMBER~xenial_all.deb` > * branding string can be overriden with newly added `-b, --brand` flag > * handle the new format version for VR version > * fix long opts (they were broken) > * tolerate and show a warning message for unrecognized flags > * usage help reformat -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10318) Bug on sorting ACL rules list in chrome
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10318?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386446#comment-16386446 ] ASF GitHub Bot commented on CLOUDSTACK-10318: - rafaelweingartner opened a new pull request #2478: [CLOUDSTACK-10318] Bug on sorting ACL rules list in chrome URL: https://github.com/apache/cloudstack/pull/2478 There is a bug on ACL rules list when a user creates more than 10 rules. Steps to reproduce this issue: - Create more than 10 ACL rules. - Access the ACL rules list page. - You will see that they are not sorted as they should by the ACL rule number This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Bug on sorting ACL rules list in chrome > > > Key: CLOUDSTACK-10318 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10318 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > Fix For: 4.12 > > > There is a bug on ACL rules list when a user creates more than 10 rules. > #Steps to reproduce this issue > - Create more than 10 ACL rules. > - Access the ACL rules list page. > - You will see that they are not sorted as they should by the ACL rule number -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CLOUDSTACK-10318) Bug on sorting ACL rules list in chrome
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10318?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner updated CLOUDSTACK-10318: Status: Reviewable (was: In Progress) > Bug on sorting ACL rules list in chrome > > > Key: CLOUDSTACK-10318 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10318 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > Fix For: 4.12 > > > There is a bug on ACL rules list when a user creates more than 10 rules. > #Steps to reproduce this issue > - Create more than 10 ACL rules. > - Access the ACL rules list page. > - You will see that they are not sorted as they should by the ACL rule number -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CLOUDSTACK-10318) Bug on sorting ACL rules list in chrome
Rafael Weingärtner created CLOUDSTACK-10318: --- Summary: Bug on sorting ACL rules list in chrome Key: CLOUDSTACK-10318 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10318 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Rafael Weingärtner Assignee: Rafael Weingärtner Fix For: 4.12 There is a bug on ACL rules list when a user creates more than 10 rules. #Steps to reproduce this issue - Create more than 10 ACL rules. - Access the ACL rules list page. - You will see that they are not sorted as they should by the ACL rule number -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10240) ACS cannot migrate a volume from local to shared storage (for XenServer)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386388#comment-16386388 ] ASF GitHub Bot commented on CLOUDSTACK-10240: - blueorangutan commented on issue #2425: [CLOUDSTACK-10240] ACS cannot migrate a local volume to shared storage URL: https://github.com/apache/cloudstack/pull/2425#issuecomment-370493732 Trillian test result (tid-2312) Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7 Total time taken: 28936 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2425-t2312-kvm-centos7.zip Intermitten failure detected: /marvin/tests/smoke/test_deploy_virtio_scsi_vm.py Intermitten failure detected: /marvin/tests/smoke/test_outofbandmanagement.py Intermitten failure detected: /marvin/tests/smoke/test_vpc_redundant.py Intermitten failure detected: /marvin/tests/smoke/test_vpc_vpn.py Intermitten failure detected: /marvin/tests/smoke/test_hostha_kvm.py Smoke tests completed. 66 look OK, 1 have error(s) Only failed tests results shown below: Test | Result | Time (s) | Test File --- | --- | --- | --- test_hostha_enable_ha_when_host_in_maintenance | `Error` | 1.86 | test_hostha_kvm.py This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > ACS cannot migrate a volume from local to shared storage (for XenServer) > > > Key: CLOUDSTACK-10240 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10240 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > CloudStack is logically restricting the migration of local storages to shared > storage and vice versa. This restriction is a logical one and can be removed > for XenServer deployments. Therefore, we will enable migration of volumes > between local-shared storages in XenServers independently of their service > offering. This will work as an override mechanism to the disk offering used > by volumes. If administrators want to migrate local volumes to a shared > storage, they should be able to do so (the hypervisor already allows that). > The same the other way around. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10317) In case of multiple-public ips, snat fails to work for addtional public nics/network for guest traffic
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386346#comment-16386346 ] ASF GitHub Bot commented on CLOUDSTACK-10317: - rafaelweingartner commented on a change in pull request #2476: CLOUDSTACK-10317: Fix SNAT rules for additional public nics URL: https://github.com/apache/cloudstack/pull/2476#discussion_r172254964 ## File path: systemvm/debian/opt/cloud/bin/cs/CsAddress.py ## @@ -388,7 +388,7 @@ def fw_router(self): self.fw.append(["mangle", "", "-A VPN_%s -j RETURN" % self.address['public_ip']]) self.fw.append(["nat", "", -"-A POSTROUTING -o eth2 -j SNAT --to-source %s" % self.address['public_ip']]) +"-A POSTROUTING -o %s -j SNAT --to-source %s" % (self.dev, self.address['public_ip'])]) Review comment: Thanks for the explanation. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > In case of multiple-public ips, snat fails to work for addtional public > nics/network for guest traffic > -- > > Key: CLOUDSTACK-10317 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10317 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Minor > Fix For: 4.12.0.0, 4.11.1.0 > > > If a VR has two+ public nics, traffic from guest VM fails to be NAT-ed > correctly for traffic towards additional public nics. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10317) In case of multiple-public ips, snat fails to work for addtional public nics/network for guest traffic
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386343#comment-16386343 ] ASF GitHub Bot commented on CLOUDSTACK-10317: - rhtyd commented on a change in pull request #2476: CLOUDSTACK-10317: Fix SNAT rules for additional public nics URL: https://github.com/apache/cloudstack/pull/2476#discussion_r172254521 ## File path: systemvm/debian/opt/cloud/bin/cs/CsAddress.py ## @@ -388,7 +388,7 @@ def fw_router(self): self.fw.append(["mangle", "", "-A VPN_%s -j RETURN" % self.address['public_ip']]) self.fw.append(["nat", "", -"-A POSTROUTING -o eth2 -j SNAT --to-source %s" % self.address['public_ip']]) +"-A POSTROUTING -o %s -j SNAT --to-source %s" % (self.dev, self.address['public_ip'])]) Review comment: Yes @rafaelweingartner, the logic is same what is being used in vpc routers, see - https://github.com/apache/cloudstack/blob/4.11/systemvm/debian/opt/cloud/bin/cs/CsAddress.py#L584 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > In case of multiple-public ips, snat fails to work for addtional public > nics/network for guest traffic > -- > > Key: CLOUDSTACK-10317 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10317 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Minor > Fix For: 4.12.0.0, 4.11.1.0 > > > If a VR has two+ public nics, traffic from guest VM fails to be NAT-ed > correctly for traffic towards additional public nics. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10317) In case of multiple-public ips, snat fails to work for addtional public nics/network for guest traffic
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386344#comment-16386344 ] ASF GitHub Bot commented on CLOUDSTACK-10317: - rhtyd commented on a change in pull request #2476: CLOUDSTACK-10317: Fix SNAT rules for additional public nics URL: https://github.com/apache/cloudstack/pull/2476#discussion_r172254521 ## File path: systemvm/debian/opt/cloud/bin/cs/CsAddress.py ## @@ -388,7 +388,7 @@ def fw_router(self): self.fw.append(["mangle", "", "-A VPN_%s -j RETURN" % self.address['public_ip']]) self.fw.append(["nat", "", -"-A POSTROUTING -o eth2 -j SNAT --to-source %s" % self.address['public_ip']]) +"-A POSTROUTING -o %s -j SNAT --to-source %s" % (self.dev, self.address['public_ip'])]) Review comment: Yes @rafaelweingartner, the logic is same what as in vpc routers, see - https://github.com/apache/cloudstack/blob/4.11/systemvm/debian/opt/cloud/bin/cs/CsAddress.py#L584 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > In case of multiple-public ips, snat fails to work for addtional public > nics/network for guest traffic > -- > > Key: CLOUDSTACK-10317 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10317 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Minor > Fix For: 4.12.0.0, 4.11.1.0 > > > If a VR has two+ public nics, traffic from guest VM fails to be NAT-ed > correctly for traffic towards additional public nics. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10317) In case of multiple-public ips, snat fails to work for addtional public nics/network for guest traffic
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386330#comment-16386330 ] ASF GitHub Bot commented on CLOUDSTACK-10317: - rafaelweingartner commented on a change in pull request #2476: CLOUDSTACK-10317: Fix SNAT rules for additional public nics URL: https://github.com/apache/cloudstack/pull/2476#discussion_r172252984 ## File path: systemvm/debian/opt/cloud/bin/cs/CsAddress.py ## @@ -388,7 +388,7 @@ def fw_router(self): self.fw.append(["mangle", "", "-A VPN_%s -j RETURN" % self.address['public_ip']]) self.fw.append(["nat", "", -"-A POSTROUTING -o eth2 -j SNAT --to-source %s" % self.address['public_ip']]) +"-A POSTROUTING -o %s -j SNAT --to-source %s" % (self.dev, self.address['public_ip'])]) Review comment: The attribute `self.dev` is already populated with the correct device name? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > In case of multiple-public ips, snat fails to work for addtional public > nics/network for guest traffic > -- > > Key: CLOUDSTACK-10317 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10317 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Minor > Fix For: 4.12.0.0, 4.11.1.0 > > > If a VR has two+ public nics, traffic from guest VM fails to be NAT-ed > correctly for traffic towards additional public nics. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10317) In case of multiple-public ips, snat fails to work for addtional public nics/network for guest traffic
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386328#comment-16386328 ] ASF GitHub Bot commented on CLOUDSTACK-10317: - blueorangutan commented on issue #2476: CLOUDSTACK-10317: Fix SNAT rules for additional public nics URL: https://github.com/apache/cloudstack/pull/2476#issuecomment-370483999 @rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > In case of multiple-public ips, snat fails to work for addtional public > nics/network for guest traffic > -- > > Key: CLOUDSTACK-10317 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10317 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Minor > Fix For: 4.12.0.0, 4.11.1.0 > > > If a VR has two+ public nics, traffic from guest VM fails to be NAT-ed > correctly for traffic towards additional public nics. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10317) In case of multiple-public ips, snat fails to work for addtional public nics/network for guest traffic
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386326#comment-16386326 ] ASF GitHub Bot commented on CLOUDSTACK-10317: - rhtyd commented on issue #2476: CLOUDSTACK-10317: Fix SNAT rules for additional public nics URL: https://github.com/apache/cloudstack/pull/2476#issuecomment-370483846 @blueorangutan test This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > In case of multiple-public ips, snat fails to work for addtional public > nics/network for guest traffic > -- > > Key: CLOUDSTACK-10317 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10317 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Minor > Fix For: 4.12.0.0, 4.11.1.0 > > > If a VR has two+ public nics, traffic from guest VM fails to be NAT-ed > correctly for traffic towards additional public nics. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10317) In case of multiple-public ips, snat fails to work for addtional public nics/network for guest traffic
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386320#comment-16386320 ] ASF GitHub Bot commented on CLOUDSTACK-10317: - blueorangutan commented on issue #2476: CLOUDSTACK-10317: Fix SNAT rules for additional public nics URL: https://github.com/apache/cloudstack/pull/2476#issuecomment-370482352 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1753 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > In case of multiple-public ips, snat fails to work for addtional public > nics/network for guest traffic > -- > > Key: CLOUDSTACK-10317 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10317 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Minor > Fix For: 4.12.0.0, 4.11.1.0 > > > If a VR has two+ public nics, traffic from guest VM fails to be NAT-ed > correctly for traffic towards additional public nics. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10317) In case of multiple-public ips, snat fails to work for addtional public nics/network for guest traffic
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386273#comment-16386273 ] ASF GitHub Bot commented on CLOUDSTACK-10317: - blueorangutan commented on issue #2476: CLOUDSTACK-10317: Fix SNAT rules for additional public nics URL: https://github.com/apache/cloudstack/pull/2476#issuecomment-370468577 @rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > In case of multiple-public ips, snat fails to work for addtional public > nics/network for guest traffic > -- > > Key: CLOUDSTACK-10317 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10317 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Minor > Fix For: 4.12.0.0, 4.11.1.0 > > > If a VR has two+ public nics, traffic from guest VM fails to be NAT-ed > correctly for traffic towards additional public nics. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10317) In case of multiple-public ips, snat fails to work for addtional public nics/network for guest traffic
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386272#comment-16386272 ] ASF GitHub Bot commented on CLOUDSTACK-10317: - rhtyd commented on issue #2476: CLOUDSTACK-10317: Fix SNAT rules for additional public nics URL: https://github.com/apache/cloudstack/pull/2476#issuecomment-370468520 @blueorangutan package This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > In case of multiple-public ips, snat fails to work for addtional public > nics/network for guest traffic > -- > > Key: CLOUDSTACK-10317 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10317 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Minor > Fix For: 4.12.0.0, 4.11.1.0 > > > If a VR has two+ public nics, traffic from guest VM fails to be NAT-ed > correctly for traffic towards additional public nics. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CLOUDSTACK-10317) In case of multiple-public ips, snat fails to work for addtional public nics/network for guest traffic
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10317?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav updated CLOUDSTACK-10317: - Priority: Minor (was: Major) > In case of multiple-public ips, snat fails to work for addtional public > nics/network for guest traffic > -- > > Key: CLOUDSTACK-10317 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10317 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Minor > Fix For: 4.12.0.0, 4.11.1.0 > > > If a VR has two+ public nics, traffic from guest VM fails to be NAT-ed > correctly for traffic towards additional public nics. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10317) In case of multiple-public ips, snat fails to work for addtional public nics/network for guest traffic
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386271#comment-16386271 ] ASF GitHub Bot commented on CLOUDSTACK-10317: - rhtyd commented on issue #2476: CLOUDSTACK-10317: Fix SNAT rules for additional public nics URL: https://github.com/apache/cloudstack/pull/2476#issuecomment-370467906 Same logic in vpc: https://github.com/apache/cloudstack/blob/4.11/systemvm/debian/opt/cloud/bin/cs/CsAddress.py#L584 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > In case of multiple-public ips, snat fails to work for addtional public > nics/network for guest traffic > -- > > Key: CLOUDSTACK-10317 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10317 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: 4.12.0.0, 4.11.1.0 > > > If a VR has two+ public nics, traffic from guest VM fails to be NAT-ed > correctly for traffic towards additional public nics. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10317) In case of multiple-public ips, snat fails to work for addtional public nics/network for guest traffic
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386268#comment-16386268 ] ASF GitHub Bot commented on CLOUDSTACK-10317: - rhtyd commented on issue #2476: CLOUDSTACK-10317: Fix SNAT rules for additional public nics URL: https://github.com/apache/cloudstack/pull/2476#issuecomment-370467906 Same logic in vpc: https://github.com/apache/cloudstack/blob/4.11/systemvm/debian/opt/cloud/bin/cs/CsAddress.py#L480 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > In case of multiple-public ips, snat fails to work for addtional public > nics/network for guest traffic > -- > > Key: CLOUDSTACK-10317 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10317 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: 4.12.0.0, 4.11.1.0 > > > If a VR has two+ public nics, traffic from guest VM fails to be NAT-ed > correctly for traffic towards additional public nics. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10317) In case of multiple-public ips, snat fails to work for addtional public nics/network for guest traffic
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10317?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386230#comment-16386230 ] ASF GitHub Bot commented on CLOUDSTACK-10317: - rhtyd opened a new pull request #2476: CLOUDSTACK-10317: Fix SNAT rules for additional public nics URL: https://github.com/apache/cloudstack/pull/2476 This allows networks with additional public nics to have correct SNAT iptables rules applied on configuration. Pinging for review - @ustcweizhou @PaulAngus @DagSonstebo and others. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > In case of multiple-public ips, snat fails to work for addtional public > nics/network for guest traffic > -- > > Key: CLOUDSTACK-10317 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10317 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: 4.12.0.0, 4.11.1.0 > > > If a VR has two+ public nics, traffic from guest VM fails to be NAT-ed > correctly for traffic towards additional public nics. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CLOUDSTACK-10315) Inconsistent debugging info in catch block
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhenhao Li updated CLOUDSTACK-10315: Issue Type: Bug (was: Improvement) > Inconsistent debugging info in catch block > -- > > Key: CLOUDSTACK-10315 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10315 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Zhenhao Li >Priority: Minor > Labels: easyfix > Attachments: image-2018-03-05-09-59-19-369.png, > image-2018-03-05-10-14-00-552.png, image-2018-03-05-10-14-25-802.png > > > We found that some logging statements have same log message, but one of them > has stack trace info, the other one of them doesn't have. Maybe a possible > reason is that they are code clone, developers changed one of them(add stack > trace info) but forgot to change the other one. Here's the details of those > logging statements we found: > > 1.*"Moving on to the next host because " + h.toString() + " is unavailable"*, > _com.cloud.hypervisor.ovm3.resources.Ovm3FenceBuilder.*fenceOff()*,_ > _com.cloud.ha.*SimulatorFencer()*_, > There are two identical log messages in these two places, the latter one > logged stack trace but the previous one did not. > !image-2018-03-05-09-59-19-369.png! > We can see that they are in different type of catch block, but when checking > the logs they generated, maybe it's impossible to know the difference of them > without stack trace. So maybe the stack traces info should also be added here? > > 2.*"Network rule Conflict"* > _org.apache.cloudstack.api.command.user.firewall.CreatePortForwardingRuleCmd.*create()*,_ > _org.apache.cloudstack.api.command.user.firewall.CreateFirewallRuleCmd.*create()*_ > > The previous one has these two logging statements: > s_logger.info("Network rule conflict: ", ex); > s_logger.trace("Network Rule Conflict: ", ex); > > Comparing to the latter one which contains: > s_logger.info("Network rule conflict: " + ex.getMessage()); > s_logger.trace("Network Rule Conflict: ", ex); > Maybe it's better to have consistent exception handling here? > > 3.*"Failed to take snapshot: "* > _org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.*takeSnapshot()*,_ > _org.apache.cloudstack.storage.datastore.driver.ElastistorPrimaryDataStoreDriver.*takeSnapshot()*_ > The previous one has catch block: > !image-2018-03-05-10-14-00-552.png! > and the latter one: > !image-2018-03-05-10-14-25-802.png! > We can see that the code snippers are almost the same except the logging > statements. > Will it be better to change the latter one, to be consistent with the > previous one? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CLOUDSTACK-10316) Inconsistent logging level with same log messages
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhenhao Li updated CLOUDSTACK-10316: Issue Type: Bug (was: Improvement) > Inconsistent logging level with same log messages > - > > Key: CLOUDSTACK-10316 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10316 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Zhenhao Li >Priority: Minor > Labels: easyfix > > We found that some logging statements have same log message, but they have > different logging level. Maybe a possible reason is that they are code clone, > developers changed one of them(changed it's level) but forgot to change the > other one. Here's the details of those logging statements we found: > 1.*"Unexpected exception caught while removing network elements from OVF:"* > _com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.*removeOVFNetwork()*,_ > _com.cloud.agent.api.api.storage.OVFHelper.*rewriteOVFFile()*,_ > They catch the same exception type, but the previous one is warn level, and > the latter one is info level. Should they have consistent logging level? > > > 2.*"Nuage VSP Device with ID " + nuageVspDevice.getId() + " is configured > with an unknown CMS ID!"* > _com.cloud.network.manager.NuageVspManagerImpl.*executeSyncCmsId()*,_ > _com.cloud.network.manager.NuageVspManagerImpl.*auditHost()*_ > They have the same logging messages, but the previous one has fatal level, > the latter one has error level. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CLOUDSTACK-10315) Inconsistent debugging info in catch block
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10315?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhenhao Li updated CLOUDSTACK-10315: Issue Type: Improvement (was: Bug) > Inconsistent debugging info in catch block > -- > > Key: CLOUDSTACK-10315 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10315 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Zhenhao Li >Priority: Minor > Labels: easyfix > Attachments: image-2018-03-05-09-59-19-369.png, > image-2018-03-05-10-14-00-552.png, image-2018-03-05-10-14-25-802.png > > > We found that some logging statements have same log message, but one of them > has stack trace info, the other one of them doesn't have. Maybe a possible > reason is that they are code clone, developers changed one of them(add stack > trace info) but forgot to change the other one. Here's the details of those > logging statements we found: > > 1.*"Moving on to the next host because " + h.toString() + " is unavailable"*, > _com.cloud.hypervisor.ovm3.resources.Ovm3FenceBuilder.*fenceOff()*,_ > _com.cloud.ha.*SimulatorFencer()*_, > There are two identical log messages in these two places, the latter one > logged stack trace but the previous one did not. > !image-2018-03-05-09-59-19-369.png! > We can see that they are in different type of catch block, but when checking > the logs they generated, maybe it's impossible to know the difference of them > without stack trace. So maybe the stack traces info should also be added here? > > 2.*"Network rule Conflict"* > _org.apache.cloudstack.api.command.user.firewall.CreatePortForwardingRuleCmd.*create()*,_ > _org.apache.cloudstack.api.command.user.firewall.CreateFirewallRuleCmd.*create()*_ > > The previous one has these two logging statements: > s_logger.info("Network rule conflict: ", ex); > s_logger.trace("Network Rule Conflict: ", ex); > > Comparing to the latter one which contains: > s_logger.info("Network rule conflict: " + ex.getMessage()); > s_logger.trace("Network Rule Conflict: ", ex); > Maybe it's better to have consistent exception handling here? > > 3.*"Failed to take snapshot: "* > _org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.*takeSnapshot()*,_ > _org.apache.cloudstack.storage.datastore.driver.ElastistorPrimaryDataStoreDriver.*takeSnapshot()*_ > The previous one has catch block: > !image-2018-03-05-10-14-00-552.png! > and the latter one: > !image-2018-03-05-10-14-25-802.png! > We can see that the code snippers are almost the same except the logging > statements. > Will it be better to change the latter one, to be consistent with the > previous one? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CLOUDSTACK-10316) Inconsistent logging level with same log messages
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10316?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Zhenhao Li updated CLOUDSTACK-10316: Issue Type: Improvement (was: Bug) > Inconsistent logging level with same log messages > - > > Key: CLOUDSTACK-10316 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10316 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Zhenhao Li >Priority: Minor > Labels: easyfix > > We found that some logging statements have same log message, but they have > different logging level. Maybe a possible reason is that they are code clone, > developers changed one of them(changed it's level) but forgot to change the > other one. Here's the details of those logging statements we found: > 1.*"Unexpected exception caught while removing network elements from OVF:"* > _com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.*removeOVFNetwork()*,_ > _com.cloud.agent.api.api.storage.OVFHelper.*rewriteOVFFile()*,_ > They catch the same exception type, but the previous one is warn level, and > the latter one is info level. Should they have consistent logging level? > > > 2.*"Nuage VSP Device with ID " + nuageVspDevice.getId() + " is configured > with an unknown CMS ID!"* > _com.cloud.network.manager.NuageVspManagerImpl.*executeSyncCmsId()*,_ > _com.cloud.network.manager.NuageVspManagerImpl.*auditHost()*_ > They have the same logging messages, but the previous one has fatal level, > the latter one has error level. > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CLOUDSTACK-10317) In case of multiple-public ips, snat fails to work for addtional public nics/network for guest traffic
Rohit Yadav created CLOUDSTACK-10317: Summary: In case of multiple-public ips, snat fails to work for addtional public nics/network for guest traffic Key: CLOUDSTACK-10317 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10317 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Rohit Yadav Assignee: Rohit Yadav Fix For: 4.12.0.0, 4.11.1.0 If a VR has two+ public nics, traffic from guest VM fails to be NAT-ed correctly for traffic towards additional public nics. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CLOUDSTACK-10316) Inconsistent logging level with same log messages
Zhenhao Li created CLOUDSTACK-10316: --- Summary: Inconsistent logging level with same log messages Key: CLOUDSTACK-10316 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10316 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Zhenhao Li We found that some logging statements have same log message, but they have different logging level. Maybe a possible reason is that they are code clone, developers changed one of them(changed it's level) but forgot to change the other one. Here's the details of those logging statements we found: 1.*"Unexpected exception caught while removing network elements from OVF:"* _com.cloud.hypervisor.vmware.mo.HypervisorHostHelper.*removeOVFNetwork()*,_ _com.cloud.agent.api.api.storage.OVFHelper.*rewriteOVFFile()*,_ They catch the same exception type, but the previous one is warn level, and the latter one is info level. Should they have consistent logging level? 2.*"Nuage VSP Device with ID " + nuageVspDevice.getId() + " is configured with an unknown CMS ID!"* _com.cloud.network.manager.NuageVspManagerImpl.*executeSyncCmsId()*,_ _com.cloud.network.manager.NuageVspManagerImpl.*auditHost()*_ They have the same logging messages, but the previous one has fatal level, the latter one has error level. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CLOUDSTACK-10315) Inconsistent debugging info in catch block
Zhenhao Li created CLOUDSTACK-10315: --- Summary: Inconsistent debugging info in catch block Key: CLOUDSTACK-10315 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10315 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Reporter: Zhenhao Li Attachments: image-2018-03-05-09-59-19-369.png, image-2018-03-05-10-14-00-552.png, image-2018-03-05-10-14-25-802.png We found that some logging statements have same log message, but one of them has stack trace info, the other one of them doesn't have. Maybe a possible reason is that they are code clone, developers changed one of them(add stack trace info) but forgot to change the other one. Here's the details of those logging statements we found: 1.*"Moving on to the next host because " + h.toString() + " is unavailable"*, _com.cloud.hypervisor.ovm3.resources.Ovm3FenceBuilder.*fenceOff()*,_ _com.cloud.ha.*SimulatorFencer()*_, There are two identical log messages in these two places, the latter one logged stack trace but the previous one did not. !image-2018-03-05-09-59-19-369.png! We can see that they are in different type of catch block, but when checking the logs they generated, maybe it's impossible to know the difference of them without stack trace. So maybe the stack traces info should also be added here? 2.*"Network rule Conflict"* _org.apache.cloudstack.api.command.user.firewall.CreatePortForwardingRuleCmd.*create()*,_ _org.apache.cloudstack.api.command.user.firewall.CreateFirewallRuleCmd.*create()*_ The previous one has these two logging statements: s_logger.info("Network rule conflict: ", ex); s_logger.trace("Network Rule Conflict: ", ex); Comparing to the latter one which contains: s_logger.info("Network rule conflict: " + ex.getMessage()); s_logger.trace("Network Rule Conflict: ", ex); Maybe it's better to have consistent exception handling here? 3.*"Failed to take snapshot: "* _org.apache.cloudstack.storage.snapshot.SnapshotServiceImpl.*takeSnapshot()*,_ _org.apache.cloudstack.storage.datastore.driver.ElastistorPrimaryDataStoreDriver.*takeSnapshot()*_ The previous one has catch block: !image-2018-03-05-10-14-00-552.png! and the latter one: !image-2018-03-05-10-14-25-802.png! We can see that the code snippers are almost the same except the logging statements. Will it be better to change the latter one, to be consistent with the previous one? -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10274) L2 network refused to be designed on VXLAN physical network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386045#comment-16386045 ] ASF GitHub Bot commented on CLOUDSTACK-10274: - blueorangutan commented on issue #2448: CLOUDSTACK-10274: L2 network refused to be designed on VXLAN physical network URL: https://github.com/apache/cloudstack/pull/2448#issuecomment-370412972 @nvazquez a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > L2 network refused to be designed on VXLAN physical network > > > Key: CLOUDSTACK-10274 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10274 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0 >Reporter: Nicolas Vazquez >Priority: Major > Fix For: 4.11.1.1 > > > Issue reported by [~nuxro] while trying to add an L2 network on a VXLAN > physical network: > 2018-02-06 11:20:27,748 DEBUG [c.c.n.NetworkServiceImpl] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Found physical > network id=201 based on requested tags mellanoxvxlan > 2018-02-06 11:20:27,749 DEBUG [c.c.n.NetworkServiceImpl] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Found physical > network id=201 based on requested tags mellanoxvxlan > 2018-02-06 11:20:27,766 DEBUG [c.c.n.g.BigSwitchBcfGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network, the physical isolation type is not BCF_SEGMENT > 2018-02-06 11:20:27,766 DEBUG [o.a.c.n.c.m.ContrailGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,767 DEBUG [c.c.n.g.NiciraNvpGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,767 DEBUG [o.a.c.n.o.OpendaylightGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,767 DEBUG [c.c.n.g.OvsGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,769 DEBUG [o.a.c.n.g.SspGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) SSP not > configured to be active > 2018-02-06 11:20:27,769 DEBUG [c.c.n.g.BrocadeVcsGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,769 DEBUG [c.c.n.g.NuageVspGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design network using network offering 19 on physical network 201 > 2018-02-06 11:20:27,770 DEBUG [o.a.c.e.o.NetworkOrchestrator] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Releasing lock > for Acct[6af2875b-04fc-11e8-923e-002590474525-admin] > 2018-02-06 11:20:27,789 DEBUG [c.c.u.d.T.Transaction] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Rolling back > the transaction: Time = 38 Name = qtp788117692-390; called by > -TransactionLegacy.rollback:889-TransactionLegacy.removeUpTo:832-TransactionLegacy.close:656-Transaction.execute:43-Transaction.execute:47-NetworkOrchestrator.createGuestNetwork:2315-NetworkServiceImpl$4.doInTransaction:1383-NetworkServiceImpl$4.doInTransaction:1331-Transaction.execute:40-NetworkServiceImpl.commitNetwork:1331-NetworkServiceImpl.createGuestNetwork:1294-NativeMethodAccessorImpl.invoke0:-2 > 2018-02-06 11:20:27,798 ERROR [c.c.a.ApiServer] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) unhandled > exception executing api command: [Ljava.lang.String;@43b9df02 > com.cloud.utils.exception.CloudRuntimeException: Unable to convert network > offering with specified id to network profile > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.setupNetwork(NetworkOrchestrator.java:726) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator$10.doInTransaction(NetworkOrchestrator.java:2364) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator$10.doInTransaction(NetworkOrchestrator.java:2315) > at > com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:50) > at com.cloud.utils.db.Transaction.execute(Transaction.java:40)
[jira] [Commented] (CLOUDSTACK-10274) L2 network refused to be designed on VXLAN physical network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386043#comment-16386043 ] ASF GitHub Bot commented on CLOUDSTACK-10274: - nvazquez commented on issue #2448: CLOUDSTACK-10274: L2 network refused to be designed on VXLAN physical network URL: https://github.com/apache/cloudstack/pull/2448#issuecomment-370412798 @blueorangutan test This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > L2 network refused to be designed on VXLAN physical network > > > Key: CLOUDSTACK-10274 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10274 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0 >Reporter: Nicolas Vazquez >Priority: Major > Fix For: 4.11.1.1 > > > Issue reported by [~nuxro] while trying to add an L2 network on a VXLAN > physical network: > 2018-02-06 11:20:27,748 DEBUG [c.c.n.NetworkServiceImpl] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Found physical > network id=201 based on requested tags mellanoxvxlan > 2018-02-06 11:20:27,749 DEBUG [c.c.n.NetworkServiceImpl] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Found physical > network id=201 based on requested tags mellanoxvxlan > 2018-02-06 11:20:27,766 DEBUG [c.c.n.g.BigSwitchBcfGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network, the physical isolation type is not BCF_SEGMENT > 2018-02-06 11:20:27,766 DEBUG [o.a.c.n.c.m.ContrailGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,767 DEBUG [c.c.n.g.NiciraNvpGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,767 DEBUG [o.a.c.n.o.OpendaylightGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,767 DEBUG [c.c.n.g.OvsGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,769 DEBUG [o.a.c.n.g.SspGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) SSP not > configured to be active > 2018-02-06 11:20:27,769 DEBUG [c.c.n.g.BrocadeVcsGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,769 DEBUG [c.c.n.g.NuageVspGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design network using network offering 19 on physical network 201 > 2018-02-06 11:20:27,770 DEBUG [o.a.c.e.o.NetworkOrchestrator] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Releasing lock > for Acct[6af2875b-04fc-11e8-923e-002590474525-admin] > 2018-02-06 11:20:27,789 DEBUG [c.c.u.d.T.Transaction] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Rolling back > the transaction: Time = 38 Name = qtp788117692-390; called by > -TransactionLegacy.rollback:889-TransactionLegacy.removeUpTo:832-TransactionLegacy.close:656-Transaction.execute:43-Transaction.execute:47-NetworkOrchestrator.createGuestNetwork:2315-NetworkServiceImpl$4.doInTransaction:1383-NetworkServiceImpl$4.doInTransaction:1331-Transaction.execute:40-NetworkServiceImpl.commitNetwork:1331-NetworkServiceImpl.createGuestNetwork:1294-NativeMethodAccessorImpl.invoke0:-2 > 2018-02-06 11:20:27,798 ERROR [c.c.a.ApiServer] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) unhandled > exception executing api command: [Ljava.lang.String;@43b9df02 > com.cloud.utils.exception.CloudRuntimeException: Unable to convert network > offering with specified id to network profile > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.setupNetwork(NetworkOrchestrator.java:726) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator$10.doInTransaction(NetworkOrchestrator.java:2364) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator$10.doInTransaction(NetworkOrchestrator.java:2315) > at > com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:50) > at com.cloud.utils.db.Transaction.execute(Transaction.java:40) > at com.cloud.utils.db.Transaction.execute(Transaction.java:47) -- This mes
[jira] [Commented] (CLOUDSTACK-10274) L2 network refused to be designed on VXLAN physical network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386036#comment-16386036 ] ASF GitHub Bot commented on CLOUDSTACK-10274: - blueorangutan commented on issue #2448: CLOUDSTACK-10274: L2 network refused to be designed on VXLAN physical network URL: https://github.com/apache/cloudstack/pull/2448#issuecomment-370411609 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1752 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > L2 network refused to be designed on VXLAN physical network > > > Key: CLOUDSTACK-10274 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10274 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0 >Reporter: Nicolas Vazquez >Priority: Major > Fix For: 4.11.1.1 > > > Issue reported by [~nuxro] while trying to add an L2 network on a VXLAN > physical network: > 2018-02-06 11:20:27,748 DEBUG [c.c.n.NetworkServiceImpl] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Found physical > network id=201 based on requested tags mellanoxvxlan > 2018-02-06 11:20:27,749 DEBUG [c.c.n.NetworkServiceImpl] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Found physical > network id=201 based on requested tags mellanoxvxlan > 2018-02-06 11:20:27,766 DEBUG [c.c.n.g.BigSwitchBcfGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network, the physical isolation type is not BCF_SEGMENT > 2018-02-06 11:20:27,766 DEBUG [o.a.c.n.c.m.ContrailGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,767 DEBUG [c.c.n.g.NiciraNvpGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,767 DEBUG [o.a.c.n.o.OpendaylightGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,767 DEBUG [c.c.n.g.OvsGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,769 DEBUG [o.a.c.n.g.SspGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) SSP not > configured to be active > 2018-02-06 11:20:27,769 DEBUG [c.c.n.g.BrocadeVcsGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,769 DEBUG [c.c.n.g.NuageVspGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design network using network offering 19 on physical network 201 > 2018-02-06 11:20:27,770 DEBUG [o.a.c.e.o.NetworkOrchestrator] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Releasing lock > for Acct[6af2875b-04fc-11e8-923e-002590474525-admin] > 2018-02-06 11:20:27,789 DEBUG [c.c.u.d.T.Transaction] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Rolling back > the transaction: Time = 38 Name = qtp788117692-390; called by > -TransactionLegacy.rollback:889-TransactionLegacy.removeUpTo:832-TransactionLegacy.close:656-Transaction.execute:43-Transaction.execute:47-NetworkOrchestrator.createGuestNetwork:2315-NetworkServiceImpl$4.doInTransaction:1383-NetworkServiceImpl$4.doInTransaction:1331-Transaction.execute:40-NetworkServiceImpl.commitNetwork:1331-NetworkServiceImpl.createGuestNetwork:1294-NativeMethodAccessorImpl.invoke0:-2 > 2018-02-06 11:20:27,798 ERROR [c.c.a.ApiServer] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) unhandled > exception executing api command: [Ljava.lang.String;@43b9df02 > com.cloud.utils.exception.CloudRuntimeException: Unable to convert network > offering with specified id to network profile > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.setupNetwork(NetworkOrchestrator.java:726) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator$10.doInTransaction(NetworkOrchestrator.java:2364) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator$10.doInTransaction(NetworkOrchestrator.java:2315) > at > com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:50) > at com.cloud.utils.db.Transaction.execute(Transaction.java:40) > at com.cloud.utils.db.Transaction.exec
[jira] [Commented] (CLOUDSTACK-10314) Add Text-Field to each ACL Rule
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386011#comment-16386011 ] ASF GitHub Bot commented on CLOUDSTACK-10314: - rafaelweingartner commented on issue #2475: [CLOUDSTACK-10314] Add Text-Field to each ACL Rule URL: https://github.com/apache/cloudstack/pull/2475#issuecomment-370405145 I was checking that tag thing there, and it is a bit too generic in my opinion. I could change the UI to use those fields (I would also need to increase the size of those fields), but I do prefer a not so generic solution as this one, where the description/history field becomes part of the ACL rule API. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add Text-Field to each ACL Rule > > > Key: CLOUDSTACK-10314 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10314 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Minor > > It might be interesting to have a text field (e.g. CHAR-256) added to each > ACL rule, which allows to enter a "reason" for each FW Rule created. This is > valuable for customer documentation, as well as best practice for an evidence > towards auditing the system. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10274) L2 network refused to be designed on VXLAN physical network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386002#comment-16386002 ] ASF GitHub Bot commented on CLOUDSTACK-10274: - nvazquez commented on issue #2448: CLOUDSTACK-10274: L2 network refused to be designed on VXLAN physical network URL: https://github.com/apache/cloudstack/pull/2448#issuecomment-370402683 @blueorangutan package This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > L2 network refused to be designed on VXLAN physical network > > > Key: CLOUDSTACK-10274 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10274 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0 >Reporter: Nicolas Vazquez >Priority: Major > Fix For: 4.11.1.1 > > > Issue reported by [~nuxro] while trying to add an L2 network on a VXLAN > physical network: > 2018-02-06 11:20:27,748 DEBUG [c.c.n.NetworkServiceImpl] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Found physical > network id=201 based on requested tags mellanoxvxlan > 2018-02-06 11:20:27,749 DEBUG [c.c.n.NetworkServiceImpl] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Found physical > network id=201 based on requested tags mellanoxvxlan > 2018-02-06 11:20:27,766 DEBUG [c.c.n.g.BigSwitchBcfGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network, the physical isolation type is not BCF_SEGMENT > 2018-02-06 11:20:27,766 DEBUG [o.a.c.n.c.m.ContrailGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,767 DEBUG [c.c.n.g.NiciraNvpGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,767 DEBUG [o.a.c.n.o.OpendaylightGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,767 DEBUG [c.c.n.g.OvsGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,769 DEBUG [o.a.c.n.g.SspGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) SSP not > configured to be active > 2018-02-06 11:20:27,769 DEBUG [c.c.n.g.BrocadeVcsGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,769 DEBUG [c.c.n.g.NuageVspGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design network using network offering 19 on physical network 201 > 2018-02-06 11:20:27,770 DEBUG [o.a.c.e.o.NetworkOrchestrator] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Releasing lock > for Acct[6af2875b-04fc-11e8-923e-002590474525-admin] > 2018-02-06 11:20:27,789 DEBUG [c.c.u.d.T.Transaction] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Rolling back > the transaction: Time = 38 Name = qtp788117692-390; called by > -TransactionLegacy.rollback:889-TransactionLegacy.removeUpTo:832-TransactionLegacy.close:656-Transaction.execute:43-Transaction.execute:47-NetworkOrchestrator.createGuestNetwork:2315-NetworkServiceImpl$4.doInTransaction:1383-NetworkServiceImpl$4.doInTransaction:1331-Transaction.execute:40-NetworkServiceImpl.commitNetwork:1331-NetworkServiceImpl.createGuestNetwork:1294-NativeMethodAccessorImpl.invoke0:-2 > 2018-02-06 11:20:27,798 ERROR [c.c.a.ApiServer] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) unhandled > exception executing api command: [Ljava.lang.String;@43b9df02 > com.cloud.utils.exception.CloudRuntimeException: Unable to convert network > offering with specified id to network profile > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.setupNetwork(NetworkOrchestrator.java:726) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator$10.doInTransaction(NetworkOrchestrator.java:2364) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator$10.doInTransaction(NetworkOrchestrator.java:2315) > at > com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:50) > at com.cloud.utils.db.Transaction.execute(Transaction.java:40) > at com.cloud.utils.db.Transaction.execute(Transaction.java:47) -- This
[jira] [Commented] (CLOUDSTACK-10274) L2 network refused to be designed on VXLAN physical network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16386003#comment-16386003 ] ASF GitHub Bot commented on CLOUDSTACK-10274: - blueorangutan commented on issue #2448: CLOUDSTACK-10274: L2 network refused to be designed on VXLAN physical network URL: https://github.com/apache/cloudstack/pull/2448#issuecomment-370402817 @nvazquez a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > L2 network refused to be designed on VXLAN physical network > > > Key: CLOUDSTACK-10274 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10274 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0 >Reporter: Nicolas Vazquez >Priority: Major > Fix For: 4.11.1.1 > > > Issue reported by [~nuxro] while trying to add an L2 network on a VXLAN > physical network: > 2018-02-06 11:20:27,748 DEBUG [c.c.n.NetworkServiceImpl] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Found physical > network id=201 based on requested tags mellanoxvxlan > 2018-02-06 11:20:27,749 DEBUG [c.c.n.NetworkServiceImpl] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Found physical > network id=201 based on requested tags mellanoxvxlan > 2018-02-06 11:20:27,766 DEBUG [c.c.n.g.BigSwitchBcfGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network, the physical isolation type is not BCF_SEGMENT > 2018-02-06 11:20:27,766 DEBUG [o.a.c.n.c.m.ContrailGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,767 DEBUG [c.c.n.g.NiciraNvpGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,767 DEBUG [o.a.c.n.o.OpendaylightGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,767 DEBUG [c.c.n.g.OvsGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,769 DEBUG [o.a.c.n.g.SspGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) SSP not > configured to be active > 2018-02-06 11:20:27,769 DEBUG [c.c.n.g.BrocadeVcsGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,769 DEBUG [c.c.n.g.NuageVspGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design network using network offering 19 on physical network 201 > 2018-02-06 11:20:27,770 DEBUG [o.a.c.e.o.NetworkOrchestrator] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Releasing lock > for Acct[6af2875b-04fc-11e8-923e-002590474525-admin] > 2018-02-06 11:20:27,789 DEBUG [c.c.u.d.T.Transaction] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Rolling back > the transaction: Time = 38 Name = qtp788117692-390; called by > -TransactionLegacy.rollback:889-TransactionLegacy.removeUpTo:832-TransactionLegacy.close:656-Transaction.execute:43-Transaction.execute:47-NetworkOrchestrator.createGuestNetwork:2315-NetworkServiceImpl$4.doInTransaction:1383-NetworkServiceImpl$4.doInTransaction:1331-Transaction.execute:40-NetworkServiceImpl.commitNetwork:1331-NetworkServiceImpl.createGuestNetwork:1294-NativeMethodAccessorImpl.invoke0:-2 > 2018-02-06 11:20:27,798 ERROR [c.c.a.ApiServer] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) unhandled > exception executing api command: [Ljava.lang.String;@43b9df02 > com.cloud.utils.exception.CloudRuntimeException: Unable to convert network > offering with specified id to network profile > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.setupNetwork(NetworkOrchestrator.java:726) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator$10.doInTransaction(NetworkOrchestrator.java:2364) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator$10.doInTransaction(NetworkOrchestrator.java:2315) > at > com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:50) > at com.cloud.utils.db.Transaction.execute(Transaction.java:40) >
[jira] [Commented] (CLOUDSTACK-10314) Add Text-Field to each ACL Rule
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16385975#comment-16385975 ] ASF GitHub Bot commented on CLOUDSTACK-10314: - rafaelweingartner commented on issue #2475: [CLOUDSTACK-10314] Add Text-Field to each ACL Rule URL: https://github.com/apache/cloudstack/pull/2475#issuecomment-370391836 So, that option has nothing to do with ACS tagging system? I meant those tags used in hosts and storage. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add Text-Field to each ACL Rule > > > Key: CLOUDSTACK-10314 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10314 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Minor > > It might be interesting to have a text field (e.g. CHAR-256) added to each > ACL rule, which allows to enter a "reason" for each FW Rule created. This is > valuable for customer documentation, as well as best practice for an evidence > towards auditing the system. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10314) Add Text-Field to each ACL Rule
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16385974#comment-16385974 ] ASF GitHub Bot commented on CLOUDSTACK-10314: - rafaelweingartner commented on issue #2475: [CLOUDSTACK-10314] Add Text-Field to each ACL Rule URL: https://github.com/apache/cloudstack/pull/2475#issuecomment-370391836 So, that option has nothing to do with ACS tagging system? This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add Text-Field to each ACL Rule > > > Key: CLOUDSTACK-10314 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10314 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Minor > > It might be interesting to have a text field (e.g. CHAR-256) added to each > ACL rule, which allows to enter a "reason" for each FW Rule created. This is > valuable for customer documentation, as well as best practice for an evidence > towards auditing the system. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10314) Add Text-Field to each ACL Rule
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16385970#comment-16385970 ] ASF GitHub Bot commented on CLOUDSTACK-10314: - DaanHoogland commented on issue #2475: [CLOUDSTACK-10314] Add Text-Field to each ACL Rule URL: https://github.com/apache/cloudstack/pull/2475#issuecomment-370391319 ok, so there is a UI issue there. It is meant to be a an audit trail on updates. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add Text-Field to each ACL Rule > > > Key: CLOUDSTACK-10314 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10314 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Minor > > It might be interesting to have a text field (e.g. CHAR-256) added to each > ACL rule, which allows to enter a "reason" for each FW Rule created. This is > valuable for customer documentation, as well as best practice for an evidence > towards auditing the system. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10197) XenServer 7.1: Cannot mount xentool iso from cloudstack on VMs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16385961#comment-16385961 ] ASF GitHub Bot commented on CLOUDSTACK-10197: - DaanHoogland commented on issue #2470: [CLOUDSTACK-10197] Update DisplayText of XenServer tools ISO entry in the database when it already exists URL: https://github.com/apache/cloudstack/pull/2470#issuecomment-370388456 @blueorangutan test This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > XenServer 7.1: Cannot mount xentool iso from cloudstack on VMs > --- > > Key: CLOUDSTACK-10197 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10197 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0 > Environment: XenServer 7.0+ >Reporter: Khosrow Moossavi >Priority: Major > Fix For: 4.11.0.0 > > > In XenServer 7.0+ xentools iso has been renamed from *xs-tools* to > *guest-tools* so CloudStack fails to attach it to any VM. > {code} > (acs-admin) > attach iso > virtualmachineid=d13eeff1-2d99-46a9-8fc5-3510df6e9f5e > id=e8a56540-0fc3-44de-9911-635d2d8f25c4 > errorcode = 530 > errortext = Failed to attach iso > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10197) XenServer 7.1: Cannot mount xentool iso from cloudstack on VMs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16385962#comment-16385962 ] ASF GitHub Bot commented on CLOUDSTACK-10197: - blueorangutan commented on issue #2470: [CLOUDSTACK-10197] Update DisplayText of XenServer tools ISO entry in the database when it already exists URL: https://github.com/apache/cloudstack/pull/2470#issuecomment-370388632 @DaanHoogland a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > XenServer 7.1: Cannot mount xentool iso from cloudstack on VMs > --- > > Key: CLOUDSTACK-10197 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10197 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0 > Environment: XenServer 7.0+ >Reporter: Khosrow Moossavi >Priority: Major > Fix For: 4.11.0.0 > > > In XenServer 7.0+ xentools iso has been renamed from *xs-tools* to > *guest-tools* so CloudStack fails to attach it to any VM. > {code} > (acs-admin) > attach iso > virtualmachineid=d13eeff1-2d99-46a9-8fc5-3510df6e9f5e > id=e8a56540-0fc3-44de-9911-635d2d8f25c4 > errorcode = 530 > errortext = Failed to attach iso > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10274) L2 network refused to be designed on VXLAN physical network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16385951#comment-16385951 ] ASF GitHub Bot commented on CLOUDSTACK-10274: - nvazquez commented on issue #2448: CLOUDSTACK-10274: L2 network refused to be designed on VXLAN physical network URL: https://github.com/apache/cloudstack/pull/2448#issuecomment-370386912 Yes @NuxRo, it can be ignored as gurus are iterated, asking each one of them if they can design the network. Before reaching VxlanGuestNetworkGuru and successfully design it, it tried BigSwitchBcfGuestNetworkGuru (and others) and refused This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > L2 network refused to be designed on VXLAN physical network > > > Key: CLOUDSTACK-10274 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10274 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0 >Reporter: Nicolas Vazquez >Priority: Major > Fix For: 4.11.1.1 > > > Issue reported by [~nuxro] while trying to add an L2 network on a VXLAN > physical network: > 2018-02-06 11:20:27,748 DEBUG [c.c.n.NetworkServiceImpl] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Found physical > network id=201 based on requested tags mellanoxvxlan > 2018-02-06 11:20:27,749 DEBUG [c.c.n.NetworkServiceImpl] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Found physical > network id=201 based on requested tags mellanoxvxlan > 2018-02-06 11:20:27,766 DEBUG [c.c.n.g.BigSwitchBcfGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network, the physical isolation type is not BCF_SEGMENT > 2018-02-06 11:20:27,766 DEBUG [o.a.c.n.c.m.ContrailGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,767 DEBUG [c.c.n.g.NiciraNvpGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,767 DEBUG [o.a.c.n.o.OpendaylightGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,767 DEBUG [c.c.n.g.OvsGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,769 DEBUG [o.a.c.n.g.SspGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) SSP not > configured to be active > 2018-02-06 11:20:27,769 DEBUG [c.c.n.g.BrocadeVcsGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,769 DEBUG [c.c.n.g.NuageVspGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design network using network offering 19 on physical network 201 > 2018-02-06 11:20:27,770 DEBUG [o.a.c.e.o.NetworkOrchestrator] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Releasing lock > for Acct[6af2875b-04fc-11e8-923e-002590474525-admin] > 2018-02-06 11:20:27,789 DEBUG [c.c.u.d.T.Transaction] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Rolling back > the transaction: Time = 38 Name = qtp788117692-390; called by > -TransactionLegacy.rollback:889-TransactionLegacy.removeUpTo:832-TransactionLegacy.close:656-Transaction.execute:43-Transaction.execute:47-NetworkOrchestrator.createGuestNetwork:2315-NetworkServiceImpl$4.doInTransaction:1383-NetworkServiceImpl$4.doInTransaction:1331-Transaction.execute:40-NetworkServiceImpl.commitNetwork:1331-NetworkServiceImpl.createGuestNetwork:1294-NativeMethodAccessorImpl.invoke0:-2 > 2018-02-06 11:20:27,798 ERROR [c.c.a.ApiServer] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) unhandled > exception executing api command: [Ljava.lang.String;@43b9df02 > com.cloud.utils.exception.CloudRuntimeException: Unable to convert network > offering with specified id to network profile > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.setupNetwork(NetworkOrchestrator.java:726) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator$10.doInTransaction(NetworkOrchestrator.java:2364) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator$10.doInTransaction(NetworkOrchestrator.java:2315) > at > com.cloud
[jira] [Commented] (CLOUDSTACK-10274) L2 network refused to be designed on VXLAN physical network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16385950#comment-16385950 ] ASF GitHub Bot commented on CLOUDSTACK-10274: - nvazquez commented on issue #2448: CLOUDSTACK-10274: L2 network refused to be designed on VXLAN physical network URL: https://github.com/apache/cloudstack/pull/2448#issuecomment-370386912 Yes @NuxRo, it can be ignored as gurus are iterated, asking each one of them if they can design the network. Before reaching VxlanGuestNetworkGuru and successfully design it, it tried BigSwitchBcfGuestNetworkGuru and refused This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > L2 network refused to be designed on VXLAN physical network > > > Key: CLOUDSTACK-10274 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10274 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0 >Reporter: Nicolas Vazquez >Priority: Major > Fix For: 4.11.1.1 > > > Issue reported by [~nuxro] while trying to add an L2 network on a VXLAN > physical network: > 2018-02-06 11:20:27,748 DEBUG [c.c.n.NetworkServiceImpl] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Found physical > network id=201 based on requested tags mellanoxvxlan > 2018-02-06 11:20:27,749 DEBUG [c.c.n.NetworkServiceImpl] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Found physical > network id=201 based on requested tags mellanoxvxlan > 2018-02-06 11:20:27,766 DEBUG [c.c.n.g.BigSwitchBcfGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network, the physical isolation type is not BCF_SEGMENT > 2018-02-06 11:20:27,766 DEBUG [o.a.c.n.c.m.ContrailGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,767 DEBUG [c.c.n.g.NiciraNvpGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,767 DEBUG [o.a.c.n.o.OpendaylightGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,767 DEBUG [c.c.n.g.OvsGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,769 DEBUG [o.a.c.n.g.SspGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) SSP not > configured to be active > 2018-02-06 11:20:27,769 DEBUG [c.c.n.g.BrocadeVcsGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,769 DEBUG [c.c.n.g.NuageVspGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design network using network offering 19 on physical network 201 > 2018-02-06 11:20:27,770 DEBUG [o.a.c.e.o.NetworkOrchestrator] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Releasing lock > for Acct[6af2875b-04fc-11e8-923e-002590474525-admin] > 2018-02-06 11:20:27,789 DEBUG [c.c.u.d.T.Transaction] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Rolling back > the transaction: Time = 38 Name = qtp788117692-390; called by > -TransactionLegacy.rollback:889-TransactionLegacy.removeUpTo:832-TransactionLegacy.close:656-Transaction.execute:43-Transaction.execute:47-NetworkOrchestrator.createGuestNetwork:2315-NetworkServiceImpl$4.doInTransaction:1383-NetworkServiceImpl$4.doInTransaction:1331-Transaction.execute:40-NetworkServiceImpl.commitNetwork:1331-NetworkServiceImpl.createGuestNetwork:1294-NativeMethodAccessorImpl.invoke0:-2 > 2018-02-06 11:20:27,798 ERROR [c.c.a.ApiServer] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) unhandled > exception executing api command: [Ljava.lang.String;@43b9df02 > com.cloud.utils.exception.CloudRuntimeException: Unable to convert network > offering with specified id to network profile > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.setupNetwork(NetworkOrchestrator.java:726) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator$10.doInTransaction(NetworkOrchestrator.java:2364) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator$10.doInTransaction(NetworkOrchestrator.java:2315) > at > com.cloud.utils.db.Tran
[jira] [Commented] (CLOUDSTACK-10274) L2 network refused to be designed on VXLAN physical network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16385927#comment-16385927 ] ASF GitHub Bot commented on CLOUDSTACK-10274: - NuxRo commented on issue #2448: CLOUDSTACK-10274: L2 network refused to be designed on VXLAN physical network URL: https://github.com/apache/cloudstack/pull/2448#issuecomment-370381293 I have tested this and can confirm I can now create VXLAN based L2 and high ID numbers, thanks! I still see complaints like this, but I guess it's safe to ignore since I don't use BigSwitch: 2018-03-05 10:47:43,096 DEBUG [c.c.n.g.BigSwitchBcfGuestNetworkGuru] (qtp788117692-288:ctx-822f75f3 ctx-8f100d92) (logid:ac2301da) Refusing to design this network, the physical isolation type is not BCF_SEGMENT This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > L2 network refused to be designed on VXLAN physical network > > > Key: CLOUDSTACK-10274 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10274 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0 >Reporter: Nicolas Vazquez >Priority: Major > Fix For: 4.11.1.1 > > > Issue reported by [~nuxro] while trying to add an L2 network on a VXLAN > physical network: > 2018-02-06 11:20:27,748 DEBUG [c.c.n.NetworkServiceImpl] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Found physical > network id=201 based on requested tags mellanoxvxlan > 2018-02-06 11:20:27,749 DEBUG [c.c.n.NetworkServiceImpl] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Found physical > network id=201 based on requested tags mellanoxvxlan > 2018-02-06 11:20:27,766 DEBUG [c.c.n.g.BigSwitchBcfGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network, the physical isolation type is not BCF_SEGMENT > 2018-02-06 11:20:27,766 DEBUG [o.a.c.n.c.m.ContrailGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,767 DEBUG [c.c.n.g.NiciraNvpGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,767 DEBUG [o.a.c.n.o.OpendaylightGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,767 DEBUG [c.c.n.g.OvsGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,769 DEBUG [o.a.c.n.g.SspGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) SSP not > configured to be active > 2018-02-06 11:20:27,769 DEBUG [c.c.n.g.BrocadeVcsGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,769 DEBUG [c.c.n.g.NuageVspGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design network using network offering 19 on physical network 201 > 2018-02-06 11:20:27,770 DEBUG [o.a.c.e.o.NetworkOrchestrator] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Releasing lock > for Acct[6af2875b-04fc-11e8-923e-002590474525-admin] > 2018-02-06 11:20:27,789 DEBUG [c.c.u.d.T.Transaction] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Rolling back > the transaction: Time = 38 Name = qtp788117692-390; called by > -TransactionLegacy.rollback:889-TransactionLegacy.removeUpTo:832-TransactionLegacy.close:656-Transaction.execute:43-Transaction.execute:47-NetworkOrchestrator.createGuestNetwork:2315-NetworkServiceImpl$4.doInTransaction:1383-NetworkServiceImpl$4.doInTransaction:1331-Transaction.execute:40-NetworkServiceImpl.commitNetwork:1331-NetworkServiceImpl.createGuestNetwork:1294-NativeMethodAccessorImpl.invoke0:-2 > 2018-02-06 11:20:27,798 ERROR [c.c.a.ApiServer] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) unhandled > exception executing api command: [Ljava.lang.String;@43b9df02 > com.cloud.utils.exception.CloudRuntimeException: Unable to convert network > offering with specified id to network profile > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.setupNetwork(NetworkOrchestrator.java:726) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator$10.doInTransaction(Netwo
[jira] [Commented] (CLOUDSTACK-10314) Add Text-Field to each ACL Rule
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10314?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16385895#comment-16385895 ] ASF GitHub Bot commented on CLOUDSTACK-10314: - rafaelweingartner commented on issue #2475: [CLOUDSTACK-10314] Add Text-Field to each ACL Rule URL: https://github.com/apache/cloudstack/pull/2475#issuecomment-370372894 @DaanHoogland yes I did, but I did not quite understand their purpose. I was not sure if the goal was to be used as the tag system we have in ACS for host and storage. Also, they are quite limited in the UI if you need to write something more than a few words. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add Text-Field to each ACL Rule > > > Key: CLOUDSTACK-10314 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10314 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Minor > > It might be interesting to have a text field (e.g. CHAR-256) added to each > ACL rule, which allows to enter a "reason" for each FW Rule created. This is > valuable for customer documentation, as well as best practice for an evidence > towards auditing the system. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10197) XenServer 7.1: Cannot mount xentool iso from cloudstack on VMs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16385892#comment-16385892 ] ASF GitHub Bot commented on CLOUDSTACK-10197: - rafaelweingartner commented on issue #2470: [CLOUDSTACK-10197] Update DisplayText of XenServer tools ISO entry in the database when it already exists URL: https://github.com/apache/cloudstack/pull/2470#issuecomment-370372305 @DaanHoogland no it does not ;) This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > XenServer 7.1: Cannot mount xentool iso from cloudstack on VMs > --- > > Key: CLOUDSTACK-10197 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10197 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0 > Environment: XenServer 7.0+ >Reporter: Khosrow Moossavi >Priority: Major > Fix For: 4.11.0.0 > > > In XenServer 7.0+ xentools iso has been renamed from *xs-tools* to > *guest-tools* so CloudStack fails to attach it to any VM. > {code} > (acs-admin) > attach iso > virtualmachineid=d13eeff1-2d99-46a9-8fc5-3510df6e9f5e > id=e8a56540-0fc3-44de-9911-635d2d8f25c4 > errorcode = 530 > errortext = Failed to attach iso > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10274) L2 network refused to be designed on VXLAN physical network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16385864#comment-16385864 ] ASF GitHub Bot commented on CLOUDSTACK-10274: - blueorangutan commented on issue #2448: CLOUDSTACK-10274: L2 network refused to be designed on VXLAN physical network URL: https://github.com/apache/cloudstack/pull/2448#issuecomment-370363253 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1751 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > L2 network refused to be designed on VXLAN physical network > > > Key: CLOUDSTACK-10274 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10274 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0 >Reporter: Nicolas Vazquez >Priority: Major > Fix For: 4.11.1.1 > > > Issue reported by [~nuxro] while trying to add an L2 network on a VXLAN > physical network: > 2018-02-06 11:20:27,748 DEBUG [c.c.n.NetworkServiceImpl] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Found physical > network id=201 based on requested tags mellanoxvxlan > 2018-02-06 11:20:27,749 DEBUG [c.c.n.NetworkServiceImpl] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Found physical > network id=201 based on requested tags mellanoxvxlan > 2018-02-06 11:20:27,766 DEBUG [c.c.n.g.BigSwitchBcfGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network, the physical isolation type is not BCF_SEGMENT > 2018-02-06 11:20:27,766 DEBUG [o.a.c.n.c.m.ContrailGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,767 DEBUG [c.c.n.g.NiciraNvpGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,767 DEBUG [o.a.c.n.o.OpendaylightGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,767 DEBUG [c.c.n.g.OvsGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,769 DEBUG [o.a.c.n.g.SspGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) SSP not > configured to be active > 2018-02-06 11:20:27,769 DEBUG [c.c.n.g.BrocadeVcsGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,769 DEBUG [c.c.n.g.NuageVspGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design network using network offering 19 on physical network 201 > 2018-02-06 11:20:27,770 DEBUG [o.a.c.e.o.NetworkOrchestrator] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Releasing lock > for Acct[6af2875b-04fc-11e8-923e-002590474525-admin] > 2018-02-06 11:20:27,789 DEBUG [c.c.u.d.T.Transaction] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Rolling back > the transaction: Time = 38 Name = qtp788117692-390; called by > -TransactionLegacy.rollback:889-TransactionLegacy.removeUpTo:832-TransactionLegacy.close:656-Transaction.execute:43-Transaction.execute:47-NetworkOrchestrator.createGuestNetwork:2315-NetworkServiceImpl$4.doInTransaction:1383-NetworkServiceImpl$4.doInTransaction:1331-Transaction.execute:40-NetworkServiceImpl.commitNetwork:1331-NetworkServiceImpl.createGuestNetwork:1294-NativeMethodAccessorImpl.invoke0:-2 > 2018-02-06 11:20:27,798 ERROR [c.c.a.ApiServer] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) unhandled > exception executing api command: [Ljava.lang.String;@43b9df02 > com.cloud.utils.exception.CloudRuntimeException: Unable to convert network > offering with specified id to network profile > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.setupNetwork(NetworkOrchestrator.java:726) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator$10.doInTransaction(NetworkOrchestrator.java:2364) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator$10.doInTransaction(NetworkOrchestrator.java:2315) > at > com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:50) > at com.cloud.utils.db.Transaction.execute(Transaction.java:40) > at com.cloud.utils.db.Transaction.exec
[jira] [Commented] (CLOUDSTACK-10274) L2 network refused to be designed on VXLAN physical network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16385829#comment-16385829 ] ASF GitHub Bot commented on CLOUDSTACK-10274: - blueorangutan commented on issue #2448: CLOUDSTACK-10274: L2 network refused to be designed on VXLAN physical network URL: https://github.com/apache/cloudstack/pull/2448#issuecomment-370353620 @rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > L2 network refused to be designed on VXLAN physical network > > > Key: CLOUDSTACK-10274 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10274 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0 >Reporter: Nicolas Vazquez >Priority: Major > Fix For: 4.11.1.1 > > > Issue reported by [~nuxro] while trying to add an L2 network on a VXLAN > physical network: > 2018-02-06 11:20:27,748 DEBUG [c.c.n.NetworkServiceImpl] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Found physical > network id=201 based on requested tags mellanoxvxlan > 2018-02-06 11:20:27,749 DEBUG [c.c.n.NetworkServiceImpl] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Found physical > network id=201 based on requested tags mellanoxvxlan > 2018-02-06 11:20:27,766 DEBUG [c.c.n.g.BigSwitchBcfGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network, the physical isolation type is not BCF_SEGMENT > 2018-02-06 11:20:27,766 DEBUG [o.a.c.n.c.m.ContrailGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,767 DEBUG [c.c.n.g.NiciraNvpGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,767 DEBUG [o.a.c.n.o.OpendaylightGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,767 DEBUG [c.c.n.g.OvsGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,769 DEBUG [o.a.c.n.g.SspGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) SSP not > configured to be active > 2018-02-06 11:20:27,769 DEBUG [c.c.n.g.BrocadeVcsGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,769 DEBUG [c.c.n.g.NuageVspGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design network using network offering 19 on physical network 201 > 2018-02-06 11:20:27,770 DEBUG [o.a.c.e.o.NetworkOrchestrator] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Releasing lock > for Acct[6af2875b-04fc-11e8-923e-002590474525-admin] > 2018-02-06 11:20:27,789 DEBUG [c.c.u.d.T.Transaction] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Rolling back > the transaction: Time = 38 Name = qtp788117692-390; called by > -TransactionLegacy.rollback:889-TransactionLegacy.removeUpTo:832-TransactionLegacy.close:656-Transaction.execute:43-Transaction.execute:47-NetworkOrchestrator.createGuestNetwork:2315-NetworkServiceImpl$4.doInTransaction:1383-NetworkServiceImpl$4.doInTransaction:1331-Transaction.execute:40-NetworkServiceImpl.commitNetwork:1331-NetworkServiceImpl.createGuestNetwork:1294-NativeMethodAccessorImpl.invoke0:-2 > 2018-02-06 11:20:27,798 ERROR [c.c.a.ApiServer] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) unhandled > exception executing api command: [Ljava.lang.String;@43b9df02 > com.cloud.utils.exception.CloudRuntimeException: Unable to convert network > offering with specified id to network profile > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.setupNetwork(NetworkOrchestrator.java:726) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator$10.doInTransaction(NetworkOrchestrator.java:2364) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator$10.doInTransaction(NetworkOrchestrator.java:2315) > at > com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:50) > at com.cloud.utils.db.Transaction.execute(Transaction.java:40) >
[jira] [Commented] (CLOUDSTACK-10274) L2 network refused to be designed on VXLAN physical network
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10274?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16385828#comment-16385828 ] ASF GitHub Bot commented on CLOUDSTACK-10274: - rhtyd commented on issue #2448: CLOUDSTACK-10274: L2 network refused to be designed on VXLAN physical network URL: https://github.com/apache/cloudstack/pull/2448#issuecomment-370353531 @blueorangutan package This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > L2 network refused to be designed on VXLAN physical network > > > Key: CLOUDSTACK-10274 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10274 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.11.0.0 >Reporter: Nicolas Vazquez >Priority: Major > Fix For: 4.11.1.1 > > > Issue reported by [~nuxro] while trying to add an L2 network on a VXLAN > physical network: > 2018-02-06 11:20:27,748 DEBUG [c.c.n.NetworkServiceImpl] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Found physical > network id=201 based on requested tags mellanoxvxlan > 2018-02-06 11:20:27,749 DEBUG [c.c.n.NetworkServiceImpl] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Found physical > network id=201 based on requested tags mellanoxvxlan > 2018-02-06 11:20:27,766 DEBUG [c.c.n.g.BigSwitchBcfGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network, the physical isolation type is not BCF_SEGMENT > 2018-02-06 11:20:27,766 DEBUG [o.a.c.n.c.m.ContrailGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,767 DEBUG [c.c.n.g.NiciraNvpGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,767 DEBUG [o.a.c.n.o.OpendaylightGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,767 DEBUG [c.c.n.g.OvsGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,769 DEBUG [o.a.c.n.g.SspGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) SSP not > configured to be active > 2018-02-06 11:20:27,769 DEBUG [c.c.n.g.BrocadeVcsGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design this network > 2018-02-06 11:20:27,769 DEBUG [c.c.n.g.NuageVspGuestNetworkGuru] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Refusing to > design network using network offering 19 on physical network 201 > 2018-02-06 11:20:27,770 DEBUG [o.a.c.e.o.NetworkOrchestrator] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Releasing lock > for Acct[6af2875b-04fc-11e8-923e-002590474525-admin] > 2018-02-06 11:20:27,789 DEBUG [c.c.u.d.T.Transaction] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) Rolling back > the transaction: Time = 38 Name = qtp788117692-390; called by > -TransactionLegacy.rollback:889-TransactionLegacy.removeUpTo:832-TransactionLegacy.close:656-Transaction.execute:43-Transaction.execute:47-NetworkOrchestrator.createGuestNetwork:2315-NetworkServiceImpl$4.doInTransaction:1383-NetworkServiceImpl$4.doInTransaction:1331-Transaction.execute:40-NetworkServiceImpl.commitNetwork:1331-NetworkServiceImpl.createGuestNetwork:1294-NativeMethodAccessorImpl.invoke0:-2 > 2018-02-06 11:20:27,798 ERROR [c.c.a.ApiServer] > (qtp788117692-390:ctx-f1a980be ctx-61be30e8) (logid:0ca0c866) unhandled > exception executing api command: [Ljava.lang.String;@43b9df02 > com.cloud.utils.exception.CloudRuntimeException: Unable to convert network > offering with specified id to network profile > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator.setupNetwork(NetworkOrchestrator.java:726) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator$10.doInTransaction(NetworkOrchestrator.java:2364) > at > org.apache.cloudstack.engine.orchestration.NetworkOrchestrator$10.doInTransaction(NetworkOrchestrator.java:2315) > at > com.cloud.utils.db.Transaction$2.doInTransaction(Transaction.java:50) > at com.cloud.utils.db.Transaction.execute(Transaction.java:40) > at com.cloud.utils.db.Transaction.execute(Transaction.java:47) -- This mes
[jira] [Commented] (CLOUDSTACK-10240) ACS cannot migrate a volume from local to shared storage (for XenServer)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16385805#comment-16385805 ] ASF GitHub Bot commented on CLOUDSTACK-10240: - blueorangutan commented on issue #2425: [CLOUDSTACK-10240] ACS cannot migrate a local volume to shared storage URL: https://github.com/apache/cloudstack/pull/2425#issuecomment-370348709 @DaanHoogland a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > ACS cannot migrate a volume from local to shared storage (for XenServer) > > > Key: CLOUDSTACK-10240 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10240 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > CloudStack is logically restricting the migration of local storages to shared > storage and vice versa. This restriction is a logical one and can be removed > for XenServer deployments. Therefore, we will enable migration of volumes > between local-shared storages in XenServers independently of their service > offering. This will work as an override mechanism to the disk offering used > by volumes. If administrators want to migrate local volumes to a shared > storage, they should be able to do so (the hypervisor already allows that). > The same the other way around. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10240) ACS cannot migrate a volume from local to shared storage (for XenServer)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10240?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16385804#comment-16385804 ] ASF GitHub Bot commented on CLOUDSTACK-10240: - DaanHoogland commented on issue #2425: [CLOUDSTACK-10240] ACS cannot migrate a local volume to shared storage URL: https://github.com/apache/cloudstack/pull/2425#issuecomment-370348656 :( jenkins had crashed due to disk full, should not be related and should not be. acting insane: @blueorangutan test This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > ACS cannot migrate a volume from local to shared storage (for XenServer) > > > Key: CLOUDSTACK-10240 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10240 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > CloudStack is logically restricting the migration of local storages to shared > storage and vice versa. This restriction is a logical one and can be removed > for XenServer deployments. Therefore, we will enable migration of volumes > between local-shared storages in XenServers independently of their service > offering. This will work as an override mechanism to the disk offering used > by volumes. If administrators want to migrate local volumes to a shared > storage, they should be able to do so (the hypervisor already allows that). > The same the other way around. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10197) XenServer 7.1: Cannot mount xentool iso from cloudstack on VMs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10197?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16385749#comment-16385749 ] ASF GitHub Bot commented on CLOUDSTACK-10197: - blueorangutan commented on issue #2470: [CLOUDSTACK-10197] Update DisplayText of XenServer tools ISO entry in the database when it already exists URL: https://github.com/apache/cloudstack/pull/2470#issuecomment-370338595 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1750 This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > XenServer 7.1: Cannot mount xentool iso from cloudstack on VMs > --- > > Key: CLOUDSTACK-10197 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10197 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0 > Environment: XenServer 7.0+ >Reporter: Khosrow Moossavi >Priority: Major > Fix For: 4.11.0.0 > > > In XenServer 7.0+ xentools iso has been renamed from *xs-tools* to > *guest-tools* so CloudStack fails to attach it to any VM. > {code} > (acs-admin) > attach iso > virtualmachineid=d13eeff1-2d99-46a9-8fc5-3510df6e9f5e > id=e8a56540-0fc3-44de-9911-635d2d8f25c4 > errorcode = 530 > errortext = Failed to attach iso > {code} -- This message was sent by Atlassian JIRA (v7.6.3#76005)