[jira] [Commented] (CLOUDSTACK-9849) Cannot migrate VMware VM to host in different cluster
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15965483#comment-15965483 ] Mike Tutkowski commented on CLOUDSTACK-9849: Hi [~rajanik] I'm still out of the country and unable to set up a 4.9 environment (my current lab is needed for other versions at the moment). However, Sateesh has assigned the ticket to himself and is working it. Thanks! Mike > Cannot migrate VMware VM to host in different cluster > - > > Key: CLOUDSTACK-9849 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9849 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Affects Versions: 4.10.0.0 > Environment: VMware 5.5 >Reporter: Mike Tutkowski >Assignee: Sateesh Chodapuneedi >Priority: Blocker > Fix For: 4.10.0.0 > > > I have two VMware clusters in the same VMware datacenter. Each cluster has a > single ESXi 5.5 host in it. > I have a shared primary storage in each cluster (I have tried this scenario > with both NFS and iSCSI shared primary storage and the results are the same). > I have a VM with its root disk running on primary storage from a host in the > one cluster and I cannot migrate this VM and its root disk to the host in the > other cluster (both primary storages even make use of the same storage tag). > The source host has access to the source datastore, but it does not have > access to the target datastore. > The target host has access to the target datastore, but it does not have > access to the source datastore. > When I try to perform the migration, it fails with the following error > message: > Required property datastore is missing from data object of type > VirtualMachineRelocateSpecDiskLocator > while parsing serialized DataObject of type vim.vm.RelocateSpec.DiskLocator > at line 1, column 327 > while parsing property "disk" of static type > ArrayOfVirtualMachineRelocateSpecDiskLocator > while parsing serialized DataObject of type vim.vm.RelocateSpec > at line 1, column 187 > while parsing call information for method RelocateVM_Task > at line 1, column 110 > while parsing SOAP body > at line 1, column 102 > while parsing SOAP envelope > at line 1, column 38 > while parsing HTTP request for method relocate > on object of type vim.VirtualMachine > at line 1, column 0 > When I run the test in the debugger and look at the > VirtualMachineRelocateSpec instance passed to > VirtualMachineMO.changeDatastore, I see the target datastore is populated, > but not the source datastore: > http://imgur.com/a/vtKcq datastore-66 is the target datastore > Based on an e-mail chain on dev@, it sounds like my scenario should work. > Thanks! -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9849) Cannot migrate VMware VM to host in different cluster
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9849?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15965485#comment-15965485 ] Mike Tutkowski commented on CLOUDSTACK-9849: [~rajanik] Sorry - I thought your question was being asked to me. :) I see you had directed it to Sateesh. > Cannot migrate VMware VM to host in different cluster > - > > Key: CLOUDSTACK-9849 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9849 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Affects Versions: 4.10.0.0 > Environment: VMware 5.5 >Reporter: Mike Tutkowski >Assignee: Sateesh Chodapuneedi >Priority: Blocker > Fix For: 4.10.0.0 > > > I have two VMware clusters in the same VMware datacenter. Each cluster has a > single ESXi 5.5 host in it. > I have a shared primary storage in each cluster (I have tried this scenario > with both NFS and iSCSI shared primary storage and the results are the same). > I have a VM with its root disk running on primary storage from a host in the > one cluster and I cannot migrate this VM and its root disk to the host in the > other cluster (both primary storages even make use of the same storage tag). > The source host has access to the source datastore, but it does not have > access to the target datastore. > The target host has access to the target datastore, but it does not have > access to the source datastore. > When I try to perform the migration, it fails with the following error > message: > Required property datastore is missing from data object of type > VirtualMachineRelocateSpecDiskLocator > while parsing serialized DataObject of type vim.vm.RelocateSpec.DiskLocator > at line 1, column 327 > while parsing property "disk" of static type > ArrayOfVirtualMachineRelocateSpecDiskLocator > while parsing serialized DataObject of type vim.vm.RelocateSpec > at line 1, column 187 > while parsing call information for method RelocateVM_Task > at line 1, column 110 > while parsing SOAP body > at line 1, column 102 > while parsing SOAP envelope > at line 1, column 38 > while parsing HTTP request for method relocate > on object of type vim.VirtualMachine > at line 1, column 0 > When I run the test in the debugger and look at the > VirtualMachineRelocateSpec instance passed to > VirtualMachineMO.changeDatastore, I see the target datastore is populated, > but not the source datastore: > http://imgur.com/a/vtKcq datastore-66 is the target datastore > Based on an e-mail chain on dev@, it sounds like my scenario should work. > Thanks! -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9099) SecretKey is returned from the APIs
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15965488#comment-15965488
]
ASF GitHub Bot commented on CLOUDSTACK-9099:
Github user koushik-das commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1996#discussion_r111075302
--- Diff:
api/src/org/apache/cloudstack/api/command/admin/user/GetUserKeysCmd.java ---
@@ -0,0 +1,76 @@
+// Licensed to the Apache Software Foundation (ASF) under one
+// or more contributor license agreements. See the NOTICE file
+// distributed with this work for additional information
+// regarding copyright ownership. The ASF licenses this file
+// to you under the Apache License, Version 2.0 (the
+// "License"); you may not use this file except in compliance
+// with the License. You may obtain a copy of the License at
+//
+// http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing,
+// software distributed under the License is distributed on an
+// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+// KIND, either express or implied. See the License for the
+// specific language governing permissions and limitations
+// under the License.
+
+package org.apache.cloudstack.api.command.admin.user;
+
+
+import com.cloud.user.Account;
+import com.cloud.user.User;
+import org.apache.cloudstack.acl.RoleType;
+import org.apache.cloudstack.api.APICommand;
+import org.apache.cloudstack.api.ApiConstants;
+import org.apache.cloudstack.api.BaseCmd;
+import org.apache.cloudstack.api.Parameter;
+import org.apache.cloudstack.api.response.RegisterResponse;
+import org.apache.cloudstack.api.response.UserResponse;
+
+import java.util.List;
+import java.util.logging.Logger;
+
+@APICommand(name = "getUserKeys",
+description = "This command allows the user to query the
seceret and API keys for the account",
+responseObject = RegisterResponse.class,
+requestHasSensitiveInfo = false,
+responseHasSensitiveInfo = true,
+authorized = {RoleType.User})
+
+public class GetUserKeysCmd extends BaseCmd{
+
+@Parameter(name= ApiConstants.ID, type = CommandType.UUID, entityType
= UserResponse.class, required = true, description = "ID of the user whose keys
are required")
+private Long id;
+
+public static final Logger s_logger =
Logger.getLogger(RegisterCmd.class.getName());
+public static final String s_name = "getuserkeysresponse";
+
+public Long getID(){
+return id;
+}
+
+public String getCommandName(){
+return s_name;
+}
+
+public long getEntityOwnerId(){
+User user = _entityMgr.findById(User.class, getID());
+if(user != null){
+return user.getAccountId();
+}
+else return Account.ACCOUNT_ID_SYSTEM;
+}
+public void execute(){
+List keys = _accountService.getKeys(this);
+RegisterResponse response = new RegisterResponse();
+if(keys != null){
+response.setApiKey(keys.get(0));
+response.setSecretKey(keys.get(1));
+}
+
+response.setObjectName("listkeys");
--- End diff --
Should this be 'userKeys'?
> SecretKey is returned from the APIs
> ---
>
> Key: CLOUDSTACK-9099
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9099
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.9.0
>Reporter: Kshitij Kansal
>Assignee: Kshitij Kansal
> Fix For: 4.10.0.0, 4.9.3.0
>
>
> The sercreKey parameter is returned from the following APIs:
> createAccount
> createUser
> disableAccount
> disableUser
> enableAccount
> enableUser
> listAccounts
> listUsers
> lockAccount
> lockUser
> registerUserKeys
> updateAccount
> updateUser
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9099) SecretKey is returned from the APIs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15965486#comment-15965486 ] ASF GitHub Bot commented on CLOUDSTACK-9099: Github user koushik-das commented on a diff in the pull request: https://github.com/apache/cloudstack/pull/1996#discussion_r111078382 --- Diff: server/src/com/cloud/api/ApiDBUtils.java --- @@ -559,6 +561,8 @@ @Inject private VpcManager vpcMgr; @Inject +private AccountManager accountManager; --- End diff -- Why there is a need to inject AccountManager? If the config key is a static it can be accessed as AccountManager. > SecretKey is returned from the APIs > --- > > Key: CLOUDSTACK-9099 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9099 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.9.0 >Reporter: Kshitij Kansal >Assignee: Kshitij Kansal > Fix For: 4.10.0.0, 4.9.3.0 > > > The sercreKey parameter is returned from the following APIs: > createAccount > createUser > disableAccount > disableUser > enableAccount > enableUser > listAccounts > listUsers > lockAccount > lockUser > registerUserKeys > updateAccount > updateUser -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9099) SecretKey is returned from the APIs
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15965487#comment-15965487
]
ASF GitHub Bot commented on CLOUDSTACK-9099:
Github user koushik-das commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1996#discussion_r111075076
--- Diff:
api/src/org/apache/cloudstack/api/command/admin/user/GetUserKeysCmd.java ---
@@ -0,0 +1,76 @@
+// Licensed to the Apache Software Foundation (ASF) under one
+// or more contributor license agreements. See the NOTICE file
+// distributed with this work for additional information
+// regarding copyright ownership. The ASF licenses this file
+// to you under the Apache License, Version 2.0 (the
+// "License"); you may not use this file except in compliance
+// with the License. You may obtain a copy of the License at
+//
+// http://www.apache.org/licenses/LICENSE-2.0
+//
+// Unless required by applicable law or agreed to in writing,
+// software distributed under the License is distributed on an
+// "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY
+// KIND, either express or implied. See the License for the
+// specific language governing permissions and limitations
+// under the License.
+
+package org.apache.cloudstack.api.command.admin.user;
+
+
+import com.cloud.user.Account;
+import com.cloud.user.User;
+import org.apache.cloudstack.acl.RoleType;
+import org.apache.cloudstack.api.APICommand;
+import org.apache.cloudstack.api.ApiConstants;
+import org.apache.cloudstack.api.BaseCmd;
+import org.apache.cloudstack.api.Parameter;
+import org.apache.cloudstack.api.response.RegisterResponse;
+import org.apache.cloudstack.api.response.UserResponse;
+
+import java.util.List;
+import java.util.logging.Logger;
+
+@APICommand(name = "getUserKeys",
+description = "This command allows the user to query the
seceret and API keys for the account",
+responseObject = RegisterResponse.class,
+requestHasSensitiveInfo = false,
+responseHasSensitiveInfo = true,
+authorized = {RoleType.User})
--- End diff --
Can you add the 'since' parameter?
> SecretKey is returned from the APIs
> ---
>
> Key: CLOUDSTACK-9099
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9099
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Affects Versions: 4.9.0
>Reporter: Kshitij Kansal
>Assignee: Kshitij Kansal
> Fix For: 4.10.0.0, 4.9.3.0
>
>
> The sercreKey parameter is returned from the following APIs:
> createAccount
> createUser
> disableAccount
> disableUser
> enableAccount
> enableUser
> listAccounts
> listUsers
> lockAccount
> lockUser
> registerUserKeys
> updateAccount
> updateUser
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Created] (CLOUDSTACK-9871) MySQL 5.7 compatibility
Wido den Hollander created CLOUDSTACK-9871: -- Summary: MySQL 5.7 compatibility Key: CLOUDSTACK-9871 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9871 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.10.0.0 Environment: Ubuntu 16.04, MySQL 5.7 Reporter: Wido den Hollander Priority: Minor MySQL 5.7 comes with a more strict SQL mode by default which causes problems for CloudStack as the queries it executes are not all compatible with MySQL 5.7. https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html A work-around is setting the sql_mode to a more relaxed mode in the my.cnf: [mysqld] sql_mode='STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION' In the future CloudStack should be fully compatible with the new SQL mode. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9871) MySQL 5.7 compatibility
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15965519#comment-15965519 ] ASF GitHub Bot commented on CLOUDSTACK-9871: GitHub user wido opened a pull request: https://github.com/apache/cloudstack/pull/2037 CLOUDSTACK-9871: Set SQL Mode in SQL Session for MySQL 5.7 compatibility MySQL 5.7 has a more strict SQL mode by default with which CloudStack is not compatible. By setting the SQL Mode to a more relaxed mode on run-time we can run without changing any SQL server settings. Admins could also apply this to the [mysqld] section of their my.cnf: sql_mode = 'STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION' Signed-off-by: Wido den Hollander You can merge this pull request into a Git repository by running: $ git pull https://github.com/wido/cloudstack sql_mode Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/2037.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2037 commit d3f307b1b06da095db7f4410b9e7505182b726af Author: Wido den Hollander Date: 2017-04-12T07:48:16Z CLOUDSTACK-9871: Set SQL Mode in SQL Session for MySQL 5.7 compatibility MySQL 5.7 has a more strict SQL mode by default with which CloudStack is not compatible. By setting the SQL Mode to a more relaxed mode on run-time we can run without changing any SQL server settings. Admins could also apply this to the [mysqld] section of their my.cnf: sql_mode = 'STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION' Signed-off-by: Wido den Hollander > MySQL 5.7 compatibility > --- > > Key: CLOUDSTACK-9871 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9871 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.10.0.0 > Environment: Ubuntu 16.04, MySQL 5.7 >Reporter: Wido den Hollander >Priority: Minor > Labels: jdbc, mysql > > MySQL 5.7 comes with a more strict SQL mode by default which causes problems > for CloudStack as the queries it executes are not all compatible with MySQL > 5.7. > https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html > A work-around is setting the sql_mode to a more relaxed mode in the my.cnf: > [mysqld] > sql_mode='STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION' > In the future CloudStack should be fully compatible with the new SQL mode. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9867) VM snapshots - not charged for the primary storage they use up
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15965604#comment-15965604 ] ASF GitHub Bot commented on CLOUDSTACK-9867: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/2035 @abhinandanprateek a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. > VM snapshots - not charged for the primary storage they use up > -- > > Key: CLOUDSTACK-9867 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9867 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek > Fix For: Future > > > Currently, when a user takes a VM snapshot, the snapshot is kept on primary > storage. CloudStack has no mechanism to record the additional storage used by > these snapshots. > To add an additional usage metric that is “primary storage used by > snapshots”. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9867) VM snapshots - not charged for the primary storage they use up
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15965602#comment-15965602 ] ASF GitHub Bot commented on CLOUDSTACK-9867: Github user abhinandanprateek commented on the issue: https://github.com/apache/cloudstack/pull/2035 @blueorangutan package > VM snapshots - not charged for the primary storage they use up > -- > > Key: CLOUDSTACK-9867 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9867 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek > Fix For: Future > > > Currently, when a user takes a VM snapshot, the snapshot is kept on primary > storage. CloudStack has no mechanism to record the additional storage used by > these snapshots. > To add an additional usage metric that is “primary storage used by > snapshots”. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9867) VM snapshots - not charged for the primary storage they use up
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9867?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15965627#comment-15965627 ] ASF GitHub Bot commented on CLOUDSTACK-9867: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/2035 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-633 > VM snapshots - not charged for the primary storage they use up > -- > > Key: CLOUDSTACK-9867 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9867 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.10.0.0 >Reporter: Abhinandan Prateek >Assignee: Abhinandan Prateek > Fix For: Future > > > Currently, when a user takes a VM snapshot, the snapshot is kept on primary > storage. CloudStack has no mechanism to record the additional storage used by > these snapshots. > To add an additional usage metric that is “primary storage used by > snapshots”. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9462) Systemd packaging for Ubuntu 16.04
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15965755#comment-15965755 ] ASF GitHub Bot commented on CLOUDSTACK-9462: GitHub user rhtyd reopened a pull request: https://github.com/apache/cloudstack/pull/2033 [master/4.10+] CLOUDSTACK-9462: Support for Ubuntu 14.04/16.04 with tomcat6/tomcat7 This extends work from @ustcweizhou from https://github.com/apache/cloudstack/pull/1950 by fixing some build issues to make this work with Ubuntu 14.04 and 16.04. This closes #1950 You can merge this pull request into a Git repository by running: $ git pull https://github.com/shapeblue/cloudstack ubuntu1604-fixsystemd-weiz Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/2033.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2033 commit 4a77a799490a0cd655b1a53377c4db1bb51ddc7c Author: Wei Zhou Date: 2017-02-17T08:59:52Z CLOUDSTACK-9462: Build packages on Ubuntu 14.04/16.04 and support tomcat6/tomcat7 Changes (1) add systemd support in debian/control and debian/rules for 16.04 (2) add python-setuptools in Build-Depends in debian/control (3) seperate cloudstack-management.service and cloudstack-management.default for CentOS7 and Ubuntu 16.04 (4) add server7-ssl.xml and server7-nonssl.xml in management installation (5) link /usr/share/cloudstack-management/lib and /usr/share/cloudstack-management/bin to correct path (tomcat6 or tomcat7) (6) link /etc/cloudstack/management/server.xml to correct file path (server-nonssl.xml or server7-nonssl.xml) (7) remove *.zip from .gitignore to avoid build error caused by missing /vhds/test.vhd.zip Instruction (1) build packages on Ubuntu 16.04: dpkg-buildpackage -uc -us Output on Ubuntu 16.04: -rw-r--r-- 1 root root 4090 Feb 17 10:12 cloudstack_4.10.0.0-SNAPSHOT_amd64.changes -rw-r--r-- 1 root root 1235 Feb 17 09:53 cloudstack_4.10.0.0-SNAPSHOT.dsc -rw-r--r-- 1 root root 8018248 Feb 17 09:53 cloudstack_4.10.0.0-SNAPSHOT.tar.xz -rw-r--r-- 1 root root 91868746 Feb 17 10:11 cloudstack-agent_4.10.0.0-SNAPSHOT_all.deb -rw-r--r-- 1 root root 52882 Feb 17 10:12 cloudstack-cli_4.10.0.0-SNAPSHOT_all.deb -rw-r--r-- 1 root root 98556216 Feb 17 10:08 cloudstack-common_4.10.0.0-SNAPSHOT_all.deb -rw-r--r-- 1 root root 52864 Feb 17 10:12 cloudstack-docs_4.10.0.0-SNAPSHOT_all.deb -rw-r--r-- 1 root root585434 Feb 17 10:12 cloudstack-integration-tests_4.10.0.0-SNAPSHOT_all.deb -rw-r--r-- 1 root root 323459934 Feb 17 10:10 cloudstack-management_4.10.0.0-SNAPSHOT_all.deb -rw-r--r-- 1 root root442656 Feb 17 10:12 cloudstack-marvin_4.10.0.0-SNAPSHOT_all.deb -rw-r--r-- 1 root root 87037576 Feb 17 10:12 cloudstack-usage_4.10.0.0-SNAPSHOT_all.deb (2) setup tomcat6/tomcat7 on management server: tomcat6: cloudstack-setup-management --tomcat6 tomcat7: cloudstack-setup-management --tomcat7 Signed-off-by: Rohit Yadav > Systemd packaging for Ubuntu 16.04 > -- > > Key: CLOUDSTACK-9462 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9462 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.10.0.0, 4.9.1.0 > > > Support for building deb packages that will work on Ubuntu 16.04 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9462) Systemd packaging for Ubuntu 16.04
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15965753#comment-15965753 ] ASF GitHub Bot commented on CLOUDSTACK-9462: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/2033 @karuturi done, thanks. > Systemd packaging for Ubuntu 16.04 > -- > > Key: CLOUDSTACK-9462 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9462 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.10.0.0, 4.9.1.0 > > > Support for building deb packages that will work on Ubuntu 16.04 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9462) Systemd packaging for Ubuntu 16.04
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15965754#comment-15965754 ] ASF GitHub Bot commented on CLOUDSTACK-9462: Github user rhtyd closed the pull request at: https://github.com/apache/cloudstack/pull/2033 > Systemd packaging for Ubuntu 16.04 > -- > > Key: CLOUDSTACK-9462 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9462 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.10.0.0, 4.9.1.0 > > > Support for building deb packages that will work on Ubuntu 16.04 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9462) Systemd packaging for Ubuntu 16.04
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15965756#comment-15965756 ] ASF GitHub Bot commented on CLOUDSTACK-9462: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/2033 @ustcweizhou thanks, yes there is a minor difference around the init-helper version that's all @karuturi jenkins/travis re-kicked. @blueorangutan package > Systemd packaging for Ubuntu 16.04 > -- > > Key: CLOUDSTACK-9462 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9462 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.10.0.0, 4.9.1.0 > > > Support for building deb packages that will work on Ubuntu 16.04 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9462) Systemd packaging for Ubuntu 16.04
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15965757#comment-15965757 ] ASF GitHub Bot commented on CLOUDSTACK-9462: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/2033 @rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. > Systemd packaging for Ubuntu 16.04 > -- > > Key: CLOUDSTACK-9462 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9462 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.10.0.0, 4.9.1.0 > > > Support for building deb packages that will work on Ubuntu 16.04 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9838) When 2 VMs have SNAT IPs assigned, they cannot communicate with each other via the SNAP IPs (normal VR)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9838?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15965758#comment-15965758 ] ASF GitHub Bot commented on CLOUDSTACK-9838: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/2034 Verified the mangle table firewall rules are now ACCEPT instead of RETURN. Pinging for review -- @wido @jayapalu @karuturi @abhinandanprateek @DaanHoogland /cc @PaulAngus > When 2 VMs have SNAT IPs assigned, they cannot communicate with each other > via the SNAP IPs (normal VR) > --- > > Key: CLOUDSTACK-9838 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9838 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.6.2, 4.7.1, 4.10.0.0, 4.9.2.0, 4.8.1.1 >Reporter: Paul Angus >Assignee: Rohit Yadav >Priority: Minor > > When 2 VMs have SNAT IPs (on different public subnets) assigned, they cannot > communicate with each other via the SNAP IPs. > Traffic flows over the SNAT IPs successfully to/from external networks/IPs > using iptables -t mangle -vL > from ACS 4.5 > established connections are ACCEPTed and are at the top of the order. RETURN > happens later. > Chain FIREWALL_10.1.35.23 (1 references) > pkts bytes target prot opt in out source > destination > 0 0 ACCEPT all -- anyany anywhere anywhere >state RELATED,ESTABLISHED > 0 0 RETURN icmp -- anyany anywhere anywhere >icmptype 8 code 0 > 0 0 RETURN tcp -- anyany anywhere anywhere >tcp dpt:http > 0 0 DROP all -- anyany anywhere anywhere > using ACS 4.9 > the ACCEPT of established connections is at the END after the RETURN and so > inspections don't get as far as the ACCEPT > Chain FIREWALL_10.1.64.9 (1 references) > pkts bytes target prot opt in out source > destination > 0 0 ACCEPT icmp -- anyany anywhere anywhere >icmptype 8 code 0 >39 3002 RETURN tcp -- anyany anywhere anywhere >tcp dpt:http > 4921 4906K ACCEPT all -- anyany anywhere anywhere >state RELATED,ESTABLISHED > 397 40700 DROP all -- anyany anywhere anywhere > moving > 4921 4906K ACCEPT all -- anyany anywhere anywhere >state RELATED,ESTABLISHED > to the top of this section resolves the issues and traffic can flow over the > SNAT IPs. > I believe that this only affects 'hairpin nat' traffic as it is in the mangle > table -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9805) Show VRs in a tab for a network in network detail view
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15965761#comment-15965761 ] ASF GitHub Bot commented on CLOUDSTACK-9805: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1980 @karuturi this is a simple UI change with screenshots attached, and has enough LGTM. Please merge this. > Show VRs in a tab for a network in network detail view > -- > > Key: CLOUDSTACK-9805 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9805 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9719) [VMware] VR loses DHCP settings and VMs cannot obtain IP after HA recovery
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9719?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15965771#comment-15965771 ] ASF GitHub Bot commented on CLOUDSTACK-9719: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/1879 @karuturi thanks I'll see how I can help. This PR though looks like a bug to me, though not a blocker. > [VMware] VR loses DHCP settings and VMs cannot obtain IP after HA recovery > -- > > Key: CLOUDSTACK-9719 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9719 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: VMware >Reporter: Suresh Kumar Anaparti >Assignee: Suresh Kumar Anaparti > Fix For: 4.10.0.0 > > > After HA being triggered on VMware, some VMs fail to acquire DHCP address > from a VR. These VMs are live migrated as part of vCenter HA to another > available host before the VR and couldn't acquire DHCP address as VR is not > migrated yet and these VMs request failed to reach the VR. > Resolving this requires manual intervention by the CloudStack administrator; > the router must be rebooted or the network restarted. This behavior is not > ideal and will prolong downtime caused by an HA event and there is no point > for the non-functional virtual router to even be running. CloudStack should > handle this situation by setting VR restart priority to high in the vCenter > when HA is enabled. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9871) MySQL 5.7 compatibility
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15965785#comment-15965785 ] ASF GitHub Bot commented on CLOUDSTACK-9871: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/2037 LGTM @wido can you change the base branch to 4.9, to get this in 4.9 branch as well? Thanks. > MySQL 5.7 compatibility > --- > > Key: CLOUDSTACK-9871 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9871 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.10.0.0 > Environment: Ubuntu 16.04, MySQL 5.7 >Reporter: Wido den Hollander >Priority: Minor > Labels: jdbc, mysql > > MySQL 5.7 comes with a more strict SQL mode by default which causes problems > for CloudStack as the queries it executes are not all compatible with MySQL > 5.7. > https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html > A work-around is setting the sql_mode to a more relaxed mode in the my.cnf: > [mysqld] > sql_mode='STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION' > In the future CloudStack should be fully compatible with the new SQL mode. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9462) Systemd packaging for Ubuntu 16.04
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15965793#comment-15965793 ] ASF GitHub Bot commented on CLOUDSTACK-9462: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/2033 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-634 > Systemd packaging for Ubuntu 16.04 > -- > > Key: CLOUDSTACK-9462 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9462 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.10.0.0, 4.9.1.0 > > > Support for building deb packages that will work on Ubuntu 16.04 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9099) SecretKey is returned from the APIs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9099?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15965800#comment-15965800 ] ASF GitHub Bot commented on CLOUDSTACK-9099: Github user jayapalu commented on the issue: https://github.com/apache/cloudstack/pull/1996 @koushik-das I have updated for your review comments. > SecretKey is returned from the APIs > --- > > Key: CLOUDSTACK-9099 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9099 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.9.0 >Reporter: Kshitij Kansal >Assignee: Kshitij Kansal > Fix For: 4.10.0.0, 4.9.3.0 > > > The sercreKey parameter is returned from the following APIs: > createAccount > createUser > disableAccount > disableUser > enableAccount > enableUser > listAccounts > listUsers > lockAccount > lockUser > registerUserKeys > updateAccount > updateUser -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (CLOUDSTACK-9872) Batch S2S VPN script doesn't return all responses
Sean Lair created CLOUDSTACK-9872:
-
Summary: Batch S2S VPN script doesn't return all responses
Key: CLOUDSTACK-9872
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9872
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Virtual Router
Affects Versions: 4.9.0.1, 4.8.1.1, 4.9.0, 4.8.0, 4.10.0.0
Environment: Any using Site-to-Site VPNs
Reporter: Sean Lair
Priority: Minor
The checkbatchs2svpn.sh VR script returns ("via echo") that status of each
requested S2S VPN check one-at-a-time. If there is even a slight delay between
VPN checks, the sshExecutor stops monitoring stdout and assumes it has all of
the output.
When checking the management server logs, we see a request to check X number of
VPNs, but the response is occasionally less than X number... The rest of the
Cloudstack code assumes "isConnected" as false if the VPN is not included in
the response.
We've noticed that if an account had more than 3 site-to-site VPNs, that there
are many errors per day stating that a S2S VPN is down.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9871) MySQL 5.7 compatibility
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15965807#comment-15965807 ] ASF GitHub Bot commented on CLOUDSTACK-9871: Github user wido commented on the issue: https://github.com/apache/cloudstack/pull/2037 Done @rhtyd, how does this look like? > MySQL 5.7 compatibility > --- > > Key: CLOUDSTACK-9871 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9871 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.10.0.0 > Environment: Ubuntu 16.04, MySQL 5.7 >Reporter: Wido den Hollander >Priority: Minor > Labels: jdbc, mysql > > MySQL 5.7 comes with a more strict SQL mode by default which causes problems > for CloudStack as the queries it executes are not all compatible with MySQL > 5.7. > https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html > A work-around is setting the sql_mode to a more relaxed mode in the my.cnf: > [mysqld] > sql_mode='STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION' > In the future CloudStack should be fully compatible with the new SQL mode. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (CLOUDSTACK-9873) VR related periodic jobs are scheduled twice and run twice on management servers
Sean Lair created CLOUDSTACK-9873: - Summary: VR related periodic jobs are scheduled twice and run twice on management servers Key: CLOUDSTACK-9873 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9873 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server, Virtual Router Affects Versions: 4.9.0, 4.8.0 Environment: Appears all environments Reporter: Sean Lair Priority: Minor Fix For: 4.10.0.0 The "start" method of VirtualNetworkApplianceManagerImpl schedules several period checks, including stats updates, alert updates, and VR checks including S2S vpn checks. VpcVirtualNetworkApplianceManagerImpl also extends VirtualNetworkApplianceManagerImpl. Thus when VpcVirtualNetworkApplianceManagerImpl is used, it re-runs the "start" method and once again schedules all the various jobs. Thus all the jobs run twice at each scheduled run. This is easily seen in the mangement-server.log: cat /var/log/cloudstack/management/management-server.log | grep "routers to update status" 2017-04-10 21:48:12,879 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] (RouterStatusMonitor-1:ctx-5f7bc584) (logid:4d5b1031) Found 10 routers to update status. 2017-04-10 21:48:12,932 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] (RouterStatusMonitor-1:ctx-d027ab6f) (logid:1bc50629) Found 10 routers to update status. 2017-04-10 21:48:42,877 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] (RouterStatusMonitor-1:ctx-2c8f4d18) (logid:e9111785) Found 10 routers to update status. 2017-04-10 21:48:42,927 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] (RouterStatusMonitor-1:ctx-1bfd5351) (logid:ad0f95ef) Found 10 routers to update status. 2017-04-10 21:49:12,874 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] (RouterStatusMonitor-1:ctx-ede0d2bb) (logid:6f244423) Found 10 routers to update status. 2017-04-10 21:49:12,928 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] (RouterStatusMonitor-1:ctx-d58842d5) (logid:8442d73c) Found 10 routers to update status. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Updated] (CLOUDSTACK-9872) Batch S2S VPN script doesn't return all responses
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Lair updated CLOUDSTACK-9872:
--
Environment: Any using Site-to-Site VPNs. Seems to be all versions of
Cloudstack (was: Any using Site-to-Site VPNs)
> Batch S2S VPN script doesn't return all responses
> -
>
> Key: CLOUDSTACK-9872
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9872
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.8.0, 4.9.0, 4.10.0.0, 4.8.1.1, 4.9.0.1
> Environment: Any using Site-to-Site VPNs. Seems to be all versions
> of Cloudstack
>Reporter: Sean Lair
>Priority: Minor
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The checkbatchs2svpn.sh VR script returns ("via echo") that status of each
> requested S2S VPN check one-at-a-time. If there is even a slight delay
> between VPN checks, the sshExecutor stops monitoring stdout and assumes it
> has all of the output.
> When checking the management server logs, we see a request to check X number
> of VPNs, but the response is occasionally less than X number... The rest of
> the Cloudstack code assumes "isConnected" as false if the VPN is not included
> in the response.
> We've noticed that if an account had more than 3 site-to-site VPNs, that
> there are many errors per day stating that a S2S VPN is down.
> This is exacerbated by Issue CLOUDSTACK-9873, because that issues causes the
> S2S VPN check (and many others) to run twice as often as intended.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Updated] (CLOUDSTACK-9872) Batch S2S VPN script doesn't return all responses
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9872?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Sean Lair updated CLOUDSTACK-9872:
--
Description:
The checkbatchs2svpn.sh VR script returns ("via echo") that status of each
requested S2S VPN check one-at-a-time. If there is even a slight delay between
VPN checks, the sshExecutor stops monitoring stdout and assumes it has all of
the output.
When checking the management server logs, we see a request to check X number of
VPNs, but the response is occasionally less than X number... The rest of the
Cloudstack code assumes "isConnected" as false if the VPN is not included in
the response.
We've noticed that if an account had more than 3 site-to-site VPNs, that there
are many errors per day stating that a S2S VPN is down.
This is exacerbated by Issue CLOUDSTACK-9873, because that issues causes the
S2S VPN check (and many others) to run twice as often as intended.
was:
The checkbatchs2svpn.sh VR script returns ("via echo") that status of each
requested S2S VPN check one-at-a-time. If there is even a slight delay between
VPN checks, the sshExecutor stops monitoring stdout and assumes it has all of
the output.
When checking the management server logs, we see a request to check X number of
VPNs, but the response is occasionally less than X number... The rest of the
Cloudstack code assumes "isConnected" as false if the VPN is not included in
the response.
We've noticed that if an account had more than 3 site-to-site VPNs, that there
are many errors per day stating that a S2S VPN is down.
> Batch S2S VPN script doesn't return all responses
> -
>
> Key: CLOUDSTACK-9872
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9872
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.8.0, 4.9.0, 4.10.0.0, 4.8.1.1, 4.9.0.1
> Environment: Any using Site-to-Site VPNs
>Reporter: Sean Lair
>Priority: Minor
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The checkbatchs2svpn.sh VR script returns ("via echo") that status of each
> requested S2S VPN check one-at-a-time. If there is even a slight delay
> between VPN checks, the sshExecutor stops monitoring stdout and assumes it
> has all of the output.
> When checking the management server logs, we see a request to check X number
> of VPNs, but the response is occasionally less than X number... The rest of
> the Cloudstack code assumes "isConnected" as false if the VPN is not included
> in the response.
> We've noticed that if an account had more than 3 site-to-site VPNs, that
> there are many errors per day stating that a S2S VPN is down.
> This is exacerbated by Issue CLOUDSTACK-9873, because that issues causes the
> S2S VPN check (and many others) to run twice as often as intended.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9871) MySQL 5.7 compatibility
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15965845#comment-15965845 ] ASF GitHub Bot commented on CLOUDSTACK-9871: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/2037 @rhtyd a Jenkins job has been kicked to build packages. I'll keep you posted as I make progress. > MySQL 5.7 compatibility > --- > > Key: CLOUDSTACK-9871 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9871 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.10.0.0 > Environment: Ubuntu 16.04, MySQL 5.7 >Reporter: Wido den Hollander >Priority: Minor > Labels: jdbc, mysql > > MySQL 5.7 comes with a more strict SQL mode by default which causes problems > for CloudStack as the queries it executes are not all compatible with MySQL > 5.7. > https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html > A work-around is setting the sql_mode to a more relaxed mode in the my.cnf: > [mysqld] > sql_mode='STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION' > In the future CloudStack should be fully compatible with the new SQL mode. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9871) MySQL 5.7 compatibility
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15965844#comment-15965844 ] ASF GitHub Bot commented on CLOUDSTACK-9871: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/2037 Lgtm @blueorangutan package > MySQL 5.7 compatibility > --- > > Key: CLOUDSTACK-9871 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9871 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.10.0.0 > Environment: Ubuntu 16.04, MySQL 5.7 >Reporter: Wido den Hollander >Priority: Minor > Labels: jdbc, mysql > > MySQL 5.7 comes with a more strict SQL mode by default which causes problems > for CloudStack as the queries it executes are not all compatible with MySQL > 5.7. > https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html > A work-around is setting the sql_mode to a more relaxed mode in the my.cnf: > [mysqld] > sql_mode='STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION' > In the future CloudStack should be fully compatible with the new SQL mode. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9858) Retirement of midonet plugin (disabling ticket)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15965858#comment-15965858 ] ASF GitHub Bot commented on CLOUDSTACK-9858: Github user wido commented on the issue: https://github.com/apache/cloudstack/pull/2036 LGTM > Retirement of midonet plugin (disabling ticket) > --- > > Key: CLOUDSTACK-9858 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9858 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner > > Recently there have been two threads asking and discussing the “midonet” > integration with Apache CloudStack (ACS) [1-2]. > After quite some discussions, we noticed that despite having some people > willing to use it, the plugin has never been fully developed by its vendor > (Midokura). Further, nobody else has put the effort on fully testing and > finishing its implementation. It seems that the plugin was incorporated into > our code base without being fully finished. Moreover, I have asked around at > the Midonet community, and the java client they use has changed quite a bit > from the one we use. > It begs the question if it does not work, why do we advertise such > integration? [3]. > Following the component retirement process defined in [4], a vote thread was > started in [5]. The community decided to retire this Midonet plugin. This > task represents the first step of the retirement, which is the disabling of > the plugin in CloudStack`s build process. > > [1] > http://cloudstack.markmail.org/thread/qyedle5jb2c34gsc#query:+page:1+mid:xn2zq2v3eim5vl2q+state:results > [2] > http://cloudstack.markmail.org/message/rewzk4v7dgzpsxkm?q=midonet+order:date-backward&page=1#query:midonet%20order%3Adate-backward+page:1+mid:i563khxlginf6smg+state:results > [3] http://docs.cloudstack.apache.org/en/latest/networking/midonet.html > [4] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=68720798 > [5] http://markmail.org/message/qigrtfirwnmct4hr -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9871) MySQL 5.7 compatibility
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15965904#comment-15965904 ] ASF GitHub Bot commented on CLOUDSTACK-9871: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/2037 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-635 > MySQL 5.7 compatibility > --- > > Key: CLOUDSTACK-9871 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9871 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.10.0.0 > Environment: Ubuntu 16.04, MySQL 5.7 >Reporter: Wido den Hollander >Priority: Minor > Labels: jdbc, mysql > > MySQL 5.7 comes with a more strict SQL mode by default which causes problems > for CloudStack as the queries it executes are not all compatible with MySQL > 5.7. > https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html > A work-around is setting the sql_mode to a more relaxed mode in the my.cnf: > [mysqld] > sql_mode='STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION' > In the future CloudStack should be fully compatible with the new SQL mode. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Created] (CLOUDSTACK-9874) OVM3 - Not being able to add an Oracle VM Server Host to Cloudstack
Boris Stoyanov created CLOUDSTACK-9874:
--
Summary: OVM3 - Not being able to add an Oracle VM Server Host to
Cloudstack
Key: CLOUDSTACK-9874
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9874
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Oracle VM (OVM)
Affects Versions: 4.9.2.0
Reporter: Boris Stoyanov
Attachments: ifconfig.txt, ovm.logs, ovs-agent.logs.txt
When adding host, the agent fails to send the IP information and "Address
Family not supported by protocol" error is displayed in the logs.
{code}
[2017-04-05 12:32:52 1530] INFO (notificationserver:257) Notification Server
started.
[2017-04-05 12:32:53 1539] INFO (remaster:151) REMASTER SERVER STARTED
[2017-04-05 12:32:53 1541] INFO (monitor:24) MONITOR SERVER STARTED
[2017-04-05 12:32:53 1543] INFO (ha:94) HA SERVER STARTED
[2017-04-05 12:32:53 1544] INFO (stats:20) Statistic server started.
[2017-04-05 12:32:54 1545] WARNING (xmlrpc:384) Error getting hostname and IP:
[Errno -3] Temporary failure in name resolution
[2017-04-05 12:32:54 1545] INFO (xmlrpc:386) Oracle VM Server version:
{'release': '3.3.2', 'date': '201503312309', 'build': '1076'}, hostname:
xen-13-2-a2-khi03, ip:
[2017-04-05 12:32:54 1545] INFO (xmlrpc:396) Oracle VM Agent XMLRPC Server
started.
[2017-04-05 12:32:55 1530] ERROR (notificationserver:240) Error sendinging
statistics: [Errno 97] Address family not supported by protocol
[2017-04-05 12:32:58 1541] DEBUG (monitor:39) Cluster state changed from
[Unknown] to [Offline]{code}
Attaching agent logs, management and ip configuration on the OVM3 hosts
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9872) Batch S2S VPN script doesn't return all responses
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9872?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15966014#comment-15966014
]
ASF GitHub Bot commented on CLOUDSTACK-9872:
GitHub user Slair1 opened a pull request:
https://github.com/apache/cloudstack/pull/2040
CLOUDSTACK-9872: Gather all S2S vpn statuses before outputting
The checkbatchs2svpn.sh VR script returns ("via echo") that status of each
requested S2S VPN check one-at-a-time. If there is even a slight delay between
VPN checks, the sshExecutor stops monitoring stdout and assumes it has all of
the output.
When checking the management server logs, we see a request to check _X_
number of VPNs, but the response is occasionally less than _X_ number... The
rest of the Cloudstack code assumes "isConnected" as false if the VPN is not
included in the response.
We've noticed that if an account had more than 3 site-to-site VPNs, that
there are many errors per day stating that a S2S VPN is down.
This is exacerbated by Issue CLOUDSTACK-9873, because that issues causes
the S2S VPN check (and many others) to run twice as often as intended.
Example where a request was to check 4x S2S VPN connections, but only 3x
responses were returned.
```
2017-04-11 17:05:40,444 DEBUG [c.c.h.x.r.CitrixResourceBase]
(DirectAgent-190:ctx-e894af45) (logid:cbbccfaa) Executing command in VR:
/opt/cloud/bin/router_proxy.sh checkbatchs2svpn.sh 169.254.2.130 67.41.109.167
65.100.18.183 67.41.109.165 67.41.109.166
2017-04-11 17:05:41,836 DEBUG [c.c.a.t.Request]
(DirectAgent-190:ctx-e894af45) (logid:cbbccfaa) Seq 51-772085861117329631:
Processing: { Ans: , MgmtId: 345050927939, via:
51(cloudxen01.dsm1.ippathways.net), Ver: v1, Flags: 110,
[{"com.cloud.agent.api.CheckS2SVpnConnectionsAnswer":{"ipToConnected":{"65.100.18.183":true,"67.41.109.167":true,"67.41.109.165":true},"ipToDetail":{"65.100.18.183":"ISAKMP
SA found;IPsec SA found;Site-to-site VPN have
connected","67.41.109.167":"ISAKMP SA found;IPsec SA found;Site-to-site VPN
have connected","67.41.109.165":"ISAKMP SA found;IPsec SA found;Site-to-site
VPN have connected"},"details":"67.41.109.167:0:ISAKMP SA found;IPsec SA
found;Site-to-site VPN have connected&65.100.18.183:0:ISAKMP SA found;IPsec SA
found;Site-to-site VPN have connected&67.41.109.165:0:ISAKMP SA found;IPsec SA
found;Site-to-site VPN have connected&","result":true,"wait":0}}] }
```
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/Slair1/cloudstack
CLOUDSTACK-9872-Check-Batch-S2S-VPN
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/cloudstack/pull/2040.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #2040
commit 9814be159d87073535716542a4430380e4202576
Author: Slair1
Date: 2017-04-12T14:58:56Z
Gather all S2S vpn statuses before outputting
> Batch S2S VPN script doesn't return all responses
> -
>
> Key: CLOUDSTACK-9872
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9872
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Virtual Router
>Affects Versions: 4.8.0, 4.9.0, 4.10.0.0, 4.8.1.1, 4.9.0.1
> Environment: Any using Site-to-Site VPNs. Seems to be all versions
> of Cloudstack
>Reporter: Sean Lair
>Priority: Minor
> Original Estimate: 1h
> Remaining Estimate: 1h
>
> The checkbatchs2svpn.sh VR script returns ("via echo") that status of each
> requested S2S VPN check one-at-a-time. If there is even a slight delay
> between VPN checks, the sshExecutor stops monitoring stdout and assumes it
> has all of the output.
> When checking the management server logs, we see a request to check X number
> of VPNs, but the response is occasionally less than X number... The rest of
> the Cloudstack code assumes "isConnected" as false if the VPN is not included
> in the response.
> We've noticed that if an account had more than 3 site-to-site VPNs, that
> there are many errors per day stating that a S2S VPN is down.
> This is exacerbated by Issue CLOUDSTACK-9873, because that issues causes the
> S2S VPN check (and many others) to run twice as often as intended.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9873) VR related periodic jobs are scheduled twice and run twice on management servers
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15966049#comment-15966049 ] ASF GitHub Bot commented on CLOUDSTACK-9873: GitHub user Slair1 opened a pull request: https://github.com/apache/cloudstack/pull/2041 CLOUDSTACK-9873: VR related periodic jobs are scheduled twice and run twice on management servers The "start" method of VirtualNetworkApplianceManagerImpl schedules several period checks, including stats updates, alert updates, and VR checks including S2S vpn checks. VpcVirtualNetworkApplianceManagerImpl extends VirtualNetworkApplianceManagerImpl. Thus when VpcVirtualNetworkApplianceManagerImpl is used, it re-runs the "start" method and once again schedules all the various jobs. Thus all the jobs run twice at each scheduled run. This is easily seen in the mangement-server.log (this is one of the checks that is doubled-up): `cat /var/log/cloudstack/management/management-server.log | grep "routers to update status"` Before (runs twice every 30 seconds): ``` 2017-04-10 21:48:12,879 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] (RouterStatusMonitor-1:ctx-5f7bc584) (logid:4d5b1031) Found 10 routers to update status. 2017-04-10 21:48:12,932 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] (RouterStatusMonitor-1:ctx-d027ab6f) (logid:1bc50629) Found 10 routers to update status. 2017-04-10 21:48:42,877 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] (RouterStatusMonitor-1:ctx-2c8f4d18) (logid:e9111785) Found 10 routers to update status. 2017-04-10 21:48:42,927 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] (RouterStatusMonitor-1:ctx-1bfd5351) (logid:ad0f95ef) Found 10 routers to update status. 2017-04-10 21:49:12,874 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] (RouterStatusMonitor-1:ctx-ede0d2bb) (logid:6f244423) Found 10 routers to update status. 2017-04-10 21:49:12,928 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] (RouterStatusMonitor-1:ctx-d58842d5) (logid:8442d73c) Found 10 routers to update status. ``` After change (runs once every 30 seconds): ``` 2017-04-12 15:19:09,150 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] (RouterStatusMonitor-1:ctx-34e46de7) (logid:280dc634) Found 10 routers to update status. 2017-04-12 15:19:39,150 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] (RouterStatusMonitor-1:ctx-5499a10d) (logid:33ca447b) Found 10 routers to update status. 2017-04-12 15:20:09,155 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] (RouterStatusMonitor-1:ctx-1df751da) (logid:c8d29e06) Found 10 routers to update status. 2017-04-12 15:20:39,152 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] (RouterStatusMonitor-1:ctx-b4cb567a) (logid:a09e1f29) Found 10 routers to update status. 2017-04-12 15:21:09,153 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] (RouterStatusMonitor-1:ctx-ab8e4023) (logid:f329b5ff) Found 10 routers to update status. 2017-04-12 15:21:39,150 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] (RouterStatusMonitor-1:ctx-04fee930) (logid:32f6619b) Found 10 routers to update status. ``` Exacerbates #2040 You can merge this pull request into a Git repository by running: $ git pull https://github.com/Slair1/cloudstack CLOUDSTACK-9873-VR-Scheduled-Checks-Scheduled-Twice Alternatively you can review and apply these changes as the patch at: https://github.com/apache/cloudstack/pull/2041.patch To close this pull request, make a commit to your master/trunk branch with (at least) the following in the commit message: This closes #2041 commit 81d83db5276a77b5c0debd8b5e58cf668e92196d Author: Slair1 Date: 2017-04-12T15:17:16Z VR related periodic jobs are scheduled twice and run twice on management servers > VR related periodic jobs are scheduled twice and run twice on management > servers > > > Key: CLOUDSTACK-9873 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9873 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, Virtual Router >Affects Versions: 4.8.0, 4.9.0 > Environment: Appears all environments >Reporter: Sean Lair >Priority: Minor > Fix For: 4.10.0.0 > > > The "start" method of VirtualNetworkApplianceManagerImpl schedules several > period checks, including stats updates, alert updates, and VR checks > including S2S vpn checks. > VpcVirtualNetworkApplianceManagerImpl also extends > VirtualNetworkApplianceManagerImpl. Thus when > VpcVirtualNetworkApplianceManagerImpl is used, it re-runs the "start" method > a
[jira] [Commented] (CLOUDSTACK-9871) MySQL 5.7 compatibility
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15966060#comment-15966060 ] ASF GitHub Bot commented on CLOUDSTACK-9871: Github user pdion891 commented on the issue: https://github.com/apache/cloudstack/pull/2037 Do you know if this have an impact if we still use MySQL 5.6 or MySQL 5.5 on another host and have CloudStack installed on Ubuntu or CentOS 7 ? > MySQL 5.7 compatibility > --- > > Key: CLOUDSTACK-9871 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9871 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.10.0.0 > Environment: Ubuntu 16.04, MySQL 5.7 >Reporter: Wido den Hollander >Priority: Minor > Labels: jdbc, mysql > > MySQL 5.7 comes with a more strict SQL mode by default which causes problems > for CloudStack as the queries it executes are not all compatible with MySQL > 5.7. > https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html > A work-around is setting the sql_mode to a more relaxed mode in the my.cnf: > [mysqld] > sql_mode='STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION' > In the future CloudStack should be fully compatible with the new SQL mode. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9871) MySQL 5.7 compatibility
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15966169#comment-15966169 ] ASF GitHub Bot commented on CLOUDSTACK-9871: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/2037 @pdion891 I'll run regression tests @blueorangutan test > MySQL 5.7 compatibility > --- > > Key: CLOUDSTACK-9871 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9871 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.10.0.0 > Environment: Ubuntu 16.04, MySQL 5.7 >Reporter: Wido den Hollander >Priority: Minor > Labels: jdbc, mysql > > MySQL 5.7 comes with a more strict SQL mode by default which causes problems > for CloudStack as the queries it executes are not all compatible with MySQL > 5.7. > https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html > A work-around is setting the sql_mode to a more relaxed mode in the my.cnf: > [mysqld] > sql_mode='STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION' > In the future CloudStack should be fully compatible with the new SQL mode. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9871) MySQL 5.7 compatibility
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15966170#comment-15966170 ] ASF GitHub Bot commented on CLOUDSTACK-9871: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/2037 @rhtyd a Trillian-Jenkins test job (centos7 mgmt + kvm-centos7) has been kicked to run smoke tests > MySQL 5.7 compatibility > --- > > Key: CLOUDSTACK-9871 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9871 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.10.0.0 > Environment: Ubuntu 16.04, MySQL 5.7 >Reporter: Wido den Hollander >Priority: Minor > Labels: jdbc, mysql > > MySQL 5.7 comes with a more strict SQL mode by default which causes problems > for CloudStack as the queries it executes are not all compatible with MySQL > 5.7. > https://dev.mysql.com/doc/refman/5.7/en/sql-mode.html > A work-around is setting the sql_mode to a more relaxed mode in the my.cnf: > [mysqld] > sql_mode='STRICT_TRANS_TABLES,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION' > In the future CloudStack should be fully compatible with the new SQL mode. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9462) Systemd packaging for Ubuntu 16.04
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15966252#comment-15966252 ] ASF GitHub Bot commented on CLOUDSTACK-9462: Github user rhtyd commented on the issue: https://github.com/apache/cloudstack/pull/2033 @blueorangutan test ubuntu kvm-ubuntu > Systemd packaging for Ubuntu 16.04 > -- > > Key: CLOUDSTACK-9462 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9462 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.10.0.0, 4.9.1.0 > > > Support for building deb packages that will work on Ubuntu 16.04 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9462) Systemd packaging for Ubuntu 16.04
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15966253#comment-15966253 ] ASF GitHub Bot commented on CLOUDSTACK-9462: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/2033 @rhtyd a Trillian-Jenkins test job (ubuntu mgmt + kvm-ubuntu) has been kicked to run smoke tests > Systemd packaging for Ubuntu 16.04 > -- > > Key: CLOUDSTACK-9462 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9462 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: 4.10.0.0, 4.9.1.0 > > > Support for building deb packages that will work on Ubuntu 16.04 -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9782) Host HA
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9782?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15966299#comment-15966299 ] ASF GitHub Bot commented on CLOUDSTACK-9782: Github user serverchief commented on the issue: https://github.com/apache/cloudstack/pull/1960 Hi @koushik-das I believe you missed a discussion on this a while back - when this was initially proposed and we were gathering community feedback. please read this thread http://markmail.org/message/dtsfb6crbtqx3xut It will explain why we are choosing this solution and how current VM HA in production is not meeting the needs. Thanks -ilya PS: we also gave community ample of opportunity to respond to our FS, this was almost 2 years in the making.. > Host HA > --- > > Key: CLOUDSTACK-9782 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9782 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav > Fix For: Future, 4.11.0.0 > > > CloudStack lacks a way to reliably fence a host, the idea of the host-ha > feature is to provide a general purpose HA framework and implementation > specific for hypervisor that can use additional mechanism such as OOBM (ipmi > based power management) to reliably investigate, recover and fencing a host. > This feature can handle scenarios associated with server crash issues and > reliable fencing of hosts and HA of VM. > FS: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Host+HA -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9858) Retirement of midonet plugin (disabling ticket)
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9858?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15966495#comment-15966495 ] ASF GitHub Bot commented on CLOUDSTACK-9858: Github user rafaelweingartner commented on the issue: https://github.com/apache/cloudstack/pull/2036 I tried to access the Jenkins details to see the checking problems, but I am getting a 404. Am I missing something? > Retirement of midonet plugin (disabling ticket) > --- > > Key: CLOUDSTACK-9858 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9858 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner > > Recently there have been two threads asking and discussing the “midonet” > integration with Apache CloudStack (ACS) [1-2]. > After quite some discussions, we noticed that despite having some people > willing to use it, the plugin has never been fully developed by its vendor > (Midokura). Further, nobody else has put the effort on fully testing and > finishing its implementation. It seems that the plugin was incorporated into > our code base without being fully finished. Moreover, I have asked around at > the Midonet community, and the java client they use has changed quite a bit > from the one we use. > It begs the question if it does not work, why do we advertise such > integration? [3]. > Following the component retirement process defined in [4], a vote thread was > started in [5]. The community decided to retire this Midonet plugin. This > task represents the first step of the retirement, which is the disabling of > the plugin in CloudStack`s build process. > > [1] > http://cloudstack.markmail.org/thread/qyedle5jb2c34gsc#query:+page:1+mid:xn2zq2v3eim5vl2q+state:results > [2] > http://cloudstack.markmail.org/message/rewzk4v7dgzpsxkm?q=midonet+order:date-backward&page=1#query:midonet%20order%3Adate-backward+page:1+mid:i563khxlginf6smg+state:results > [3] http://docs.cloudstack.apache.org/en/latest/networking/midonet.html > [4] https://cwiki.apache.org/confluence/pages/viewpage.action?pageId=68720798 > [5] http://markmail.org/message/qigrtfirwnmct4hr -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9871) MySQL 5.7 compatibility
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15966928#comment-15966928 ] ASF GitHub Bot commented on CLOUDSTACK-9871: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/2037 Trillian test result (tid-990) Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7 Total time taken: 29008 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2037-t990-kvm-centos7.zip Intermitten failure detected: /marvin/tests/smoke/test_privategw_acl.py Intermitten failure detected: /marvin/tests/smoke/test_snapshots.py Test completed. 47 look ok, 2 have error(s) Test | Result | Time (s) | Test File --- | --- | --- | --- test_04_rvpc_privategw_static_routes | `Failure` | 356.82 | test_privategw_acl.py test_02_list_snapshots_with_removed_data_store | `Error` | 0.04 | test_snapshots.py test_01_vpc_site2site_vpn | Success | 170.05 | test_vpc_vpn.py test_01_vpc_remote_access_vpn | Success | 71.17 | test_vpc_vpn.py test_01_redundant_vpc_site2site_vpn | Success | 266.25 | test_vpc_vpn.py test_02_VPC_default_routes | Success | 314.92 | test_vpc_router_nics.py test_01_VPC_nics_after_destroy | Success | 551.56 | test_vpc_router_nics.py test_05_rvpc_multi_tiers | Success | 526.61 | test_vpc_redundant.py test_04_rvpc_network_garbage_collector_nics | Success | 1427.30 | test_vpc_redundant.py test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | Success | 579.18 | test_vpc_redundant.py test_02_redundant_VPC_default_routes | Success | 771.35 | test_vpc_redundant.py test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Success | 1315.83 | test_vpc_redundant.py test_09_delete_detached_volume | Success | 157.04 | test_volumes.py test_08_resize_volume | Success | 157.09 | test_volumes.py test_07_resize_fail | Success | 156.55 | test_volumes.py test_06_download_detached_volume | Success | 156.29 | test_volumes.py test_05_detach_volume | Success | 155.82 | test_volumes.py test_04_delete_attached_volume | Success | 151.24 | test_volumes.py test_03_download_attached_volume | Success | 156.37 | test_volumes.py test_02_attach_volume | Success | 124.30 | test_volumes.py test_01_create_volume | Success | 715.49 | test_volumes.py test_deploy_vm_multiple | Success | 252.94 | test_vm_life_cycle.py test_deploy_vm | Success | 0.03 | test_vm_life_cycle.py test_advZoneVirtualRouter | Success | 0.03 | test_vm_life_cycle.py test_10_attachAndDetach_iso | Success | 26.62 | test_vm_life_cycle.py test_09_expunge_vm | Success | 125.23 | test_vm_life_cycle.py test_08_migrate_vm | Success | 40.94 | test_vm_life_cycle.py test_07_restore_vm | Success | 0.13 | test_vm_life_cycle.py test_06_destroy_vm | Success | 130.89 | test_vm_life_cycle.py test_03_reboot_vm | Success | 125.91 | test_vm_life_cycle.py test_02_start_vm | Success | 10.16 | test_vm_life_cycle.py test_01_stop_vm | Success | 40.33 | test_vm_life_cycle.py test_CreateTemplateWithDuplicateName | Success | 45.49 | test_templates.py test_08_list_system_templates | Success | 0.03 | test_templates.py test_07_list_public_templates | Success | 0.04 | test_templates.py test_05_template_permissions | Success | 0.06 | test_templates.py test_04_extract_template | Success | 5.17 | test_templates.py test_03_delete_template | Success | 5.11 | test_templates.py test_02_edit_template | Success | 90.14 | test_templates.py test_01_create_template | Success | 45.90 | test_templates.py test_10_destroy_cpvm | Success | 161.72 | test_ssvm.py test_09_destroy_ssvm | Success | 163.75 | test_ssvm.py test_08_reboot_cpvm | Success | 101.57 | test_ssvm.py test_07_reboot_ssvm | Success | 163.72 | test_ssvm.py test_06_stop_cpvm | Success | 131.86 | test_ssvm.py test_05_stop_ssvm | Success | 164.04 | test_ssvm.py test_04_cpvm_internals | Success | 1.21 | test_ssvm.py test_03_ssvm_internals | Success | 3.46 | test_ssvm.py test_02_list_cpvm_vm | Success | 0.13 | test_ssvm.py test_01_list_sec_storage_vm | Success | 0.13 | test_ssvm.py test_01_snapshot_root_disk | Success | 11.11 | test_snapshots.py test_04_change_offering_small | Success | 239.66 | test_service_offerings.py test_03_delete_service_offering | Success | 0.04 | test_service_offerings.py test_02_edit_service_offering | Success | 0.06 | test_service_offerings.py test_01_create_service_offering | Success | 0.12 | test_service_offerings.py test_02_sys_template_ready | Success | 0.13 | test_secondary_storage.py test_01_sys_vm_start | Success | 0.19 | test_secondary_storage.py test_09_reboot_router | Success | 40.34 | test_routers.py test
[jira] [Commented] (CLOUDSTACK-9462) Systemd packaging for Ubuntu 16.04
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9462?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15967066#comment-15967066 ] ASF GitHub Bot commented on CLOUDSTACK-9462: Github user blueorangutan commented on the issue: https://github.com/apache/cloudstack/pull/2033 Trillian test result (tid-991) Environment: kvm-ubuntu (x2), Advanced Networking with Mgmt server u Total time taken: 36466 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2033-t991-kvm-ubuntu.zip Intermitten failure detected: /marvin/tests/smoke/test_privategw_acl.py Intermitten failure detected: /marvin/tests/smoke/test_volumes.py Intermitten failure detected: /marvin/tests/smoke/test_vpc_redundant.py Test completed. 49 look ok, 1 have error(s) Test | Result | Time (s) | Test File --- | --- | --- | --- test_04_rvpc_privategw_static_routes | `Failure` | 314.57 | test_privategw_acl.py test_01_vpc_site2site_vpn | Success | 160.26 | test_vpc_vpn.py test_01_vpc_remote_access_vpn | Success | 65.91 | test_vpc_vpn.py test_01_redundant_vpc_site2site_vpn | Success | 235.65 | test_vpc_vpn.py test_02_VPC_default_routes | Success | 268.26 | test_vpc_router_nics.py test_01_VPC_nics_after_destroy | Success | 508.80 | test_vpc_router_nics.py test_05_rvpc_multi_tiers | Success | 526.78 | test_vpc_redundant.py test_04_rvpc_network_garbage_collector_nics | Success | 1410.41 | test_vpc_redundant.py test_03_create_redundant_VPC_1tier_2VMs_2IPs_2PF_ACL_reboot_routers | Success | 549.20 | test_vpc_redundant.py test_02_redundant_VPC_default_routes | Success | 764.88 | test_vpc_redundant.py test_01_create_redundant_VPC_2tiers_4VMs_4IPs_4PF_ACL | Success | 1290.96 | test_vpc_redundant.py test_09_delete_detached_volume | Success | 161.34 | test_volumes.py test_08_resize_volume | Success | 151.15 | test_volumes.py test_07_resize_fail | Success | 166.29 | test_volumes.py test_06_download_detached_volume | Success | 156.32 | test_volumes.py test_05_detach_volume | Success | 155.65 | test_volumes.py test_04_delete_attached_volume | Success | 156.05 | test_volumes.py test_03_download_attached_volume | Success | 156.04 | test_volumes.py test_02_attach_volume | Success | 95.12 | test_volumes.py test_01_create_volume | Success | 711.25 | test_volumes.py test_03_delete_vm_snapshots | Success | 275.17 | test_vm_snapshots.py test_02_revert_vm_snapshots | Success | 95.67 | test_vm_snapshots.py test_01_create_vm_snapshots | Success | 163.73 | test_vm_snapshots.py test_deploy_vm_multiple | Success | 257.26 | test_vm_life_cycle.py test_deploy_vm | Success | 0.02 | test_vm_life_cycle.py test_advZoneVirtualRouter | Success | 0.02 | test_vm_life_cycle.py test_10_attachAndDetach_iso | Success | 26.64 | test_vm_life_cycle.py test_09_expunge_vm | Success | 125.22 | test_vm_life_cycle.py test_08_migrate_vm | Success | 40.76 | test_vm_life_cycle.py test_07_restore_vm | Success | 0.08 | test_vm_life_cycle.py test_06_destroy_vm | Success | 130.76 | test_vm_life_cycle.py test_03_reboot_vm | Success | 130.73 | test_vm_life_cycle.py test_02_start_vm | Success | 10.13 | test_vm_life_cycle.py test_01_stop_vm | Success | 45.46 | test_vm_life_cycle.py test_CreateTemplateWithDuplicateName | Success | 45.41 | test_templates.py test_08_list_system_templates | Success | 0.02 | test_templates.py test_07_list_public_templates | Success | 0.02 | test_templates.py test_05_template_permissions | Success | 0.03 | test_templates.py test_04_extract_template | Success | 5.14 | test_templates.py test_03_delete_template | Success | 5.09 | test_templates.py test_02_edit_template | Success | 90.14 | test_templates.py test_01_create_template | Success | 30.34 | test_templates.py test_10_destroy_cpvm | Success | 166.99 | test_ssvm.py test_09_destroy_ssvm | Success | 164.01 | test_ssvm.py test_08_reboot_cpvm | Success | 132.21 | test_ssvm.py test_07_reboot_ssvm | Success | 134.06 | test_ssvm.py test_06_stop_cpvm | Success | 162.04 | test_ssvm.py test_05_stop_ssvm | Success | 139.18 | test_ssvm.py test_04_cpvm_internals | Success | 1.67 | test_ssvm.py test_03_ssvm_internals | Success | 4.15 | test_ssvm.py test_02_list_cpvm_vm | Success | 0.09 | test_ssvm.py test_01_list_sec_storage_vm | Success | 0.09 | test_ssvm.py test_02_list_snapshots_with_removed_data_store | Success | 86.60 | test_snapshots.py test_01_snapshot_root_disk | Success | 11.09 | test_snapshots.py test_04_change_offering_small | Success | 245.47 | test_service_offerings.py test_03_delete_service_offering | Success | 0.04 | test_service_offerings.py test_02_edit_service_offering | Success | 0.06 | test_service_offerings.py
[jira] [Commented] (CLOUDSTACK-9585) UI doesn't give an option to select the xentools version for non ROOT users
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9585?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15967105#comment-15967105 ] ASF GitHub Bot commented on CLOUDSTACK-9585: Github user yvsubhash commented on the issue: https://github.com/apache/cloudstack/pull/1756 tag:mergeready > UI doesn't give an option to select the xentools version for non ROOT users > --- > > Key: CLOUDSTACK-9585 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9585 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: UI >Affects Versions: 4.8.0 > Environment: Xen Server >Reporter: subhash yedugundla > Fix For: 4.8.1 > > > UI doesn't give an option to select the xentools version while registering > template for any user other than ROOT admin. Templates registered by other > users are marked as 'xenserver56' and results in unsusable VMs due to the > device_id:002 issue with windows if the template is having xentools version > higher than 6.1 . > Repro Steps > Select register template as any other user than ROOT domain admin and UI > doesn't give an option to select the xentools version. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
[jira] [Commented] (CLOUDSTACK-9873) VR related periodic jobs are scheduled twice and run twice on management servers
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9873?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15967189#comment-15967189 ] ASF GitHub Bot commented on CLOUDSTACK-9873: Github user ustcweizhou commented on the issue: https://github.com/apache/cloudstack/pull/2041 @Slair1 this is already fixed by commit ba9dcba in 4.10/master > VR related periodic jobs are scheduled twice and run twice on management > servers > > > Key: CLOUDSTACK-9873 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9873 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server, Virtual Router >Affects Versions: 4.8.0, 4.9.0 > Environment: Appears all environments >Reporter: Sean Lair >Priority: Minor > Fix For: 4.10.0.0 > > > The "start" method of VirtualNetworkApplianceManagerImpl schedules several > period checks, including stats updates, alert updates, and VR checks > including S2S vpn checks. > VpcVirtualNetworkApplianceManagerImpl also extends > VirtualNetworkApplianceManagerImpl. Thus when > VpcVirtualNetworkApplianceManagerImpl is used, it re-runs the "start" method > and once again schedules all the various jobs. Thus all the jobs run twice > at each scheduled run. This is easily seen in the mangement-server.log: > cat /var/log/cloudstack/management/management-server.log | grep "routers to > update status" > 2017-04-10 21:48:12,879 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] > (RouterStatusMonitor-1:ctx-5f7bc584) (logid:4d5b1031) Found 10 routers to > update status. > 2017-04-10 21:48:12,932 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] > (RouterStatusMonitor-1:ctx-d027ab6f) (logid:1bc50629) Found 10 routers to > update status. > 2017-04-10 21:48:42,877 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] > (RouterStatusMonitor-1:ctx-2c8f4d18) (logid:e9111785) Found 10 routers to > update status. > 2017-04-10 21:48:42,927 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] > (RouterStatusMonitor-1:ctx-1bfd5351) (logid:ad0f95ef) Found 10 routers to > update status. > 2017-04-10 21:49:12,874 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] > (RouterStatusMonitor-1:ctx-ede0d2bb) (logid:6f244423) Found 10 routers to > update status. > 2017-04-10 21:49:12,928 DEBUG [c.c.n.r.VirtualNetworkApplianceManagerImpl] > (RouterStatusMonitor-1:ctx-d58842d5) (logid:8442d73c) Found 10 routers to > update status. -- This message was sent by Atlassian JIRA (v6.3.15#6346)
