[jira] [Commented] (CLOUDSTACK-10317) In case of multiple-public ips, snat fails to work for addtional public nics/network for guest traffic

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread Daan Hoogland (JIRA)

 [ 
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

2018-03-05 Thread Daan Hoogland (JIRA)

 [ 
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

2018-03-05 Thread Daan Hoogland (JIRA)

 [ 
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

2018-03-05 Thread Daan Hoogland (JIRA)

 [ 
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

2018-03-05 Thread Daan Hoogland (JIRA)

 [ 
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

2018-03-05 Thread Daan Hoogland (JIRA)

 [ 
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

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread JIRA

 [ 
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

2018-03-05 Thread JIRA
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)

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread Rohit Yadav (JIRA)

 [ 
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

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread Zhenhao Li (JIRA)

 [ 
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

2018-03-05 Thread Zhenhao Li (JIRA)

 [ 
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

2018-03-05 Thread Zhenhao Li (JIRA)

 [ 
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

2018-03-05 Thread Zhenhao Li (JIRA)

 [ 
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

2018-03-05 Thread Rohit Yadav (JIRA)
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

2018-03-05 Thread Zhenhao Li (JIRA)
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

2018-03-05 Thread Zhenhao Li (JIRA)
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

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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)

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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)

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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

2018-03-05 Thread ASF GitHub Bot (JIRA)

[ 
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)