[jira] [Commented] (CLOUDSTACK-10327) SSO fails with error "Session Expired", except for root admin
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16410882#comment-16410882
]
ASF GitHub Bot commented on CLOUDSTACK-10327:
-
blueorangutan commented on issue #2498: CLOUDSTACK-10327: Do not invalidate the
session when API command not found
URL: https://github.com/apache/cloudstack/pull/2498#issuecomment-375559143
@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
> SSO fails with error "Session Expired", except for root admin
> -
>
> Key: CLOUDSTACK-10327
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10327
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Affects Versions: 4.11.0.0
>Reporter: Olivier Lemasle
>Assignee: Olivier Lemasle
>Priority: Critical
>
> CloudStack SSO (using {{security.singlesignon.key}}) does not work anymore
> with CloudStack 4.11, since commit
> [9988c26|https://github.com/apache/cloudstack/commit/9988c269b259b84c0b8436bad17f88dbc1d706e7#diff-16f2bfa56c6e8760760dd2b27b47d5b4]
> This commit introduced a new feature (the ability to limit admin API calls to
> a network CIDR), but also a regression due to a refactoring: every API
> request that is not "validated" generates the same error (401 - Unauthorized)
> and *invalidates the session*.
> However, during an SSO login, CloudStack executes (since ACS 4.7), a [call to
> "listConfigurations"|https://github.com/apache/cloudstack/blob/8a3943b7632eddf3856a19e7d9a3fee82dd325be/ui/scripts/cloudStack.js#L172],
> an API command reserved for root admins. When the user is not a root admin,
> he does not have the privileges for this command.
> With CloudStack up to 4.10, an error 432 was returned (and ignored):
> {noformat}
> {"errorresponse":{"uuidList":[],"errorcode":432,"cserrorcode":,"errortext":"The
> user is not allowed to request the API command or the API command does not
> exist"}}
> {noformat}
> With CloudStack 4.11, the error 432 is replaced by an error 401 and the
> session is invalidated. Then the next API calls lead to an error "Session
> Expired" and the user cannot log in.
> {noformat}
> {"listconfigurationsresponse":{"uuidList":[],"errorcode":401,"errortext":"unable
> to verify user credentials and/or request signature"}}
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Updated] (CLOUDSTACK-10341) Systemvmtemplate 4.11 changes
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10341?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav updated CLOUDSTACK-10341: - Status: Reviewable (was: In Progress) > Systemvmtemplate 4.11 changes > - > > Key: CLOUDSTACK-10341 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10341 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: 4.12.0.0, 4.11.1.0 > > > Systemvmtemplate and fail due to low /run memory allocation, the template is > slow to copy the size may be further reduced. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10327) SSO fails with error "Session Expired", except for root admin
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16410881#comment-16410881
]
ASF GitHub Bot commented on CLOUDSTACK-10327:
-
rhtyd commented on issue #2498: CLOUDSTACK-10327: Do not invalidate the session
when API command not found
URL: https://github.com/apache/cloudstack/pull/2498#issuecomment-375559096
@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
> SSO fails with error "Session Expired", except for root admin
> -
>
> Key: CLOUDSTACK-10327
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10327
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Affects Versions: 4.11.0.0
>Reporter: Olivier Lemasle
>Assignee: Olivier Lemasle
>Priority: Critical
>
> CloudStack SSO (using {{security.singlesignon.key}}) does not work anymore
> with CloudStack 4.11, since commit
> [9988c26|https://github.com/apache/cloudstack/commit/9988c269b259b84c0b8436bad17f88dbc1d706e7#diff-16f2bfa56c6e8760760dd2b27b47d5b4]
> This commit introduced a new feature (the ability to limit admin API calls to
> a network CIDR), but also a regression due to a refactoring: every API
> request that is not "validated" generates the same error (401 - Unauthorized)
> and *invalidates the session*.
> However, during an SSO login, CloudStack executes (since ACS 4.7), a [call to
> "listConfigurations"|https://github.com/apache/cloudstack/blob/8a3943b7632eddf3856a19e7d9a3fee82dd325be/ui/scripts/cloudStack.js#L172],
> an API command reserved for root admins. When the user is not a root admin,
> he does not have the privileges for this command.
> With CloudStack up to 4.10, an error 432 was returned (and ignored):
> {noformat}
> {"errorresponse":{"uuidList":[],"errorcode":432,"cserrorcode":,"errortext":"The
> user is not allowed to request the API command or the API command does not
> exist"}}
> {noformat}
> With CloudStack 4.11, the error 432 is replaced by an error 401 and the
> session is invalidated. Then the next API calls lead to an error "Session
> Expired" and the user cannot log in.
> {noformat}
> {"listconfigurationsresponse":{"uuidList":[],"errorcode":401,"errortext":"unable
> to verify user credentials and/or request signature"}}
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10271) detect vulnerabilities in depndencies
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10271?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16410879#comment-16410879 ] ASF GitHub Bot commented on CLOUDSTACK-10271: - rhtyd commented on issue #2446: CLOUDSTACK-10271 maven plugin for owasp dependency check added URL: https://github.com/apache/cloudstack/pull/2446#issuecomment-375558901 @DaanHoogland can you check and fix Travis failures? 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 > detect vulnerabilities in depndencies > - > > Key: CLOUDSTACK-10271 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10271 > Project: CloudStack > Issue Type: Wish > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Daan Hoogland >Assignee: Daan Hoogland >Priority: Major > > As a developer I want to know whether and what dependencies I am using that > might harm my users. For this we need to add the owasp dependency checker to > the maven build. It will require more then just this but it is a good first > step. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-9781) ACS records ID in events tables instead of UUID.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9781?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16410877#comment-16410877 ] 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-375558690 Ping @syed, let's re-discuss this? 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-10341) Systemvmtemplate 4.11 changes
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16410873#comment-16410873 ] ASF subversion and git services commented on CLOUDSTACK-10341: -- Commit 9753cc3681b4dd31a9e409897f89228fb3fbd562 in cloudstack's branch refs/heads/master from [~rohit.ya...@shapeblue.com] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=9753cc3 ] Merge branch '4.11' CLOUDSTACK-10341: VR minor fixes to systemvmtemplate (#2468) CLOUDSTACK-10340: Add setter to hypervisorType in VMInstanceVO (#2504) Signed-off-by: Rohit Yadav > Systemvmtemplate 4.11 changes > - > > Key: CLOUDSTACK-10341 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10341 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: 4.12.0.0, 4.11.1.0 > > > Systemvmtemplate and fail due to low /run memory allocation, the template is > slow to copy the size may be further reduced. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10340) Add setter in vminstancevo
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16410871#comment-16410871 ] ASF subversion and git services commented on CLOUDSTACK-10340: -- Commit 2a068696f8620410326a3984b498c7e9f1fd2ec5 in cloudstack's branch refs/heads/master from [~rohithsharma] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=2a06869 ] CLOUDSTACK-10340: Add setter to hypervisorType in VMInstanceVO (#2504) This adds a missing setter to set hypervisorType in VMInstanceVO. Signed-off-by: Rohit Yadav > Add setter in vminstancevo > --- > > Key: CLOUDSTACK-10340 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10340 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: 4.12.0.0, 4.11.1.0 > > > Add setter for: > _VMInstanceVO needs setHypervisorType()_ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10341) Systemvmtemplate 4.11 changes
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16410872#comment-16410872 ] ASF subversion and git services commented on CLOUDSTACK-10341: -- Commit c8dcc64b6534f3e035ebc8597c38591e40009ea5 in cloudstack's branch refs/heads/master from [~resmo] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=c8dcc64 ] CLOUDSTACK-10341: VR minor fixes to systemvmtemplate (#2468) - Fixes rsyslog: fix config error in rsylslog.conf Feb 26 08:09:54 r-413-VM liblogging-stdlog[19754]: action '*' treated as ':omusrmsg:*' - please use ':omusrmsg:*' syntax instead, '*' will not be supported in the future [v8.24.0 try http://www.rsyslog.com/e/2184 ] Feb 26 08:09:54 r-413-VM liblogging-stdlog[19754]: error during parsing file /etc/rsyslog.conf, on or before line 95: warnings occured in file '/etc/rsyslog.conf' around line 95 [v8.24.0 try http://www.rsyslog.com/e/2207 ] - Run apache2 only after cloud-postinit - Increase /run size for VR with 256M RAM root@r-395-VM:~# systemctl daemon-reload Failed to reload daemon: Refusing to reload, not enough space available on /run/systemd. Currently, 15.8M are free, but a safety buffer of 16.0M is enforced. tmpfs23M 6.5M 16M 29% /run > Systemvmtemplate 4.11 changes > - > > Key: CLOUDSTACK-10341 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10341 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: 4.12.0.0, 4.11.1.0 > > > Systemvmtemplate and fail due to low /run memory allocation, the template is > slow to copy the size may be further reduced. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10340) Add setter in vminstancevo
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16410874#comment-16410874 ] ASF subversion and git services commented on CLOUDSTACK-10340: -- Commit 9753cc3681b4dd31a9e409897f89228fb3fbd562 in cloudstack's branch refs/heads/master from [~rohit.ya...@shapeblue.com] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=9753cc3 ] Merge branch '4.11' CLOUDSTACK-10341: VR minor fixes to systemvmtemplate (#2468) CLOUDSTACK-10340: Add setter to hypervisorType in VMInstanceVO (#2504) Signed-off-by: Rohit Yadav > Add setter in vminstancevo > --- > > Key: CLOUDSTACK-10340 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10340 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: 4.12.0.0, 4.11.1.0 > > > Add setter for: > _VMInstanceVO needs setHypervisorType()_ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10341) Systemvmtemplate 4.11 changes
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16410868#comment-16410868 ] ASF GitHub Bot commented on CLOUDSTACK-10341: - rhtyd opened a new pull request #2506: CLOUDSTACK-10341: Reduce template size, install nft URL: https://github.com/apache/cloudstack/pull/2506 ## Description This reduces systemvmtemplate size by 600MB and installs nftables, updates iptables. ## Types of changes - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] New feature (non-breaking change which adds functionality) - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] Enhancement (improves an existing feature and functionality) - [ ] Cleanup (Code refactoring and cleanup, that may add test cases) ## Screenshots (if appropriate): ## How Has This Been Tested? Manually built using packer and tested locally by running smoketests. ## Checklist: - [ ] I have read the [CONTRIBUTING](https://github.com/apache/cloudstack/blob/master/CONTRIBUTING.md) document. - [ ] My code follows the code style of this project. - [ ] All new and existing tests passed. 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 > Systemvmtemplate 4.11 changes > - > > Key: CLOUDSTACK-10341 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10341 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: 4.12.0.0, 4.11.1.0 > > > Systemvmtemplate and fail due to low /run memory allocation, the template is > slow to copy the size may be further reduced. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10341) Systemvmtemplate 4.11 changes
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10341?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16410867#comment-16410867 ] ASF subversion and git services commented on CLOUDSTACK-10341: -- Commit c8dcc64b6534f3e035ebc8597c38591e40009ea5 in cloudstack's branch refs/heads/4.11 from [~resmo] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=c8dcc64 ] CLOUDSTACK-10341: VR minor fixes to systemvmtemplate (#2468) - Fixes rsyslog: fix config error in rsylslog.conf Feb 26 08:09:54 r-413-VM liblogging-stdlog[19754]: action '*' treated as ':omusrmsg:*' - please use ':omusrmsg:*' syntax instead, '*' will not be supported in the future [v8.24.0 try http://www.rsyslog.com/e/2184 ] Feb 26 08:09:54 r-413-VM liblogging-stdlog[19754]: error during parsing file /etc/rsyslog.conf, on or before line 95: warnings occured in file '/etc/rsyslog.conf' around line 95 [v8.24.0 try http://www.rsyslog.com/e/2207 ] - Run apache2 only after cloud-postinit - Increase /run size for VR with 256M RAM root@r-395-VM:~# systemctl daemon-reload Failed to reload daemon: Refusing to reload, not enough space available on /run/systemd. Currently, 15.8M are free, but a safety buffer of 16.0M is enforced. tmpfs23M 6.5M 16M 29% /run > Systemvmtemplate 4.11 changes > - > > Key: CLOUDSTACK-10341 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10341 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: 4.12.0.0, 4.11.1.0 > > > Systemvmtemplate and fail due to low /run memory allocation, the template is > slow to copy the size may be further reduced. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CLOUDSTACK-10341) Systemvmtemplate 4.11 changes
Rohit Yadav created CLOUDSTACK-10341: Summary: Systemvmtemplate 4.11 changes Key: CLOUDSTACK-10341 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10341 Project: CloudStack Issue Type: Task Security Level: Public (Anyone can view this level - this is the default.) Reporter: Rohit Yadav Assignee: Rohit Yadav Fix For: 4.12.0.0, 4.11.1.0 Systemvmtemplate and fail due to low /run memory allocation, the template is slow to copy the size may be further reduced. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10340) Add setter in vminstancevo
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16410864#comment-16410864 ] ASF GitHub Bot commented on CLOUDSTACK-10340: - blueorangutan commented on issue #2504: CLOUDSTACK-10340: Add setter to hypervisorType in VMInstanceVO URL: https://github.com/apache/cloudstack/pull/2504#issuecomment-375556408 @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 > Add setter in vminstancevo > --- > > Key: CLOUDSTACK-10340 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10340 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: 4.12.0.0, 4.11.1.0 > > > Add setter for: > _VMInstanceVO needs setHypervisorType()_ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10340) Add setter in vminstancevo
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16410861#comment-16410861
]
ASF GitHub Bot commented on CLOUDSTACK-10340:
-
rhtyd closed pull request #2504: CLOUDSTACK-10340: Add setter to hypervisorType
in VMInstanceVO
URL: https://github.com/apache/cloudstack/pull/2504
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/schema/src/com/cloud/vm/VMInstanceVO.java
b/engine/schema/src/com/cloud/vm/VMInstanceVO.java
index b55e030620b..b0ebf2406f5 100644
--- a/engine/schema/src/com/cloud/vm/VMInstanceVO.java
+++ b/engine/schema/src/com/cloud/vm/VMInstanceVO.java
@@ -267,6 +267,10 @@ public HypervisorType getHypervisorType() {
return hypervisorType;
}
+public void setHypervisorType(HypervisorType hypervisorType) {
+this.hypervisorType = hypervisorType;
+}
+
@Override
public Date getCreated() {
return created;
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> Add setter in vminstancevo
> ---
>
> Key: CLOUDSTACK-10340
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10340
> Project: CloudStack
> Issue Type: Task
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: Rohit Yadav
>Assignee: Rohit Yadav
>Priority: Major
> Fix For: 4.12.0.0, 4.11.1.0
>
>
> Add setter for:
> _VMInstanceVO needs setHypervisorType()_
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10340) Add setter in vminstancevo
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16410862#comment-16410862 ] ASF subversion and git services commented on CLOUDSTACK-10340: -- Commit 2a068696f8620410326a3984b498c7e9f1fd2ec5 in cloudstack's branch refs/heads/4.11 from [~rohithsharma] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=2a06869 ] CLOUDSTACK-10340: Add setter to hypervisorType in VMInstanceVO (#2504) This adds a missing setter to set hypervisorType in VMInstanceVO. Signed-off-by: Rohit Yadav > Add setter in vminstancevo > --- > > Key: CLOUDSTACK-10340 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10340 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: 4.12.0.0, 4.11.1.0 > > > Add setter for: > _VMInstanceVO needs setHypervisorType()_ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10340) Add setter in vminstancevo
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16410859#comment-16410859 ] ASF GitHub Bot commented on CLOUDSTACK-10340: - rhtyd commented on issue #2504: CLOUDSTACK-10340: Add setter to hypervisorType in VMInstanceVO URL: https://github.com/apache/cloudstack/pull/2504#issuecomment-375556274 Thanks all, merging this based on code reviews and test results (the failures were not caused by this PR, but were intermitted/env caused). This is an automated message from the Apache Git Service. To respond to the message, please log on GitHub and use the URL above to go to the specific comment. For queries about this service, please contact Infrastructure at: us...@infra.apache.org > Add setter in vminstancevo > --- > > Key: CLOUDSTACK-10340 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10340 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: 4.12.0.0, 4.11.1.0 > > > Add setter for: > _VMInstanceVO needs setHypervisorType()_ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10332) Users are not able to change/edit the protocol of an ACL rule
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16410812#comment-16410812 ] ASF GitHub Bot commented on CLOUDSTACK-10332: - blueorangutan commented on issue #2496: [CLOUDSTACK-10332] Users are not able to change/edit the protocol of an ACL rule URL: https://github.com/apache/cloudstack/pull/2496#issuecomment-375545689 Trillian test result (tid-2404) Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7 Total time taken: 32457 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2496-t2404-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_privategw_acl.py Intermitten failure detected: /marvin/tests/smoke/test_vpc_redundant.py Intermitten failure detected: /marvin/tests/smoke/test_vpc_vpn.py Intermitten failure detected: /marvin/tests/smoke/test_host_maintenance.py Intermitten failure detected: /marvin/tests/smoke/test_hostha_kvm.py Smoke tests completed. 64 look OK, 3 have error(s) Only failed tests results shown below: Test | Result | Time (s) | Test File --- | --- | --- | --- test_03_vpc_privategw_restart_vpc_cleanup | `Failure` | 204.34 | test_privategw_acl.py test_04_rvpc_network_garbage_collector_nics | `Failure` | 497.44 | test_vpc_redundant.py test_hostha_enable_ha_when_host_in_maintenance | `Error` | 1.44 | 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 > Users are not able to change/edit the protocol of an ACL rule > -- > > Key: CLOUDSTACK-10332 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10332 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > Fix For: 4.12 > > > Users should be able to edit an ACL rule completely. Therefore, they must be > able to change the protocol type and others configs of an ACL rules. > Right now users are not able to execute the following. > * Create an ACL for ICMP > * Click on edit and change the protocol to TCP > * An error will happen when saving the rule. > Users should be able to execute the protocol changes without problem. > In addition, it is not just the protocol that users are not able to change. > For instance, after defining ports, or reason/description for the rule, users > are not able to set those values back to null. The same happens for ICMP code > and type. > We will introduce a new parameter called "partialUpdate", which will have its > default value as true to maintain backward compatibility. When this parameter > is set to false, we will consider only the parameters sent, and not the > parameters we already have in the database to change and validate the ACL > rule data. This allows us to update parameters already set back to null, and > to completely change an ACL rule. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10332) Users are not able to change/edit the protocol of an ACL rule
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16410171#comment-16410171 ] ASF GitHub Bot commented on CLOUDSTACK-10332: - blueorangutan commented on issue #2496: [CLOUDSTACK-10332] Users are not able to change/edit the protocol of an ACL rule URL: https://github.com/apache/cloudstack/pull/2496#issuecomment-375430900 @borisstoyanov 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 > Users are not able to change/edit the protocol of an ACL rule > -- > > Key: CLOUDSTACK-10332 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10332 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > Fix For: 4.12 > > > Users should be able to edit an ACL rule completely. Therefore, they must be > able to change the protocol type and others configs of an ACL rules. > Right now users are not able to execute the following. > * Create an ACL for ICMP > * Click on edit and change the protocol to TCP > * An error will happen when saving the rule. > Users should be able to execute the protocol changes without problem. > In addition, it is not just the protocol that users are not able to change. > For instance, after defining ports, or reason/description for the rule, users > are not able to set those values back to null. The same happens for ICMP code > and type. > We will introduce a new parameter called "partialUpdate", which will have its > default value as true to maintain backward compatibility. When this parameter > is set to false, we will consider only the parameters sent, and not the > parameters we already have in the database to change and validate the ACL > rule data. This allows us to update parameters already set back to null, and > to completely change an ACL rule. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10332) Users are not able to change/edit the protocol of an ACL rule
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16410170#comment-16410170 ] ASF GitHub Bot commented on CLOUDSTACK-10332: - borisstoyanov commented on issue #2496: [CLOUDSTACK-10332] Users are not able to change/edit the protocol of an ACL rule URL: https://github.com/apache/cloudstack/pull/2496#issuecomment-375430753 @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 > Users are not able to change/edit the protocol of an ACL rule > -- > > Key: CLOUDSTACK-10332 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10332 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > Fix For: 4.12 > > > Users should be able to edit an ACL rule completely. Therefore, they must be > able to change the protocol type and others configs of an ACL rules. > Right now users are not able to execute the following. > * Create an ACL for ICMP > * Click on edit and change the protocol to TCP > * An error will happen when saving the rule. > Users should be able to execute the protocol changes without problem. > In addition, it is not just the protocol that users are not able to change. > For instance, after defining ports, or reason/description for the rule, users > are not able to set those values back to null. The same happens for ICMP code > and type. > We will introduce a new parameter called "partialUpdate", which will have its > default value as true to maintain backward compatibility. When this parameter > is set to false, we will consider only the parameters sent, and not the > parameters we already have in the database to change and validate the ACL > rule data. This allows us to update parameters already set back to null, and > to completely change an ACL rule. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16410151#comment-16410151 ] ASF GitHub Bot commented on CLOUDSTACK-10323: - blueorangutan commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk offering during volume migration URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-375426587 @borisstoyanov 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 > Change disk offering when volume is migrated to different type of storage > pool. > --- > > Key: CLOUDSTACK-10323 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10323 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.12 >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > This is a continuation of work developed on PR #2425 (CLOUDSTACK-10240), > which provided root admins an override mechanism to move volumes between > storage systems types (local/shared) even when the disk offering would not > allow such operation. To complete the work, we will now provide a way for > administrators to enter a new disk offering that can reflect the new > placement of the volume. We will add an extra parameter to allow the root > admin inform a new disk offering for the volume. Therefore, when the volume > is being migrated, it will be possible to replace the disk offering to > reflect the new placement of the volume. > The API method will have the following parameters: > * storageid (required) > * volumeid (required) > * livemigrate(optional) > * newdiskofferingid (optional) – this is the new parameter > The expected behavior is the following: > * If “newdiskofferingid” is not provided the current behavior is maintained. > Override mechanism will also keep working as we have seen so far. > * If the “newdiskofferingid” is provided by the admin, we will execute the > following checks > ** new disk offering mode (local/shared) must match the target storage mode. > If it does not match, an exception will be thrown and the operator will > receive a message indicating the problem. > ** we will check if the new disk offering tags match the target storage tags. > If it does not match, an exception will be thrown and the operator will > receive a message indicating the problem. > ** check if the target storage has the capacity for the new volume. If it > does not have enough space, then an exception is thrown and the operator will > receive a message indicating the problem. > ** check if the size of the volume is the same as the size of the new disk > offering. If it is not the same, we will ALLOW the change of the service > offering, and a warning message will be logged. > We execute the change of the Disk offering as soon as the migration of the > volume finishes. Therefore, if an error happens during the migration and the > volume remains in the original storage system, the disk offering will keep > reflecting this situation -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16410148#comment-16410148 ] ASF GitHub Bot commented on CLOUDSTACK-10323: - borisstoyanov commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk offering during volume migration URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-375426295 @rafaelweingartner let me run this again, don't know why it appeared. @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 > Change disk offering when volume is migrated to different type of storage > pool. > --- > > Key: CLOUDSTACK-10323 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10323 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.12 >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > This is a continuation of work developed on PR #2425 (CLOUDSTACK-10240), > which provided root admins an override mechanism to move volumes between > storage systems types (local/shared) even when the disk offering would not > allow such operation. To complete the work, we will now provide a way for > administrators to enter a new disk offering that can reflect the new > placement of the volume. We will add an extra parameter to allow the root > admin inform a new disk offering for the volume. Therefore, when the volume > is being migrated, it will be possible to replace the disk offering to > reflect the new placement of the volume. > The API method will have the following parameters: > * storageid (required) > * volumeid (required) > * livemigrate(optional) > * newdiskofferingid (optional) – this is the new parameter > The expected behavior is the following: > * If “newdiskofferingid” is not provided the current behavior is maintained. > Override mechanism will also keep working as we have seen so far. > * If the “newdiskofferingid” is provided by the admin, we will execute the > following checks > ** new disk offering mode (local/shared) must match the target storage mode. > If it does not match, an exception will be thrown and the operator will > receive a message indicating the problem. > ** we will check if the new disk offering tags match the target storage tags. > If it does not match, an exception will be thrown and the operator will > receive a message indicating the problem. > ** check if the target storage has the capacity for the new volume. If it > does not have enough space, then an exception is thrown and the operator will > receive a message indicating the problem. > ** check if the size of the volume is the same as the size of the new disk > offering. If it is not the same, we will ALLOW the change of the service > offering, and a warning message will be logged. > We execute the change of the Disk offering as soon as the migration of the > volume finishes. Therefore, if an error happens during the migration and the > volume remains in the original storage system, the disk offering will keep > reflecting this situation -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10340) Add setter in vminstancevo
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16410144#comment-16410144 ] ASF GitHub Bot commented on CLOUDSTACK-10340: - blueorangutan commented on issue #2504: CLOUDSTACK-10340: Add setter to hypervisorType in VMInstanceVO URL: https://github.com/apache/cloudstack/pull/2504#issuecomment-375425876 Trillian test result (tid-2399) Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7 Total time taken: 37455 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2504-t2399-kvm-centos7.zip 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_templates.py Intermitten failure detected: /marvin/tests/smoke/test_usage.py Intermitten failure detected: /marvin/tests/smoke/test_volumes.py Intermitten failure detected: /marvin/tests/smoke/test_vpc_redundant.py Intermitten failure detected: /marvin/tests/smoke/test_vpc_vpn.py Smoke tests completed. 63 look OK, 4 have error(s) Only failed tests results shown below: Test | Result | Time (s) | Test File --- | --- | --- | --- test_04_extract_template | `Failure` | 128.29 | test_templates.py ContextSuite context=TestISOUsage>:setup | `Error` | 0.00 | test_usage.py test_06_download_detached_volume | `Failure` | 137.64 | test_volumes.py test_04_rvpc_network_garbage_collector_nics | `Failure` | 509.98 | test_vpc_redundant.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 > Add setter in vminstancevo > --- > > Key: CLOUDSTACK-10340 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10340 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: 4.12.0.0, 4.11.1.0 > > > Add setter for: > _VMInstanceVO needs setHypervisorType()_ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CLOUDSTACK-10169) Clean up old and obsolete branches
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10169?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Rafael Weingärtner updated CLOUDSTACK-10169:
Description:
The following is full list of branches available on
https://github.com/apache/cloudstack and the old ones can be deleted.
||Branch name||Ticket number||POM version||Last updated||Last commit||HEAD on
master||PR number||Should be deleted||
|4.0|-|4.0.2|Jul 19
2013|[8f4b9bc|https://github.com/apache/cloudstack/commit/8f4b9bccfed63a37762907bdd058506f4e7b6e6d)]|No|-|{color:#d04437}*No*{color}|
|4.1|-|4.1.2-SNAPSHOT|Dec 10
2013|[1b7c886|https://github.com/apache/cloudstack/commit/1b7c886bb1a4cd28840a13e199fedc8c2e865011)]|No|-|{color:#d04437}*No*{color}|
|4.10|-|4.10.1.0-SNAPSHOT|Nov 16
2017|[330f241|https://github.com/apache/cloudstack/commit/330f24117cc5c90b85db291981652a2191417d5a)]|Yes|-|{color:#d04437}*No*{color}|
|4.2|-|4.2.1-SNAPSHOT|May 13
2015|[709e0c0|https://github.com/apache/cloudstack/commit/709e0c093fc280cee79b30c7ee0a11331ebbae57)]|No|-|{color:#d04437}*No*{color}|
|4.3|-|4.3.2|Aug 12
2015|[c116ca9|https://github.com/apache/cloudstack/commit/c116ca968e552f079e1ebfe855b4bfa02d368f74)]|No|-|{color:#d04437}*No*{color}|
|4.4|-|4.4.5-SNAPSHOT|Sep 1
2015|[b0a4593|https://github.com/apache/cloudstack/commit/b0a45931527cb57e4d23edab36adf4fac1ffa494)]|No|-|{color:#d04437}*No*{color}|
|4.5|-|4.5.3-SNAPSHOT|Oct 18
2016|[e731c70|https://github.com/apache/cloudstack/commit/e731c70cf7ab72b593cde10af8e49673a21b9f9c)]|No|-|{color:#d04437}*No*{color}|
|4.5.2.1-security-RC20160525T1207|-|4.5.2.1|May 25
2016|[7059c29|https://github.com/apache/cloudstack/commit/7059c29e940f9e1321eee2b35ff045c2eb655df3)]|No|-|Yes|
|4.6|-|4.6.3-SNAPSHOT|Oct 18
2016|[08b4052|https://github.com/apache/cloudstack/commit/08b40525955881869340a8ae3b268dea6edd926b)]|No|-|{color:#d04437}*No*{color}|
|4.7|-|4.7.2-SNAPSHOT|Nov 8
2016|[0279ac2|https://github.com/apache/cloudstack/commit/0279ac20e46cbbc7f699dc41eafbe31fe0c4797b)]|Yes|-|{color:#d04437}*No*{color}|
|4.7.0-RC20151213T2109|-|4.7.0|Dec 13
2015|[2f26a85|https://github.com/apache/cloudstack/commit/2f26a859a971a9852ed9f6f34fe35e52fe6028a9)]|Yes|-|Yes|
|4.7.1-RC20160120T2318|-|4.7.1|Jan 20
2016|[5ea07dc|https://github.com/apache/cloudstack/commit/5ea07dc93799f28dd6c268b17514867d92dc53f7)]|No|-|Yes|
|4.7.1.1-RC20160525T1230|-|4.7.1.1|May 25
2016|[781775a|https://github.com/apache/cloudstack/commit/781775a31f6c0f08043cb6f73494628e71fb)]|No|-|Yes|
|4.8|-|4.8.2.0-SNAPSHOT|Feb 28
2017|[113ce13|https://github.com/apache/cloudstack/commit/113ce13bda9d4a095ff3a22d6fedf925117f4f6f)]|Yes|-|{color:#d04437}*No*{color}|
|4.8.0-RC20160120T2343|-|4.8.0|Jan 20
2016|[62f218b|https://github.com/apache/cloudstack/commit/62f218b7bd005d201d1c8516180d8e6d6797)]|Yes|-|Yes|
|4.8.0.1-RC20160525T1247|-|4.8.0.1|May 25
2016|[6d575df|https://github.com/apache/cloudstack/commit/6d575df3b83dd3e2f5eb94c1ba63bb7a083f44d0)]|No|-|Yes|
|4.8.1-RC20160808T1006|-|4.8.1|Aug 8
2016|[a63db21|https://github.com/apache/cloudstack/commit/a63db21d16072821a1e27473813fddf36accfdd4)]|Yes|-|Yes|
|4.8.2.0-RC20161210T0832|-|4.8.2.0|Dec 10
2016|[4a1f7ed|https://github.com/apache/cloudstack/commit/4a1f7ed8bc51d859c5e0e5b9c3ad513752ff8c40)]|No|-|Yes|
|4.9|-|4.9.4.0-SNAPSHOT|Nov 15
2017|[f250b3a|https://github.com/apache/cloudstack/commit/f250b3ae0cf7efeef486f15474b606299d17318e)]|Yes|-|{color:#d04437}*No*{color}|
|4.9-bountycastle-daan|-|4.10.0.0-SNAPSHOT|May 18
2016|[b9ee34f|https://github.com/apache/cloudstack/commit/b9ee34fa9510f10b0bddeff869c821a5361932b2)]|No|Closed
([1511|https://github.com/apache/cloudstack/pull/1511])|Yes|
|4.9-systemdubuntupkging|-|4.9.1.0-SNAPSHOT|Aug 24
2016|[c8a52c9|https://github.com/apache/cloudstack/commit/c8a52c94d2f34f0204404707c04148f5ee4f3f2e)]|Yes|Merged
([1647|https://github.com/apache/cloudstack/pull/1647])|Yes|
|4.9.0-RC20160706T1546|-|4.9.0|Jul 6
2016|[643f75a|https://github.com/apache/cloudstack/commit/643f75aa9150156b1fb05f339a338614fc7ad3fb)]|No|-|Yes|
|4.9.0-RC20160725T1656|-|4.9.0|Jul 25
2016|[227ff38|https://github.com/apache/cloudstack/commit/227ff3884dd0b9c2804f20a2cc53964b01256ad9)]|Yes|-|Yes|
|4.9.1.0-RC20161210T0838|-|4.9.1.0|Dec 10
2016|[af26799|https://github.com/apache/cloudstack/commit/af2679959b634d095b93b8265c6da294d360065d)]|Yes|-|Yes|
|4.9.2.0-RC20161227T1309|-|4.9.2.0|Dec 27
2016|[d410612|https://github.com/apache/cloudstack/commit/d410612dbc9623d3ff0e96e468cf0a72ef98a765)]|No|-|Yes|
|CLOUDSTACK-10012|CLOUDSTACK-10012|4.11.0.0-SNAPSHOT|Aug 7
2017|[a04da57|https://github.com/apache/cloudstack/commit/a04da57cff3962d805dba931f0c7a42b0b27f9b0)]|No|Merged
([2226|https://github.com/apache/cloudstack/pull/2226])|Yes|
|CLOUDSTACK-1302|CLOUDSTACK-1302|4.6.0-SNAPSHOT|Apr 30
2015|[10c1deb|https://github.com/apache/cloudstack/commit/10c1deb1892d3eb8b1d20a2c2cd7fc6c7a9e6902)]|No|-|Yes|
|CLOUDSTACK-2554|CLOUDSTACK-2554
[jira] [Resolved] (CLOUDSTACK-10324) Remove branches 4.1l10n, 4.2-*, 4.3.0-forward, and 4.4-*
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10324?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-10324. - Resolution: Fixed > Remove branches 4.1l10n, 4.2-*, 4.3.0-forward, and 4.4-* > > > Key: CLOUDSTACK-10324 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10324 > Project: CloudStack > Issue Type: Sub-task > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > Following the protocol defined in [1]. We will remove branches of 4.10.0.0-RC > The branches that will be removed are the following: > * 4.1l10n > * 4.2-forward > * 4.2-workplace > * 4.3.0-forward > * 4.4-automation > * 4.4-forward > * 4.4-forward-iam > * 4.4-forward-iam-disabled > [1] > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Clean+up+old+and+obsolete+branches+protocol -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10333) Secure VM Live migration for KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16409938#comment-16409938 ] ASF GitHub Bot commented on CLOUDSTACK-10333: - blueorangutan commented on issue #2505: CLOUDSTACK-10333: Secure Live VM Migration for KVM URL: https://github.com/apache/cloudstack/pull/2505#issuecomment-375390869 Trillian test result (tid-2401) Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7 Total time taken: 24349 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2505-t2401-kvm-centos7.zip Intermitten failure detected: /marvin/tests/smoke/test_deploy_virtio_scsi_vm.py Intermitten failure detected: /marvin/tests/smoke/test_privategw_acl.py Intermitten failure detected: /marvin/tests/smoke/test_vpc_redundant.py Intermitten failure detected: /marvin/tests/smoke/test_hostha_kvm.py Smoke tests completed. 65 look OK, 2 have error(s) Only failed tests results shown below: Test | Result | Time (s) | Test File --- | --- | --- | --- test_04_rvpc_network_garbage_collector_nics | `Failure` | 448.47 | test_vpc_redundant.py test_hostha_enable_ha_when_host_in_maintenance | `Error` | 2.09 | 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 > Secure VM Live migration for KVM > > > Key: CLOUDSTACK-10333 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10333 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: 4.12.0.0, 4.11.1.0 > > > With use of CA framework to secure hosts, the current mechanisms don't secure > libvirtd to use those certificates (used by agent to connect to mgmt server). > This causes insecure vm migration over tcp instead of tls. The aim is to use > the same framework and certificates to secure live VM migration. This could > be coupled with securing of a host and renewal/provisioning of certificates > to host. > > FS: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Secure+Live+VM+Migration+for+KVM -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10327) SSO fails with error "Session Expired", except for root admin
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10327?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16409872#comment-16409872
]
ASF GitHub Bot commented on CLOUDSTACK-10327:
-
wido commented on issue #2498: CLOUDSTACK-10327: Do not invalidate the session
when API command not found
URL: https://github.com/apache/cloudstack/pull/2498#issuecomment-375377353
I don't see anything odd in this PR, looks good to me. I didn't catch this
situation.
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
> SSO fails with error "Session Expired", except for root admin
> -
>
> Key: CLOUDSTACK-10327
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10327
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Affects Versions: 4.11.0.0
>Reporter: Olivier Lemasle
>Assignee: Olivier Lemasle
>Priority: Critical
>
> CloudStack SSO (using {{security.singlesignon.key}}) does not work anymore
> with CloudStack 4.11, since commit
> [9988c26|https://github.com/apache/cloudstack/commit/9988c269b259b84c0b8436bad17f88dbc1d706e7#diff-16f2bfa56c6e8760760dd2b27b47d5b4]
> This commit introduced a new feature (the ability to limit admin API calls to
> a network CIDR), but also a regression due to a refactoring: every API
> request that is not "validated" generates the same error (401 - Unauthorized)
> and *invalidates the session*.
> However, during an SSO login, CloudStack executes (since ACS 4.7), a [call to
> "listConfigurations"|https://github.com/apache/cloudstack/blob/8a3943b7632eddf3856a19e7d9a3fee82dd325be/ui/scripts/cloudStack.js#L172],
> an API command reserved for root admins. When the user is not a root admin,
> he does not have the privileges for this command.
> With CloudStack up to 4.10, an error 432 was returned (and ignored):
> {noformat}
> {"errorresponse":{"uuidList":[],"errorcode":432,"cserrorcode":,"errortext":"The
> user is not allowed to request the API command or the API command does not
> exist"}}
> {noformat}
> With CloudStack 4.11, the error 432 is replaced by an error 401 and the
> session is invalidated. Then the next API calls lead to an error "Session
> Expired" and the user cannot log in.
> {noformat}
> {"listconfigurationsresponse":{"uuidList":[],"errorcode":401,"errortext":"unable
> to verify user credentials and/or request signature"}}
> {noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-7982) Storage live migration support for KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16409844#comment-16409844 ] ASF GitHub Bot commented on CLOUDSTACK-7982: wido commented on issue #1709: CLOUDSTACK-7982: KVM live migration with local storage URL: https://github.com/apache/cloudstack/pull/1709#issuecomment-375373749 @marcaurele Yes, I should be able to do that or @GabrielBrascher might be able to help 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 > 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-10320) Invalid pair for response object breaking response parsing
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10320?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16409843#comment-16409843
]
ASF GitHub Bot commented on CLOUDSTACK-10320:
-
marcaurele commented on issue #2481: CLOUDSTACK-10320 - Invalid pair for
response object breaking response parsing
URL: https://github.com/apache/cloudstack/pull/2481#issuecomment-375373737
@DaanHoogland bad news: it didn't last very long before I had to rollback
the isolation level due to DB dead locks (at least in our branch based from
4.4.2). So it's the only quick fix & hacky solution for now which doesn't add
another issue.
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
> Invalid pair for response object breaking response parsing
> --
>
> Key: CLOUDSTACK-10320
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10320
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: API
>Reporter: Marc-Aurèle Brothier
>Assignee: Marc-Aurèle Brothier
>Priority: Major
>
> Under some circumstances, the API is returning an invalid response, for
> simplicity I will expose the JSON case. The API response on a
> listVirtualMachines can be this string:
> {code:java}
> { "listvirtualmachinesresponse" : ] } }{code}
> To understand how this is possible, assume you have more than one management
> server and one is processing the destroy of a virtual machine in the account
> X which is the only one it has. Another process is returning the result of
> listVirtualMachines for that same account X. During the listVM command, the
> result set is fetch with a searchAndDistinctCount due to the view
> ([https://github.com/apache/cloudstack/blob/master/server/src/main/java/com/cloud/api/query/QueryManagerImpl.java#L1024).]
> This is done through 2 queries in the GenericDao
> [https://github.com/apache/cloudstack/blob/master/framework/db/src/main/java/com/cloud/utils/db/GenericDaoBase.java#L1323]
> and if you encounter the _right_ conditions, the VM will be marked as
> removed in between those 2 queries. This results in having a Pair result with
> at least one object but a count of 0. Then following how is done the
> serialization of the response at
> [https://github.com/apache/cloudstack/blob/master/server/src/main/java/com/cloud/api/response/ApiResponseSerializer.java#L86]
> you will reach the case where your output is the one previously mentioned.
> To overcome this issue, there isn't a true fix but only a better pair
> response to ensure a correct response formatting. If the result set contains
> at least something, the count cannot be 0 but we cannot guess the correct
> answer, but only state it has at least one element.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10241) Duplicated file SRs being created in XenServer pools
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16409837#comment-16409837 ] ASF GitHub Bot commented on CLOUDSTACK-10241: - blueorangutan commented on issue #2414: [CLOUDSTACK-10241] Duplicated file SRs being created in XenServer pools URL: https://github.com/apache/cloudstack/pull/2414#issuecomment-375372060 @rhtyd a Trillian-Jenkins test job (centos7 mgmt + xenserver-65sp1) 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 > Duplicated file SRs being created in XenServer pools > > > Key: CLOUDSTACK-10241 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10241 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > Due to a race condition between multiple management servers, in some rare > cases, CloudStack is creating multiple file SRs to the same secondary folder. > This causes a problem when introducing the SR to the XenServer pools, as > “there will be VDIs with duplicated UUIDs“. The VDIs are the same, but they > are seen in different SRs, and therefore cause an error. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10241) Duplicated file SRs being created in XenServer pools
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16409834#comment-16409834 ] ASF GitHub Bot commented on CLOUDSTACK-10241: - rhtyd commented on issue #2414: [CLOUDSTACK-10241] Duplicated file SRs being created in XenServer pools URL: https://github.com/apache/cloudstack/pull/2414#issuecomment-375371878 okay @rafaelweingartner, I'll review this 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 > Duplicated file SRs being created in XenServer pools > > > Key: CLOUDSTACK-10241 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10241 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > Due to a race condition between multiple management servers, in some rare > cases, CloudStack is creating multiple file SRs to the same secondary folder. > This causes a problem when introducing the SR to the XenServer pools, as > “there will be VDIs with duplicated UUIDs“. The VDIs are the same, but they > are seen in different SRs, and therefore cause an error. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10241) Duplicated file SRs being created in XenServer pools
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16409835#comment-16409835 ] ASF GitHub Bot commented on CLOUDSTACK-10241: - rhtyd commented on issue #2414: [CLOUDSTACK-10241] Duplicated file SRs being created in XenServer pools URL: https://github.com/apache/cloudstack/pull/2414#issuecomment-375371958 @blueorangutan test centos7 xenserver-65sp1 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 > Duplicated file SRs being created in XenServer pools > > > Key: CLOUDSTACK-10241 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10241 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > Due to a race condition between multiple management servers, in some rare > cases, CloudStack is creating multiple file SRs to the same secondary folder. > This causes a problem when introducing the SR to the XenServer pools, as > “there will be VDIs with duplicated UUIDs“. The VDIs are the same, but they > are seen in different SRs, and therefore cause an error. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-7982) Storage live migration support for KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7982?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16409831#comment-16409831 ] 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-375371493 @wido I'll work on the rebase, but I need help to get it tested. The marvin tests are failing but I cannot access the management server logs to understand the issue, so I need someone who's using master in their lab to test this branch and give me a feedback on the log exceptions. Can you do that ? 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-10241) Duplicated file SRs being created in XenServer pools
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16409828#comment-16409828 ] ASF GitHub Bot commented on CLOUDSTACK-10241: - rafaelweingartner commented on issue #2414: [CLOUDSTACK-10241] Duplicated file SRs being created in XenServer pools URL: https://github.com/apache/cloudstack/pull/2414#issuecomment-375371248 @rhtyd I would rather not. It is not a simple rebase to 4.11. I just tried and a lot of conflicts appeared, which would require some extra work to solve. 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 > Duplicated file SRs being created in XenServer pools > > > Key: CLOUDSTACK-10241 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10241 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > Due to a race condition between multiple management servers, in some rare > cases, CloudStack is creating multiple file SRs to the same secondary folder. > This causes a problem when introducing the SR to the XenServer pools, as > “there will be VDIs with duplicated UUIDs“. The VDIs are the same, but they > are seen in different SRs, and therefore cause an error. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10241) Duplicated file SRs being created in XenServer pools
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16409801#comment-16409801 ] ASF GitHub Bot commented on CLOUDSTACK-10241: - rhtyd commented on issue #2414: [CLOUDSTACK-10241] Duplicated file SRs being created in XenServer pools URL: https://github.com/apache/cloudstack/pull/2414#issuecomment-375366161 Thanks @rafaelweingartner since this is a bug fix, do you think it may be useful for 4.11 LTS? 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 > Duplicated file SRs being created in XenServer pools > > > Key: CLOUDSTACK-10241 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10241 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > Due to a race condition between multiple management servers, in some rare > cases, CloudStack is creating multiple file SRs to the same secondary folder. > This causes a problem when introducing the SR to the XenServer pools, as > “there will be VDIs with duplicated UUIDs“. The VDIs are the same, but they > are seen in different SRs, and therefore cause an error. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10241) Duplicated file SRs being created in XenServer pools
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16409612#comment-16409612
]
ASF GitHub Bot commented on CLOUDSTACK-10241:
-
rafaelweingartner commented on a change in pull request #2414:
[CLOUDSTACK-10241] Duplicated file SRs being created in XenServer pools
URL: https://github.com/apache/cloudstack/pull/2414#discussion_r176441369
##
File path:
plugins/hypervisors/xenserver/src/main/java/com/cloud/hypervisor/xenserver/resource/Xenserver625StorageProcessor.java
##
@@ -65,90 +69,181 @@ public Xenserver625StorageProcessor(final
CitrixResourceBase resource) {
super(resource);
}
-protected boolean mountNfs(final Connection conn, final String remoteDir,
String localDir) {
+private void mountNfs(Connection conn, String remoteDir, String localDir) {
if (localDir == null) {
localDir = "/var/cloud_mount/" +
UUID.nameUUIDFromBytes(remoteDir.getBytes());
}
-
-final String results = hypervisorResource.callHostPluginAsync(conn,
"cloud-plugin-storage", "mountNfsSecondaryStorage", 100 * 1000, "localDir",
localDir, "remoteDir",
-remoteDir);
-
-if (results == null || results.isEmpty()) {
+String result = hypervisorResource.callHostPluginAsync(conn,
"cloud-plugin-storage", "mountNfsSecondaryStorage", 100 * 1000, "localDir",
localDir, "remoteDir", remoteDir);
+if (StringUtils.isBlank(result)) {
final String errMsg = "Could not mount secondary storage " +
remoteDir + " on host " + localDir;
-
s_logger.warn(errMsg);
-
throw new CloudRuntimeException(errMsg);
}
-
-return true;
}
-protected boolean makeDirectory(final Connection conn, final String path) {
-final String result = hypervisorResource.callHostPlugin(conn,
"cloud-plugin-storage", "makeDirectory", "path", path);
+protected boolean makeDirectory(Connection conn, String path) {
+String result = hypervisorResource.callHostPlugin(conn,
"cloud-plugin-storage", "makeDirectory", "path", path);
+return StringUtils.isNotBlank(result);
+}
-if (result == null || result.isEmpty()) {
-return false;
+/**
+ * Creates the file SR for the given path. If there already exist a file
SR for the path, we return the existing one.
+ * This method uses a synchronized block to guarantee that only a single
file SR is created per path.
+ * If it is not possible to retrieve one file SR or to create one, a
runtime exception will be thrown.
+ */
+protected SR createFileSR(Connection conn, String path) {
+String srPath = StringUtils.trim(path);
+synchronized (srPath) {
+SR sr = retrieveAlreadyConfiguredSrWithoutException(conn, srPath);
+if (sr == null) {
+sr = createNewFileSr(conn, srPath);
+}
+if (sr == null) {
+String hostUuid = this.hypervisorResource._host.getUuid();
+throw new CloudRuntimeException(String.format("Could not
retrieve an already used file SR for path [%s] or create a new file SR on host
[%s]", srPath, hostUuid));
+}
+return sr;
}
-
-return true;
}
-protected SR createFileSR(final Connection conn, final String path) {
+/**
+ * Creates a new file SR for the given path. If any of XenServer's checked
exception occurs, we use method {@link #removeSrAndPbdIfPossible(Connection,
SR, PBD)} to clean the created PBD and SR entries.
+ * To avoid race conditions between management servers, we are using a
deterministic srUuid for the file SR to be created (we are leaving XenServer
with the burden of managing race conditions). The UUID is based on the SR file
path, and is generated using {@link UUID#nameUUIDFromBytes(byte[])}.
+ * If there is an SR with the generated UUID, this means that some other
management server has just created it. An exception will occur and this
exception will be an {@link InternalError}. The exception will contain {@link
InternalError#message} a message saying
'Db_exn.Uniqueness_constraint_violation'.
+ * For cases where the previous described error happens, we catch the
exception and use the method {@link
#retrieveAlreadyConfiguredSrWithoutException(Connection, String)}.
+ */
+protected SR createNewFileSr(Connection conn, String srPath) {
+String hostUuid = hypervisorResource.getHost().getUuid();
+s_logger.debug(String.format("Creating file SR for path [%s] on host
[%s]", srPath, this.hypervisorResource._host.getUuid()));
SR sr = null;
PBD pbd = null;
-
try {
-final String srname = path.trim();
-synchronized (srname.intern()) {
-final Set srs = SR.getByN
[jira] [Commented] (CLOUDSTACK-10332) Users are not able to change/edit the protocol of an ACL rule
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16409592#comment-16409592 ] ASF GitHub Bot commented on CLOUDSTACK-10332: - blueorangutan commented on issue #2496: [CLOUDSTACK-10332] Users are not able to change/edit the protocol of an ACL rule URL: https://github.com/apache/cloudstack/pull/2496#issuecomment-375323027 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1809 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 > Users are not able to change/edit the protocol of an ACL rule > -- > > Key: CLOUDSTACK-10332 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10332 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > Fix For: 4.12 > > > Users should be able to edit an ACL rule completely. Therefore, they must be > able to change the protocol type and others configs of an ACL rules. > Right now users are not able to execute the following. > * Create an ACL for ICMP > * Click on edit and change the protocol to TCP > * An error will happen when saving the rule. > Users should be able to execute the protocol changes without problem. > In addition, it is not just the protocol that users are not able to change. > For instance, after defining ports, or reason/description for the rule, users > are not able to set those values back to null. The same happens for ICMP code > and type. > We will introduce a new parameter called "partialUpdate", which will have its > default value as true to maintain backward compatibility. When this parameter > is set to false, we will consider only the parameters sent, and not the > parameters we already have in the database to change and validate the ACL > rule data. This allows us to update parameters already set back to null, and > to completely change an ACL rule. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10241) Duplicated file SRs being created in XenServer pools
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10241?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16409568#comment-16409568
]
ASF GitHub Bot commented on CLOUDSTACK-10241:
-
GabrielBrascher commented on a change in pull request #2414: [CLOUDSTACK-10241]
Duplicated file SRs being created in XenServer pools
URL: https://github.com/apache/cloudstack/pull/2414#discussion_r175882326
##
File path:
plugins/hypervisors/xenserver/src/main/java/com/cloud/hypervisor/xenserver/resource/Xenserver625StorageProcessor.java
##
@@ -65,90 +69,181 @@ public Xenserver625StorageProcessor(final
CitrixResourceBase resource) {
super(resource);
}
-protected boolean mountNfs(final Connection conn, final String remoteDir,
String localDir) {
+private void mountNfs(Connection conn, String remoteDir, String localDir) {
if (localDir == null) {
localDir = "/var/cloud_mount/" +
UUID.nameUUIDFromBytes(remoteDir.getBytes());
}
-
-final String results = hypervisorResource.callHostPluginAsync(conn,
"cloud-plugin-storage", "mountNfsSecondaryStorage", 100 * 1000, "localDir",
localDir, "remoteDir",
-remoteDir);
-
-if (results == null || results.isEmpty()) {
+String result = hypervisorResource.callHostPluginAsync(conn,
"cloud-plugin-storage", "mountNfsSecondaryStorage", 100 * 1000, "localDir",
localDir, "remoteDir", remoteDir);
+if (StringUtils.isBlank(result)) {
final String errMsg = "Could not mount secondary storage " +
remoteDir + " on host " + localDir;
-
s_logger.warn(errMsg);
-
throw new CloudRuntimeException(errMsg);
}
-
-return true;
}
-protected boolean makeDirectory(final Connection conn, final String path) {
-final String result = hypervisorResource.callHostPlugin(conn,
"cloud-plugin-storage", "makeDirectory", "path", path);
+protected boolean makeDirectory(Connection conn, String path) {
+String result = hypervisorResource.callHostPlugin(conn,
"cloud-plugin-storage", "makeDirectory", "path", path);
+return StringUtils.isNotBlank(result);
+}
-if (result == null || result.isEmpty()) {
-return false;
+/**
+ * Creates the file SR for the given path. If there already exist a file
SR for the path, we return the existing one.
+ * This method uses a synchronized block to guarantee that only a single
file SR is created per path.
+ * If it is not possible to retrieve one file SR or to create one, a
runtime exception will be thrown.
+ */
+protected SR createFileSR(Connection conn, String path) {
+String srPath = StringUtils.trim(path);
+synchronized (srPath) {
+SR sr = retrieveAlreadyConfiguredSrWithoutException(conn, srPath);
+if (sr == null) {
+sr = createNewFileSr(conn, srPath);
+}
+if (sr == null) {
+String hostUuid = this.hypervisorResource._host.getUuid();
+throw new CloudRuntimeException(String.format("Could not
retrieve an already used file SR for path [%s] or create a new file SR on host
[%s]", srPath, hostUuid));
+}
+return sr;
}
-
-return true;
}
-protected SR createFileSR(final Connection conn, final String path) {
+/**
+ * Creates a new file SR for the given path. If any of XenServer's checked
exception occurs, we use method {@link #removeSrAndPbdIfPossible(Connection,
SR, PBD)} to clean the created PBD and SR entries.
+ * To avoid race conditions between management servers, we are using a
deterministic srUuid for the file SR to be created (we are leaving XenServer
with the burden of managing race conditions). The UUID is based on the SR file
path, and is generated using {@link UUID#nameUUIDFromBytes(byte[])}.
+ * If there is an SR with the generated UUID, this means that some other
management server has just created it. An exception will occur and this
exception will be an {@link InternalError}. The exception will contain {@link
InternalError#message} a message saying
'Db_exn.Uniqueness_constraint_violation'.
+ * For cases where the previous described error happens, we catch the
exception and use the method {@link
#retrieveAlreadyConfiguredSrWithoutException(Connection, String)}.
+ */
+protected SR createNewFileSr(Connection conn, String srPath) {
+String hostUuid = hypervisorResource.getHost().getUuid();
+s_logger.debug(String.format("Creating file SR for path [%s] on host
[%s]", srPath, this.hypervisorResource._host.getUuid()));
SR sr = null;
PBD pbd = null;
-
try {
-final String srname = path.trim();
-synchronized (srname.intern()) {
-final Set srs = SR.getByNam
[jira] [Commented] (CLOUDSTACK-10307) Remove unused things from HostDaoImpl
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10307?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16409554#comment-16409554 ] ASF GitHub Bot commented on CLOUDSTACK-10307: - rafaelweingartner commented on issue #2438: [CLOUDSTACK-10307] Remove unused things from HostDaoImpl URL: https://github.com/apache/cloudstack/pull/2438#issuecomment-375314280 @DaanHoogland do you have the test results? It seems that something went wrong and they never got posted 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, please contact Infrastructure at: us...@infra.apache.org > Remove unused things from HostDaoImpl > - > > Key: CLOUDSTACK-10307 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10307 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Minor > > Remove unnecessary annotation of HostDaoImpl. While removing this annotation > I noticed that one of the methods were not necessary. While removing it, I > found some code in CloudZonesStartupProcessor that was also not used, and > removed it. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16409553#comment-16409553 ] ASF GitHub Bot commented on CLOUDSTACK-10323: - rafaelweingartner commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk offering during volume migration URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-375313966 @borisstoyanov are these errors something that I should take a look into? I noticed that the test you included is failing as well. I looked at the error of the new test, and it seems you are trying to change the service offering to a new one that does not have the tags of the target storage. `Target Storage [id=0818cecf-5f99-3b1e-beb2-5f0669c7b5ba] tags [storage.overprovisioning.factor] does not match new disk offering [id=a2992784-662b-4cad-b833-38c46136f97e] tags [null].'}, accountid : u'9f16aecc-2c1d-11e8-8460-06d348010705'}\n"]` 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 > Change disk offering when volume is migrated to different type of storage > pool. > --- > > Key: CLOUDSTACK-10323 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10323 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.12 >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > This is a continuation of work developed on PR #2425 (CLOUDSTACK-10240), > which provided root admins an override mechanism to move volumes between > storage systems types (local/shared) even when the disk offering would not > allow such operation. To complete the work, we will now provide a way for > administrators to enter a new disk offering that can reflect the new > placement of the volume. We will add an extra parameter to allow the root > admin inform a new disk offering for the volume. Therefore, when the volume > is being migrated, it will be possible to replace the disk offering to > reflect the new placement of the volume. > The API method will have the following parameters: > * storageid (required) > * volumeid (required) > * livemigrate(optional) > * newdiskofferingid (optional) – this is the new parameter > The expected behavior is the following: > * If “newdiskofferingid” is not provided the current behavior is maintained. > Override mechanism will also keep working as we have seen so far. > * If the “newdiskofferingid” is provided by the admin, we will execute the > following checks > ** new disk offering mode (local/shared) must match the target storage mode. > If it does not match, an exception will be thrown and the operator will > receive a message indicating the problem. > ** we will check if the new disk offering tags match the target storage tags. > If it does not match, an exception will be thrown and the operator will > receive a message indicating the problem. > ** check if the target storage has the capacity for the new volume. If it > does not have enough space, then an exception is thrown and the operator will > receive a message indicating the problem. > ** check if the size of the volume is the same as the size of the new disk > offering. If it is not the same, we will ALLOW the change of the service > offering, and a warning message will be logged. > We execute the change of the Disk offering as soon as the migration of the > volume finishes. Therefore, if an error happens during the migration and the > volume remains in the original storage system, the disk offering will keep > reflecting this situation -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10323) Change disk offering when volume is migrated to different type of storage pool.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16409552#comment-16409552 ] ASF GitHub Bot commented on CLOUDSTACK-10323: - rafaelweingartner commented on issue #2486: [CLOUDSTACK-10323] Allow changing disk offering during volume migration URL: https://github.com/apache/cloudstack/pull/2486#issuecomment-375313966 @borisstoyanov are these errors something that I should take a look into? I noticed that the test you included is failing as well. I look at the error of the new test, and it seems you are trying to change the service offering to a new one that does not have the tags of the target storage. `Target Storage [id=0818cecf-5f99-3b1e-beb2-5f0669c7b5ba] tags [storage.overprovisioning.factor] does not match new disk offering [id=a2992784-662b-4cad-b833-38c46136f97e] tags [null].'}, accountid : u'9f16aecc-2c1d-11e8-8460-06d348010705'}\n"]` 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 > Change disk offering when volume is migrated to different type of storage > pool. > --- > > Key: CLOUDSTACK-10323 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10323 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.12 >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > > This is a continuation of work developed on PR #2425 (CLOUDSTACK-10240), > which provided root admins an override mechanism to move volumes between > storage systems types (local/shared) even when the disk offering would not > allow such operation. To complete the work, we will now provide a way for > administrators to enter a new disk offering that can reflect the new > placement of the volume. We will add an extra parameter to allow the root > admin inform a new disk offering for the volume. Therefore, when the volume > is being migrated, it will be possible to replace the disk offering to > reflect the new placement of the volume. > The API method will have the following parameters: > * storageid (required) > * volumeid (required) > * livemigrate(optional) > * newdiskofferingid (optional) – this is the new parameter > The expected behavior is the following: > * If “newdiskofferingid” is not provided the current behavior is maintained. > Override mechanism will also keep working as we have seen so far. > * If the “newdiskofferingid” is provided by the admin, we will execute the > following checks > ** new disk offering mode (local/shared) must match the target storage mode. > If it does not match, an exception will be thrown and the operator will > receive a message indicating the problem. > ** we will check if the new disk offering tags match the target storage tags. > If it does not match, an exception will be thrown and the operator will > receive a message indicating the problem. > ** check if the target storage has the capacity for the new volume. If it > does not have enough space, then an exception is thrown and the operator will > receive a message indicating the problem. > ** check if the size of the volume is the same as the size of the new disk > offering. If it is not the same, we will ALLOW the change of the service > offering, and a warning message will be logged. > We execute the change of the Disk offering as soon as the migration of the > volume finishes. Therefore, if an error happens during the migration and the > volume remains in the original storage system, the disk offering will keep > reflecting this situation -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10332) Users are not able to change/edit the protocol of an ACL rule
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16409545#comment-16409545 ] ASF GitHub Bot commented on CLOUDSTACK-10332: - blueorangutan commented on issue #2496: [CLOUDSTACK-10332] Users are not able to change/edit the protocol of an ACL rule URL: https://github.com/apache/cloudstack/pull/2496#issuecomment-375312530 @rafaelweingartner 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 > Users are not able to change/edit the protocol of an ACL rule > -- > > Key: CLOUDSTACK-10332 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10332 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > Fix For: 4.12 > > > Users should be able to edit an ACL rule completely. Therefore, they must be > able to change the protocol type and others configs of an ACL rules. > Right now users are not able to execute the following. > * Create an ACL for ICMP > * Click on edit and change the protocol to TCP > * An error will happen when saving the rule. > Users should be able to execute the protocol changes without problem. > In addition, it is not just the protocol that users are not able to change. > For instance, after defining ports, or reason/description for the rule, users > are not able to set those values back to null. The same happens for ICMP code > and type. > We will introduce a new parameter called "partialUpdate", which will have its > default value as true to maintain backward compatibility. When this parameter > is set to false, we will consider only the parameters sent, and not the > parameters we already have in the database to change and validate the ACL > rule data. This allows us to update parameters already set back to null, and > to completely change an ACL rule. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10332) Users are not able to change/edit the protocol of an ACL rule
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10332?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16409543#comment-16409543 ] ASF GitHub Bot commented on CLOUDSTACK-10332: - rafaelweingartner commented on issue #2496: [CLOUDSTACK-10332] Users are not able to change/edit the protocol of an ACL rule URL: https://github.com/apache/cloudstack/pull/2496#issuecomment-375312348 @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 > Users are not able to change/edit the protocol of an ACL rule > -- > > Key: CLOUDSTACK-10332 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10332 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > Fix For: 4.12 > > > Users should be able to edit an ACL rule completely. Therefore, they must be > able to change the protocol type and others configs of an ACL rules. > Right now users are not able to execute the following. > * Create an ACL for ICMP > * Click on edit and change the protocol to TCP > * An error will happen when saving the rule. > Users should be able to execute the protocol changes without problem. > In addition, it is not just the protocol that users are not able to change. > For instance, after defining ports, or reason/description for the rule, users > are not able to set those values back to null. The same happens for ICMP code > and type. > We will introduce a new parameter called "partialUpdate", which will have its > default value as true to maintain backward compatibility. When this parameter > is set to false, we will consider only the parameters sent, and not the > parameters we already have in the database to change and validate the ACL > rule data. This allows us to update parameters already set back to null, and > to completely change an ACL rule. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10340) Add setter in vminstancevo
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16409503#comment-16409503 ] ASF GitHub Bot commented on CLOUDSTACK-10340: - nitin-maharana commented on issue #2504: CLOUDSTACK-10340: Add setter to hypervisorType in VMInstanceVO URL: https://github.com/apache/cloudstack/pull/2504#issuecomment-375302496 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 > Add setter in vminstancevo > --- > > Key: CLOUDSTACK-10340 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10340 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: 4.12.0.0, 4.11.1.0 > > > Add setter for: > _VMInstanceVO needs setHypervisorType()_ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10340) Add setter in vminstancevo
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16409496#comment-16409496 ] ASF GitHub Bot commented on CLOUDSTACK-10340: - ustcweizhou commented on issue #2504: CLOUDSTACK-10340: Add setter to hypervisorType in VMInstanceVO URL: https://github.com/apache/cloudstack/pull/2504#issuecomment-375298688 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 > Add setter in vminstancevo > --- > > Key: CLOUDSTACK-10340 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10340 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: 4.12.0.0, 4.11.1.0 > > > Add setter for: > _VMInstanceVO needs setHypervisorType()_ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10333) Secure VM Live migration for KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16409330#comment-16409330 ] ASF GitHub Bot commented on CLOUDSTACK-10333: - blueorangutan commented on issue #2505: CLOUDSTACK-10333: Secure Live VM Migration for KVM URL: https://github.com/apache/cloudstack/pull/2505#issuecomment-375244965 @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 > Secure VM Live migration for KVM > > > Key: CLOUDSTACK-10333 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10333 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: 4.12.0.0, 4.11.1.0 > > > With use of CA framework to secure hosts, the current mechanisms don't secure > libvirtd to use those certificates (used by agent to connect to mgmt server). > This causes insecure vm migration over tcp instead of tls. The aim is to use > the same framework and certificates to secure live VM migration. This could > be coupled with securing of a host and renewal/provisioning of certificates > to host. > > FS: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Secure+Live+VM+Migration+for+KVM -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10333) Secure VM Live migration for KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16409329#comment-16409329 ] ASF GitHub Bot commented on CLOUDSTACK-10333: - rhtyd commented on issue #2505: CLOUDSTACK-10333: Secure Live VM Migration for KVM URL: https://github.com/apache/cloudstack/pull/2505#issuecomment-375244794 @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 > Secure VM Live migration for KVM > > > Key: CLOUDSTACK-10333 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10333 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: 4.12.0.0, 4.11.1.0 > > > With use of CA framework to secure hosts, the current mechanisms don't secure > libvirtd to use those certificates (used by agent to connect to mgmt server). > This causes insecure vm migration over tcp instead of tls. The aim is to use > the same framework and certificates to secure live VM migration. This could > be coupled with securing of a host and renewal/provisioning of certificates > to host. > > FS: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Secure+Live+VM+Migration+for+KVM -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10333) Secure VM Live migration for KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16409315#comment-16409315 ] ASF GitHub Bot commented on CLOUDSTACK-10333: - blueorangutan commented on issue #2505: CLOUDSTACK-10333: Secure Live VM Migration for KVM URL: https://github.com/apache/cloudstack/pull/2505#issuecomment-375242563 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1808 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 > Secure VM Live migration for KVM > > > Key: CLOUDSTACK-10333 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10333 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: 4.12.0.0, 4.11.1.0 > > > With use of CA framework to secure hosts, the current mechanisms don't secure > libvirtd to use those certificates (used by agent to connect to mgmt server). > This causes insecure vm migration over tcp instead of tls. The aim is to use > the same framework and certificates to secure live VM migration. This could > be coupled with securing of a host and renewal/provisioning of certificates > to host. > > FS: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Secure+Live+VM+Migration+for+KVM -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10333) Secure VM Live migration for KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16409292#comment-16409292 ] ASF GitHub Bot commented on CLOUDSTACK-10333: - blueorangutan commented on issue #2505: CLOUDSTACK-10333: Secure Live VM Migration for KVM URL: https://github.com/apache/cloudstack/pull/2505#issuecomment-375234980 @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 > Secure VM Live migration for KVM > > > Key: CLOUDSTACK-10333 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10333 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: 4.12.0.0, 4.11.1.0 > > > With use of CA framework to secure hosts, the current mechanisms don't secure > libvirtd to use those certificates (used by agent to connect to mgmt server). > This causes insecure vm migration over tcp instead of tls. The aim is to use > the same framework and certificates to secure live VM migration. This could > be coupled with securing of a host and renewal/provisioning of certificates > to host. > > FS: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Secure+Live+VM+Migration+for+KVM -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10333) Secure VM Live migration for KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16409290#comment-16409290 ] ASF GitHub Bot commented on CLOUDSTACK-10333: - rhtyd commented on issue #2505: CLOUDSTACK-10333: Secure Live VM Migration for KVM URL: https://github.com/apache/cloudstack/pull/2505#issuecomment-375234673 @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 > Secure VM Live migration for KVM > > > Key: CLOUDSTACK-10333 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10333 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: 4.12.0.0, 4.11.1.0 > > > With use of CA framework to secure hosts, the current mechanisms don't secure > libvirtd to use those certificates (used by agent to connect to mgmt server). > This causes insecure vm migration over tcp instead of tls. The aim is to use > the same framework and certificates to secure live VM migration. This could > be coupled with securing of a host and renewal/provisioning of certificates > to host. > > FS: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Secure+Live+VM+Migration+for+KVM -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10333) Secure VM Live migration for KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16409288#comment-16409288 ] ASF GitHub Bot commented on CLOUDSTACK-10333: - blueorangutan commented on issue #2505: CLOUDSTACK-10333: Secure Live VM Migration for KVM URL: https://github.com/apache/cloudstack/pull/2505#issuecomment-375225865 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1807 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 > Secure VM Live migration for KVM > > > Key: CLOUDSTACK-10333 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10333 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: 4.12.0.0, 4.11.1.0 > > > With use of CA framework to secure hosts, the current mechanisms don't secure > libvirtd to use those certificates (used by agent to connect to mgmt server). > This causes insecure vm migration over tcp instead of tls. The aim is to use > the same framework and certificates to secure live VM migration. This could > be coupled with securing of a host and renewal/provisioning of certificates > to host. > > FS: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Secure+Live+VM+Migration+for+KVM -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10333) Secure VM Live migration for KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16409289#comment-16409289 ] ASF GitHub Bot commented on CLOUDSTACK-10333: - blueorangutan commented on issue #2505: CLOUDSTACK-10333: Secure Live VM Migration for KVM URL: https://github.com/apache/cloudstack/pull/2505#issuecomment-375218363 @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 > Secure VM Live migration for KVM > > > Key: CLOUDSTACK-10333 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10333 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: 4.12.0.0, 4.11.1.0 > > > With use of CA framework to secure hosts, the current mechanisms don't secure > libvirtd to use those certificates (used by agent to connect to mgmt server). > This causes insecure vm migration over tcp instead of tls. The aim is to use > the same framework and certificates to secure live VM migration. This could > be coupled with securing of a host and renewal/provisioning of certificates > to host. > > FS: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Secure+Live+VM+Migration+for+KVM -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10333) Secure VM Live migration for KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16409252#comment-16409252 ] ASF GitHub Bot commented on CLOUDSTACK-10333: - blueorangutan commented on issue #2505: CLOUDSTACK-10333: Secure Live VM Migration for KVM URL: https://github.com/apache/cloudstack/pull/2505#issuecomment-375225865 Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1807 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 > Secure VM Live migration for KVM > > > Key: CLOUDSTACK-10333 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10333 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: 4.12.0.0, 4.11.1.0 > > > With use of CA framework to secure hosts, the current mechanisms don't secure > libvirtd to use those certificates (used by agent to connect to mgmt server). > This causes insecure vm migration over tcp instead of tls. The aim is to use > the same framework and certificates to secure live VM migration. This could > be coupled with securing of a host and renewal/provisioning of certificates > to host. > > FS: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Secure+Live+VM+Migration+for+KVM -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10333) Secure VM Live migration for KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16409218#comment-16409218 ] ASF GitHub Bot commented on CLOUDSTACK-10333: - blueorangutan commented on issue #2505: CLOUDSTACK-10333: Secure Live VM Migration for KVM URL: https://github.com/apache/cloudstack/pull/2505#issuecomment-375218363 @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 > Secure VM Live migration for KVM > > > Key: CLOUDSTACK-10333 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10333 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: 4.12.0.0, 4.11.1.0 > > > With use of CA framework to secure hosts, the current mechanisms don't secure > libvirtd to use those certificates (used by agent to connect to mgmt server). > This causes insecure vm migration over tcp instead of tls. The aim is to use > the same framework and certificates to secure live VM migration. This could > be coupled with securing of a host and renewal/provisioning of certificates > to host. > > FS: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Secure+Live+VM+Migration+for+KVM -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10333) Secure VM Live migration for KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10333?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16409217#comment-16409217 ] ASF GitHub Bot commented on CLOUDSTACK-10333: - rhtyd opened a new pull request #2505: CLOUDSTACK-10333: Secure Live VM Migration for KVM URL: https://github.com/apache/cloudstack/pull/2505 ## Description This extends securing of KVM hosts to securing of libvirt on KVM host as well for TLS enabled live VM migration. To simplify implementation securing of host implies that both host and libvirtd processes are secured with management server's CA plugin issued certificates. FS: https://cwiki.apache.org/confluence/display/CLOUDSTACK/Secure+Live+VM+Migration+for+KVM Based on whether keystore and certificates files are available at /etc/cloudstack/agent, the KVM agent determines whether to use TLS or TCP based uris for live VM migration. It is also enforced that a secured host will allow live VM migration to/from other secured host, and an unsecured hosts will allow live VM migration to/from other unsecured host only. Post upgrade the KVM agent on startup will expose its security state (secured detail is sent as true or false) to the managements server that gets saved in host_details for the host. This host detail can be accesed via the listHosts response, and in the UI unsecured KVM hosts will show up with the host state of ‘unsecured’. Further, a button has been added that allows admins to provision/renew certificates to KVM hosts and can be used to secure any unsecured KVM host. The `cloudstack-setup-agent` was modified to accept a new flag `-s` which will reconfigure libvirtd with following settings: listen_tcp=0 listen_tls=1 tcp_port="16509" tls_port="16514" auth_tcp="none" auth_tls="none" key_file = "/etc/pki/libvirt/private/serverkey.pem" cert_file = "/etc/pki/libvirt/servercert.pem" ca_file = "/etc/pki/CA/cacert.pem" For a connected KVM host agent, when the certificate are renewed/provisioned a background task is scheduled that waits until all of the agent tasks finish after which libvirt process is restarted and finally the agent is restarted via AgentShell. There are no API or DB changes. ## Types of changes - [ ] Breaking change (fix or feature that would cause existing functionality to change) - [ ] New feature (non-breaking change which adds functionality) - [ ] Bug fix (non-breaking change which fixes an issue) - [ ] Enhancement (improves an existing feature and functionality) - [ ] Cleanup (Code refactoring and cleanup, that may add test cases) ## Screenshots (if appropriate): Unsecured KVM hosts when are Up and connected show up as:  Button to secure host, or renew/provision certificate using configured CA plugin;   Error message when VM migration is between secured and unsecured hosts:  ## How Has This Been Tested? - Tested between a pre-upgraded secured KVM host (el7 based) and post-upgrade it secures libvirtd using same certificates. - Tested tls enabled live vm migration between two secured and unsecured el7 kvm hosts. ## Checklist: - [ ] I have read the [CONTRIBUTING](https://github.com/apache/cloudstack/blob/master/CONTRIBUTING.md) document. - [ ] My code follows the code style of this project. - [ ] My change requires a change to the documentation. - [ ] I have updated the documentation accordingly. - [ ] I have added tests to cover my changes. - [ ] All new and existing tests passed. @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 > Secure VM Live migration for KVM > > > Key: CLOUDSTACK-10333 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10333 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can vie
[jira] [Commented] (CLOUDSTACK-10340) Add setter in vminstancevo
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16409210#comment-16409210 ] ASF GitHub Bot commented on CLOUDSTACK-10340: - blueorangutan commented on issue #2504: CLOUDSTACK-10340: Add setter to hypervisorType in VMInstanceVO URL: https://github.com/apache/cloudstack/pull/2504#issuecomment-375215756 @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 > Add setter in vminstancevo > --- > > Key: CLOUDSTACK-10340 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10340 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: 4.12.0.0, 4.11.1.0 > > > Add setter for: > _VMInstanceVO needs setHypervisorType()_ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10340) Add setter in vminstancevo
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10340?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16409209#comment-16409209 ] ASF GitHub Bot commented on CLOUDSTACK-10340: - rhtyd commented on issue #2504: CLOUDSTACK-10340: Add setter to hypervisorType in VMInstanceVO URL: https://github.com/apache/cloudstack/pull/2504#issuecomment-375215615 @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 > Add setter in vminstancevo > --- > > Key: CLOUDSTACK-10340 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10340 > Project: CloudStack > Issue Type: Task > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: 4.12.0.0, 4.11.1.0 > > > Add setter for: > _VMInstanceVO needs setHypervisorType()_ -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Updated] (CLOUDSTACK-10333) Secure VM Live migration for KVM
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10333?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rohit Yadav updated CLOUDSTACK-10333: - Status: Reviewable (was: In Progress) > Secure VM Live migration for KVM > > > Key: CLOUDSTACK-10333 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10333 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: 4.12.0.0, 4.11.1.0 > > > With use of CA framework to secure hosts, the current mechanisms don't secure > libvirtd to use those certificates (used by agent to connect to mgmt server). > This causes insecure vm migration over tcp instead of tls. The aim is to use > the same framework and certificates to secure live VM migration. This could > be coupled with securing of a host and renewal/provisioning of certificates > to host. > > FS: > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Secure+Live+VM+Migration+for+KVM -- This message was sent by Atlassian JIRA (v7.6.3#76005)
