[jira] [Commented] (CLOUDSTACK-10199) Support requesting a specific IPv4 address in Basic Networking during Instance creation

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16461817#comment-16461817
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10199:
-

rafaelweingartner commented on a change in pull request #2595: 
CLOUDSTACK-10199: Support requesting a specific IPv4 address
URL: https://github.com/apache/cloudstack/pull/2595#discussion_r185681019
 
 

 ##
 File path: engine/schema/src/main/java/com/cloud/dc/dao/VlanDaoImpl.java
 ##
 @@ -82,6 +83,24 @@ public VlanVO findByZoneAndVlanId(long zoneId, String 
vlanId) {
 return findOneBy(sc);
 }
 
+/**
+ * Returns a vlan by the network id and if the given IPv4 is in the 
network IP range.
+ */
+@Override
+public VlanVO findByNetworkIdAndIpv4Range(long networkId, String 
ipv4Address) {
+List vlanVoList = listVlansByNetworkId(networkId);
+for (VlanVO vlan : vlanVoList) {
+String ipRange = vlan.getIpRange();
+String[] ipRangeParts = ipRange.split("-");
+String startIP = ipRangeParts[0];
+String endIP = ipRangeParts[1];
+if (NetUtils.isIpInRange(ipv4Address, startIP, endIP)) {
 
 Review comment:
   What about using something similar to `isIp6InNetwork`?
   I also get a feeling that this method you implemented is doing the same as 
`isIpWithInCidrRange`


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


> Support requesting a specific IPv4 address in Basic Networking during 
> Instance creation
> ---
>
> Key: CLOUDSTACK-10199
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10199
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
> Environment: CloudStack 4.10
>Reporter: Wido den Hollander
>Priority: Major
>  Labels: basic-networking
>
> DirectPodBasedNetworkGuru does not support requesting a custom IP-Address 
> while creating a new NIC/Instance.
> {quote}
> Error 530: Does not support custom ip allocation at this time: 
> NicProfile[0-0-null-null-null
> {
>   "cserrorcode": 4250,
>   "errorcode": 530,
>   "errortext": "Does not support custom ip allocation at this time: 
> NicProfile[0-0-null-null-null",
>   "uuidList": []
> }
> {quote}
> Some use-cases prefer the ability to request the IPv4 address which the 
> Instance will get.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10199) Support requesting a specific IPv4 address in Basic Networking during Instance creation

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16461819#comment-16461819
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10199:
-

rafaelweingartner commented on a change in pull request #2595: 
CLOUDSTACK-10199: Support requesting a specific IPv4 address
URL: https://github.com/apache/cloudstack/pull/2595#discussion_r185680460
 
 

 ##
 File path: 
engine/orchestration/src/main/java/org/apache/cloudstack/engine/orchestration/NetworkOrchestrator.java
 ##
 @@ -883,6 +885,78 @@ public void saveExtraDhcpOptions(final String 
networkUuid, final Long nicId, fin
 return new Pair(vmNic, Integer.valueOf(deviceId));
 }
 
+/**
+ * If the requested IPv4 address from the NicProfile was configured then 
it configures the IPv4 address, Netmask and Gateway to deploy the VM with the 
requested IP.
+ */
+protected void configureNicProfileBasedOnRequestedIp(NicProfile 
requestedNicProfile, NicProfile nicProfile, Network network) {
+if (requestedNicProfile == null) {
+return;
+}
+String requestedIpv4Address = requestedNicProfile.getRequestedIPv4();
+if (requestedIpv4Address == null) {
+return;
+}
+if (!NetUtils.isValidIp4(requestedIpv4Address)) {
+throw new InvalidParameterValueException(String.format("The 
requested [IPv4 address='%s'] is not a valid IP address", 
requestedIpv4Address));
+}
+
+VlanVO vlanVo = _vlanDao.findByNetworkIdAndIpv4Range(network.getId(), 
requestedIpv4Address);
+if (vlanVo == null) {
+throw new CloudRuntimeException(String.format("Trying to configure 
a Nic with the requested [IPv4='%s'] but cannot find a Vlan for the [network 
id='%s']",
+requestedIpv4Address, network.getId()));
+}
+
+String ipv4Gateway = vlanVo.getVlanGateway();
+String ipv4Netmask = vlanVo.getVlanNetmask();
+
+if (!NetUtils.isValidIp4(ipv4Gateway)) {
+throw new CloudRuntimeException(String.format("The 
[IPv4Gateway='%s'] from [VlanId='%s'] is not valid", ipv4Gateway, 
vlanVo.getId()));
+}
+if (!NetUtils.isValidIp4Netmask(ipv4Netmask)) {
+throw new CloudRuntimeException(String.format("The 
[IPv4Netmask='%s'] from [VlanId='%s'] is not valid", ipv4Netmask, 
vlanVo.getId()));
+}
+
+acquireLockAndCheckIfIpv4IsFree(network, requestedIpv4Address);
+
+nicProfile.setIPv4Address(requestedIpv4Address);
+nicProfile.setIPv4Gateway(ipv4Gateway);
+nicProfile.setIPv4Netmask(ipv4Netmask);
+
+if (nicProfile.getMacAddress() == null) {
+try {
+String macAddress = 
_networkModel.getNextAvailableMacAddressInNetwork(network.getId());
+nicProfile.setMacAddress(macAddress);
+} catch (InsufficientAddressCapacityException e) {
+throw new CloudRuntimeException(String.format("Cannot get next 
available mac address in [network id='%s']", network.getId()), e);
+}
+}
+}
+
+/**
+ *  Acquires lock of in table "user_ip_address" and checks if the 
requested IPv4 address is Free.
+ */
+protected void acquireLockAndCheckIfIpv4IsFree(Network network, String 
requestedIpv4Address) {
 
 Review comment:
   These exceptions that you throw here, I think it might be better to throw an 
`InvalidParameterValueException` instead. These exception will happen when the 
user enters an "invalid/already used" IP, right?


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


> Support requesting a specific IPv4 address in Basic Networking during 
> Instance creation
> ---
>
> Key: CLOUDSTACK-10199
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10199
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
> Environment: CloudStack 4.10
>Reporter: Wido den Hollander
>Priority: Major
>  Labels: basic-networking
>
> DirectPodBasedNetworkGuru does not support requesting a custom IP-Address 
> while creating a new NIC/Instance.
> {quote}
> Error 530: Does not support custom ip allocation at this time: 
> NicProfile[0-0-null-null-null
> {
>   "cserrorcode": 4250,
>   "errorcode": 530,
>   "errortext": "Does not support custom ip allocation at this time: 
> NicProfile[0-0-null-null-null",
>  

[jira] [Commented] (CLOUDSTACK-10199) Support requesting a specific IPv4 address in Basic Networking during Instance creation

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16461820#comment-16461820
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10199:
-

rafaelweingartner commented on a change in pull request #2595: 
CLOUDSTACK-10199: Support requesting a specific IPv4 address
URL: https://github.com/apache/cloudstack/pull/2595#discussion_r185680530
 
 

 ##
 File path: 
engine/orchestration/src/test/java/org/apache/cloudstack/engine/orchestration/NetworkOrchestratorTest.java
 ##
 @@ -159,4 +174,255 @@ public void testDontRemoveDhcpServiceWhenNotProvided() {
 verify(testOrchastrator._ntwkSrvcDao, 
never()).getProviderForServiceInNetwork(network.getId(), Service.Dhcp);
 verify(testOrchastrator._networksDao, 
times(1)).findById(nic.getNetworkId());
 }
+
+@Test
+public void testConfigureNicProfileBasedOnRequestedIpTestMacNull() {
+Network network = mock(Network.class);
+NicProfile requestedNicProfile = new NicProfile();
+NicProfile nicProfile = Mockito.spy(new NicProfile());
+
+configureTestConfigureNicProfileBasedOnRequestedIpTests(nicProfile, 
0l, false, IPAddressVO.State.Free, "192.168.100.1", "255.255.255.0", 
"00-88-14-4D-4C-FB",
+requestedNicProfile, null, "192.168.100.150");
+
+
testOrchastrator.configureNicProfileBasedOnRequestedIp(requestedNicProfile, 
nicProfile, network);
+
+verifyAndAssert("192.168.100.150", "192.168.100.1", "255.255.255.0", 
nicProfile, 1, 1);
+}
+
+@Test
+public void 
testConfigureNicProfileBasedOnRequestedIpTestNicProfileMacNotNull() {
+Network network = mock(Network.class);
+NicProfile requestedNicProfile = new NicProfile();
+NicProfile nicProfile = Mockito.spy(new NicProfile());
+
+configureTestConfigureNicProfileBasedOnRequestedIpTests(nicProfile, 
0l, false, IPAddressVO.State.Free, "192.168.100.1", "255.255.255.0", 
"00-88-14-4D-4C-FB",
+requestedNicProfile, "00-88-14-4D-4C-FB", "192.168.100.150");
+
+
testOrchastrator.configureNicProfileBasedOnRequestedIp(requestedNicProfile, 
nicProfile, network);
+
+verifyAndAssert("192.168.100.150", "192.168.100.1", "255.255.255.0", 
nicProfile, 1, 0);
+}
+
+@Test
+public void testConfigureNicProfileBasedOnRequestedIpTestRequestedIpNull() 
{
+testConfigureNicProfileBasedOnRequestedIpTestRequestedIp(null, "", 
false);
+}
+
+@Test
+public void 
testConfigureNicProfileBasedOnRequestedIpTestRequestedIpIsBlank() {
+testConfigureNicProfileBasedOnRequestedIpTestRequestedIp("", "The 
requested [IPv4 address=''] is not a valid IP address", true);
+}
+
+@Test
+public void 
testConfigureNicProfileBasedOnRequestedIpTestRequestedIpIsNotValid() {
+testConfigureNicProfileBasedOnRequestedIpTestRequestedIp("123", "The 
requested [IPv4 address='123'] is not a valid IP address", true);
+}
+
+private void 
testConfigureNicProfileBasedOnRequestedIpTestRequestedIp(String 
requestedIpv4Address, String exceptionAssert, boolean expectException) {
+Network network = mock(Network.class);
+NicProfile requestedNicProfile = new NicProfile();
+NicProfile nicProfile = Mockito.spy(new NicProfile());
+
+configureTestConfigureNicProfileBasedOnRequestedIpTests(nicProfile, 
0l, false, IPAddressVO.State.Free, "192.168.100.1", "255.255.255.0", 
"00-88-14-4D-4C-FB",
+requestedNicProfile, null, requestedIpv4Address);
+try {
+
testOrchastrator.configureNicProfileBasedOnRequestedIp(requestedNicProfile, 
nicProfile, network);
+} catch (InvalidParameterValueException e) {
+assertEquals(exceptionAssert, e.getMessage());
 
 Review comment:
   why not use the `@Test` with the `expected` parameter?


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


> Support requesting a specific IPv4 address in Basic Networking during 
> Instance creation
> ---
>
> Key: CLOUDSTACK-10199
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10199
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
> Environment: CloudStack 4.10
>Reporter: Wido den Hollander
>Priority: Major
>  Labels: basic-networking
>
> DirectPodBasedNetworkGuru does not support requesting a custom IP-Address 
> while creating a new NIC/Instance.
> 

[jira] [Commented] (CLOUDSTACK-10199) Support requesting a specific IPv4 address in Basic Networking during Instance creation

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16461818#comment-16461818
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10199:
-

rafaelweingartner commented on a change in pull request #2595: 
CLOUDSTACK-10199: Support requesting a specific IPv4 address
URL: https://github.com/apache/cloudstack/pull/2595#discussion_r185680248
 
 

 ##
 File path: 
engine/orchestration/src/main/java/org/apache/cloudstack/engine/orchestration/NetworkOrchestrator.java
 ##
 @@ -883,6 +885,78 @@ public void saveExtraDhcpOptions(final String 
networkUuid, final Long nicId, fin
 return new Pair(vmNic, Integer.valueOf(deviceId));
 }
 
+/**
+ * If the requested IPv4 address from the NicProfile was configured then 
it configures the IPv4 address, Netmask and Gateway to deploy the VM with the 
requested IP.
+ */
+protected void configureNicProfileBasedOnRequestedIp(NicProfile 
requestedNicProfile, NicProfile nicProfile, Network network) {
+if (requestedNicProfile == null) {
+return;
+}
+String requestedIpv4Address = requestedNicProfile.getRequestedIPv4();
+if (requestedIpv4Address == null) {
+return;
+}
+if (!NetUtils.isValidIp4(requestedIpv4Address)) {
+throw new InvalidParameterValueException(String.format("The 
requested [IPv4 address='%s'] is not a valid IP address", 
requestedIpv4Address));
+}
+
+VlanVO vlanVo = _vlanDao.findByNetworkIdAndIpv4Range(network.getId(), 
requestedIpv4Address);
+if (vlanVo == null) {
+throw new CloudRuntimeException(String.format("Trying to configure 
a Nic with the requested [IPv4='%s'] but cannot find a Vlan for the [network 
id='%s']",
+requestedIpv4Address, network.getId()));
+}
+
+String ipv4Gateway = vlanVo.getVlanGateway();
+String ipv4Netmask = vlanVo.getVlanNetmask();
+
+if (!NetUtils.isValidIp4(ipv4Gateway)) {
+throw new CloudRuntimeException(String.format("The 
[IPv4Gateway='%s'] from [VlanId='%s'] is not valid", ipv4Gateway, 
vlanVo.getId()));
+}
+if (!NetUtils.isValidIp4Netmask(ipv4Netmask)) {
+throw new CloudRuntimeException(String.format("The 
[IPv4Netmask='%s'] from [VlanId='%s'] is not valid", ipv4Netmask, 
vlanVo.getId()));
+}
+
+acquireLockAndCheckIfIpv4IsFree(network, requestedIpv4Address);
+
+nicProfile.setIPv4Address(requestedIpv4Address);
+nicProfile.setIPv4Gateway(ipv4Gateway);
+nicProfile.setIPv4Netmask(ipv4Netmask);
+
+if (nicProfile.getMacAddress() == null) {
+try {
+String macAddress = 
_networkModel.getNextAvailableMacAddressInNetwork(network.getId());
+nicProfile.setMacAddress(macAddress);
+} catch (InsufficientAddressCapacityException e) {
+throw new CloudRuntimeException(String.format("Cannot get next 
available mac address in [network id='%s']", network.getId()), e);
+}
+}
+}
+
+/**
+ *  Acquires lock of in table "user_ip_address" and checks if the 
requested IPv4 address is Free.
+ */
+protected void acquireLockAndCheckIfIpv4IsFree(Network network, String 
requestedIpv4Address) {
+IPAddressVO ipVO = 
_ipAddressDao.findByIpAndSourceNetworkId(network.getId(), requestedIpv4Address);
+if (ipVO == null) {
+throw new CloudRuntimeException(String.format("Cannot find 
IPAddressVO for guest [IPv4 address='%s'] and [network id='%s']", 
requestedIpv4Address, network.getId()));
+}
+try {
+IPAddressVO lockedIpVO = 
_ipAddressDao.acquireInLockTable(ipVO.getId());
+if (lockedIpVO == null) {
+_ipAddressDao.releaseFromLockTable(ipVO.getId());
+}
+if (lockedIpVO.getState() != IPAddressVO.State.Free) {
+String ipState = lockedIpVO.getState().toString();
+_ipAddressDao.releaseFromLockTable(lockedIpVO.getId());
+throw new CloudRuntimeException(String.format("Cannot acquire 
guest [IPv4 address='%s']; The Ip address is in [state='%s']", 
requestedIpv4Address, ipState));
+}
+lockedIpVO.setState(IPAddressVO.State.Allocated);
+_ipAddressDao.update(lockedIpVO.getId(), lockedIpVO);
+} catch (Exception e) {
+_ipAddressDao.releaseFromLockTable(ipVO.getId());
 
 Review comment:
   Danger zone  here! Please do not hide exceptions.
   
   BTW, do you need to catch pokemons here?


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, 

[jira] [Commented] (CLOUDSTACK-10199) Support requesting a specific IPv4 address in Basic Networking during Instance creation

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16461816#comment-16461816
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10199:
-

rafaelweingartner commented on a change in pull request #2595: 
CLOUDSTACK-10199: Support requesting a specific IPv4 address
URL: https://github.com/apache/cloudstack/pull/2595#discussion_r185680088
 
 

 ##
 File path: 
engine/orchestration/src/main/java/org/apache/cloudstack/engine/orchestration/NetworkOrchestrator.java
 ##
 @@ -883,6 +885,78 @@ public void saveExtraDhcpOptions(final String 
networkUuid, final Long nicId, fin
 return new Pair(vmNic, Integer.valueOf(deviceId));
 }
 
+/**
+ * If the requested IPv4 address from the NicProfile was configured then 
it configures the IPv4 address, Netmask and Gateway to deploy the VM with the 
requested IP.
+ */
+protected void configureNicProfileBasedOnRequestedIp(NicProfile 
requestedNicProfile, NicProfile nicProfile, Network network) {
+if (requestedNicProfile == null) {
+return;
+}
+String requestedIpv4Address = requestedNicProfile.getRequestedIPv4();
+if (requestedIpv4Address == null) {
+return;
+}
+if (!NetUtils.isValidIp4(requestedIpv4Address)) {
+throw new InvalidParameterValueException(String.format("The 
requested [IPv4 address='%s'] is not a valid IP address", 
requestedIpv4Address));
+}
+
+VlanVO vlanVo = _vlanDao.findByNetworkIdAndIpv4Range(network.getId(), 
requestedIpv4Address);
 
 Review comment:
   This name `findByNetworkIdAndIpv4Range` does not seem to be adequate. It 
seems that you are going to look for a `VlanVo` by ipv4 range, which is not the 
case. You are looking for a `VlanVo` of a network that "supports" the specified 
IPv4. Therefore, something like `findVlanByNetworkIdAndIpv4` seems better.


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


> Support requesting a specific IPv4 address in Basic Networking during 
> Instance creation
> ---
>
> Key: CLOUDSTACK-10199
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10199
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
> Environment: CloudStack 4.10
>Reporter: Wido den Hollander
>Priority: Major
>  Labels: basic-networking
>
> DirectPodBasedNetworkGuru does not support requesting a custom IP-Address 
> while creating a new NIC/Instance.
> {quote}
> Error 530: Does not support custom ip allocation at this time: 
> NicProfile[0-0-null-null-null
> {
>   "cserrorcode": 4250,
>   "errorcode": 530,
>   "errortext": "Does not support custom ip allocation at this time: 
> NicProfile[0-0-null-null-null",
>   "uuidList": []
> }
> {quote}
> Some use-cases prefer the ability to request the IPv4 address which the 
> Instance will get.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10199) Support requesting a specific IPv4 address in Basic Networking during Instance creation

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10199?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16461614#comment-16461614
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10199:
-

GabrielBrascher commented on issue #2595: CLOUDSTACK-10199: Support requesting 
a specific IPv4 address
URL: https://github.com/apache/cloudstack/pull/2595#issuecomment-385842603
 
 
   @rhtyd I am using basic network and KVM. It might be a problem only on the 
basic network then.
   I tested with cloudmonkey, using the following command:
   `deploy virtualmachine zoneid= serviceofferingid= templateid= 
startvm=true ipaddress= name= displayname=<“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


> Support requesting a specific IPv4 address in Basic Networking during 
> Instance creation
> ---
>
> Key: CLOUDSTACK-10199
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10199
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: API
> Environment: CloudStack 4.10
>Reporter: Wido den Hollander
>Priority: Major
>  Labels: basic-networking
>
> DirectPodBasedNetworkGuru does not support requesting a custom IP-Address 
> while creating a new NIC/Instance.
> {quote}
> Error 530: Does not support custom ip allocation at this time: 
> NicProfile[0-0-null-null-null
> {
>   "cserrorcode": 4250,
>   "errorcode": 530,
>   "errortext": "Does not support custom ip allocation at this time: 
> NicProfile[0-0-null-null-null",
>   "uuidList": []
> }
> {quote}
> Some use-cases prefer the ability to request the IPv4 address which the 
> Instance will get.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-4045) IP address acquired with associateIpAddress is marked as source NAT, causing disassociateIpAddress to fail later

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16461543#comment-16461543
 ] 

ASF GitHub Bot commented on CLOUDSTACK-4045:


blueorangutan commented on issue #2382: CLOUDSTACK-4045 IP address acquired 
with associateIpAddress is marked as source NAT
URL: https://github.com/apache/cloudstack/pull/2382#issuecomment-386094830
 
 
   Trillian test result (tid-2575)
   Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
   Total time taken: 26440 seconds
   Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2382-t2575-kvm-centos7.zip
   Intermitten failure detected: /marvin/tests/smoke/test_certauthority_root.py
   Intermitten failure detected: /marvin/tests/smoke/test_internal_lb.py
   Intermitten failure detected: /marvin/tests/smoke/test_vm_life_cycle.py
   Intermitten failure detected: /marvin/tests/smoke/test_volumes.py
   Intermitten failure detected: /marvin/tests/smoke/test_vpc_vpn.py
   Intermitten failure detected: /marvin/tests/smoke/test_hostha_kvm.py
   Smoke tests completed. 63 look OK, 4 have error(s)
   Only failed tests results shown below:
   
   
   Test | Result | Time (s) | Test File
   --- | --- | --- | ---
   test_01_secured_vm_migration | `Error` | 37.52 | test_vm_life_cycle.py
   test_02_not_secured_vm_migration | `Error` | 38.54 | test_vm_life_cycle.py
   test_03_secured_to_nonsecured_vm_migration | `Error` | 38.55 | 
test_vm_life_cycle.py
   test_04_nonsecured_to_secured_vm_migration | `Error` | 38.53 | 
test_vm_life_cycle.py
   test_11_migrate_volume_and_change_offering | `Error` | 129.43 | 
test_volumes.py
   test_01_redundant_vpc_site2site_vpn | `Failure` | 375.30 | test_vpc_vpn.py
   test_01_vpc_site2site_vpn | `Failure` | 155.24 | test_vpc_vpn.py
   test_hostha_enable_ha_when_host_in_maintenance | `Error` | 4.69 | 
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


> IP address acquired with associateIpAddress is marked as source NAT, causing 
> disassociateIpAddress to fail later
> 
>
> Key: CLOUDSTACK-4045
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4045
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.1.0, 4.1.1, 4.2.0
>Reporter: Murali Reddy
>Assignee: Henko Holtzhausen
>Priority: Major
> Fix For: Future
>
>
> When you can create network, network is in allocated state. when network is 
> implemented CloudStack implicitly should acquire a public IP for source nat. 
> But there is assumption that first IP this is associated with network is 
> always for source NAT IP. So when you do
> 1. create network (network is in allocated state)
> 2. acquire a public IP and associate with the network
> 3. disassociate ip address
> #3 will fail because CloudStack marks the IP acquired in #1 to be source NAT. 
> For users this is counter-intutive because when a IP is acquired, he/she 
> should be able to release it as well.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10309) VMs with HA enabled, power back on if shutdown from guest OS

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16461261#comment-16461261
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10309:
-

blueorangutan commented on issue #2473: CLOUDSTACK-10309 Add option on if to VM 
HA power-on a OOB-shut-off-VM
URL: https://github.com/apache/cloudstack/pull/2473#issuecomment-386040632
 
 
   Trillian test result (tid-2574)
   Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
   Total time taken: 21986 seconds
   Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2473-t2574-kvm-centos7.zip
   Intermitten failure detected: /marvin/tests/smoke/test_privategw_acl.py
   Intermitten failure detected: /marvin/tests/smoke/test_public_ip_range.py
   Intermitten failure detected: /marvin/tests/smoke/test_reset_vm_on_reboot.py
   Intermitten failure detected: /marvin/tests/smoke/test_router_dhcphosts.py
   Intermitten failure detected: /marvin/tests/smoke/test_router_dns.py
   Intermitten failure detected: /marvin/tests/smoke/test_router_dnsservice.py
   Intermitten failure detected: 
/marvin/tests/smoke/test_routers_iptables_default_policy.py
   Intermitten failure detected: /marvin/tests/smoke/test_routers_network_ops.py
   Intermitten failure detected: /marvin/tests/smoke/test_routers.py
   Intermitten failure detected: /marvin/tests/smoke/test_secondary_storage.py
   Intermitten failure detected: /marvin/tests/smoke/test_service_offerings.py
   Intermitten failure detected: /marvin/tests/smoke/test_snapshots.py
   Intermitten failure detected: /marvin/tests/smoke/test_ssvm.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_vm_life_cycle.py
   Intermitten failure detected: /marvin/tests/smoke/test_vm_snapshots.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_vpc_router_nics.py
   Intermitten failure detected: /marvin/tests/smoke/test_vpc_vpn.py
   Intermitten failure detected: /marvin/tests/smoke/test_host_maintenance.py
   Intermitten failure detected: /marvin/tests/smoke/test_hostha_kvm.py
   Smoke tests completed. 45 look OK, 22 have error(s)
   Only failed tests results shown below:
   
   
   Test | Result | Time (s) | Test File
   --- | --- | --- | ---
   test_04_rvpc_privategw_static_routes | `Error` | 474.81 | 
test_privategw_acl.py
   ContextSuite context=TestResetVmOnReboot>:setup | `Error` | 0.00 | 
test_reset_vm_on_reboot.py
   ContextSuite context=TestRouterDHCPHosts>:setup | `Error` | 0.00 | 
test_router_dhcphosts.py
   ContextSuite context=TestRouterDHCPOpts>:setup | `Error` | 0.00 | 
test_router_dhcphosts.py
   ContextSuite context=TestRouterDns>:setup | `Error` | 0.00 | 
test_router_dns.py
   ContextSuite context=TestVmSnapshot>:setup | `Error` | 0.05 | 
test_vm_snapshots.py
   ContextSuite context=TestRouterDnsService>:setup | `Error` | 0.00 | 
test_router_dnsservice.py
   ContextSuite context=TestRouterIpTablesPolicies>:setup | `Error` | 0.00 | 
test_routers_iptables_default_policy.py
   ContextSuite context=TestVPCIpTablesPolicies>:setup | `Error` | 0.00 | 
test_routers_iptables_default_policy.py
   test_01_isolate_network_FW_PF_default_routes_egress_true | `Error` | 0.12 | 
test_routers_network_ops.py
   test_02_isolate_network_FW_PF_default_routes_egress_false | `Error` | 0.12 | 
test_routers_network_ops.py
   ContextSuite context=TestRedundantIsolateNetworks>:setup | `Error` | 1.26 | 
test_routers_network_ops.py
   ContextSuite context=TestRouterServices>:setup | `Error` | 0.00 | 
test_routers.py
   test_01_sys_vm_start | `Failure` | 0.08 | test_secondary_storage.py
   test_02_sys_template_ready | `Failure` | 0.06 | test_secondary_storage.py
   ContextSuite context=TestCpuCapServiceOfferings>:setup | `Error` | 0.00 | 
test_service_offerings.py
   ContextSuite context=TestServiceOfferings>:setup | `Error` | 0.13 | 
test_service_offerings.py
   ContextSuite context=TestSnapshotRootDisk>:setup | `Error` | 0.00 | 
test_snapshots.py
   test_01_list_sec_storage_vm | `Failure` | 0.03 | test_ssvm.py
   test_02_list_cpvm_vm | `Failure` | 0.03 | test_ssvm.py
   test_03_ssvm_internals | `Failure` | 0.03 | test_ssvm.py
   test_04_cpvm_internals | `Failure` | 0.03 | test_ssvm.py
   test_05_stop_ssvm | `Failure` | 0.02 | test_ssvm.py
   test_06_stop_cpvm | `Failure` | 0.02 | test_ssvm.py
   test_07_reboot_ssvm | `Failure` | 0.02 | test_ssvm.py
   test_08_reboot_cpvm | `Failure` | 0.03 | test_ssvm.py
   test_09_destroy_ssvm | `Failure` | 0.03 | test_ssvm.py
   test_10_destroy_cpvm | `Failure` | 0.02 | test_ssvm.py
   test_02_create_template_with_checksum_sha1 | `Error` | 65.32 | 
test_templates.py
   

[jira] [Commented] (CLOUDSTACK-10232) SystemVMs and VR to run as HVM on XenServer

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16461110#comment-16461110
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10232:
-

khos2ow commented on a change in pull request #2465: CLOUDSTACK-10232: 
SystemVMs and VR to run as HVM on XenServer
URL: https://github.com/apache/cloudstack/pull/2465#discussion_r185519409
 
 

 ##
 File path: systemvm/debian/opt/cloud/bin/setup/cloud-early-config
 ##
 @@ -64,10 +71,17 @@ config_guest() {
 
 get_boot_params() {
   case $HYPERVISOR in
- xen-domU|xen-hvm)
+ xen-pv)
   cat /proc/cmdline > $CMDLINE
   sed -i "s/%/ /g" $CMDLINE
   ;;
+ xen-hvm)
+  if [ ! -f /usr/sbin/xenstore-read ]; then
+log_it "ERROR: xentools not installed, cannot found xenstore-read" 
&& exit 5
+  fi
+  /usr/sbin/xenstore-read vm-data/cloudstack/init > 
/var/cache/cloud/cmdline
 
 Review comment:
   That's strange, I really don't know what's going on. I just checked dozens 
of random VMs, on various Xenserver version (7.x.x+ though) and all of them had 
`xenstore-read` in both places! I guess using `/usr/bin` would be safer. or 
even check both places then log an error?
   BTW I wrote a comment on your PR 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


> SystemVMs and VR to run as HVM on XenServer
> ---
>
> Key: CLOUDSTACK-10232
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10232
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM, Virtual Router, XenServer
>Affects Versions: 4.10.0.0, 4.9.3.0
>Reporter: Pierre-Luc Dion
>Priority: Major
>
> Following the recent Meltdown-Spectre security risk,one of the mitigation,as 
> of Jan 2018, for XenServer Hypervisor is to run Virtual-Machine in HVM mode.
> Currently SystemVMs and Virtual-Routers run as PV on XenServer and the eth0 
> is configured using {{/etc/init.d/cloud-early-config}} using grub params from 
> {{/proc/cmdline}}. When VM run as HVM, it is not possible to push initial 
> boot instruction via pygrub.
> Quick tests has been done using xenstore and it look like it would be 
> possible to send same initial boot instruction has pygrub but using xenstore 
> for HVM instances.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (CLOUDSTACK-10375) Remove obsolete DefaultNuageVspSharedNetworkOfferingWithSGService

[Frank Maximus (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10375?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Frank Maximus reassigned CLOUDSTACK-10375:
--

Assignee: Frank Maximus

> Remove obsolete DefaultNuageVspSharedNetworkOfferingWithSGService
> -
>
> Key: CLOUDSTACK-10375
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10375
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.11.0.0
> Environment: ACS 4.11 + Nuage
>Reporter: Raf Smeets
>Assignee: Frank Maximus
>Priority: Minor
>
> Remove obsolete DefaultNuageVspSharedNetworkOfferingWithSGService



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Assigned] (CLOUDSTACK-10376) UI : no longer possible to select configdrive as userdata provider in a new VPC offering

[Frank Maximus (JIRA)]

 [ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10376?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Frank Maximus reassigned CLOUDSTACK-10376:
--

Assignee: Frank Maximus

> UI : no longer possible to select configdrive as userdata provider in a new 
> VPC offering
> 
>
> Key: CLOUDSTACK-10376
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10376
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: UI
>Affects Versions: 4.11.0.0
> Environment: ACS 4.11 + Nuage
>Reporter: Raf Smeets
>Assignee: Frank Maximus
>Priority: Major
>
> UI : no longer possible to select configdrive as userdata provider in a new 
> VPC offering



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (CLOUDSTACK-10376) UI : no longer possible to select configdrive as userdata provider in a new VPC offering

[Raf Smeets (JIRA)]

Raf Smeets created CLOUDSTACK-10376:
---

 Summary: UI : no longer possible to select configdrive as userdata 
provider in a new VPC offering
 Key: CLOUDSTACK-10376
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10376
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: UI
Affects Versions: 4.11.0.0
 Environment: ACS 4.11 + Nuage
Reporter: Raf Smeets


UI : no longer possible to select configdrive as userdata provider in a new VPC 
offering



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Created] (CLOUDSTACK-10375) Remove obsolete DefaultNuageVspSharedNetworkOfferingWithSGService

[Raf Smeets (JIRA)]

Raf Smeets created CLOUDSTACK-10375:
---

 Summary: Remove obsolete 
DefaultNuageVspSharedNetworkOfferingWithSGService
 Key: CLOUDSTACK-10375
 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10375
 Project: CloudStack
  Issue Type: Bug
  Security Level: Public (Anyone can view this level - this is the default.)
  Components: Management Server
Affects Versions: 4.11.0.0
 Environment: ACS 4.11 + Nuage
Reporter: Raf Smeets


Remove obsolete DefaultNuageVspSharedNetworkOfferingWithSGService



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-9114) restartnetwork with cleanup should not update/restart both routers at once

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16461056#comment-16461056
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9114:


blueorangutan commented on issue #2508: CLOUDSTACK-9114: Reduce VR downtime 
during network restart
URL: https://github.com/apache/cloudstack/pull/2508#issuecomment-385628954
 
 
   @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


> restartnetwork with cleanup should not update/restart both routers at once
> --
>
> Key: CLOUDSTACK-9114
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9114
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>Priority: Major
>
> for now, restartnetwork with cleanup will stop both RVRs at first, then start 
> two  new RVRs.
> to reduce the downtime of network, we'd better restart the RVRs one by one.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-9114) restartnetwork with cleanup should not update/restart both routers at once

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16461053#comment-16461053
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9114:


blueorangutan commented on issue #2508: CLOUDSTACK-9114: Reduce VR downtime 
during network restart
URL: https://github.com/apache/cloudstack/pull/2508#issuecomment-385577308
 
 
   Trillian test result (tid-2553)
   Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
   Total time taken: 53363 seconds
   Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2508-t2553-kvm-centos7.zip
   Intermitten failure detected: /marvin/tests/smoke/test_network.py
   Intermitten failure detected: /marvin/tests/smoke/test_privategw_acl.py
   Intermitten failure detected: /marvin/tests/smoke/test_routers_network_ops.py
   Intermitten failure detected: /marvin/tests/smoke/test_vm_life_cycle.py
   Intermitten failure detected: /marvin/tests/smoke/test_vpc_vpn.py
   Intermitten failure detected: /marvin/tests/smoke/test_host_maintenance.py
   Intermitten failure detected: /marvin/tests/smoke/test_hostha_kvm.py
   Smoke tests completed. 63 look OK, 4 have error(s)
   Only failed tests results shown below:
   
   
   Test | Result | Time (s) | Test File
   --- | --- | --- | ---
   test_reboot_router | `Failure` | 478.10 | test_network.py
   test_02_vpc_privategw_static_routes | `Failure` | 202.70 | 
test_privategw_acl.py
   test_03_vpc_privategw_restart_vpc_cleanup | `Failure` | 207.98 | 
test_privategw_acl.py
   test_04_rvpc_privategw_static_routes | `Failure` | 597.12 | 
test_privategw_acl.py
   test_02_isolate_network_FW_PF_default_routes_egress_false | `Failure` | 
402.71 | test_routers_network_ops.py
   test_01_RVR_Network_FW_PF_SSH_default_routes_egress_true | `Failure` | 
749.84 | test_routers_network_ops.py
   test_02_RVR_Network_FW_PF_SSH_default_routes_egress_false | `Failure` | 
760.36 | test_routers_network_ops.py
   test_02_cancel_host_maintenace_with_migration_jobs | `Error` | 2.26 | 
test_host_maintenance.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


> restartnetwork with cleanup should not update/restart both routers at once
> --
>
> Key: CLOUDSTACK-9114
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9114
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>Priority: Major
>
> for now, restartnetwork with cleanup will stop both RVRs at first, then start 
> two  new RVRs.
> to reduce the downtime of network, we'd better restart the RVRs one by one.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-9114) restartnetwork with cleanup should not update/restart both routers at once

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16461057#comment-16461057
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9114:


blueorangutan commented on issue #2508: CLOUDSTACK-9114: Reduce VR downtime 
during network restart
URL: https://github.com/apache/cloudstack/pull/2508#issuecomment-385799975
 
 
   Trillian test result (tid-2561)
   Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7
   Total time taken: 41070 seconds
   Marvin logs: 
https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2508-t2561-kvm-centos7.zip
   Intermitten failure detected: /marvin/tests/smoke/test_internal_lb.py
   Intermitten failure detected: /marvin/tests/smoke/test_privategw_acl.py
   Intermitten failure detected: /marvin/tests/smoke/test_vm_life_cycle.py
   Intermitten failure detected: /marvin/tests/smoke/test_vpc_redundant.py
   Intermitten failure detected: /marvin/tests/smoke/test_hostha_kvm.py
   Smoke tests completed. 63 look OK, 4 have error(s)
   Only failed tests results shown below:
   
   
   Test | Result | Time (s) | Test File
   --- | --- | --- | ---
   test_03_vpc_privategw_restart_vpc_cleanup | `Error` | 238.99 | 
test_privategw_acl.py
   test_02_not_secured_vm_migration | `Error` | 0.12 | test_vm_life_cycle.py
   test_03_secured_to_nonsecured_vm_migration | `Error` | 0.09 | 
test_vm_life_cycle.py
   test_04_nonsecured_to_secured_vm_migration | `Error` | 0.10 | 
test_vm_life_cycle.py
   test_04_rvpc_network_garbage_collector_nics | `Failure` | 289.87 | 
test_vpc_redundant.py
   test_hostha_enable_ha_when_host_in_maintenance | `Error` | 1.43 | 
test_hostha_kvm.py
   test_hostha_kvm_host_degraded | `Error` | 785.29 | 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


> restartnetwork with cleanup should not update/restart both routers at once
> --
>
> Key: CLOUDSTACK-9114
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9114
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>Priority: Major
>
> for now, restartnetwork with cleanup will stop both RVRs at first, then start 
> two  new RVRs.
> to reduce the downtime of network, we'd better restart the RVRs one by one.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-9114) restartnetwork with cleanup should not update/restart both routers at once

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16461054#comment-16461054
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9114:


rhtyd commented on issue #2508: CLOUDSTACK-9114: Reduce VR downtime during 
network restart
URL: https://github.com/apache/cloudstack/pull/2508#issuecomment-385628843
 
 
   @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


> restartnetwork with cleanup should not update/restart both routers at once
> --
>
> Key: CLOUDSTACK-9114
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9114
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>Priority: Major
>
> for now, restartnetwork with cleanup will stop both RVRs at first, then start 
> two  new RVRs.
> to reduce the downtime of network, we'd better restart the RVRs one by one.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-9114) restartnetwork with cleanup should not update/restart both routers at once

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16461051#comment-16461051
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9114:


rhtyd commented on issue #2508: CLOUDSTACK-9114: Reduce VR downtime during 
network restart
URL: https://github.com/apache/cloudstack/pull/2508#issuecomment-385358311
 
 
   @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


> restartnetwork with cleanup should not update/restart both routers at once
> --
>
> Key: CLOUDSTACK-9114
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9114
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>Priority: Major
>
> for now, restartnetwork with cleanup will stop both RVRs at first, then start 
> two  new RVRs.
> to reduce the downtime of network, we'd better restart the RVRs one by one.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-9114) restartnetwork with cleanup should not update/restart both routers at once

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9114?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16461052#comment-16461052
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9114:


blueorangutan commented on issue #2508: CLOUDSTACK-9114: Reduce VR downtime 
during network restart
URL: https://github.com/apache/cloudstack/pull/2508#issuecomment-385358428
 
 
   @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


> restartnetwork with cleanup should not update/restart both routers at once
> --
>
> Key: CLOUDSTACK-9114
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9114
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Wei Zhou
>Priority: Major
>
> for now, restartnetwork with cleanup will stop both RVRs at first, then start 
> two  new RVRs.
> to reduce the downtime of network, we'd better restart the RVRs one by one.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-7982) Storage live migration support for KVM

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-7982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460931#comment-16460931
 ] 

ASF GitHub Bot commented on CLOUDSTACK-7982:


marcaurele commented on issue #1709: CLOUDSTACK-7982: KVM live migration with 
local storage
URL: https://github.com/apache/cloudstack/pull/1709#issuecomment-385953605
 
 
   rebase done


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


> Storage live migration support for KVM
> --
>
> Key: CLOUDSTACK-7982
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7982
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Wei Zhou
>Assignee: Marc-Aurèle Brothier
>Priority: Major
> Fix For: Future
>
>
> Currently it supports Xenserver, Vmware, Hyper-V, but not KVM.
> We need to add the implementation for KVM.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-4045) IP address acquired with associateIpAddress is marked as source NAT, causing disassociateIpAddress to fail later

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460917#comment-16460917
 ] 

ASF GitHub Bot commented on CLOUDSTACK-4045:


rhtyd commented on issue #2382: CLOUDSTACK-4045 IP address acquired with 
associateIpAddress is marked as source NAT
URL: https://github.com/apache/cloudstack/pull/2382#issuecomment-385950273
 
 
   @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


> IP address acquired with associateIpAddress is marked as source NAT, causing 
> disassociateIpAddress to fail later
> 
>
> Key: CLOUDSTACK-4045
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4045
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.1.0, 4.1.1, 4.2.0
>Reporter: Murali Reddy
>Assignee: Henko Holtzhausen
>Priority: Major
> Fix For: Future
>
>
> When you can create network, network is in allocated state. when network is 
> implemented CloudStack implicitly should acquire a public IP for source nat. 
> But there is assumption that first IP this is associated with network is 
> always for source NAT IP. So when you do
> 1. create network (network is in allocated state)
> 2. acquire a public IP and associate with the network
> 3. disassociate ip address
> #3 will fail because CloudStack marks the IP acquired in #1 to be source NAT. 
> For users this is counter-intutive because when a IP is acquired, he/she 
> should be able to release it as well.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-4045) IP address acquired with associateIpAddress is marked as source NAT, causing disassociateIpAddress to fail later

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460919#comment-16460919
 ] 

ASF GitHub Bot commented on CLOUDSTACK-4045:


blueorangutan commented on issue #2382: CLOUDSTACK-4045 IP address acquired 
with associateIpAddress is marked as source NAT
URL: https://github.com/apache/cloudstack/pull/2382#issuecomment-385950452
 
 
   @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


> IP address acquired with associateIpAddress is marked as source NAT, causing 
> disassociateIpAddress to fail later
> 
>
> Key: CLOUDSTACK-4045
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4045
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.1.0, 4.1.1, 4.2.0
>Reporter: Murali Reddy
>Assignee: Henko Holtzhausen
>Priority: Major
> Fix For: Future
>
>
> When you can create network, network is in allocated state. when network is 
> implemented CloudStack implicitly should acquire a public IP for source nat. 
> But there is assumption that first IP this is associated with network is 
> always for source NAT IP. So when you do
> 1. create network (network is in allocated state)
> 2. acquire a public IP and associate with the network
> 3. disassociate ip address
> #3 will fail because CloudStack marks the IP acquired in #1 to be source NAT. 
> For users this is counter-intutive because when a IP is acquired, he/she 
> should be able to release it as well.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-4045) IP address acquired with associateIpAddress is marked as source NAT, causing disassociateIpAddress to fail later

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460909#comment-16460909
 ] 

ASF GitHub Bot commented on CLOUDSTACK-4045:


blueorangutan commented on issue #2382: CLOUDSTACK-4045 IP address acquired 
with associateIpAddress is marked as source NAT
URL: https://github.com/apache/cloudstack/pull/2382#issuecomment-385947928
 
 
   Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1993


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


> IP address acquired with associateIpAddress is marked as source NAT, causing 
> disassociateIpAddress to fail later
> 
>
> Key: CLOUDSTACK-4045
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4045
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.1.0, 4.1.1, 4.2.0
>Reporter: Murali Reddy
>Assignee: Henko Holtzhausen
>Priority: Major
> Fix For: Future
>
>
> When you can create network, network is in allocated state. when network is 
> implemented CloudStack implicitly should acquire a public IP for source nat. 
> But there is assumption that first IP this is associated with network is 
> always for source NAT IP. So when you do
> 1. create network (network is in allocated state)
> 2. acquire a public IP and associate with the network
> 3. disassociate ip address
> #3 will fail because CloudStack marks the IP acquired in #1 to be source NAT. 
> For users this is counter-intutive because when a IP is acquired, he/she 
> should be able to release it as well.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-9781) ACS records ID in events tables instead of UUID.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460878#comment-16460878
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9781:


rhtyd commented on issue #1940: CLOUDSTACK-9781:ACS records ID in events tables 
instead of UUID.
URL: https://github.com/apache/cloudstack/pull/1940#issuecomment-385942506
 
 
   Okay @rafaelweingartner. Let me diagnose that and get back to you soon.


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 records ID in events tables instead of UUID.
> 
>
> Key: CLOUDSTACK-9781
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9781
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Jayant Patil
>Priority: Major
>
> ISSUE
> =
> Wrong presentation of volume id in ACS events.
> While creating a snapshot, only volume ID is mentioned in the events. For 
> example, “Scheduled async job for creating snapshot for volume Id:270". On 
> looking into the notification, user is not able to identify the volume. So 
> modified event description with UUID.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-4045) IP address acquired with associateIpAddress is marked as source NAT, causing disassociateIpAddress to fail later

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460880#comment-16460880
 ] 

ASF GitHub Bot commented on CLOUDSTACK-4045:


rhtyd commented on issue #2382: CLOUDSTACK-4045 IP address acquired with 
associateIpAddress is marked as source NAT
URL: https://github.com/apache/cloudstack/pull/2382#issuecomment-385942642
 
 
   @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


> IP address acquired with associateIpAddress is marked as source NAT, causing 
> disassociateIpAddress to fail later
> 
>
> Key: CLOUDSTACK-4045
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4045
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.1.0, 4.1.1, 4.2.0
>Reporter: Murali Reddy
>Assignee: Henko Holtzhausen
>Priority: Major
> Fix For: Future
>
>
> When you can create network, network is in allocated state. when network is 
> implemented CloudStack implicitly should acquire a public IP for source nat. 
> But there is assumption that first IP this is associated with network is 
> always for source NAT IP. So when you do
> 1. create network (network is in allocated state)
> 2. acquire a public IP and associate with the network
> 3. disassociate ip address
> #3 will fail because CloudStack marks the IP acquired in #1 to be source NAT. 
> For users this is counter-intutive because when a IP is acquired, he/she 
> should be able to release it as well.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-4045) IP address acquired with associateIpAddress is marked as source NAT, causing disassociateIpAddress to fail later

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460881#comment-16460881
 ] 

ASF GitHub Bot commented on CLOUDSTACK-4045:


blueorangutan commented on issue #2382: CLOUDSTACK-4045 IP address acquired 
with associateIpAddress is marked as source NAT
URL: https://github.com/apache/cloudstack/pull/2382#issuecomment-385942661
 
 
   @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


> IP address acquired with associateIpAddress is marked as source NAT, causing 
> disassociateIpAddress to fail later
> 
>
> Key: CLOUDSTACK-4045
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4045
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.1.0, 4.1.1, 4.2.0
>Reporter: Murali Reddy
>Assignee: Henko Holtzhausen
>Priority: Major
> Fix For: Future
>
>
> When you can create network, network is in allocated state. when network is 
> implemented CloudStack implicitly should acquire a public IP for source nat. 
> But there is assumption that first IP this is associated with network is 
> always for source NAT IP. So when you do
> 1. create network (network is in allocated state)
> 2. acquire a public IP and associate with the network
> 3. disassociate ip address
> #3 will fail because CloudStack marks the IP acquired in #1 to be source NAT. 
> For users this is counter-intutive because when a IP is acquired, he/she 
> should be able to release it as well.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10309) VMs with HA enabled, power back on if shutdown from guest OS

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460876#comment-16460876
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10309:
-

rhtyd commented on issue #2473: CLOUDSTACK-10309 Add option on if to VM HA 
power-on a OOB-shut-off-VM
URL: https://github.com/apache/cloudstack/pull/2473#issuecomment-385942294
 
 
   Okay @rafaelweingartner I'll merge after smoketests are back.


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


> VMs with HA enabled, power back on if shutdown from guest OS
> 
>
> Key: CLOUDSTACK-10309
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10309
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.9.0, 4.10.0.0
> Environment: KVM
>Reporter: Sean Lair
>Priority: Minor
>
> When a user shuts down their VM from the guest OS (and VM HA is enabled), the 
> VM just powers itself back on.  Our environment is on KVM hosts.
> CloudStack does not know the difference between a VM failing or being 
> shutdown from within the guest OS.
> This is a major pain point for all our users - especially since they don't 
> pay for VMs when they are shutoff.  It is not intuitive for end-users to 
> understand why they can't shutdown VMs from within the guest OS.  Especially 
> when they all come from (non-cloudstack) VMware and Hyper-V environments 
> where this is not an issue.
> However, if a host fails, we need VM HA to still work.
> This Issue is being tied to a new PR that creates a configuration option 
> "ha.vm.restart.hostup".  With this option set to false, if CloudStack sees a 
> VM shutdown out-of-band, +*but the host it was on is still* *onlin*e+, then 
> it won't power it back on.  The logic is that since the host is online, it 
> was most likely shutdown from the guest OS.
> For when a host actually fails, standard VM HA logic takes over and powers on 
> VMs (with VM HA enabled) if the host they were on fails.
> If that "ha.vm.restart.hostup" option is true (the default to match current 
> functionality), it works like always, and even in-guest shutdowns of VMs 
> causes CloudStack to power back on the VM.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-4045) IP address acquired with associateIpAddress is marked as source NAT, causing disassociateIpAddress to fail later

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-4045?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460851#comment-16460851
 ] 

ASF GitHub Bot commented on CLOUDSTACK-4045:


houthuis commented on issue #2382: CLOUDSTACK-4045 IP address acquired with 
associateIpAddress is marked as source NAT
URL: https://github.com/apache/cloudstack/pull/2382#issuecomment-385935862
 
 
   @DaanHoogland thanks for running the tests, I am happy.


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


> IP address acquired with associateIpAddress is marked as source NAT, causing 
> disassociateIpAddress to fail later
> 
>
> Key: CLOUDSTACK-4045
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4045
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Affects Versions: 4.0.0, 4.0.1, 4.0.2, 4.1.0, 4.1.1, 4.2.0
>Reporter: Murali Reddy
>Assignee: Henko Holtzhausen
>Priority: Major
> Fix For: Future
>
>
> When you can create network, network is in allocated state. when network is 
> implemented CloudStack implicitly should acquire a public IP for source nat. 
> But there is assumption that first IP this is associated with network is 
> always for source NAT IP. So when you do
> 1. create network (network is in allocated state)
> 2. acquire a public IP and associate with the network
> 3. disassociate ip address
> #3 will fail because CloudStack marks the IP acquired in #1 to be source NAT. 
> For users this is counter-intutive because when a IP is acquired, he/she 
> should be able to release it as well.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10309) VMs with HA enabled, power back on if shutdown from guest OS

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460842#comment-16460842
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10309:
-

rafaelweingartner commented on issue #2473: CLOUDSTACK-10309 Add option on if 
to VM HA power-on a OOB-shut-off-VM
URL: https://github.com/apache/cloudstack/pull/2473#issuecomment-385934377
 
 
   I do believe it needs code extraction and unit tests, but you want to merge 
it. Let's proceed and merge.
   


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


> VMs with HA enabled, power back on if shutdown from guest OS
> 
>
> Key: CLOUDSTACK-10309
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10309
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.9.0, 4.10.0.0
> Environment: KVM
>Reporter: Sean Lair
>Priority: Minor
>
> When a user shuts down their VM from the guest OS (and VM HA is enabled), the 
> VM just powers itself back on.  Our environment is on KVM hosts.
> CloudStack does not know the difference between a VM failing or being 
> shutdown from within the guest OS.
> This is a major pain point for all our users - especially since they don't 
> pay for VMs when they are shutoff.  It is not intuitive for end-users to 
> understand why they can't shutdown VMs from within the guest OS.  Especially 
> when they all come from (non-cloudstack) VMware and Hyper-V environments 
> where this is not an issue.
> However, if a host fails, we need VM HA to still work.
> This Issue is being tied to a new PR that creates a configuration option 
> "ha.vm.restart.hostup".  With this option set to false, if CloudStack sees a 
> VM shutdown out-of-band, +*but the host it was on is still* *onlin*e+, then 
> it won't power it back on.  The logic is that since the host is online, it 
> was most likely shutdown from the guest OS.
> For when a host actually fails, standard VM HA logic takes over and powers on 
> VMs (with VM HA enabled) if the host they were on fails.
> If that "ha.vm.restart.hostup" option is true (the default to match current 
> functionality), it works like always, and even in-guest shutdowns of VMs 
> causes CloudStack to power back on the VM.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-9781) ACS records ID in events tables instead of UUID.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460836#comment-16460836
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9781:


rafaelweingartner commented on issue #1940: CLOUDSTACK-9781:ACS records ID in 
events tables instead of UUID.
URL: https://github.com/apache/cloudstack/pull/1940#issuecomment-385933561
 
 
   I have replied you guys at #2607. This error might happen if there are some 
other testes that change the tags of the primary storage I use.


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 records ID in events tables instead of UUID.
> 
>
> Key: CLOUDSTACK-9781
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9781
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Jayant Patil
>Priority: Major
>
> ISSUE
> =
> Wrong presentation of volume id in ACS events.
> While creating a snapshot, only volume ID is mentioned in the events. For 
> example, “Scheduled async job for creating snapshot for volume Id:270". On 
> looking into the notification, user is not able to identify the volume. So 
> modified event description with UUID.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-9781) ACS records ID in events tables instead of UUID.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460837#comment-16460837
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9781:


rafaelweingartner commented on issue #1940: CLOUDSTACK-9781:ACS records ID in 
events tables instead of UUID.
URL: https://github.com/apache/cloudstack/pull/1940#issuecomment-385933561
 
 
   I have replied you guys at #2607. This error happens if there are some other 
testes that change the tags of the primary storage I use.


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 records ID in events tables instead of UUID.
> 
>
> Key: CLOUDSTACK-9781
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9781
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Jayant Patil
>Priority: Major
>
> ISSUE
> =
> Wrong presentation of volume id in ACS events.
> While creating a snapshot, only volume ID is mentioned in the events. For 
> example, “Scheduled async job for creating snapshot for volume Id:270". On 
> looking into the notification, user is not able to identify the volume. So 
> modified event description with UUID.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10309) VMs with HA enabled, power back on if shutdown from guest OS

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460801#comment-16460801
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10309:
-

blueorangutan commented on issue #2473: CLOUDSTACK-10309 Add option on if to VM 
HA power-on a OOB-shut-off-VM
URL: https://github.com/apache/cloudstack/pull/2473#issuecomment-385926883
 
 
   @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


> VMs with HA enabled, power back on if shutdown from guest OS
> 
>
> Key: CLOUDSTACK-10309
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10309
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.9.0, 4.10.0.0
> Environment: KVM
>Reporter: Sean Lair
>Priority: Minor
>
> When a user shuts down their VM from the guest OS (and VM HA is enabled), the 
> VM just powers itself back on.  Our environment is on KVM hosts.
> CloudStack does not know the difference between a VM failing or being 
> shutdown from within the guest OS.
> This is a major pain point for all our users - especially since they don't 
> pay for VMs when they are shutoff.  It is not intuitive for end-users to 
> understand why they can't shutdown VMs from within the guest OS.  Especially 
> when they all come from (non-cloudstack) VMware and Hyper-V environments 
> where this is not an issue.
> However, if a host fails, we need VM HA to still work.
> This Issue is being tied to a new PR that creates a configuration option 
> "ha.vm.restart.hostup".  With this option set to false, if CloudStack sees a 
> VM shutdown out-of-band, +*but the host it was on is still* *onlin*e+, then 
> it won't power it back on.  The logic is that since the host is online, it 
> was most likely shutdown from the guest OS.
> For when a host actually fails, standard VM HA logic takes over and powers on 
> VMs (with VM HA enabled) if the host they were on fails.
> If that "ha.vm.restart.hostup" option is true (the default to match current 
> functionality), it works like always, and even in-guest shutdowns of VMs 
> causes CloudStack to power back on the VM.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10309) VMs with HA enabled, power back on if shutdown from guest OS

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460800#comment-16460800
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10309:
-

rhtyd commented on issue #2473: CLOUDSTACK-10309 Add option on if to VM HA 
power-on a OOB-shut-off-VM
URL: https://github.com/apache/cloudstack/pull/2473#issuecomment-385926721
 
 
   @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


> VMs with HA enabled, power back on if shutdown from guest OS
> 
>
> Key: CLOUDSTACK-10309
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10309
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.9.0, 4.10.0.0
> Environment: KVM
>Reporter: Sean Lair
>Priority: Minor
>
> When a user shuts down their VM from the guest OS (and VM HA is enabled), the 
> VM just powers itself back on.  Our environment is on KVM hosts.
> CloudStack does not know the difference between a VM failing or being 
> shutdown from within the guest OS.
> This is a major pain point for all our users - especially since they don't 
> pay for VMs when they are shutoff.  It is not intuitive for end-users to 
> understand why they can't shutdown VMs from within the guest OS.  Especially 
> when they all come from (non-cloudstack) VMware and Hyper-V environments 
> where this is not an issue.
> However, if a host fails, we need VM HA to still work.
> This Issue is being tied to a new PR that creates a configuration option 
> "ha.vm.restart.hostup".  With this option set to false, if CloudStack sees a 
> VM shutdown out-of-band, +*but the host it was on is still* *onlin*e+, then 
> it won't power it back on.  The logic is that since the host is online, it 
> was most likely shutdown from the guest OS.
> For when a host actually fails, standard VM HA logic takes over and powers on 
> VMs (with VM HA enabled) if the host they were on fails.
> If that "ha.vm.restart.hostup" option is true (the default to match current 
> functionality), it works like always, and even in-guest shutdowns of VMs 
> causes CloudStack to power back on the VM.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10232) SystemVMs and VR to run as HVM on XenServer

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460777#comment-16460777
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10232:
-

rhtyd commented on a change in pull request #2465: CLOUDSTACK-10232: SystemVMs 
and VR to run as HVM on XenServer
URL: https://github.com/apache/cloudstack/pull/2465#discussion_r185440771
 
 

 ##
 File path: systemvm/debian/opt/cloud/bin/setup/cloud-early-config
 ##
 @@ -64,10 +71,17 @@ config_guest() {
 
 get_boot_params() {
   case $HYPERVISOR in
- xen-domU|xen-hvm)
+ xen-pv)
   cat /proc/cmdline > $CMDLINE
   sed -i "s/%/ /g" $CMDLINE
   ;;
+ xen-hvm)
+  if [ ! -f /usr/sbin/xenstore-read ]; then
+log_it "ERROR: xentools not installed, cannot found xenstore-read" 
&& exit 5
+  fi
+  /usr/sbin/xenstore-read vm-data/cloudstack/init > 
/var/cache/cloud/cmdline
 
 Review comment:
   @khos2ow in 4.11 systemvmtemplate, the xenstore-read is at /usr/bin, can you 
check/comment why /usr/sbin was used? I've however, fixed this blocker in the 
stabilization PR: 
https://github.com/shapeblue/cloudstack/commit/3dbb2e6b4b98cba9d59b241bd0a8c2a051131cbc


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


> SystemVMs and VR to run as HVM on XenServer
> ---
>
> Key: CLOUDSTACK-10232
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10232
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM, Virtual Router, XenServer
>Affects Versions: 4.10.0.0, 4.9.3.0
>Reporter: Pierre-Luc Dion
>Priority: Major
>
> Following the recent Meltdown-Spectre security risk,one of the mitigation,as 
> of Jan 2018, for XenServer Hypervisor is to run Virtual-Machine in HVM mode.
> Currently SystemVMs and Virtual-Routers run as PV on XenServer and the eth0 
> is configured using {{/etc/init.d/cloud-early-config}} using grub params from 
> {{/proc/cmdline}}. When VM run as HVM, it is not possible to push initial 
> boot instruction via pygrub.
> Quick tests has been done using xenstore and it look like it would be 
> possible to send same initial boot instruction has pygrub but using xenstore 
> for HVM instances.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10309) VMs with HA enabled, power back on if shutdown from guest OS

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460771#comment-16460771
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10309:
-

blueorangutan commented on issue #2473: CLOUDSTACK-10309 Add option on if to VM 
HA power-on a OOB-shut-off-VM
URL: https://github.com/apache/cloudstack/pull/2473#issuecomment-385918272
 
 
   Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1991


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


> VMs with HA enabled, power back on if shutdown from guest OS
> 
>
> Key: CLOUDSTACK-10309
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10309
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.9.0, 4.10.0.0
> Environment: KVM
>Reporter: Sean Lair
>Priority: Minor
>
> When a user shuts down their VM from the guest OS (and VM HA is enabled), the 
> VM just powers itself back on.  Our environment is on KVM hosts.
> CloudStack does not know the difference between a VM failing or being 
> shutdown from within the guest OS.
> This is a major pain point for all our users - especially since they don't 
> pay for VMs when they are shutoff.  It is not intuitive for end-users to 
> understand why they can't shutdown VMs from within the guest OS.  Especially 
> when they all come from (non-cloudstack) VMware and Hyper-V environments 
> where this is not an issue.
> However, if a host fails, we need VM HA to still work.
> This Issue is being tied to a new PR that creates a configuration option 
> "ha.vm.restart.hostup".  With this option set to false, if CloudStack sees a 
> VM shutdown out-of-band, +*but the host it was on is still* *onlin*e+, then 
> it won't power it back on.  The logic is that since the host is online, it 
> was most likely shutdown from the guest OS.
> For when a host actually fails, standard VM HA logic takes over and powers on 
> VMs (with VM HA enabled) if the host they were on fails.
> If that "ha.vm.restart.hostup" option is true (the default to match current 
> functionality), it works like always, and even in-guest shutdowns of VMs 
> causes CloudStack to power back on the VM.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10309) VMs with HA enabled, power back on if shutdown from guest OS

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460741#comment-16460741
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10309:
-

rhtyd commented on issue #2473: CLOUDSTACK-10309 Add option on if to VM HA 
power-on a OOB-shut-off-VM
URL: https://github.com/apache/cloudstack/pull/2473#issuecomment-385910875
 
 
   @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


> VMs with HA enabled, power back on if shutdown from guest OS
> 
>
> Key: CLOUDSTACK-10309
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10309
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.9.0, 4.10.0.0
> Environment: KVM
>Reporter: Sean Lair
>Priority: Minor
>
> When a user shuts down their VM from the guest OS (and VM HA is enabled), the 
> VM just powers itself back on.  Our environment is on KVM hosts.
> CloudStack does not know the difference between a VM failing or being 
> shutdown from within the guest OS.
> This is a major pain point for all our users - especially since they don't 
> pay for VMs when they are shutoff.  It is not intuitive for end-users to 
> understand why they can't shutdown VMs from within the guest OS.  Especially 
> when they all come from (non-cloudstack) VMware and Hyper-V environments 
> where this is not an issue.
> However, if a host fails, we need VM HA to still work.
> This Issue is being tied to a new PR that creates a configuration option 
> "ha.vm.restart.hostup".  With this option set to false, if CloudStack sees a 
> VM shutdown out-of-band, +*but the host it was on is still* *onlin*e+, then 
> it won't power it back on.  The logic is that since the host is online, it 
> was most likely shutdown from the guest OS.
> For when a host actually fails, standard VM HA logic takes over and powers on 
> VMs (with VM HA enabled) if the host they were on fails.
> If that "ha.vm.restart.hostup" option is true (the default to match current 
> functionality), it works like always, and even in-guest shutdowns of VMs 
> causes CloudStack to power back on the VM.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10309) VMs with HA enabled, power back on if shutdown from guest OS

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460742#comment-16460742
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10309:
-

blueorangutan commented on issue #2473: CLOUDSTACK-10309 Add option on if to VM 
HA power-on a OOB-shut-off-VM
URL: https://github.com/apache/cloudstack/pull/2473#issuecomment-385910924
 
 
   @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


> VMs with HA enabled, power back on if shutdown from guest OS
> 
>
> Key: CLOUDSTACK-10309
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10309
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.9.0, 4.10.0.0
> Environment: KVM
>Reporter: Sean Lair
>Priority: Minor
>
> When a user shuts down their VM from the guest OS (and VM HA is enabled), the 
> VM just powers itself back on.  Our environment is on KVM hosts.
> CloudStack does not know the difference between a VM failing or being 
> shutdown from within the guest OS.
> This is a major pain point for all our users - especially since they don't 
> pay for VMs when they are shutoff.  It is not intuitive for end-users to 
> understand why they can't shutdown VMs from within the guest OS.  Especially 
> when they all come from (non-cloudstack) VMware and Hyper-V environments 
> where this is not an issue.
> However, if a host fails, we need VM HA to still work.
> This Issue is being tied to a new PR that creates a configuration option 
> "ha.vm.restart.hostup".  With this option set to false, if CloudStack sees a 
> VM shutdown out-of-band, +*but the host it was on is still* *onlin*e+, then 
> it won't power it back on.  The logic is that since the host is online, it 
> was most likely shutdown from the guest OS.
> For when a host actually fails, standard VM HA logic takes over and powers on 
> VMs (with VM HA enabled) if the host they were on fails.
> If that "ha.vm.restart.hostup" option is true (the default to match current 
> functionality), it works like always, and even in-guest shutdowns of VMs 
> causes CloudStack to power back on the VM.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-8959) Option to remove mapping of the config drive when deploying VM

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-8959?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460727#comment-16460727
 ] 

ASF GitHub Bot commented on CLOUDSTACK-8959:


rhtyd commented on issue #2116: CLOUDSTACK-8959: Option to attach the config 
drive
URL: https://github.com/apache/cloudstack/pull/2116#issuecomment-385908508
 
 
   @DaanHoogland @fmaximus @jayapalu ping, can you comment if this PR was 
already included in any other PR, or we still need this PR towards the config 
drive feature?


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


> Option to remove mapping of the config drive when deploying VM
> --
>
> Key: CLOUDSTACK-8959
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8959
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Kshitij Kansal
>Priority: Major
>




--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10362) Inconsistent method names

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460699#comment-16460699
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10362:
-

blueorangutan commented on issue #2600: CLOUDSTACK-10362: Change the "getXXX" 
method names to "isXXX".
URL: https://github.com/apache/cloudstack/pull/2600#issuecomment-385901557
 
 
   Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1989


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


> Inconsistent method names
> -
>
> Key: CLOUDSTACK-10362
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10362
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: KuiLIU
>Priority: Major
>
> Some Boolean-return methods are named "getXXX",
> but other Boolean-return methods are named "isXXX", such as the following two 
> methods.
> They will return boolean values, rename them as "isXXX" should be more clear 
> than "getXXX".
> api/src/main/java/org/apache/cloudstack/api/command/admin/vlan/ListVlanIpRangesCmd.java
> {code:java}
>  public Boolean getForVirtualNetwork() {
>  return forVirtualNetwork;
>  }
> {code}
> api/src/main/java/org/apache/cloudstack/api/command/user/address/ListPublicIpAddressesCmd.java
> {code:java}
> public Boolean isForVirtualNetwork() {
> return forVirtualNetwork;
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10309) VMs with HA enabled, power back on if shutdown from guest OS

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460700#comment-16460700
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10309:
-

blueorangutan commented on issue #2473: CLOUDSTACK-10309 Add option on if to VM 
HA power-on a OOB-shut-off-VM
URL: https://github.com/apache/cloudstack/pull/2473#issuecomment-385901746
 
 
   Packaging result: ✔centos6 ✖centos7 ✖debian. JID-1990


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


> VMs with HA enabled, power back on if shutdown from guest OS
> 
>
> Key: CLOUDSTACK-10309
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10309
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.9.0, 4.10.0.0
> Environment: KVM
>Reporter: Sean Lair
>Priority: Minor
>
> When a user shuts down their VM from the guest OS (and VM HA is enabled), the 
> VM just powers itself back on.  Our environment is on KVM hosts.
> CloudStack does not know the difference between a VM failing or being 
> shutdown from within the guest OS.
> This is a major pain point for all our users - especially since they don't 
> pay for VMs when they are shutoff.  It is not intuitive for end-users to 
> understand why they can't shutdown VMs from within the guest OS.  Especially 
> when they all come from (non-cloudstack) VMware and Hyper-V environments 
> where this is not an issue.
> However, if a host fails, we need VM HA to still work.
> This Issue is being tied to a new PR that creates a configuration option 
> "ha.vm.restart.hostup".  With this option set to false, if CloudStack sees a 
> VM shutdown out-of-band, +*but the host it was on is still* *onlin*e+, then 
> it won't power it back on.  The logic is that since the host is online, it 
> was most likely shutdown from the guest OS.
> For when a host actually fails, standard VM HA logic takes over and powers on 
> VMs (with VM HA enabled) if the host they were on fails.
> If that "ha.vm.restart.hostup" option is true (the default to match current 
> functionality), it works like always, and even in-guest shutdowns of VMs 
> causes CloudStack to power back on the VM.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-9781) ACS records ID in events tables instead of UUID.

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460672#comment-16460672
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9781:


rhtyd commented on issue #1940: CLOUDSTACK-9781:ACS records ID in events tables 
instead of UUID.
URL: https://github.com/apache/cloudstack/pull/1940#issuecomment-385895269
 
 
   The only new issue/failure I see is 
`test_11_migrate_volume_and_change_offering`. @jayantpatil1234 can you check if 
this error is caused by your PR /cc @rafaelweingartner @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


> ACS records ID in events tables instead of UUID.
> 
>
> Key: CLOUDSTACK-9781
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9781
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Jayant Patil
>Priority: Major
>
> ISSUE
> =
> Wrong presentation of volume id in ACS events.
> While creating a snapshot, only volume ID is mentioned in the events. For 
> example, “Scheduled async job for creating snapshot for volume Id:270". On 
> looking into the notification, user is not able to identify the volume. So 
> modified event description with UUID.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10223) Snapshots are not getting deleted when domain is deleted

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460671#comment-16460671
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10223:
-

blueorangutan commented on issue #2399: CLOUDSTACK-10223 delete snapshots when 
deleting domain
URL: https://github.com/apache/cloudstack/pull/2399#issuecomment-385894554
 
 
   @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


> Snapshots are not getting deleted when domain is deleted
> 
>
> Key: CLOUDSTACK-10223
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10223
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Sowjanya_Patha
>Priority: Minor
>
> After domain deletion, snapshot taken by the domain remains undeleted.
> Steps to reproduce:
> ---
> 1. Create a test domain
> 2. Create test account with admin privileges.
> 3. Login as "test" acoount.
> 4. Create 3 instances - few having root disk and rest with root and data 
> disks both.
> 5. For 2 instances take snapshots of root and data disks
> 6. Expunge above instances from ACP UI.
> 7. Make sure that those vm's should not be shown in ACP UI.
> 8. Login as root user again
> 9. Delete the test account
> 10. Delete the test domain
> Snapshots taken for root volume in step 5 are not deleted.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10309) VMs with HA enabled, power back on if shutdown from guest OS

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460669#comment-16460669
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10309:
-

DaanHoogland commented on issue #2473: CLOUDSTACK-10309 Add option on if to VM 
HA power-on a OOB-shut-off-VM
URL: https://github.com/apache/cloudstack/pull/2473#issuecomment-385894396
 
 
   @rhtyd @rafaelweingartner , i just revisited the code and stand by my the 
lgtm.


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


> VMs with HA enabled, power back on if shutdown from guest OS
> 
>
> Key: CLOUDSTACK-10309
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10309
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.9.0, 4.10.0.0
> Environment: KVM
>Reporter: Sean Lair
>Priority: Minor
>
> When a user shuts down their VM from the guest OS (and VM HA is enabled), the 
> VM just powers itself back on.  Our environment is on KVM hosts.
> CloudStack does not know the difference between a VM failing or being 
> shutdown from within the guest OS.
> This is a major pain point for all our users - especially since they don't 
> pay for VMs when they are shutoff.  It is not intuitive for end-users to 
> understand why they can't shutdown VMs from within the guest OS.  Especially 
> when they all come from (non-cloudstack) VMware and Hyper-V environments 
> where this is not an issue.
> However, if a host fails, we need VM HA to still work.
> This Issue is being tied to a new PR that creates a configuration option 
> "ha.vm.restart.hostup".  With this option set to false, if CloudStack sees a 
> VM shutdown out-of-band, +*but the host it was on is still* *onlin*e+, then 
> it won't power it back on.  The logic is that since the host is online, it 
> was most likely shutdown from the guest OS.
> For when a host actually fails, standard VM HA logic takes over and powers on 
> VMs (with VM HA enabled) if the host they were on fails.
> If that "ha.vm.restart.hostup" option is true (the default to match current 
> functionality), it works like always, and even in-guest shutdowns of VMs 
> causes CloudStack to power back on the VM.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10223) Snapshots are not getting deleted when domain is deleted

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460667#comment-16460667
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10223:
-

rhtyd commented on issue #2399: CLOUDSTACK-10223 delete snapshots when deleting 
domain
URL: https://github.com/apache/cloudstack/pull/2399#issuecomment-385894307
 
 
   LGTM, let me re-run again.
   @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


> Snapshots are not getting deleted when domain is deleted
> 
>
> Key: CLOUDSTACK-10223
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10223
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Sowjanya_Patha
>Priority: Minor
>
> After domain deletion, snapshot taken by the domain remains undeleted.
> Steps to reproduce:
> ---
> 1. Create a test domain
> 2. Create test account with admin privileges.
> 3. Login as "test" acoount.
> 4. Create 3 instances - few having root disk and rest with root and data 
> disks both.
> 5. For 2 instances take snapshots of root and data disks
> 6. Expunge above instances from ACP UI.
> 7. Make sure that those vm's should not be shown in ACP UI.
> 8. Login as root user again
> 9. Delete the test account
> 10. Delete the test domain
> Snapshots taken for root volume in step 5 are not deleted.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10311) Agent Log Rotate variable replace bug

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460655#comment-16460655
 ] 

ASF subversion and git services commented on CLOUDSTACK-10311:
--

Commit df2b26e350121834435d1f4b888a8ecd00c0b5db in cloudstack's branch 
refs/heads/4.10 from [~slair1]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=df2b26e ]

CLOUDSTACK-10311 Agent Log Rotate variable replace bug (#2471)

* CLOUDSTACK-10311 Agent Log Rotate variable replace bug

* update travis timeouts


> Agent Log Rotate variable replace bug
> -
>
> Key: CLOUDSTACK-10311
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10311
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: cloudstack-agent
>Affects Versions: 4.10.0.0, 4.9.3.0
>Reporter: Sean Lair
>Priority: Major
>
> The cloudstack-agent was modified to use the @AGENTLOG@ variable entry, but 
> the pom.xml file was not correct to do the replacement of the @AGENTLOG@.
> {{@AGENTLOG@}}
> {{/var/log/cloudstack/agent/security_group.log}}
> {{{}}
> {{ copytruncate}}
> {{ daily}}
> {{ rotate 5}}
> {{ compress}}
> {{ missingok}}
> {{}}}
> PR coming



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10311) Agent Log Rotate variable replace bug

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460660#comment-16460660
 ] 

ASF subversion and git services commented on CLOUDSTACK-10311:
--

Commit df2b26e350121834435d1f4b888a8ecd00c0b5db in cloudstack's branch 
refs/heads/master from [~slair1]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=df2b26e ]

CLOUDSTACK-10311 Agent Log Rotate variable replace bug (#2471)

* CLOUDSTACK-10311 Agent Log Rotate variable replace bug

* update travis timeouts


> Agent Log Rotate variable replace bug
> -
>
> Key: CLOUDSTACK-10311
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10311
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: cloudstack-agent
>Affects Versions: 4.10.0.0, 4.9.3.0
>Reporter: Sean Lair
>Priority: Major
>
> The cloudstack-agent was modified to use the @AGENTLOG@ variable entry, but 
> the pom.xml file was not correct to do the replacement of the @AGENTLOG@.
> {{@AGENTLOG@}}
> {{/var/log/cloudstack/agent/security_group.log}}
> {{{}}
> {{ copytruncate}}
> {{ daily}}
> {{ rotate 5}}
> {{ compress}}
> {{ missingok}}
> {{}}}
> PR coming



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10311) Agent Log Rotate variable replace bug

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460658#comment-16460658
 ] 

ASF subversion and git services commented on CLOUDSTACK-10311:
--

Commit df2b26e350121834435d1f4b888a8ecd00c0b5db in cloudstack's branch 
refs/heads/4.11 from [~slair1]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=df2b26e ]

CLOUDSTACK-10311 Agent Log Rotate variable replace bug (#2471)

* CLOUDSTACK-10311 Agent Log Rotate variable replace bug

* update travis timeouts


> Agent Log Rotate variable replace bug
> -
>
> Key: CLOUDSTACK-10311
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10311
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: cloudstack-agent
>Affects Versions: 4.10.0.0, 4.9.3.0
>Reporter: Sean Lair
>Priority: Major
>
> The cloudstack-agent was modified to use the @AGENTLOG@ variable entry, but 
> the pom.xml file was not correct to do the replacement of the @AGENTLOG@.
> {{@AGENTLOG@}}
> {{/var/log/cloudstack/agent/security_group.log}}
> {{{}}
> {{ copytruncate}}
> {{ daily}}
> {{ rotate 5}}
> {{ compress}}
> {{ missingok}}
> {{}}}
> PR coming



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10311) Agent Log Rotate variable replace bug

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460654#comment-16460654
 ] 

ASF subversion and git services commented on CLOUDSTACK-10311:
--

Commit df2b26e350121834435d1f4b888a8ecd00c0b5db in cloudstack's branch 
refs/heads/4.10 from [~slair1]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=df2b26e ]

CLOUDSTACK-10311 Agent Log Rotate variable replace bug (#2471)

* CLOUDSTACK-10311 Agent Log Rotate variable replace bug

* update travis timeouts


> Agent Log Rotate variable replace bug
> -
>
> Key: CLOUDSTACK-10311
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10311
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: cloudstack-agent
>Affects Versions: 4.10.0.0, 4.9.3.0
>Reporter: Sean Lair
>Priority: Major
>
> The cloudstack-agent was modified to use the @AGENTLOG@ variable entry, but 
> the pom.xml file was not correct to do the replacement of the @AGENTLOG@.
> {{@AGENTLOG@}}
> {{/var/log/cloudstack/agent/security_group.log}}
> {{{}}
> {{ copytruncate}}
> {{ daily}}
> {{ rotate 5}}
> {{ compress}}
> {{ missingok}}
> {{}}}
> PR coming



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10311) Agent Log Rotate variable replace bug

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460659#comment-16460659
 ] 

ASF subversion and git services commented on CLOUDSTACK-10311:
--

Commit df2b26e350121834435d1f4b888a8ecd00c0b5db in cloudstack's branch 
refs/heads/master from [~slair1]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=df2b26e ]

CLOUDSTACK-10311 Agent Log Rotate variable replace bug (#2471)

* CLOUDSTACK-10311 Agent Log Rotate variable replace bug

* update travis timeouts


> Agent Log Rotate variable replace bug
> -
>
> Key: CLOUDSTACK-10311
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10311
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: cloudstack-agent
>Affects Versions: 4.10.0.0, 4.9.3.0
>Reporter: Sean Lair
>Priority: Major
>
> The cloudstack-agent was modified to use the @AGENTLOG@ variable entry, but 
> the pom.xml file was not correct to do the replacement of the @AGENTLOG@.
> {{@AGENTLOG@}}
> {{/var/log/cloudstack/agent/security_group.log}}
> {{{}}
> {{ copytruncate}}
> {{ daily}}
> {{ rotate 5}}
> {{ compress}}
> {{ missingok}}
> {{}}}
> PR coming



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10311) Agent Log Rotate variable replace bug

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460657#comment-16460657
 ] 

ASF subversion and git services commented on CLOUDSTACK-10311:
--

Commit df2b26e350121834435d1f4b888a8ecd00c0b5db in cloudstack's branch 
refs/heads/4.11 from [~slair1]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=df2b26e ]

CLOUDSTACK-10311 Agent Log Rotate variable replace bug (#2471)

* CLOUDSTACK-10311 Agent Log Rotate variable replace bug

* update travis timeouts


> Agent Log Rotate variable replace bug
> -
>
> Key: CLOUDSTACK-10311
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10311
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: cloudstack-agent
>Affects Versions: 4.10.0.0, 4.9.3.0
>Reporter: Sean Lair
>Priority: Major
>
> The cloudstack-agent was modified to use the @AGENTLOG@ variable entry, but 
> the pom.xml file was not correct to do the replacement of the @AGENTLOG@.
> {{@AGENTLOG@}}
> {{/var/log/cloudstack/agent/security_group.log}}
> {{{}}
> {{ copytruncate}}
> {{ daily}}
> {{ rotate 5}}
> {{ compress}}
> {{ missingok}}
> {{}}}
> PR coming



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10311) Agent Log Rotate variable replace bug

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460649#comment-16460649
 ] 

ASF subversion and git services commented on CLOUDSTACK-10311:
--

Commit df2b26e350121834435d1f4b888a8ecd00c0b5db in cloudstack's branch 
refs/heads/4.9 from [~slair1]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=df2b26e ]

CLOUDSTACK-10311 Agent Log Rotate variable replace bug (#2471)

* CLOUDSTACK-10311 Agent Log Rotate variable replace bug

* update travis timeouts


> Agent Log Rotate variable replace bug
> -
>
> Key: CLOUDSTACK-10311
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10311
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: cloudstack-agent
>Affects Versions: 4.10.0.0, 4.9.3.0
>Reporter: Sean Lair
>Priority: Major
>
> The cloudstack-agent was modified to use the @AGENTLOG@ variable entry, but 
> the pom.xml file was not correct to do the replacement of the @AGENTLOG@.
> {{@AGENTLOG@}}
> {{/var/log/cloudstack/agent/security_group.log}}
> {{{}}
> {{ copytruncate}}
> {{ daily}}
> {{ rotate 5}}
> {{ compress}}
> {{ missingok}}
> {{}}}
> PR coming



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10311) Agent Log Rotate variable replace bug

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460647#comment-16460647
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10311:
-

rhtyd closed pull request #2471: CLOUDSTACK-10311 Agent Log Rotate variable 
replace bug
URL: https://github.com/apache/cloudstack/pull/2471
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git a/.travis.yml b/.travis.yml
index f975c55eacb..359d788 100644
--- a/.travis.yml
+++ b/.travis.yml
@@ -149,9 +149,9 @@ env:
 #- TESTS="component/test_accounts"
 #- TESTS="component/test_organization_states"
 
-before_install: travis_wait 30 ./tools/travis/before_install.sh
+before_install: travis_wait 60 ./tools/travis/before_install.sh
 install: ./tools/travis/install.sh
-before_script: travis_wait 30 ./tools/travis/before_script.sh
+before_script: travis_wait 60 ./tools/travis/before_script.sh
 script:
   - travis_wait 40 ./tools/travis/script.sh ${TESTS}
 after_success: ./tools/travis/after_success.sh
diff --git a/agent/conf/cloudstack-agent.logrotate 
b/agent/conf/cloudstack-agent.logrotate.in
similarity index 100%
rename from agent/conf/cloudstack-agent.logrotate
rename to agent/conf/cloudstack-agent.logrotate.in
diff --git a/agent/pom.xml b/agent/pom.xml
index 2eb6ca9e9aa..02eb9d8b1dc 100644
--- a/agent/pom.xml
+++ b/agent/pom.xml
@@ -93,12 +93,6 @@
 
   
 
-
-  
-
-  
-
   
 
   


 


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


> Agent Log Rotate variable replace bug
> -
>
> Key: CLOUDSTACK-10311
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10311
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: cloudstack-agent
>Affects Versions: 4.10.0.0, 4.9.3.0
>Reporter: Sean Lair
>Priority: Major
>
> The cloudstack-agent was modified to use the @AGENTLOG@ variable entry, but 
> the pom.xml file was not correct to do the replacement of the @AGENTLOG@.
> {{@AGENTLOG@}}
> {{/var/log/cloudstack/agent/security_group.log}}
> {{{}}
> {{ copytruncate}}
> {{ daily}}
> {{ rotate 5}}
> {{ compress}}
> {{ missingok}}
> {{}}}
> PR coming



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10309) VMs with HA enabled, power back on if shutdown from guest OS

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460642#comment-16460642
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10309:
-

rhtyd closed pull request #2473: CLOUDSTACK-10309 Add option on if to VM HA 
power-on a OOB-shut-off-VM
URL: https://github.com/apache/cloudstack/pull/2473
 
 
   

This is a PR merged from a forked repository.
As GitHub hides the original diff on merge, it is displayed below for
the sake of provenance:

As this is a foreign pull request (from a fork), the diff is supplied
below (as it won't show otherwise due to GitHub magic):

diff --git 
a/engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java 
b/engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java
index f5bdf38740f..6fdd09865da 100644
--- a/engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java
+++ b/engine/orchestration/src/com/cloud/vm/VirtualMachineManagerImpl.java
@@ -359,6 +359,9 @@ public void setHostAllocators(final List 
hostAllocators) {
 Integer.class, "vm.job.report.interval", "60",
 "Interval to send application level pings to make sure the 
connection is still working", false);
 
+static final ConfigKey HaVmRestartHostUp = new 
ConfigKey("Advanced", Boolean.class, "ha.vm.restart.hostup", "true",
+"If an out-of-band stop of a VM is detected and its host is up, 
then power on the VM", true);
+
 ScheduledExecutorService _executor = null;
 
 protected long _nodeId;
@@ -3708,7 +3711,7 @@ public String getConfigComponentName() {
 public ConfigKey[] getConfigKeys() {
 return new ConfigKey[] {ClusterDeltaSyncInterval, StartRetry, 
VmDestroyForcestop, VmOpCancelInterval, VmOpCleanupInterval, VmOpCleanupWait,
 VmOpLockStateRetry,
-VmOpWaitInterval, ExecuteInSequence, VmJobCheckInterval, 
VmJobTimeout, VmJobStateReportInterval, VmConfigDriveLabel};
+VmOpWaitInterval, ExecuteInSequence, VmJobCheckInterval, 
VmJobTimeout, VmJobStateReportInterval, VmConfigDriveLabel, HaVmRestartHostUp};
 }
 
 public List getStoragePoolAllocators() {
@@ -3853,7 +3856,7 @@ private void 
handlePowerOffReportWithNoPendingJobsOnVM(final VMInstanceVO vm) {
 case Stopped:
 case Migrating:
 s_logger.info("VM " + vm.getInstanceName() + " is at " + 
vm.getState() + " and we received a power-off report while there is no pending 
jobs on it");
-if(vm.isHaEnabled() && vm.getState() == State.Running && 
vm.getHypervisorType() != HypervisorType.VMware && vm.getHypervisorType() != 
HypervisorType.Hyperv) {
+if(vm.isHaEnabled() && vm.getState() == State.Running && 
HaVmRestartHostUp.value() && vm.getHypervisorType() != HypervisorType.VMware && 
vm.getHypervisorType() != HypervisorType.Hyperv) {
 s_logger.info("Detected out-of-band stop of a HA enabled VM " 
+ vm.getInstanceName() + ", will schedule restart");
 if(!_haMgr.hasPendingHaWork(vm.getId())) {
 _haMgr.scheduleRestart(vm, true);


 


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


> VMs with HA enabled, power back on if shutdown from guest OS
> 
>
> Key: CLOUDSTACK-10309
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10309
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.9.0, 4.10.0.0
> Environment: KVM
>Reporter: Sean Lair
>Priority: Minor
>
> When a user shuts down their VM from the guest OS (and VM HA is enabled), the 
> VM just powers itself back on.  Our environment is on KVM hosts.
> CloudStack does not know the difference between a VM failing or being 
> shutdown from within the guest OS.
> This is a major pain point for all our users - especially since they don't 
> pay for VMs when they are shutoff.  It is not intuitive for end-users to 
> understand why they can't shutdown VMs from within the guest OS.  Especially 
> when they all come from (non-cloudstack) VMware and Hyper-V environments 
> where this is not an issue.
> However, if a host fails, we need VM HA to still work.
> This Issue is being tied to a new PR that creates a configuration option 
> "ha.vm.restart.hostup".  With this option set to false, if CloudStack sees a 
> VM shutdown out-of-band, +*but the host it was on is still* *onlin*e+, then 
> it won't power it back on.  The logic 

[jira] [Commented] (CLOUDSTACK-10311) Agent Log Rotate variable replace bug

[ASF subversion and git services (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10311?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460648#comment-16460648
 ] 

ASF subversion and git services commented on CLOUDSTACK-10311:
--

Commit df2b26e350121834435d1f4b888a8ecd00c0b5db in cloudstack's branch 
refs/heads/4.9 from [~slair1]
[ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=df2b26e ]

CLOUDSTACK-10311 Agent Log Rotate variable replace bug (#2471)

* CLOUDSTACK-10311 Agent Log Rotate variable replace bug

* update travis timeouts


> Agent Log Rotate variable replace bug
> -
>
> Key: CLOUDSTACK-10311
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10311
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: cloudstack-agent
>Affects Versions: 4.10.0.0, 4.9.3.0
>Reporter: Sean Lair
>Priority: Major
>
> The cloudstack-agent was modified to use the @AGENTLOG@ variable entry, but 
> the pom.xml file was not correct to do the replacement of the @AGENTLOG@.
> {{@AGENTLOG@}}
> {{/var/log/cloudstack/agent/security_group.log}}
> {{{}}
> {{ copytruncate}}
> {{ daily}}
> {{ rotate 5}}
> {{ compress}}
> {{ missingok}}
> {{}}}
> PR coming



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10309) VMs with HA enabled, power back on if shutdown from guest OS

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460646#comment-16460646
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10309:
-

blueorangutan commented on issue #2473: CLOUDSTACK-10309 Add option on if to VM 
HA power-on a OOB-shut-off-VM
URL: https://github.com/apache/cloudstack/pull/2473#issuecomment-385892533
 
 
   @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


> VMs with HA enabled, power back on if shutdown from guest OS
> 
>
> Key: CLOUDSTACK-10309
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10309
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.9.0, 4.10.0.0
> Environment: KVM
>Reporter: Sean Lair
>Priority: Minor
>
> When a user shuts down their VM from the guest OS (and VM HA is enabled), the 
> VM just powers itself back on.  Our environment is on KVM hosts.
> CloudStack does not know the difference between a VM failing or being 
> shutdown from within the guest OS.
> This is a major pain point for all our users - especially since they don't 
> pay for VMs when they are shutoff.  It is not intuitive for end-users to 
> understand why they can't shutdown VMs from within the guest OS.  Especially 
> when they all come from (non-cloudstack) VMware and Hyper-V environments 
> where this is not an issue.
> However, if a host fails, we need VM HA to still work.
> This Issue is being tied to a new PR that creates a configuration option 
> "ha.vm.restart.hostup".  With this option set to false, if CloudStack sees a 
> VM shutdown out-of-band, +*but the host it was on is still* *onlin*e+, then 
> it won't power it back on.  The logic is that since the host is online, it 
> was most likely shutdown from the guest OS.
> For when a host actually fails, standard VM HA logic takes over and powers on 
> VMs (with VM HA enabled) if the host they were on fails.
> If that "ha.vm.restart.hostup" option is true (the default to match current 
> functionality), it works like always, and even in-guest shutdowns of VMs 
> causes CloudStack to power back on the VM.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10309) VMs with HA enabled, power back on if shutdown from guest OS

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460643#comment-16460643
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10309:
-

Slair1 opened a new pull request #2473: CLOUDSTACK-10309 Add option on if to VM 
HA power-on a OOB-shut-off-VM
URL: https://github.com/apache/cloudstack/pull/2473
 
 
   When a user shuts down their VM from the guest OS (and VM HA is enabled), 
the VM just powers itself back on.  Our environment is on KVM hosts.
   
   CloudStack does not know the difference between a VM failing or being 
shutdown from within the guest OS.
   
   This is a major pain point for all our users - especially since they don't 
pay for VMs when they are shutoff.  It is not intuitive for end-users to 
understand why they can't shutdown VMs from within the guest OS.  Especially 
when they all come from (non-cloudstack) VMware and Hyper-V environments where 
this is not an issue.
   
   However, if a host fails, we need VM HA to still work.
   
   This PR that creates a configuration option "ha.vm.restart.hostup".  With 
this option set to false, if CloudStack sees a VM shutdown out-of-band, but the 
host it was on is still *online*, then it won't power the VM back on.  The 
logic is that since the host is online, it was most likely shutdown from the 
guest OS.
   
   For when a host actually fails, standard VM HA logic takes over and powers 
on VMs (if they have VM HA enabled) if the host they were on fails.
   
   If that "ha.vm.restart.hostup" option is true (the default to match current 
functionality), it works like always, and even in-guest shutdowns of VMs causes 
CloudStack to power back on the VM.
   



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


> VMs with HA enabled, power back on if shutdown from guest OS
> 
>
> Key: CLOUDSTACK-10309
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10309
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.9.0, 4.10.0.0
> Environment: KVM
>Reporter: Sean Lair
>Priority: Minor
>
> When a user shuts down their VM from the guest OS (and VM HA is enabled), the 
> VM just powers itself back on.  Our environment is on KVM hosts.
> CloudStack does not know the difference between a VM failing or being 
> shutdown from within the guest OS.
> This is a major pain point for all our users - especially since they don't 
> pay for VMs when they are shutoff.  It is not intuitive for end-users to 
> understand why they can't shutdown VMs from within the guest OS.  Especially 
> when they all come from (non-cloudstack) VMware and Hyper-V environments 
> where this is not an issue.
> However, if a host fails, we need VM HA to still work.
> This Issue is being tied to a new PR that creates a configuration option 
> "ha.vm.restart.hostup".  With this option set to false, if CloudStack sees a 
> VM shutdown out-of-band, +*but the host it was on is still* *onlin*e+, then 
> it won't power it back on.  The logic is that since the host is online, it 
> was most likely shutdown from the guest OS.
> For when a host actually fails, standard VM HA logic takes over and powers on 
> VMs (with VM HA enabled) if the host they were on fails.
> If that "ha.vm.restart.hostup" option is true (the default to match current 
> functionality), it works like always, and even in-guest shutdowns of VMs 
> causes CloudStack to power back on the VM.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10309) VMs with HA enabled, power back on if shutdown from guest OS

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460645#comment-16460645
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10309:
-

rhtyd commented on issue #2473: CLOUDSTACK-10309 Add option on if to VM HA 
power-on a OOB-shut-off-VM
URL: https://github.com/apache/cloudstack/pull/2473#issuecomment-385892299
 
 
   FYI - I've changed PR's base branch to validate change from Travis, and 
trillian. Once this is tested and is okay we can move it back to 4.9 branch.
   @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


> VMs with HA enabled, power back on if shutdown from guest OS
> 
>
> Key: CLOUDSTACK-10309
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10309
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.9.0, 4.10.0.0
> Environment: KVM
>Reporter: Sean Lair
>Priority: Minor
>
> When a user shuts down their VM from the guest OS (and VM HA is enabled), the 
> VM just powers itself back on.  Our environment is on KVM hosts.
> CloudStack does not know the difference between a VM failing or being 
> shutdown from within the guest OS.
> This is a major pain point for all our users - especially since they don't 
> pay for VMs when they are shutoff.  It is not intuitive for end-users to 
> understand why they can't shutdown VMs from within the guest OS.  Especially 
> when they all come from (non-cloudstack) VMware and Hyper-V environments 
> where this is not an issue.
> However, if a host fails, we need VM HA to still work.
> This Issue is being tied to a new PR that creates a configuration option 
> "ha.vm.restart.hostup".  With this option set to false, if CloudStack sees a 
> VM shutdown out-of-band, +*but the host it was on is still* *onlin*e+, then 
> it won't power it back on.  The logic is that since the host is online, it 
> was most likely shutdown from the guest OS.
> For when a host actually fails, standard VM HA logic takes over and powers on 
> VMs (with VM HA enabled) if the host they were on fails.
> If that "ha.vm.restart.hostup" option is true (the default to match current 
> functionality), it works like always, and even in-guest shutdowns of VMs 
> causes CloudStack to power back on the VM.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10309) VMs with HA enabled, power back on if shutdown from guest OS

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10309?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460640#comment-16460640
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10309:
-

rhtyd commented on issue #2473: CLOUDSTACK-10309 Add option on if to VM HA 
power-on a OOB-shut-off-VM
URL: https://github.com/apache/cloudstack/pull/2473#issuecomment-385892046
 
 
   LGTM, @DaanHoogland @rafaelweingartner are we okay on the changes and to 
accept without any 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


> VMs with HA enabled, power back on if shutdown from guest OS
> 
>
> Key: CLOUDSTACK-10309
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10309
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: Management Server
>Affects Versions: 4.9.0, 4.10.0.0
> Environment: KVM
>Reporter: Sean Lair
>Priority: Minor
>
> When a user shuts down their VM from the guest OS (and VM HA is enabled), the 
> VM just powers itself back on.  Our environment is on KVM hosts.
> CloudStack does not know the difference between a VM failing or being 
> shutdown from within the guest OS.
> This is a major pain point for all our users - especially since they don't 
> pay for VMs when they are shutoff.  It is not intuitive for end-users to 
> understand why they can't shutdown VMs from within the guest OS.  Especially 
> when they all come from (non-cloudstack) VMware and Hyper-V environments 
> where this is not an issue.
> However, if a host fails, we need VM HA to still work.
> This Issue is being tied to a new PR that creates a configuration option 
> "ha.vm.restart.hostup".  With this option set to false, if CloudStack sees a 
> VM shutdown out-of-band, +*but the host it was on is still* *onlin*e+, then 
> it won't power it back on.  The logic is that since the host is online, it 
> was most likely shutdown from the guest OS.
> For when a host actually fails, standard VM HA logic takes over and powers on 
> VMs (with VM HA enabled) if the host they were on fails.
> If that "ha.vm.restart.hostup" option is true (the default to match current 
> functionality), it works like always, and even in-guest shutdowns of VMs 
> causes CloudStack to power back on the VM.
>  



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10223) Snapshots are not getting deleted when domain is deleted

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10223?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460639#comment-16460639
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10223:
-

DaanHoogland commented on issue #2399: CLOUDSTACK-10223 delete snapshots when 
deleting domain
URL: https://github.com/apache/cloudstack/pull/2399#issuecomment-385891967
 
 
   I don't see any error there that is related to domain or snapshot. 
@borisstoyanov @rhtyd agree?


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


> Snapshots are not getting deleted when domain is deleted
> 
>
> Key: CLOUDSTACK-10223
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10223
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Sowjanya_Patha
>Priority: Minor
>
> After domain deletion, snapshot taken by the domain remains undeleted.
> Steps to reproduce:
> ---
> 1. Create a test domain
> 2. Create test account with admin privileges.
> 3. Login as "test" acoount.
> 4. Create 3 instances - few having root disk and rest with root and data 
> disks both.
> 5. For 2 instances take snapshots of root and data disks
> 6. Expunge above instances from ACP UI.
> 7. Make sure that those vm's should not be shown in ACP UI.
> 8. Login as root user again
> 9. Delete the test account
> 10. Delete the test domain
> Snapshots taken for root volume in step 5 are not deleted.



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10365) Inconsistent boolean-related method names

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10365?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460633#comment-16460633
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10365:
-

DaanHoogland commented on a change in pull request #2602: CLOUDSTACK-10365: 
Change the "getXXX" boolean-related method names to…
URL: https://github.com/apache/cloudstack/pull/2602#discussion_r185414457
 
 

 ##
 File path: api/src/main/java/com/cloud/offering/ServiceOffering.java
 ##
 @@ -86,7 +86,7 @@
 /**
  * @return Does this service plan support Volatile VM that is, discard 
VM's root disk and create a new one on reboot?
  */
-boolean getVolatileVm();
+boolean isVolatileVm();
 
 Review comment:
   @BruceKuiLiu I am with 2 all the way, with the exception of the use of these 
methods in code generation tools. In this last method I would expect a name 
like isForVolatileVms() or the ealier sugested name. Of cause the accessor is 
named after the field implying that the field is not properly named either.
   I am +0 on this one. Try to find more reviews.


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


> Inconsistent boolean-related method names
> -
>
> Key: CLOUDSTACK-10365
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10365
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: KuiLIU
>Priority: Major
>
> These boolean-return methods are named as "getXXX".
> Other boolean-return methods are named as "isXXX".
> Considering there methods will return boolean values, it should be more clear 
> to rename them as "isXXX".
> {code:java}
>  public boolean getEnableRRS() {
>  return enableRRS;
>  }
> public boolean getEnableRRS() {
>  return enableRRS;
>  }
>  public boolean getShrinkOk() {
>  return shrinkOk;
>  }
>  
>  public boolean getSourceNat() {
>  return sourceNat;
>  }
>  
>  public boolean getInternalLb() {
>  return internalLb;
>  }
>  
>  public boolean getOfferHA() {
>  return offerHA;
>  }
>  
>   public boolean getVolatileVm() {
>  return volatileVm;
>  }
>  
>  public boolean getIsUserDefined() {
>  return isUserDefined;
>  }
>  
>   public boolean getEnablePassword() {
>  return enablePassword;
>  }
>  
>  public boolean getEnableSshKey() {
>  return enableSshKey;
>  }
>  
>  public boolean getUuidTranslation() {
>  return _doUuidTranslation;
>  }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10304) SystemVM - Apache Web Server Version Number Information Disclosure

[Julian Gilbert (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10304?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460632#comment-16460632
 ] 

Julian Gilbert commented on CLOUDSTACK-10304:
-

I'm happy for this to be closed.

> SystemVM - Apache Web Server Version Number Information Disclosure
> --
>
> Key: CLOUDSTACK-10304
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10304
> Project: CloudStack
>  Issue Type: Bug
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>  Components: SystemVM
>Affects Versions: 4.11.0.0
>Reporter: Julian Gilbert
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.12.0.0, 4.11.1.0
>
>
> {color:#00}The Secondary Storage System VM discloses its Apache Web 
> Server version number in HTTP headers and error pages. This type of 
> information disclosure can lead to medium vulnerabilities being reported in 
> web vulnerability scanners and reveals the Apache server version 
> unnecessarily.{color}
> {color:#00}The apache2 directory structure no longer contains 
> /etc/apache2/conf.d/ in Debian 9 and therefore the appropriate apache2 
> security configuration file is in another location. The 
> /opt/cloud/bin/setup/common.sh script has not been updated to reflect 
> this.{color}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-9852) Storage Load Balancer

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460631#comment-16460631
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9852:


rhtyd commented on issue #2067: CLOUDSTACK-9852: This patch implements the 
storage lb feature
URL: https://github.com/apache/cloudstack/pull/2067#issuecomment-385891127
 
 
   @DaanHoogland just so you know, the comment was more of an FYI for (new) 
guys if we find this feature interesting


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


> Storage Load Balancer
> -
>
> Key: CLOUDSTACK-9852
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9852
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Anshul Gangwar
>Assignee: Anshul Gangwar
>Priority: Major
>
> Currently CloudStack does not support any type of storage load balancing. It 
> always lists the primary storage and secondary storage in same order and the 
> pick the first one which satisfies the criteria. If user wants to load 
> balance then there is no way for user to tell volume to go to different 
> primary storage or secondary storage. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10362) Inconsistent method names

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460627#comment-16460627
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10362:
-

blueorangutan commented on issue #2600: CLOUDSTACK-10362: Change the "getXXX" 
method names to "isXXX".
URL: https://github.com/apache/cloudstack/pull/2600#issuecomment-385889655
 
 
   @DaanHoogland 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


> Inconsistent method names
> -
>
> Key: CLOUDSTACK-10362
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10362
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: KuiLIU
>Priority: Major
>
> Some Boolean-return methods are named "getXXX",
> but other Boolean-return methods are named "isXXX", such as the following two 
> methods.
> They will return boolean values, rename them as "isXXX" should be more clear 
> than "getXXX".
> api/src/main/java/org/apache/cloudstack/api/command/admin/vlan/ListVlanIpRangesCmd.java
> {code:java}
>  public Boolean getForVirtualNetwork() {
>  return forVirtualNetwork;
>  }
> {code}
> api/src/main/java/org/apache/cloudstack/api/command/user/address/ListPublicIpAddressesCmd.java
> {code:java}
> public Boolean isForVirtualNetwork() {
> return forVirtualNetwork;
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-10362) Inconsistent method names

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-10362?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460626#comment-16460626
 ] 

ASF GitHub Bot commented on CLOUDSTACK-10362:
-

DaanHoogland commented on issue #2600: CLOUDSTACK-10362: Change the "getXXX" 
method names to "isXXX".
URL: https://github.com/apache/cloudstack/pull/2600#issuecomment-385889579
 
 
   @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


> Inconsistent method names
> -
>
> Key: CLOUDSTACK-10362
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10362
> Project: CloudStack
>  Issue Type: Improvement
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: KuiLIU
>Priority: Major
>
> Some Boolean-return methods are named "getXXX",
> but other Boolean-return methods are named "isXXX", such as the following two 
> methods.
> They will return boolean values, rename them as "isXXX" should be more clear 
> than "getXXX".
> api/src/main/java/org/apache/cloudstack/api/command/admin/vlan/ListVlanIpRangesCmd.java
> {code:java}
>  public Boolean getForVirtualNetwork() {
>  return forVirtualNetwork;
>  }
> {code}
> api/src/main/java/org/apache/cloudstack/api/command/user/address/ListPublicIpAddressesCmd.java
> {code:java}
> public Boolean isForVirtualNetwork() {
> return forVirtualNetwork;
> }
> {code}



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)

[jira] [Commented] (CLOUDSTACK-9852) Storage Load Balancer

[ASF GitHub Bot (JIRA)]

[ 
https://issues.apache.org/jira/browse/CLOUDSTACK-9852?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=16460620#comment-16460620
 ] 

ASF GitHub Bot commented on CLOUDSTACK-9852:


DaanHoogland commented on issue #2067: CLOUDSTACK-9852: This patch implements 
the storage lb feature
URL: https://github.com/apache/cloudstack/pull/2067#issuecomment-385887582
 
 
   ConfigDrive has precendence @rhtyd , but i can look once i got that sorted


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


> Storage Load Balancer
> -
>
> Key: CLOUDSTACK-9852
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9852
> Project: CloudStack
>  Issue Type: New Feature
>  Security Level: Public(Anyone can view this level - this is the 
> default.) 
>Reporter: Anshul Gangwar
>Assignee: Anshul Gangwar
>Priority: Major
>
> Currently CloudStack does not support any type of storage load balancing. It 
> always lists the primary storage and secondary storage in same order and the 
> pick the first one which satisfies the criteria. If user wants to load 
> balance then there is no way for user to tell volume to go to different 
> primary storage or secondary storage. 



--
This message was sent by Atlassian JIRA
(v7.6.3#76005)