[jira] [Commented] (CLOUDSTACK-10284) Creating a snapshot from VM Snapshot generates error if hypervisor is not KVM.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373896#comment-16373896 ] ASF GitHub Bot commented on CLOUDSTACK-10284: - niteshsarda commented on issue #2451: CLOUDSTACK-10284:Creating a snapshot from VM Snapshot generates error if hypervisor is not KVM. URL: https://github.com/apache/cloudstack/pull/2451#issuecomment-367904712 @rhtyd @rafaelweingartner : As there are issues in rebasing against 4.11, I am fine if we put it in master and make this fix available in next release. 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 > Creating a snapshot from VM Snapshot generates error if hypervisor is not KVM. > -- > > Key: CLOUDSTACK-10284 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10284 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitesh Sarda >Priority: Major > > ISSUE > Creating a snapshot from VM Snapshot generates error if hypervisor is not KVM. > STEPS TO REPRODUCE > * Create a cloudstack setup with hypervisor other than KVM. > * Create an instance. > * Take Snapshot of that VM. > * Try to take volume snapshot from newly created VM snapshot. > * It will throw an error as hypervisor is not KVM. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Resolved] (CLOUDSTACK-10293) Single view network ACL rules listing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10293?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Rafael Weingärtner resolved CLOUDSTACK-10293. - Resolution: Fixed > Single view network ACL rules listing > - > > Key: CLOUDSTACK-10293 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10293 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > Fix For: 4.12 > > > The ACL rules editing/addition page is not user-friendly. Users are not able > to see in a single view all of the detail of the ACL rule (they need to use a > scroll bar on the horizontal). The problem becomes worse when there are a > considerable number of rules. Therefore, we are proposing the following > changes: > # Instead of using the table to create new ACL, we can create a button like > the one presented in attached pictures, where users can click, and then a > modal popup would appear and users would be able to create the new ACL there. > This is similar to the workings of the ACL edit button. > # Remove the ability to add new ACL via table where they are presented. All > ACLs should be entered via the “New ACL” button. Therefore, the section “Add > ACL” would be removed as well; > # Move the action section of the list ACL table to the most left position; > > These changes would reduce the information in the table and facilitate users > to add new rules and easily edit them as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10283) Use sudo to execute keystore setup/import for kvm agents, and fail on keystore setup failures
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373663#comment-16373663 ] ASF GitHub Bot commented on CLOUDSTACK-10283: - blueorangutan commented on issue #2454: CLOUDSTACK-10283: Sudo to setup agent keystore, fail on host add failure URL: https://github.com/apache/cloudstack/pull/2454#issuecomment-367856506 Packaging result: ✔centos6 ✖centos7 ✔debian. JID-1731 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 > Use sudo to execute keystore setup/import for kvm agents, and fail on > keystore setup failures > - > > Key: CLOUDSTACK-10283 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10283 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: 4.12.0.0, 4.11.1.0 > > > Addition of a KVM host creates keystore on the KVM host's > /etc/cloudstack/agent path. The current scripts and codebase assumes that it > will be the root user which is why the script don't call keytool with 'sudo'. > To allow addition of host using a sudo-enabled/admin user, make suitable > changes to the script, and also fail the addHost execution if keystore > scripts fail (say due to permission issues etc). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10039) Adding IOPS/GB offering
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10039?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373659#comment-16373659 ] ASF GitHub Bot commented on CLOUDSTACK-10039: - rafaelweingartner commented on issue #2231: [CLOUDSTACK-10039] Adding IOPS/GB offering URL: https://github.com/apache/cloudstack/pull/2231#issuecomment-367855144 Ping @syed 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 > Adding IOPS/GB offering > --- > > Key: CLOUDSTACK-10039 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10039 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Storage Controller >Reporter: Syed Ahmed >Priority: Major > Fix For: Future > > > We want to add a disk offering where we can specify the Min/Max IOPS as a > function of size. The idea is the larger volume you create, the greater your > IOPS will be (this is similar to the way GCE handles IOPS). We also have > added limits to the IOPS (min and max) so that once the volume goes beyond a > certain size, the IOPS won't change and are capped to the given values. > The following parameters are added to the `createDiskOffering` API: > 1. `miniopspergb' : Minimum IOPS/GB for the offering > 2. `maxiopspergb`: Maximum IOPS/GB for the offering > 3. `highestminiops`: The highest `miniops` value that is allowed for this > offering > 3. `highestmaxiops`: The highest `maxiops` value that is allowed for this > offering -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10087) Template registration errors out when template URL is https
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373656#comment-16373656
]
ASF GitHub Bot commented on CLOUDSTACK-10087:
-
rafaelweingartner commented on issue #2271: CLOUDSTACK-10087 Template
registration errors out when template URL i…
URL: https://github.com/apache/cloudstack/pull/2271#issuecomment-367854738
Ping @SudharmaJain
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
> Template registration errors out when template URL is https
> ---
>
> Key: CLOUDSTACK-10087
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10087
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: sudharma jain
>Priority: Major
>
> *Management server logs:*
> 2017-08-23 08:55:36,706 DEBUG [c.c.a.t.Request] (AgentManager-Handler-5:null)
> (logid:) Seq 4-7842174326135586819: Processing: { Ans: , MgmtId: 4278190080,
> via: 4, Ver: v1, Flags: 110,
> [{"com.cloud.agent.api.Answer":{"result":false,"details":"com.amazonaws.SdkClientException:
> Unable to execute HTTP request: sun.security.validator.ValidatorException:
> PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target\n\tat
> com.amazonaws.http.AmazonHttpClient$RequestExecutor.executeHelper(AmazonHttpClient.java:972)\n\tat
>
> com.amazonaws.http.AmazonHttpClient$RequestExecutor.doExecute(AmazonHttpClient.java:676)\n\tat
>
> com.amazonaws.http.AmazonHttpClient$RequestExecutor.executeWithTimer(AmazonHttpClient.java:650)\n\tat
>
> com.amazonaws.http.AmazonHttpClient$RequestExecutor.execute(AmazonHttpClient.java:633)\n\tat
>
> com.amazonaws.http.AmazonHttpClient$RequestExecutor.access$300(AmazonHttpClient.java:601)\n\tat
>
> com.amazonaws.http.AmazonHttpClient$RequestExecutionBuilderImpl.execute(AmazonHttpClient.java:583)\n\tat
> com.amazonaws.http.AmazonHttpClient.execute(AmazonHttpClient.java:447)\n\tat
> com.amazonaws.services.s3.AmazonS3Client.invoke(AmazonS3Client.java:4137)\n\tat
>
> com.amazonaws.services.s3.AmazonS3Client.getBucketRegionViaHeadRequest(AmazonS3Client.java:4856)\n\tat
>
> com.amazonaws.services.s3.AmazonS3Client.fetchRegionFromCache(AmazonS3Client.java:4830)\n\tat
>
> com.amazonaws.services.s3.AmazonS3Client.invoke(AmazonS3Client.java:4122)\n\tat
>
> com.amazonaws.services.s3.AmazonS3Client.invoke(AmazonS3Client.java:4079)\n\tat
>
> com.amazonaws.services.s3.AmazonS3Client.listObjects(AmazonS3Client.java:819)\n\tat
> com.cloud.utils.storage.S3.S3Utils.listDirectory(S3Utils.java:179)\n\tat
> org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.s3ListVolume(NfsSecondaryStorageResource.java:1667)\n\tat
>
> org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.execute(NfsSecondaryStorageResource.java:1721)\n\tat
>
> org.apache.cloudstack.storage.resource.NfsSecondaryStorageResource.executeRequest(NfsSecondaryStorageResource.java:277)\n\tat
>
> com.cloud.storage.resource.PremiumSecondaryStorageResource.defaultAction(PremiumSecondaryStorageResource.java:64)\n\tat
>
> com.cloud.storage.resource.PremiumSecondaryStorageResource.executeRequest(PremiumSecondaryStorageResource.java:60)\n\tat
> com.cloud.agent.Agent.processRequest(Agent.java:525)\n\tat
> com.cloud.agent.Agent$AgentRequestHandler.doTask(Agent.java:833)\n\tat
> com.cloud.utils.nio.Task.call(Task.java:83)\n\tat
> com.cloud.utils.nio.Task.call(Task.java:29)\n\tat
> java.util.concurrent.FutureTask.run(FutureTask.java:266)\n\tat
> java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1142)\n\tat
>
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:617)\n\tat
> java.lang.Thread.run(Thread.java:745)\nCaused by:
> javax.net.ssl.SSLHandshakeException:
> sun.security.validator.ValidatorException: PKIX path building failed:
> sun.security.provider.certpath.SunCertPathBuilderException: unable to find
> valid certification path to requested target\n\tat
> sun.security.ssl.Alerts.getSSLException(Alerts.java:192)\n\tat
> sun.security.ssl.SSLSocketImpl.fatal(SSLSocketImpl.java:1949)\n\tat
> sun.security.ssl.Handshaker.fatalSE(Handshaker.java:302)\n\tat
> sun.security.ssl.Handshaker.fatalSE(Handshaker.java:296)\n\tat
> sun.security.ssl.ClientHandshaker.serverCertificate(ClientHandshaker.java:1509)\n\tat
>
> sun.security.ssl.ClientHandshaker.processMessage(Cli
[jira] [Commented] (CLOUDSTACK-10054) Volume download times out in 3600 seconds
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10054?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373654#comment-16373654 ] ASF GitHub Bot commented on CLOUDSTACK-10054: - rafaelweingartner commented on issue #2244: CLOUDSTACK-10054:Volume download times out in 3600 seconds URL: https://github.com/apache/cloudstack/pull/2244#issuecomment-367854564 @DaanHoogland and @rhtyd what are your stances 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 > Volume download times out in 3600 seconds > - > > Key: CLOUDSTACK-10054 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10054 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: mrunalini >Priority: Major > > Problem Statement - > When tried to download a volume of type Vmware with large size, it fails in > an hour before generating the URL. > It can be seen in the ssvm logs that ova generation tar command fails/timed > out in an hour. The volume is of 800GB and we should be able to increase the > timeout. Unfortunately there is not method to do that. There is no global > parameter to update the timeout for this operation. > Solution > Add a global parameter 'vmware.backup.session.timeout' for all the tar > commands(commands taking long time) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-9975) Allow customizing system VM templates for SSVM and Console Proxy
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373650#comment-16373650 ] ASF GitHub Bot commented on CLOUDSTACK-9975: rafaelweingartner commented on issue #2275: CLOUDSTACK-9975: Allow customizing system VM templates for SSVM and Console Proxy URL: https://github.com/apache/cloudstack/pull/2275#issuecomment-367854135 @GabrielBrascher can you rebase and fix conflicts? 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 > Allow customizing system VM templates for SSVM and Console Proxy > > > Key: CLOUDSTACK-9975 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9975 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Gabriel Beims Bräscher >Assignee: Gabriel Beims Bräscher >Priority: Minor > > Currently, it is only possible to change the template used by virtual > routers, but other system VMs do not have the same feature. The virtual > router template is configured according to the respective global settings > parameters: router.template.hyperv, router.template.kvm, router.template.lxc, > router.template.xenserver, router.template.ovm, router.template.vmware. > This ticket proposes the configuration of templates for storage system VMs > (SSVMs) and console proxy system VMs with parameters similar with the virtual > router template configuration: ssvm.template. and > consoleproxy.template. > If a parameter is null then it keeps the current flow for that scenario > (systemvm/virtualization tool). > This proposal allows users to customize virtual machines templates according > to specific needs of each system VM. This feature was useful in a practical > scenario where it was necessary to perform some changes for the console proxy > system VM template. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-8900) listLdapUsers with listType=new only filters users for logged-in user account
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8900?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373647#comment-16373647 ] ASF GitHub Bot commented on CLOUDSTACK-8900: rafaelweingartner commented on issue #2400: CLOUDSTACK-8900 listLdapUsers with listType=new only filters users for logged-in user account URL: https://github.com/apache/cloudstack/pull/2400#issuecomment-367853649 Ping @SudharmaJain 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 > listLdapUsers with listType=new only filters users for logged-in user account > - > > Key: CLOUDSTACK-8900 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8900 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.5.0 >Reporter: sudharma jain >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-9677) Swift Storage Policy support for Secondary Storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9677?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373643#comment-16373643 ] ASF GitHub Bot commented on CLOUDSTACK-9677: rafaelweingartner commented on issue #2412: CLOUDSTACK-9677: Adding storage policy support for swift as secondary… URL: https://github.com/apache/cloudstack/pull/2412#issuecomment-367853242 @khos2ow can you provide some inputs regarding @rhtyd inquiry? This one is ready to go. 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 > Swift Storage Policy support for Secondary Storage > -- > > Key: CLOUDSTACK-9677 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9677 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Patrick D. >Assignee: Patrick D. >Priority: Major > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10254) Require checkstyle to verify package names against directory structure
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373639#comment-16373639 ] ASF GitHub Bot commented on CLOUDSTACK-10254: - rafaelweingartner commented on issue #2422: [CLOUDSTACK-10254] checkstyle: add package name declaration validation URL: https://github.com/apache/cloudstack/pull/2422#issuecomment-367852939 Ok, no problem. Can you look into travis errors? 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 > Require checkstyle to verify package names against directory structure > -- > > Key: CLOUDSTACK-10254 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10254 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Marc-Aurèle Brothier >Assignee: Marc-Aurèle Brothier >Priority: Major > > Enforce a new rule for checkstyle to verify that the java file location and > its package name match. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10253) JSON response returns boolean as string
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10253?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373637#comment-16373637
]
ASF GitHub Bot commented on CLOUDSTACK-10253:
-
rafaelweingartner commented on issue #2428: CLOUDSTACK-10253: JSON response for
SuccessResponse as boolean instead of string
URL: https://github.com/apache/cloudstack/pull/2428#issuecomment-367852746
@marcaurele there are some tests using an assert with a string `'true'`, and
not a Boolean.
Can you fix them?
```
"/home/travis/build/apache/cloudstack/test/integration/smoke/test_hostha_simulator.py",
line 164, in configureSimulatorHAProviderState
self.assertEqual(response.success, 'true')
```
There are others, but that is only one example.
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
> JSON response returns boolean as string
> ---
>
> Key: CLOUDSTACK-10253
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10253
> 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: Minor
>
> On the SuccessResponse for async call, the boolean value is returned as a
> quoted boolean string:
> {noformat}
> {"success": "true"}{noformat}
> instead of a JSON boolean:
> {noformat}
> {"success": true{noformat}
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10268) Fix and enhance package script
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10268?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373633#comment-16373633 ] ASF GitHub Bot commented on CLOUDSTACK-10268: - rafaelweingartner commented on issue #2433: CLOUDSTACK-10268: Fix and enhance package script URL: https://github.com/apache/cloudstack/pull/2433#issuecomment-367851868 @rhtyd what is your stance 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 > Fix and enhance package script > -- > > Key: CLOUDSTACK-10268 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10268 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Reporter: Khosrow Moossavi >Priority: Minor > Fix For: 4.12 > > > * new flag `-T, --use-timestamp` to use `timestamp` when POM version contains > SNAPSHOT > ** in the final artifacts (jar) name > ** in the final package (rpm, deb) name > ** in `/etc/cloudstack-release` file of SystemVMs > ** in the Management Server > About dialog > * if there's a "branding" string in the POM version (e.g. > `x.y.z.a-NAME[-SNAPSHOT]`), the branding name will be used in the final > generated pacakge name such as following: > ** `cloudstack-management-x.y.z.a-NAME.NUMBER.el7.centos.x86_64` > ** `cloudstack-management_x.y.z.a-NAME-NUMBER~xenial_all.deb` > * branding string can be overriden with newly added `-b, --brand` flag > * handle the new format version for VR version > * fix long opts (they were broken) > * tolerate and show a warning message for unrecognized flags > * usage help reformat -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10283) Use sudo to execute keystore setup/import for kvm agents, and fail on keystore setup failures
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373613#comment-16373613 ] ASF subversion and git services commented on CLOUDSTACK-10283: -- Commit f1cf5f97e97558194a813119876f56bd55d0ff2a in cloudstack's branch refs/heads/4.11 from [~rohit.ya...@shapeblue.com] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=f1cf5f9 ] CLOUDSTACK-10283: Sudo to setup agent keystore, fail on host add failure This would make keystore utility scripts being executed as sudoer in case the process uid/owner is not root but still a sudoer user. Also fails addHost while securing a KVM host and if keystore fails to be setup for any reason. Signed-off-by: Rohit Yadav > Use sudo to execute keystore setup/import for kvm agents, and fail on > keystore setup failures > - > > Key: CLOUDSTACK-10283 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10283 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: 4.12.0.0, 4.11.1.0 > > > Addition of a KVM host creates keystore on the KVM host's > /etc/cloudstack/agent path. The current scripts and codebase assumes that it > will be the root user which is why the script don't call keytool with 'sudo'. > To allow addition of host using a sudo-enabled/admin user, make suitable > changes to the script, and also fail the addHost execution if keystore > scripts fail (say due to permission issues etc). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10283) Use sudo to execute keystore setup/import for kvm agents, and fail on keystore setup failures
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373615#comment-16373615 ] ASF GitHub Bot commented on CLOUDSTACK-10283: - blueorangutan commented on issue #2454: CLOUDSTACK-10283: Sudo to setup agent keystore, fail on host add failure URL: https://github.com/apache/cloudstack/pull/2454#issuecomment-367848555 @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 > Use sudo to execute keystore setup/import for kvm agents, and fail on > keystore setup failures > - > > Key: CLOUDSTACK-10283 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10283 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: 4.12.0.0, 4.11.1.0 > > > Addition of a KVM host creates keystore on the KVM host's > /etc/cloudstack/agent path. The current scripts and codebase assumes that it > will be the root user which is why the script don't call keytool with 'sudo'. > To allow addition of host using a sudo-enabled/admin user, make suitable > changes to the script, and also fail the addHost execution if keystore > scripts fail (say due to permission issues etc). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10283) Use sudo to execute keystore setup/import for kvm agents, and fail on keystore setup failures
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373610#comment-16373610 ] ASF GitHub Bot commented on CLOUDSTACK-10283: - rafaelweingartner commented on issue #2454: CLOUDSTACK-10283: Sudo to setup agent keystore, fail on host add failure URL: https://github.com/apache/cloudstack/pull/2454#issuecomment-367848375 Tests and reviews are ok. I will merge this one then. 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 > Use sudo to execute keystore setup/import for kvm agents, and fail on > keystore setup failures > - > > Key: CLOUDSTACK-10283 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10283 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: 4.12.0.0, 4.11.1.0 > > > Addition of a KVM host creates keystore on the KVM host's > /etc/cloudstack/agent path. The current scripts and codebase assumes that it > will be the root user which is why the script don't call keytool with 'sudo'. > To allow addition of host using a sudo-enabled/admin user, make suitable > changes to the script, and also fail the addHost execution if keystore > scripts fail (say due to permission issues etc). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10283) Use sudo to execute keystore setup/import for kvm agents, and fail on keystore setup failures
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373612#comment-16373612
]
ASF GitHub Bot commented on CLOUDSTACK-10283:
-
rafaelweingartner closed pull request #2454: CLOUDSTACK-10283: Sudo to setup
agent keystore, fail on host add failure
URL: https://github.com/apache/cloudstack/pull/2454
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/agent/src/com/cloud/agent/Agent.java
b/agent/src/com/cloud/agent/Agent.java
index d2669c03aeb..1c5417bf767 100644
--- a/agent/src/com/cloud/agent/Agent.java
+++ b/agent/src/com/cloud/agent/Agent.java
@@ -647,7 +647,7 @@ public Answer setupAgentKeystore(final SetupKeyStoreCommand
cmd) {
_shell.setPersistentProperty(null,
KeyStoreUtils.passphrasePropertyName, storedPassword);
}
-Script script = new Script(_keystoreSetupPath, 6, s_logger);
+Script script = new Script(true, _keystoreSetupPath, 6, s_logger);
script.add(agentFile.getAbsolutePath());
script.add(keyStoreFile);
script.add(storedPassword);
@@ -691,7 +691,7 @@ private Answer setupAgentCertificate(final
SetupCertificateCommand cmd) {
throw new CloudRuntimeException("Unable to save received agent
client and ca certificates", e);
}
-Script script = new Script(_keystoreCertImportPath, 6, s_logger);
+Script script = new Script(true, _keystoreCertImportPath, 6,
s_logger);
script.add(agentFile.getAbsolutePath());
script.add(keyStoreFile);
script.add(KeyStoreUtils.agentMode);
diff --git
a/server/src/com/cloud/hypervisor/kvm/discoverer/LibvirtServerDiscoverer.java
b/server/src/com/cloud/hypervisor/kvm/discoverer/LibvirtServerDiscoverer.java
index 63a44b83518..c1afc9a6f88 100644
---
a/server/src/com/cloud/hypervisor/kvm/discoverer/LibvirtServerDiscoverer.java
+++
b/server/src/com/cloud/hypervisor/kvm/discoverer/LibvirtServerDiscoverer.java
@@ -62,6 +62,7 @@
import com.cloud.resource.UnableDeleteHostException;
import com.cloud.utils.PasswordGenerator;
import com.cloud.utils.StringUtils;
+import com.cloud.utils.exception.CloudRuntimeException;
import com.cloud.utils.ssh.SSHCmdHelper;
import com.trilead.ssh2.Connection;
@@ -144,8 +145,7 @@ private void setupAgentSecurity(final Connection
sshConnection, final String age
}
if (sshConnection == null) {
-s_logger.warn("Cannot secure agent communication because ssh
connection is invalid for host ip=" + agentIp);
-return;
+throw new CloudRuntimeException("Cannot secure agent communication
because ssh connection is invalid for host ip=" + agentIp);
}
Integer validityPeriod = CAManager.CertValidityPeriod.value();
@@ -154,7 +154,7 @@ private void setupAgentSecurity(final Connection
sshConnection, final String age
}
final SSHCmdHelper.SSHCmdResult keystoreSetupResult =
SSHCmdHelper.sshExecuteCmdWithResult(sshConnection,
-String.format("/usr/share/cloudstack-common/scripts/util/%s " +
+String.format("sudo
/usr/share/cloudstack-common/scripts/util/%s " +
"/etc/cloudstack/agent/agent.properties " +
"/etc/cloudstack/agent/%s " +
"%s %d " +
@@ -166,19 +166,17 @@ private void setupAgentSecurity(final Connection
sshConnection, final String age
KeyStoreUtils.defaultCsrFile));
if (!keystoreSetupResult.isSuccess()) {
-s_logger.error("Failing, the keystore setup script failed
execution on the KVM host: " + agentIp);
-return;
+throw new CloudRuntimeException("Failed to setup keystore on the
KVM host: " + agentIp);
}
final Certificate certificate =
caManager.issueCertificate(keystoreSetupResult.getStdOut(),
Collections.singletonList(agentHostname), Collections.singletonList(agentIp),
null, null);
if (certificate == null || certificate.getClientCertificate() == null)
{
-s_logger.error("Failing, the configured CA plugin failed to issue
certificates for KVM host agent: " + agentIp);
-return;
+throw new CloudRuntimeException("Failed to issue certificates for
KVM host agent: " + agentIp);
}
final SetupCertificateCommand certificateCommand = new
SetupCertificateCommand(certificate);
final SSHCmdHelper.SSHCmdResult setupCertResult =
SSHCmdHelper.sshExecuteCmdWithResult(sshConnection,
-
String.format("/usr/share/cloudstack-common/scripts
[jira] [Commented] (CLOUDSTACK-10283) Use sudo to execute keystore setup/import for kvm agents, and fail on keystore setup failures
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10283?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373614#comment-16373614 ] ASF subversion and git services commented on CLOUDSTACK-10283: -- Commit cae32925608815f7defa76621ed9c6a23fab1cef in cloudstack's branch refs/heads/4.11 from [~rafaelweingartner] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=cae3292 ] Merge pull request #2454 from shapeblue/keystore-utils-sudoer CLOUDSTACK-10283: Sudo to setup agent keystore, fail on host add failure > Use sudo to execute keystore setup/import for kvm agents, and fail on > keystore setup failures > - > > Key: CLOUDSTACK-10283 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10283 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rohit Yadav >Assignee: Rohit Yadav >Priority: Major > Fix For: 4.12.0.0, 4.11.1.0 > > > Addition of a KVM host creates keystore on the KVM host's > /etc/cloudstack/agent path. The current scripts and codebase assumes that it > will be the root user which is why the script don't call keytool with 'sudo'. > To allow addition of host using a sudo-enabled/admin user, make suitable > changes to the script, and also fail the addHost execution if keystore > scripts fail (say due to permission issues etc). -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10295) Marvin: add support for password-enabled templates
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373600#comment-16373600 ] ASF GitHub Bot commented on CLOUDSTACK-10295: - rafaelweingartner commented on issue #2457: CLOUDSTACK-10295 Marvin: add support for password-enabled templates URL: https://github.com/apache/cloudstack/pull/2457#issuecomment-367847724 The tests that failed do not seem to be related to changes introduced here. So, the PR has integration tests, Marvin and reviews. I will merge it then. 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 > Marvin: add support for password-enabled templates > -- > > Key: CLOUDSTACK-10295 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10295 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: marvin >Reporter: Dmytro Shevchenko >Priority: Major > Labels: marvin, password > > Currently when new VM created, password property always set to 'password' > even if it was auto-generated. Because of this impossible establish SSH > connection to host during testing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10295) Marvin: add support for password-enabled templates
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373603#comment-16373603 ] ASF subversion and git services commented on CLOUDSTACK-10295: -- Commit 06c2948c65512e52eee26c37ee7d0650f558b658 in cloudstack's branch refs/heads/master from [~rafaelweingartner] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=06c2948 ] Merge pull request #2457 from HiagData/CLOUDSTACK-10295 CLOUDSTACK-10295 Marvin: add support for password-enabled templates > Marvin: add support for password-enabled templates > -- > > Key: CLOUDSTACK-10295 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10295 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: marvin >Reporter: Dmytro Shevchenko >Priority: Major > Labels: marvin, password > > Currently when new VM created, password property always set to 'password' > even if it was auto-generated. Because of this impossible establish SSH > connection to host during testing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10295) Marvin: add support for password-enabled templates
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373602#comment-16373602 ] ASF subversion and git services commented on CLOUDSTACK-10295: -- Commit eeba3e4853cfefeddb98da515a685a0713de9b68 in cloudstack's branch refs/heads/master from [~Demonsh] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=eeba3e4 ] CLOUDSTACK-10295 Marvin: add support for password-enabled templates > Marvin: add support for password-enabled templates > -- > > Key: CLOUDSTACK-10295 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10295 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: marvin >Reporter: Dmytro Shevchenko >Priority: Major > Labels: marvin, password > > Currently when new VM created, password property always set to 'password' > even if it was auto-generated. Because of this impossible establish SSH > connection to host during testing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10295) Marvin: add support for password-enabled templates
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373604#comment-16373604 ] ASF subversion and git services commented on CLOUDSTACK-10295: -- Commit 06c2948c65512e52eee26c37ee7d0650f558b658 in cloudstack's branch refs/heads/master from [~rafaelweingartner] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=06c2948 ] Merge pull request #2457 from HiagData/CLOUDSTACK-10295 CLOUDSTACK-10295 Marvin: add support for password-enabled templates > Marvin: add support for password-enabled templates > -- > > Key: CLOUDSTACK-10295 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10295 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: marvin >Reporter: Dmytro Shevchenko >Priority: Major > Labels: marvin, password > > Currently when new VM created, password property always set to 'password' > even if it was auto-generated. Because of this impossible establish SSH > connection to host during testing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10295) Marvin: add support for password-enabled templates
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373601#comment-16373601 ] ASF GitHub Bot commented on CLOUDSTACK-10295: - rafaelweingartner closed pull request #2457: CLOUDSTACK-10295 Marvin: add support for password-enabled templates URL: https://github.com/apache/cloudstack/pull/2457 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/tools/marvin/marvin/lib/base.py b/tools/marvin/marvin/lib/base.py index 23621991cc2..e0253896271 100755 --- a/tools/marvin/marvin/lib/base.py +++ b/tools/marvin/marvin/lib/base.py @@ -593,6 +593,10 @@ def create(cls, apiclient, services, templateid=None, accountid=None, virtual_machine = apiclient.deployVirtualMachine(cmd, method=method) +if 'password' in virtual_machine.__dict__.keys(): +if virtual_machine.password: +services['password'] = virtual_machine.password + virtual_machine.ssh_ip = virtual_machine.nic[0].ipaddress if startvm is False: virtual_machine.public_ip = virtual_machine.nic[0].ipaddress 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 > Marvin: add support for password-enabled templates > -- > > Key: CLOUDSTACK-10295 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10295 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: marvin >Reporter: Dmytro Shevchenko >Priority: Major > Labels: marvin, password > > Currently when new VM created, password property always set to 'password' > even if it was auto-generated. Because of this impossible establish SSH > connection to host during testing. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10293) Single view network ACL rules listing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373594#comment-16373594 ] ASF subversion and git services commented on CLOUDSTACK-10293: -- Commit e9da30b24e8d4df4b22451488e459361435da80c in cloudstack's branch refs/heads/master from [~rafaelweingartner] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=e9da30b ] Merge pull request #2456 from rafaelweingartner/CLOUDSTACK-10293 [CLOUDSTACK-10293] Single view network ACL rules listing > Single view network ACL rules listing > - > > Key: CLOUDSTACK-10293 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10293 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > Fix For: 4.12 > > > The ACL rules editing/addition page is not user-friendly. Users are not able > to see in a single view all of the detail of the ACL rule (they need to use a > scroll bar on the horizontal). The problem becomes worse when there are a > considerable number of rules. Therefore, we are proposing the following > changes: > # Instead of using the table to create new ACL, we can create a button like > the one presented in attached pictures, where users can click, and then a > modal popup would appear and users would be able to create the new ACL there. > This is similar to the workings of the ACL edit button. > # Remove the ability to add new ACL via table where they are presented. All > ACLs should be entered via the “New ACL” button. Therefore, the section “Add > ACL” would be removed as well; > # Move the action section of the list ACL table to the most left position; > > These changes would reduce the information in the table and facilitate users > to add new rules and easily edit them as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10293) Single view network ACL rules listing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373593#comment-16373593 ] ASF subversion and git services commented on CLOUDSTACK-10293: -- Commit e9da30b24e8d4df4b22451488e459361435da80c in cloudstack's branch refs/heads/master from [~rafaelweingartner] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=e9da30b ] Merge pull request #2456 from rafaelweingartner/CLOUDSTACK-10293 [CLOUDSTACK-10293] Single view network ACL rules listing > Single view network ACL rules listing > - > > Key: CLOUDSTACK-10293 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10293 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > Fix For: 4.12 > > > The ACL rules editing/addition page is not user-friendly. Users are not able > to see in a single view all of the detail of the ACL rule (they need to use a > scroll bar on the horizontal). The problem becomes worse when there are a > considerable number of rules. Therefore, we are proposing the following > changes: > # Instead of using the table to create new ACL, we can create a button like > the one presented in attached pictures, where users can click, and then a > modal popup would appear and users would be able to create the new ACL there. > This is similar to the workings of the ACL edit button. > # Remove the ability to add new ACL via table where they are presented. All > ACLs should be entered via the “New ACL” button. Therefore, the section “Add > ACL” would be removed as well; > # Move the action section of the list ACL table to the most left position; > > These changes would reduce the information in the table and facilitate users > to add new rules and easily edit them as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10293) Single view network ACL rules listing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373592#comment-16373592 ] ASF subversion and git services commented on CLOUDSTACK-10293: -- Commit 689715504c84dce65e3f9d5f834cd01e5284bad6 in cloudstack's branch refs/heads/master from [~rafaelweingartner] [ https://gitbox.apache.org/repos/asf?p=cloudstack.git;h=6897155 ] [CLOUDSTACK-10293] Single view network ACL rules listing The ACL rules editing/addition page is not user-friendly. Users are not able to see in a single view all of the detail of the ACL rule (they need to use a scroll bar on the horizontal). The problem becomes worse when there are a considerable number of rules. Therefore, we are proposing the following changes: 1- Instead of using the table to create new ACL, we can create a button like the one presented in attached pictures, where users can click, and then a modal popup would appear and users would be able to create the new ACL there. This is similar to the workings of the ACL edit button. 2 - Remove the ability to add new ACL via table where they are presented. All ACLs should be entered via the “New ACL” button. Therefore, the section “Add ACL” would be removed as well; 3 - Move the action section of the list ACL table to the most left position; These changes would reduce the information in the table and facilitate users to add new rules and easily edit them as well. > Single view network ACL rules listing > - > > Key: CLOUDSTACK-10293 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10293 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > Fix For: 4.12 > > > The ACL rules editing/addition page is not user-friendly. Users are not able > to see in a single view all of the detail of the ACL rule (they need to use a > scroll bar on the horizontal). The problem becomes worse when there are a > considerable number of rules. Therefore, we are proposing the following > changes: > # Instead of using the table to create new ACL, we can create a button like > the one presented in attached pictures, where users can click, and then a > modal popup would appear and users would be able to create the new ACL there. > This is similar to the workings of the ACL edit button. > # Remove the ability to add new ACL via table where they are presented. All > ACLs should be entered via the “New ACL” button. Therefore, the section “Add > ACL” would be removed as well; > # Move the action section of the list ACL table to the most left position; > > These changes would reduce the information in the table and facilitate users > to add new rules and easily edit them as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10293) Single view network ACL rules listing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373591#comment-16373591 ] ASF GitHub Bot commented on CLOUDSTACK-10293: - rafaelweingartner commented on issue #2456: [CLOUDSTACK-10293] Single view network ACL rules listing URL: https://github.com/apache/cloudstack/pull/2456#issuecomment-367846443 Two LGTMs, and as it is only a change in JavaScript there is no need for the integration tests. I will merge this one then. 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 > Single view network ACL rules listing > - > > Key: CLOUDSTACK-10293 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10293 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > Fix For: 4.12 > > > The ACL rules editing/addition page is not user-friendly. Users are not able > to see in a single view all of the detail of the ACL rule (they need to use a > scroll bar on the horizontal). The problem becomes worse when there are a > considerable number of rules. Therefore, we are proposing the following > changes: > # Instead of using the table to create new ACL, we can create a button like > the one presented in attached pictures, where users can click, and then a > modal popup would appear and users would be able to create the new ACL there. > This is similar to the workings of the ACL edit button. > # Remove the ability to add new ACL via table where they are presented. All > ACLs should be entered via the “New ACL” button. Therefore, the section “Add > ACL” would be removed as well; > # Move the action section of the list ACL table to the most left position; > > These changes would reduce the information in the table and facilitate users > to add new rules and easily edit them as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-9338) updateResourceCount not accounting resources of VMs with custom service offering
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373588#comment-16373588 ] ASF GitHub Bot commented on CLOUDSTACK-9338: rafaelweingartner commented on issue #2443: [CLOUDSTACK-9338] ACS is not accounting resources of VMs with custom service offering properly URL: https://github.com/apache/cloudstack/pull/2443#issuecomment-367846158 @bwsw are you +1 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 > updateResourceCount not accounting resources of VMs with custom service > offering > > > Key: CLOUDSTACK-9338 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9338 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Cloudmonkey, UI >Affects Versions: 4.5.2, 4.8.0 > Environment: CloudStack 4.5.1 > MariaDB 10.0 and 10.1 >Reporter: Francois Scheurer >Assignee: Rafael Weingärtner >Priority: Major > > listAccount on a domain returns 0 for cputotal and memorytotal if the domain > accounts own VMs using a ComputeOffering with custom=enabled. > Basically, looking into the vm_instance table you get the service_offering_id > and in the service_offering table you find normally the amount of CPU/RAM > allocated for the VM. > But if your VM's ComputeOffering has custom=enabled, then you need to get the > specific CPU/RAM values from the user_vm_details table: > mysql> select * from user_vm_details WHERE vm_id=957; > Apparently the listAccount code is not doing that and it just returns zero, > because the service_offering table has cpu=0 and ram_size=0 for > ComputeOfferings with custom=enabled. > solution: the SQL query of listAccount should also look in the > user_vm_details table for matching rows. (instead of just querying in the > service_offering table) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-9338) updateResourceCount not accounting resources of VMs with custom service offering
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373585#comment-16373585 ] ASF GitHub Bot commented on CLOUDSTACK-9338: blueorangutan commented on issue #2443: [CLOUDSTACK-9338] ACS is not accounting resources of VMs with custom service offering properly URL: https://github.com/apache/cloudstack/pull/2443#issuecomment-367845502 Trillian test result (tid-2277) Environment: kvm-centos7 (x2), Advanced Networking with Mgmt server 7 Total time taken: 28307 seconds Marvin logs: https://github.com/blueorangutan/acs-prs/releases/download/trillian/pr2443-t2277-kvm-centos7.zip Intermitten failure detected: /marvin/tests/smoke/test_deploy_virtio_scsi_vm.py Intermitten failure detected: /marvin/tests/smoke/test_host_maintenance.py Intermitten failure detected: /marvin/tests/smoke/test_hostha_kvm.py Smoke tests completed. 67 look OK, 0 have error(s) Only failed tests results shown below: Test | Result | Time (s) | Test File --- | --- | --- | --- 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 > updateResourceCount not accounting resources of VMs with custom service > offering > > > Key: CLOUDSTACK-9338 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9338 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Cloudmonkey, UI >Affects Versions: 4.5.2, 4.8.0 > Environment: CloudStack 4.5.1 > MariaDB 10.0 and 10.1 >Reporter: Francois Scheurer >Assignee: Rafael Weingärtner >Priority: Major > > listAccount on a domain returns 0 for cputotal and memorytotal if the domain > accounts own VMs using a ComputeOffering with custom=enabled. > Basically, looking into the vm_instance table you get the service_offering_id > and in the service_offering table you find normally the amount of CPU/RAM > allocated for the VM. > But if your VM's ComputeOffering has custom=enabled, then you need to get the > specific CPU/RAM values from the user_vm_details table: > mysql> select * from user_vm_details WHERE vm_id=957; > Apparently the listAccount code is not doing that and it just returns zero, > because the service_offering table has cpu=0 and ram_size=0 for > ComputeOfferings with custom=enabled. > solution: the SQL query of listAccount should also look in the > user_vm_details table for matching rows. (instead of just querying in the > service_offering table) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10232) SystemVMs and VR to run as HVM on XenServer
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373564#comment-16373564
]
ASF GitHub Bot commented on CLOUDSTACK-10232:
-
rafaelweingartner commented on issue #2465: CLOUDSTACK-10232: SystemVMs and VR
to run as HVM on XenServer
URL: https://github.com/apache/cloudstack/pull/2465#issuecomment-367841653
@khos2ow and @pdion891 thanks for this one!
BTW, when you mean a load test, you are only talking about reboot/reset? are
you planning a load test in the sense of multiple VRs in the same host, to see
how XenServer will deal with all of them using this approach?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> SystemVMs and VR to run as HVM on XenServer
> ---
>
> Key: CLOUDSTACK-10232
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10232
> Project: CloudStack
> Issue Type: New Feature
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: SystemVM, Virtual Router, XenServer
>Affects Versions: 4.10.0.0, 4.9.3.0
>Reporter: Pierre-Luc Dion
>Priority: Major
>
> Following the recent Meltdown-Spectre security risk,one of the mitigation,as
> of Jan 2018, for XenServer Hypervisor is to run Virtual-Machine in HVM mode.
> Currently SystemVMs and Virtual-Routers run as PV on XenServer and the eth0
> is configured using {{/etc/init.d/cloud-early-config}} using grub params from
> {{/proc/cmdline}}. When VM run as HVM, it is not possible to push initial
> boot instruction via pygrub.
> Quick tests has been done using xenstore and it look like it would be
> possible to send same initial boot instruction has pygrub but using xenstore
> for HVM instances.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10293) Single view network ACL rules listing
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10293?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373566#comment-16373566 ] ASF GitHub Bot commented on CLOUDSTACK-10293: - GabrielBrascher commented on issue #2456: [CLOUDSTACK-10293] Single view network ACL rules listing URL: https://github.com/apache/cloudstack/pull/2456#issuecomment-367841826 Thanks, @rafaelweingartner! Code and Screenshots 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 > Single view network ACL rules listing > - > > Key: CLOUDSTACK-10293 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10293 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Rafael Weingärtner >Assignee: Rafael Weingärtner >Priority: Major > Fix For: 4.12 > > > The ACL rules editing/addition page is not user-friendly. Users are not able > to see in a single view all of the detail of the ACL rule (they need to use a > scroll bar on the horizontal). The problem becomes worse when there are a > considerable number of rules. Therefore, we are proposing the following > changes: > # Instead of using the table to create new ACL, we can create a button like > the one presented in attached pictures, where users can click, and then a > modal popup would appear and users would be able to create the new ACL there. > This is similar to the workings of the ACL edit button. > # Remove the ability to add new ACL via table where they are presented. All > ACLs should be entered via the “New ACL” button. Therefore, the section “Add > ACL” would be removed as well; > # Move the action section of the list ACL table to the most left position; > > These changes would reduce the information in the table and facilitate users > to add new rules and easily edit them as well. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10232) SystemVMs and VR to run as HVM on XenServer
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373553#comment-16373553
]
ASF GitHub Bot commented on CLOUDSTACK-10232:
-
khos2ow commented on a change in pull request #2465: CLOUDSTACK-10232:
SystemVMs and VR to run as HVM on XenServer
URL: https://github.com/apache/cloudstack/pull/2465#discussion_r170110155
##
File path:
plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/CitrixResourceBase.java
##
@@ -1368,12 +1368,23 @@ public VM createVmFromTemplate(final Connection conn,
final VirtualMachineTO vmS
final String bootArgs = vmSpec.getBootArgs();
if (bootArgs != null && bootArgs.length() > 0) {
+// send boot args for PV instances
String pvargs = vm.getPVArgs(conn);
pvargs = pvargs + vmSpec.getBootArgs().replaceAll(" ", "%");
if (s_logger.isDebugEnabled()) {
s_logger.debug("PV args are " + pvargs);
}
vm.setPVArgs(conn, pvargs);
+
+// send boot args into xenstore-data for HVM instances
+Map xenstoreData = new HashMap<>();
+
+xenstoreData.put("vm-data/cloudstack/init", bootArgs);
+vm.setXenstoreData(conn, xenstoreData);
+
+if (s_logger.isDebugEnabled()) {
+s_logger.debug("HVM args are " + bootArgs);
Review comment:
Makes totally sense to me. Removed the IF condition.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> SystemVMs and VR to run as HVM on XenServer
> ---
>
> Key: CLOUDSTACK-10232
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10232
> Project: CloudStack
> Issue Type: New Feature
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: SystemVM, Virtual Router, XenServer
>Affects Versions: 4.10.0.0, 4.9.3.0
>Reporter: Pierre-Luc Dion
>Priority: Major
>
> Following the recent Meltdown-Spectre security risk,one of the mitigation,as
> of Jan 2018, for XenServer Hypervisor is to run Virtual-Machine in HVM mode.
> Currently SystemVMs and Virtual-Routers run as PV on XenServer and the eth0
> is configured using {{/etc/init.d/cloud-early-config}} using grub params from
> {{/proc/cmdline}}. When VM run as HVM, it is not possible to push initial
> boot instruction via pygrub.
> Quick tests has been done using xenstore and it look like it would be
> possible to send same initial boot instruction has pygrub but using xenstore
> for HVM instances.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10259) Missing float part of secondary storage data when calculating secondary storage usage in listAccounts
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10259?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373547#comment-16373547 ] ASF GitHub Bot commented on CLOUDSTACK-10259: - rafaelweingartner commented on issue #2439: [CLOUDSTACK-10259] Missing float part of secondary storage data in listAccounts method URL: https://github.com/apache/cloudstack/pull/2439#issuecomment-367838927 Do we need to wait for the integration tests on this one? 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 > Missing float part of secondary storage data when calculating secondary > storage usage in listAccounts > -- > > Key: CLOUDSTACK-10259 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10259 > 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: Minor > > There is a non-floating points division that is missing the floating part of > the secondary storage usage. This will affect methods that use the following > SET method > org.apache.cloudstack.api.response.AccountResponse.setSecondaryStorageLimit(String). > It affects the listAccounts API method, making it differ from the > updateResource count method, which is presented in bytes. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10278) Adding a SQL table column is not Idempotent
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10278?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373545#comment-16373545 ] ASF GitHub Bot commented on CLOUDSTACK-10278: - rafaelweingartner commented on issue #2449: WIP CLOUDSTACK-10278 idempotent column addition URL: https://github.com/apache/cloudstack/pull/2449#issuecomment-367838510 Folks, what are the thoughts here? use this ad-hoc approach? Work a bit harder to a more comprehensive solution using a framework/system to control DB data model upgrades? 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 > Adding a SQL table column is not Idempotent > --- > > Key: CLOUDSTACK-10278 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10278 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Install and Setup >Affects Versions: 4.10.0.0, 4.11.0.0 >Reporter: Ernie Janse van Rensburg >Assignee: Ernie Janse van Rensburg >Priority: Major > Original Estimate: 4h > Remaining Estimate: 4h > > The SQL code to add a new column to a table in the > META-INF/db/schema-41000to41100.sql script is not written in an idempotent > way. When the upgrade is re-run, the code above causes a SQL error as > reported on the user mailing list: > ERROR [c.c.u.d.ScriptRunner] (main:null) (logid:) > Error executing: ALTER TABLE cloud.network_offerings ADD COLUMN for_vpc > INT(1) NOT NULL DEFAULT 0 > This is a more generic problem for every version due to to the fact that it > is not idempotent > -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10284) Creating a snapshot from VM Snapshot generates error if hypervisor is not KVM.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10284?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373537#comment-16373537 ] ASF GitHub Bot commented on CLOUDSTACK-10284: - rafaelweingartner commented on issue #2451: CLOUDSTACK-10284:Creating a snapshot from VM Snapshot generates error if hypervisor is not KVM. URL: https://github.com/apache/cloudstack/pull/2451#issuecomment-367836751 @niteshsarda can you please provide us a feedback regarding @rhtyd inquiry? 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 > Creating a snapshot from VM Snapshot generates error if hypervisor is not KVM. > -- > > Key: CLOUDSTACK-10284 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10284 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Nitesh Sarda >Priority: Major > > ISSUE > Creating a snapshot from VM Snapshot generates error if hypervisor is not KVM. > STEPS TO REPRODUCE > * Create a cloudstack setup with hypervisor other than KVM. > * Create an instance. > * Take Snapshot of that VM. > * Try to take volume snapshot from newly created VM snapshot. > * It will throw an error as hypervisor is not KVM. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10232) SystemVMs and VR to run as HVM on XenServer
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373526#comment-16373526
]
ASF GitHub Bot commented on CLOUDSTACK-10232:
-
pdion891 commented on issue #2465: CLOUDSTACK-10232: SystemVMs and VR to run as
HVM on XenServer
URL: https://github.com/apache/cloudstack/pull/2465#issuecomment-367834144
BTW we are doing some test of this on our side, to make sure we keep support
of VR running as PV on legacy deployments and support now default HVM VR on
xenserver 7.1+...
So far the xenstore method work well but still need few tests under high
workload, VR reboot, reset,... we should have more news in a week, our QA will
only focus on xenserver 7.1 including 7.1.1(cumulative updates)
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> SystemVMs and VR to run as HVM on XenServer
> ---
>
> Key: CLOUDSTACK-10232
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10232
> Project: CloudStack
> Issue Type: New Feature
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: SystemVM, Virtual Router, XenServer
>Affects Versions: 4.10.0.0, 4.9.3.0
>Reporter: Pierre-Luc Dion
>Priority: Major
>
> Following the recent Meltdown-Spectre security risk,one of the mitigation,as
> of Jan 2018, for XenServer Hypervisor is to run Virtual-Machine in HVM mode.
> Currently SystemVMs and Virtual-Routers run as PV on XenServer and the eth0
> is configured using {{/etc/init.d/cloud-early-config}} using grub params from
> {{/proc/cmdline}}. When VM run as HVM, it is not possible to push initial
> boot instruction via pygrub.
> Quick tests has been done using xenstore and it look like it would be
> possible to send same initial boot instruction has pygrub but using xenstore
> for HVM instances.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10232) SystemVMs and VR to run as HVM on XenServer
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373388#comment-16373388
]
ASF GitHub Bot commented on CLOUDSTACK-10232:
-
rafaelweingartner commented on a change in pull request #2465:
CLOUDSTACK-10232: SystemVMs and VR to run as HVM on XenServer
URL: https://github.com/apache/cloudstack/pull/2465#discussion_r170083404
##
File path:
plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/CitrixResourceBase.java
##
@@ -1368,12 +1368,23 @@ public VM createVmFromTemplate(final Connection conn,
final VirtualMachineTO vmS
final String bootArgs = vmSpec.getBootArgs();
if (bootArgs != null && bootArgs.length() > 0) {
+// send boot args for PV instances
String pvargs = vm.getPVArgs(conn);
pvargs = pvargs + vmSpec.getBootArgs().replaceAll(" ", "%");
if (s_logger.isDebugEnabled()) {
s_logger.debug("PV args are " + pvargs);
}
vm.setPVArgs(conn, pvargs);
+
+// send boot args into xenstore-data for HVM instances
+Map xenstoreData = new HashMap<>();
+
+xenstoreData.put("vm-data/cloudstack/init", bootArgs);
+vm.setXenstoreData(conn, xenstoreData);
+
+if (s_logger.isDebugEnabled()) {
+s_logger.debug("HVM args are " + bootArgs);
Review comment:
What I meant is that, in a Web API drive system such as ACS, everything is
synchronous (or almost everything). Therefore, the 1 nanoseconds of improvement
that the use of this IF conditional can bring is negligible. This means that
the code (the code used to create this optimization) is not worth it (in my
perspective).
I normally see people using this approach of checking log level before
logging when creating log messages using String.format, which uses quite some
processing. However, even in those cases, I do not see much need to check the
log level before logging (in most cases).
I just commented to give some context on the use of this isEnabled
method. The only time I used this approach of checking log level was when I
developed some standalone optimization algorithms that had a time constraint to
be executed. Therefore, there was no space to waste clock cycles creating a log
message that is not going to be used.
In summary; if I were coding, I would not use it. However, we have these
things spread all over our code base. I normally remove them, but if you want
to use, the choice is yours.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> SystemVMs and VR to run as HVM on XenServer
> ---
>
> Key: CLOUDSTACK-10232
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10232
> Project: CloudStack
> Issue Type: New Feature
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: SystemVM, Virtual Router, XenServer
>Affects Versions: 4.10.0.0, 4.9.3.0
>Reporter: Pierre-Luc Dion
>Priority: Major
>
> Following the recent Meltdown-Spectre security risk,one of the mitigation,as
> of Jan 2018, for XenServer Hypervisor is to run Virtual-Machine in HVM mode.
> Currently SystemVMs and Virtual-Routers run as PV on XenServer and the eth0
> is configured using {{/etc/init.d/cloud-early-config}} using grub params from
> {{/proc/cmdline}}. When VM run as HVM, it is not possible to push initial
> boot instruction via pygrub.
> Quick tests has been done using xenstore and it look like it would be
> possible to send same initial boot instruction has pygrub but using xenstore
> for HVM instances.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10232) SystemVMs and VR to run as HVM on XenServer
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373354#comment-16373354
]
ASF GitHub Bot commented on CLOUDSTACK-10232:
-
khos2ow commented on a change in pull request #2465: CLOUDSTACK-10232:
SystemVMs and VR to run as HVM on XenServer
URL: https://github.com/apache/cloudstack/pull/2465#discussion_r170077117
##
File path:
plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/CitrixResourceBase.java
##
@@ -1368,12 +1368,23 @@ public VM createVmFromTemplate(final Connection conn,
final VirtualMachineTO vmS
final String bootArgs = vmSpec.getBootArgs();
if (bootArgs != null && bootArgs.length() > 0) {
+// send boot args for PV instances
String pvargs = vm.getPVArgs(conn);
pvargs = pvargs + vmSpec.getBootArgs().replaceAll(" ", "%");
if (s_logger.isDebugEnabled()) {
s_logger.debug("PV args are " + pvargs);
}
vm.setPVArgs(conn, pvargs);
+
+// send boot args into xenstore-data for HVM instances
+Map xenstoreData = new HashMap<>();
+
+xenstoreData.put("vm-data/cloudstack/init", bootArgs);
+vm.setXenstoreData(conn, xenstoreData);
+
+if (s_logger.isDebugEnabled()) {
+s_logger.debug("HVM args are " + bootArgs);
Review comment:
I didn't get your point! Are your pro on this specific IF block or against
it?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> SystemVMs and VR to run as HVM on XenServer
> ---
>
> Key: CLOUDSTACK-10232
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10232
> Project: CloudStack
> Issue Type: New Feature
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: SystemVM, Virtual Router, XenServer
>Affects Versions: 4.10.0.0, 4.9.3.0
>Reporter: Pierre-Luc Dion
>Priority: Major
>
> Following the recent Meltdown-Spectre security risk,one of the mitigation,as
> of Jan 2018, for XenServer Hypervisor is to run Virtual-Machine in HVM mode.
> Currently SystemVMs and Virtual-Routers run as PV on XenServer and the eth0
> is configured using {{/etc/init.d/cloud-early-config}} using grub params from
> {{/proc/cmdline}}. When VM run as HVM, it is not possible to push initial
> boot instruction via pygrub.
> Quick tests has been done using xenstore and it look like it would be
> possible to send same initial boot instruction has pygrub but using xenstore
> for HVM instances.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10232) SystemVMs and VR to run as HVM on XenServer
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373339#comment-16373339
]
ASF GitHub Bot commented on CLOUDSTACK-10232:
-
rafaelweingartner commented on a change in pull request #2465:
CLOUDSTACK-10232: SystemVMs and VR to run as HVM on XenServer
URL: https://github.com/apache/cloudstack/pull/2465#discussion_r170073522
##
File path:
plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/CitrixResourceBase.java
##
@@ -1368,12 +1368,23 @@ public VM createVmFromTemplate(final Connection conn,
final VirtualMachineTO vmS
final String bootArgs = vmSpec.getBootArgs();
if (bootArgs != null && bootArgs.length() > 0) {
+// send boot args for PV instances
String pvargs = vm.getPVArgs(conn);
pvargs = pvargs + vmSpec.getBootArgs().replaceAll(" ", "%");
if (s_logger.isDebugEnabled()) {
s_logger.debug("PV args are " + pvargs);
}
vm.setPVArgs(conn, pvargs);
+
+// send boot args into xenstore-data for HVM instances
+Map xenstoreData = new HashMap<>();
+
+xenstoreData.put("vm-data/cloudstack/init", bootArgs);
+vm.setXenstoreData(conn, xenstoreData);
+
+if (s_logger.isDebugEnabled()) {
+s_logger.debug("HVM args are " + bootArgs);
Review comment:
In this type of system such as ACS, I believe it is worth the cost of a tiny
bit of more processing to remove an If statement. Specially in cases such as
this one, when you already have others IFs where this one is nested.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> SystemVMs and VR to run as HVM on XenServer
> ---
>
> Key: CLOUDSTACK-10232
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10232
> Project: CloudStack
> Issue Type: New Feature
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: SystemVM, Virtual Router, XenServer
>Affects Versions: 4.10.0.0, 4.9.3.0
>Reporter: Pierre-Luc Dion
>Priority: Major
>
> Following the recent Meltdown-Spectre security risk,one of the mitigation,as
> of Jan 2018, for XenServer Hypervisor is to run Virtual-Machine in HVM mode.
> Currently SystemVMs and Virtual-Routers run as PV on XenServer and the eth0
> is configured using {{/etc/init.d/cloud-early-config}} using grub params from
> {{/proc/cmdline}}. When VM run as HVM, it is not possible to push initial
> boot instruction via pygrub.
> Quick tests has been done using xenstore and it look like it would be
> possible to send same initial boot instruction has pygrub but using xenstore
> for HVM instances.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10232) SystemVMs and VR to run as HVM on XenServer
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373257#comment-16373257
]
ASF GitHub Bot commented on CLOUDSTACK-10232:
-
khos2ow commented on a change in pull request #2465: CLOUDSTACK-10232:
SystemVMs and VR to run as HVM on XenServer
URL: https://github.com/apache/cloudstack/pull/2465#discussion_r170060637
##
File path:
plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/CitrixResourceBase.java
##
@@ -1368,12 +1368,23 @@ public VM createVmFromTemplate(final Connection conn,
final VirtualMachineTO vmS
final String bootArgs = vmSpec.getBootArgs();
if (bootArgs != null && bootArgs.length() > 0) {
+// send boot args for PV instances
String pvargs = vm.getPVArgs(conn);
pvargs = pvargs + vmSpec.getBootArgs().replaceAll(" ", "%");
if (s_logger.isDebugEnabled()) {
s_logger.debug("PV args are " + pvargs);
}
vm.setPVArgs(conn, pvargs);
+
+// send boot args into xenstore-data for HVM instances
+Map xenstoreData = new HashMap<>();
+
+xenstoreData.put("vm-data/cloudstack/init", bootArgs);
Review comment:
sure.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> SystemVMs and VR to run as HVM on XenServer
> ---
>
> Key: CLOUDSTACK-10232
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10232
> Project: CloudStack
> Issue Type: New Feature
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: SystemVM, Virtual Router, XenServer
>Affects Versions: 4.10.0.0, 4.9.3.0
>Reporter: Pierre-Luc Dion
>Priority: Major
>
> Following the recent Meltdown-Spectre security risk,one of the mitigation,as
> of Jan 2018, for XenServer Hypervisor is to run Virtual-Machine in HVM mode.
> Currently SystemVMs and Virtual-Routers run as PV on XenServer and the eth0
> is configured using {{/etc/init.d/cloud-early-config}} using grub params from
> {{/proc/cmdline}}. When VM run as HVM, it is not possible to push initial
> boot instruction via pygrub.
> Quick tests has been done using xenstore and it look like it would be
> possible to send same initial boot instruction has pygrub but using xenstore
> for HVM instances.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10232) SystemVMs and VR to run as HVM on XenServer
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373253#comment-16373253
]
ASF GitHub Bot commented on CLOUDSTACK-10232:
-
syed commented on a change in pull request #2465: CLOUDSTACK-10232: SystemVMs
and VR to run as HVM on XenServer
URL: https://github.com/apache/cloudstack/pull/2465#discussion_r170059191
##
File path:
plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/CitrixResourceBase.java
##
@@ -1368,12 +1368,23 @@ public VM createVmFromTemplate(final Connection conn,
final VirtualMachineTO vmS
final String bootArgs = vmSpec.getBootArgs();
if (bootArgs != null && bootArgs.length() > 0) {
+// send boot args for PV instances
String pvargs = vm.getPVArgs(conn);
pvargs = pvargs + vmSpec.getBootArgs().replaceAll(" ", "%");
if (s_logger.isDebugEnabled()) {
s_logger.debug("PV args are " + pvargs);
}
vm.setPVArgs(conn, pvargs);
+
+// send boot args into xenstore-data for HVM instances
+Map xenstoreData = new HashMap<>();
+
+xenstoreData.put("vm-data/cloudstack/init", bootArgs);
Review comment:
Could you please move the `vm-data/cloudstack/init` string into a class
constant.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> SystemVMs and VR to run as HVM on XenServer
> ---
>
> Key: CLOUDSTACK-10232
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10232
> Project: CloudStack
> Issue Type: New Feature
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: SystemVM, Virtual Router, XenServer
>Affects Versions: 4.10.0.0, 4.9.3.0
>Reporter: Pierre-Luc Dion
>Priority: Major
>
> Following the recent Meltdown-Spectre security risk,one of the mitigation,as
> of Jan 2018, for XenServer Hypervisor is to run Virtual-Machine in HVM mode.
> Currently SystemVMs and Virtual-Routers run as PV on XenServer and the eth0
> is configured using {{/etc/init.d/cloud-early-config}} using grub params from
> {{/proc/cmdline}}. When VM run as HVM, it is not possible to push initial
> boot instruction via pygrub.
> Quick tests has been done using xenstore and it look like it would be
> possible to send same initial boot instruction has pygrub but using xenstore
> for HVM instances.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10232) SystemVMs and VR to run as HVM on XenServer
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373060#comment-16373060
]
ASF GitHub Bot commented on CLOUDSTACK-10232:
-
khos2ow commented on a change in pull request #2465: CLOUDSTACK-10232:
SystemVMs and VR to run as HVM on XenServer
URL: https://github.com/apache/cloudstack/pull/2465#discussion_r170022564
##
File path:
plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/CitrixResourceBase.java
##
@@ -1368,12 +1368,23 @@ public VM createVmFromTemplate(final Connection conn,
final VirtualMachineTO vmS
final String bootArgs = vmSpec.getBootArgs();
if (bootArgs != null && bootArgs.length() > 0) {
+// send boot args for PV instances
String pvargs = vm.getPVArgs(conn);
pvargs = pvargs + vmSpec.getBootArgs().replaceAll(" ", "%");
if (s_logger.isDebugEnabled()) {
s_logger.debug("PV args are " + pvargs);
}
vm.setPVArgs(conn, pvargs);
+
+// send boot args into xenstore-data for HVM instances
+Map xenstoreData = new HashMap<>();
+
+xenstoreData.put("vm-data/cloudstack/init", bootArgs);
+vm.setXenstoreData(conn, xenstoreData);
+
+if (s_logger.isDebugEnabled()) {
+s_logger.debug("HVM args are " + bootArgs);
Review comment:
Technically it can be removed, but as its javadoc says: `This function is
intended to lessen the computational cost of disabled log debug statements.`
and the fact that they are used all over the place I added the same if block.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> SystemVMs and VR to run as HVM on XenServer
> ---
>
> Key: CLOUDSTACK-10232
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10232
> Project: CloudStack
> Issue Type: New Feature
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: SystemVM, Virtual Router, XenServer
>Affects Versions: 4.10.0.0, 4.9.3.0
>Reporter: Pierre-Luc Dion
>Priority: Major
>
> Following the recent Meltdown-Spectre security risk,one of the mitigation,as
> of Jan 2018, for XenServer Hypervisor is to run Virtual-Machine in HVM mode.
> Currently SystemVMs and Virtual-Routers run as PV on XenServer and the eth0
> is configured using {{/etc/init.d/cloud-early-config}} using grub params from
> {{/proc/cmdline}}. When VM run as HVM, it is not possible to push initial
> boot instruction via pygrub.
> Quick tests has been done using xenstore and it look like it would be
> possible to send same initial boot instruction has pygrub but using xenstore
> for HVM instances.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10232) SystemVMs and VR to run as HVM on XenServer
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373046#comment-16373046
]
ASF GitHub Bot commented on CLOUDSTACK-10232:
-
blueorangutan commented on issue #2465: CLOUDSTACK-10232: SystemVMs and VR to
run as HVM on XenServer
URL: https://github.com/apache/cloudstack/pull/2465#issuecomment-367741560
Packaging result: ✔centos6 ✔centos7 ✔debian. JID-1730
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> SystemVMs and VR to run as HVM on XenServer
> ---
>
> Key: CLOUDSTACK-10232
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10232
> Project: CloudStack
> Issue Type: New Feature
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: SystemVM, Virtual Router, XenServer
>Affects Versions: 4.10.0.0, 4.9.3.0
>Reporter: Pierre-Luc Dion
>Priority: Major
>
> Following the recent Meltdown-Spectre security risk,one of the mitigation,as
> of Jan 2018, for XenServer Hypervisor is to run Virtual-Machine in HVM mode.
> Currently SystemVMs and Virtual-Routers run as PV on XenServer and the eth0
> is configured using {{/etc/init.d/cloud-early-config}} using grub params from
> {{/proc/cmdline}}. When VM run as HVM, it is not possible to push initial
> boot instruction via pygrub.
> Quick tests has been done using xenstore and it look like it would be
> possible to send same initial boot instruction has pygrub but using xenstore
> for HVM instances.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10232) SystemVMs and VR to run as HVM on XenServer
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16373004#comment-16373004
]
ASF GitHub Bot commented on CLOUDSTACK-10232:
-
khos2ow commented on a change in pull request #2465: CLOUDSTACK-10232:
SystemVMs and VR to run as HVM on XenServer
URL: https://github.com/apache/cloudstack/pull/2465#discussion_r170010228
##
File path: systemvm/debian/opt/cloud/bin/setup/cloud-early-config
##
@@ -42,7 +42,14 @@ hypervisor() {
grep -q QEMU /var/log/messages && echo "kvm" && return 0
[ -d /proc/xen ] && mount -t xenfs none /proc/xen
- [ -d /proc/xen ] && echo "xen-domU" && return 0
+ if [ -d /proc/xen ]; then
+`dmesg | grep -q "Xen HVM"`
Review comment:
sure.
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> SystemVMs and VR to run as HVM on XenServer
> ---
>
> Key: CLOUDSTACK-10232
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10232
> Project: CloudStack
> Issue Type: New Feature
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: SystemVM, Virtual Router, XenServer
>Affects Versions: 4.10.0.0, 4.9.3.0
>Reporter: Pierre-Luc Dion
>Priority: Major
>
> Following the recent Meltdown-Spectre security risk,one of the mitigation,as
> of Jan 2018, for XenServer Hypervisor is to run Virtual-Machine in HVM mode.
> Currently SystemVMs and Virtual-Routers run as PV on XenServer and the eth0
> is configured using {{/etc/init.d/cloud-early-config}} using grub params from
> {{/proc/cmdline}}. When VM run as HVM, it is not possible to push initial
> boot instruction via pygrub.
> Quick tests has been done using xenstore and it look like it would be
> possible to send same initial boot instruction has pygrub but using xenstore
> for HVM instances.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10232) SystemVMs and VR to run as HVM on XenServer
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16372995#comment-16372995
]
ASF GitHub Bot commented on CLOUDSTACK-10232:
-
wido commented on a change in pull request #2465: CLOUDSTACK-10232: SystemVMs
and VR to run as HVM on XenServer
URL: https://github.com/apache/cloudstack/pull/2465#discussion_r170009008
##
File path:
plugins/hypervisors/xenserver/src/com/cloud/hypervisor/xenserver/resource/CitrixResourceBase.java
##
@@ -1368,12 +1368,23 @@ public VM createVmFromTemplate(final Connection conn,
final VirtualMachineTO vmS
final String bootArgs = vmSpec.getBootArgs();
if (bootArgs != null && bootArgs.length() > 0) {
+// send boot args for PV instances
String pvargs = vm.getPVArgs(conn);
pvargs = pvargs + vmSpec.getBootArgs().replaceAll(" ", "%");
if (s_logger.isDebugEnabled()) {
s_logger.debug("PV args are " + pvargs);
}
vm.setPVArgs(conn, pvargs);
+
+// send boot args into xenstore-data for HVM instances
+Map xenstoreData = new HashMap<>();
+
+xenstoreData.put("vm-data/cloudstack/init", bootArgs);
+vm.setXenstoreData(conn, xenstoreData);
+
+if (s_logger.isDebugEnabled()) {
+s_logger.debug("HVM args are " + bootArgs);
Review comment:
Is this if statement still required to check if debug is enabled?
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> SystemVMs and VR to run as HVM on XenServer
> ---
>
> Key: CLOUDSTACK-10232
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10232
> Project: CloudStack
> Issue Type: New Feature
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: SystemVM, Virtual Router, XenServer
>Affects Versions: 4.10.0.0, 4.9.3.0
>Reporter: Pierre-Luc Dion
>Priority: Major
>
> Following the recent Meltdown-Spectre security risk,one of the mitigation,as
> of Jan 2018, for XenServer Hypervisor is to run Virtual-Machine in HVM mode.
> Currently SystemVMs and Virtual-Routers run as PV on XenServer and the eth0
> is configured using {{/etc/init.d/cloud-early-config}} using grub params from
> {{/proc/cmdline}}. When VM run as HVM, it is not possible to push initial
> boot instruction via pygrub.
> Quick tests has been done using xenstore and it look like it would be
> possible to send same initial boot instruction has pygrub but using xenstore
> for HVM instances.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10232) SystemVMs and VR to run as HVM on XenServer
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16372985#comment-16372985
]
ASF GitHub Bot commented on CLOUDSTACK-10232:
-
blueorangutan commented on issue #2465: CLOUDSTACK-10232: SystemVMs and VR to
run as HVM on XenServer
URL: https://github.com/apache/cloudstack/pull/2465#issuecomment-367728567
@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
> SystemVMs and VR to run as HVM on XenServer
> ---
>
> Key: CLOUDSTACK-10232
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10232
> Project: CloudStack
> Issue Type: New Feature
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: SystemVM, Virtual Router, XenServer
>Affects Versions: 4.10.0.0, 4.9.3.0
>Reporter: Pierre-Luc Dion
>Priority: Major
>
> Following the recent Meltdown-Spectre security risk,one of the mitigation,as
> of Jan 2018, for XenServer Hypervisor is to run Virtual-Machine in HVM mode.
> Currently SystemVMs and Virtual-Routers run as PV on XenServer and the eth0
> is configured using {{/etc/init.d/cloud-early-config}} using grub params from
> {{/proc/cmdline}}. When VM run as HVM, it is not possible to push initial
> boot instruction via pygrub.
> Quick tests has been done using xenstore and it look like it would be
> possible to send same initial boot instruction has pygrub but using xenstore
> for HVM instances.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10232) SystemVMs and VR to run as HVM on XenServer
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16372983#comment-16372983
]
ASF GitHub Bot commented on CLOUDSTACK-10232:
-
rhtyd commented on issue #2465: CLOUDSTACK-10232: SystemVMs and VR to run as
HVM on XenServer
URL: https://github.com/apache/cloudstack/pull/2465#issuecomment-367728245
@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
> SystemVMs and VR to run as HVM on XenServer
> ---
>
> Key: CLOUDSTACK-10232
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10232
> Project: CloudStack
> Issue Type: New Feature
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: SystemVM, Virtual Router, XenServer
>Affects Versions: 4.10.0.0, 4.9.3.0
>Reporter: Pierre-Luc Dion
>Priority: Major
>
> Following the recent Meltdown-Spectre security risk,one of the mitigation,as
> of Jan 2018, for XenServer Hypervisor is to run Virtual-Machine in HVM mode.
> Currently SystemVMs and Virtual-Routers run as PV on XenServer and the eth0
> is configured using {{/etc/init.d/cloud-early-config}} using grub params from
> {{/proc/cmdline}}. When VM run as HVM, it is not possible to push initial
> boot instruction via pygrub.
> Quick tests has been done using xenstore and it look like it would be
> possible to send same initial boot instruction has pygrub but using xenstore
> for HVM instances.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10232) SystemVMs and VR to run as HVM on XenServer
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16372981#comment-16372981
]
ASF GitHub Bot commented on CLOUDSTACK-10232:
-
rhtyd commented on a change in pull request #2465: CLOUDSTACK-10232: SystemVMs
and VR to run as HVM on XenServer
URL: https://github.com/apache/cloudstack/pull/2465#discussion_r170005233
##
File path: systemvm/debian/opt/cloud/bin/setup/cloud-early-config
##
@@ -42,7 +42,14 @@ hypervisor() {
grep -q QEMU /var/log/messages && echo "kvm" && return 0
[ -d /proc/xen ] && mount -t xenfs none /proc/xen
- [ -d /proc/xen ] && echo "xen-domU" && return 0
+ if [ -d /proc/xen ]; then
+`dmesg | grep -q "Xen HVM"`
Review comment:
For consistency, can you use this instead $(command 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
> SystemVMs and VR to run as HVM on XenServer
> ---
>
> Key: CLOUDSTACK-10232
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10232
> Project: CloudStack
> Issue Type: New Feature
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: SystemVM, Virtual Router, XenServer
>Affects Versions: 4.10.0.0, 4.9.3.0
>Reporter: Pierre-Luc Dion
>Priority: Major
>
> Following the recent Meltdown-Spectre security risk,one of the mitigation,as
> of Jan 2018, for XenServer Hypervisor is to run Virtual-Machine in HVM mode.
> Currently SystemVMs and Virtual-Routers run as PV on XenServer and the eth0
> is configured using {{/etc/init.d/cloud-early-config}} using grub params from
> {{/proc/cmdline}}. When VM run as HVM, it is not possible to push initial
> boot instruction via pygrub.
> Quick tests has been done using xenstore and it look like it would be
> possible to send same initial boot instruction has pygrub but using xenstore
> for HVM instances.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10232) SystemVMs and VR to run as HVM on XenServer
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16372975#comment-16372975
]
ASF GitHub Bot commented on CLOUDSTACK-10232:
-
khos2ow commented on issue #2465: CLOUDSTACK-10232: SystemVMs and VR to run as
HVM on XenServer
URL: https://github.com/apache/cloudstack/pull/2465#issuecomment-367725070
Ping for review: @DaanHoogland @rafaelweingartner @rhtyd @wido
/cc @syed @pdion891
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> SystemVMs and VR to run as HVM on XenServer
> ---
>
> Key: CLOUDSTACK-10232
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10232
> Project: CloudStack
> Issue Type: New Feature
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: SystemVM, Virtual Router, XenServer
>Affects Versions: 4.10.0.0, 4.9.3.0
>Reporter: Pierre-Luc Dion
>Priority: Major
>
> Following the recent Meltdown-Spectre security risk,one of the mitigation,as
> of Jan 2018, for XenServer Hypervisor is to run Virtual-Machine in HVM mode.
> Currently SystemVMs and Virtual-Routers run as PV on XenServer and the eth0
> is configured using {{/etc/init.d/cloud-early-config}} using grub params from
> {{/proc/cmdline}}. When VM run as HVM, it is not possible to push initial
> boot instruction via pygrub.
> Quick tests has been done using xenstore and it look like it would be
> possible to send same initial boot instruction has pygrub but using xenstore
> for HVM instances.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10232) SystemVMs and VR to run as HVM on XenServer
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10232?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16372974#comment-16372974
]
ASF GitHub Bot commented on CLOUDSTACK-10232:
-
khos2ow commented on issue #2465: CLOUDSTACK-10232: SystemVMs and VR to run as
HVM on XenServer
URL: https://github.com/apache/cloudstack/pull/2465#issuecomment-367725070
Ping for review: @DaanHoogland @rafaelweingartner @rhtyd @wido
This is an automated message from the Apache Git Service.
To respond to the message, please log on GitHub and use the
URL above to go to the specific comment.
For queries about this service, please contact Infrastructure at:
us...@infra.apache.org
> SystemVMs and VR to run as HVM on XenServer
> ---
>
> Key: CLOUDSTACK-10232
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10232
> Project: CloudStack
> Issue Type: New Feature
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: SystemVM, Virtual Router, XenServer
>Affects Versions: 4.10.0.0, 4.9.3.0
>Reporter: Pierre-Luc Dion
>Priority: Major
>
> Following the recent Meltdown-Spectre security risk,one of the mitigation,as
> of Jan 2018, for XenServer Hypervisor is to run Virtual-Machine in HVM mode.
> Currently SystemVMs and Virtual-Routers run as PV on XenServer and the eth0
> is configured using {{/etc/init.d/cloud-early-config}} using grub params from
> {{/proc/cmdline}}. When VM run as HVM, it is not possible to push initial
> boot instruction via pygrub.
> Quick tests has been done using xenstore and it look like it would be
> possible to send same initial boot instruction has pygrub but using xenstore
> for HVM instances.
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10292) Hostname in metadata when using external DNS is incorrect
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16372942#comment-16372942
]
ASF GitHub Bot commented on CLOUDSTACK-10292:
-
rafaelweingartner commented on a change in pull request #2455:
CLOUDSTACK-10292:Hostname in metadata when using external DNS is inco…
URL: https://github.com/apache/cloudstack/pull/2455#discussion_r169993368
##
File path:
engine/orchestration/src/main/java/com/cloud/vm/VirtualMachineManagerImpl.java
##
@@ -2526,7 +2526,7 @@ private void orchestrateMigrateWithStorage(final String
vmUuid, final long srcHo
final String zoneName =
_dcDao.findById(vm.getDataCenterId()).getName();
boolean isWindows =
_guestOSCategoryDao.findById(_guestOSDao.findById(vm.getGuestOSId()).getCategoryId()).getName().equalsIgnoreCase("Windows");
-vmData =
_networkModel.generateVmData(userVm.getUserData(), serviceOffering, zoneName,
vm.getInstanceName(), vm.getId(),
+vmData =
_networkModel.generateVmData(userVm.getUserData(), serviceOffering, zoneName,
vm.getInstanceName(), vm.getHostName(), vm.getId(),
Review comment:
Of course there is. I am not talking about the object you create we the call
`generateVmData`. I am talking about the object from which you are retrieving
data `vm`. That object is an instance of `UserVmVO`, which extends
`VMInstanceVO`.
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
> Hostname in metadata when using external DNS is incorrect
> -
>
> Key: CLOUDSTACK-10292
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10292
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: mrunalini
>Priority: Major
>
> In the current implementation, both the local-hostname and instance-id in the
> metadata are pointing to same thing when VM is deployed in a network with
> Network Offering that has no services.
> The metadata for the VM is presented in configdrive.iso for a VM having
> network with network offering that has no services. However the metadata
> doesn't have any info around the name of the VM user has passed when
> deploying the VM, instead the local_hostname.txt in the metadata refers to VM
> internal name "i-12-254-VM" doesn't it needs to be the name of the VM user
> has passed when creating the VM?
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10292) Hostname in metadata when using external DNS is incorrect
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16372943#comment-16372943
]
ASF GitHub Bot commented on CLOUDSTACK-10292:
-
rafaelweingartner commented on a change in pull request #2455:
CLOUDSTACK-10292:Hostname in metadata when using external DNS is inco…
URL: https://github.com/apache/cloudstack/pull/2455#discussion_r169993368
##
File path:
engine/orchestration/src/main/java/com/cloud/vm/VirtualMachineManagerImpl.java
##
@@ -2526,7 +2526,7 @@ private void orchestrateMigrateWithStorage(final String
vmUuid, final long srcHo
final String zoneName =
_dcDao.findById(vm.getDataCenterId()).getName();
boolean isWindows =
_guestOSCategoryDao.findById(_guestOSDao.findById(vm.getGuestOSId()).getCategoryId()).getName().equalsIgnoreCase("Windows");
-vmData =
_networkModel.generateVmData(userVm.getUserData(), serviceOffering, zoneName,
vm.getInstanceName(), vm.getId(),
+vmData =
_networkModel.generateVmData(userVm.getUserData(), serviceOffering, zoneName,
vm.getInstanceName(), vm.getHostName(), vm.getId(),
Review comment:
Of course there is. I am not talking about the object you create with the
call `generateVmData`. I am talking about the object from which you are
retrieving data `vm`. That object is an instance of `UserVmVO`, which extends
`VMInstanceVO`.
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
> Hostname in metadata when using external DNS is incorrect
> -
>
> Key: CLOUDSTACK-10292
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10292
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: mrunalini
>Priority: Major
>
> In the current implementation, both the local-hostname and instance-id in the
> metadata are pointing to same thing when VM is deployed in a network with
> Network Offering that has no services.
> The metadata for the VM is presented in configdrive.iso for a VM having
> network with network offering that has no services. However the metadata
> doesn't have any info around the name of the VM user has passed when
> deploying the VM, instead the local_hostname.txt in the metadata refers to VM
> internal name "i-12-254-VM" doesn't it needs to be the name of the VM user
> has passed when creating the VM?
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10292) Hostname in metadata when using external DNS is incorrect
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16372941#comment-16372941
]
ASF GitHub Bot commented on CLOUDSTACK-10292:
-
mrunalinikankariya commented on a change in pull request #2455:
CLOUDSTACK-10292:Hostname in metadata when using external DNS is inco…
URL: https://github.com/apache/cloudstack/pull/2455#discussion_r169992289
##
File path:
engine/orchestration/src/main/java/com/cloud/vm/VirtualMachineManagerImpl.java
##
@@ -2526,7 +2526,7 @@ private void orchestrateMigrateWithStorage(final String
vmUuid, final long srcHo
final String zoneName =
_dcDao.findById(vm.getDataCenterId()).getName();
boolean isWindows =
_guestOSCategoryDao.findById(_guestOSDao.findById(vm.getGuestOSId()).getCategoryId()).getName().equalsIgnoreCase("Windows");
-vmData =
_networkModel.generateVmData(userVm.getUserData(), serviceOffering, zoneName,
vm.getInstanceName(), vm.getId(),
+vmData =
_networkModel.generateVmData(userVm.getUserData(), serviceOffering, zoneName,
vm.getInstanceName(), vm.getHostName(), vm.getId(),
Review comment:
There is no displayname parameter in VirtualMachine.java. Also hostName
refers to name parameter only
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
> Hostname in metadata when using external DNS is incorrect
> -
>
> Key: CLOUDSTACK-10292
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10292
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: mrunalini
>Priority: Major
>
> In the current implementation, both the local-hostname and instance-id in the
> metadata are pointing to same thing when VM is deployed in a network with
> Network Offering that has no services.
> The metadata for the VM is presented in configdrive.iso for a VM having
> network with network offering that has no services. However the metadata
> doesn't have any info around the name of the VM user has passed when
> deploying the VM, instead the local_hostname.txt in the metadata refers to VM
> internal name "i-12-254-VM" doesn't it needs to be the name of the VM user
> has passed when creating the VM?
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-9338) updateResourceCount not accounting resources of VMs with custom service offering
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16372841#comment-16372841 ] ASF GitHub Bot commented on CLOUDSTACK-9338: blueorangutan commented on issue #2443: [CLOUDSTACK-9338] ACS is not accounting resources of VMs with custom service offering properly URL: https://github.com/apache/cloudstack/pull/2443#issuecomment-367692266 @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 > updateResourceCount not accounting resources of VMs with custom service > offering > > > Key: CLOUDSTACK-9338 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9338 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Cloudmonkey, UI >Affects Versions: 4.5.2, 4.8.0 > Environment: CloudStack 4.5.1 > MariaDB 10.0 and 10.1 >Reporter: Francois Scheurer >Assignee: Rafael Weingärtner >Priority: Major > > listAccount on a domain returns 0 for cputotal and memorytotal if the domain > accounts own VMs using a ComputeOffering with custom=enabled. > Basically, looking into the vm_instance table you get the service_offering_id > and in the service_offering table you find normally the amount of CPU/RAM > allocated for the VM. > But if your VM's ComputeOffering has custom=enabled, then you need to get the > specific CPU/RAM values from the user_vm_details table: > mysql> select * from user_vm_details WHERE vm_id=957; > Apparently the listAccount code is not doing that and it just returns zero, > because the service_offering table has cpu=0 and ram_size=0 for > ComputeOfferings with custom=enabled. > solution: the SQL query of listAccount should also look in the > user_vm_details table for matching rows. (instead of just querying in the > service_offering table) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-9338) updateResourceCount not accounting resources of VMs with custom service offering
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9338?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16372840#comment-16372840 ] ASF GitHub Bot commented on CLOUDSTACK-9338: borisstoyanov commented on issue #2443: [CLOUDSTACK-9338] ACS is not accounting resources of VMs with custom service offering properly URL: https://github.com/apache/cloudstack/pull/2443#issuecomment-367692200 @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 > updateResourceCount not accounting resources of VMs with custom service > offering > > > Key: CLOUDSTACK-9338 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9338 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Cloudmonkey, UI >Affects Versions: 4.5.2, 4.8.0 > Environment: CloudStack 4.5.1 > MariaDB 10.0 and 10.1 >Reporter: Francois Scheurer >Assignee: Rafael Weingärtner >Priority: Major > > listAccount on a domain returns 0 for cputotal and memorytotal if the domain > accounts own VMs using a ComputeOffering with custom=enabled. > Basically, looking into the vm_instance table you get the service_offering_id > and in the service_offering table you find normally the amount of CPU/RAM > allocated for the VM. > But if your VM's ComputeOffering has custom=enabled, then you need to get the > specific CPU/RAM values from the user_vm_details table: > mysql> select * from user_vm_details WHERE vm_id=957; > Apparently the listAccount code is not doing that and it just returns zero, > because the service_offering table has cpu=0 and ram_size=0 for > ComputeOfferings with custom=enabled. > solution: the SQL query of listAccount should also look in the > user_vm_details table for matching rows. (instead of just querying in the > service_offering table) -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Assigned] (CLOUDSTACK-10303) refactor plugins/nuagevsp tests to run from its own test_data.py file
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10303?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Frank Maximus reassigned CLOUDSTACK-10303: -- Assignee: Sigert Goeminne > refactor plugins/nuagevsp tests to run from its own test_data.py file > - > > Key: CLOUDSTACK-10303 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10303 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) > Components: marvin >Affects Versions: 4.11.0.0 > Environment: nuagevsp, simulator >Reporter: Raf Smeets >Assignee: Sigert Goeminne >Priority: Major > > refactor plugins/nuagevsp tests to run from its own test_data.py file and > make sure that all nuagevsp tests run with simulator. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Created] (CLOUDSTACK-10303) refactor plugins/nuagevsp tests to run from its own test_data.py file
Raf Smeets created CLOUDSTACK-10303: --- Summary: refactor plugins/nuagevsp tests to run from its own test_data.py file Key: CLOUDSTACK-10303 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10303 Project: CloudStack Issue Type: Improvement Security Level: Public (Anyone can view this level - this is the default.) Components: marvin Affects Versions: 4.11.0.0 Environment: nuagevsp, simulator Reporter: Raf Smeets refactor plugins/nuagevsp tests to run from its own test_data.py file and make sure that all nuagevsp tests run with simulator. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10292) Hostname in metadata when using external DNS is incorrect
[
https://issues.apache.org/jira/browse/CLOUDSTACK-10292?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16372746#comment-16372746
]
ASF GitHub Bot commented on CLOUDSTACK-10292:
-
rafaelweingartner commented on a change in pull request #2455:
CLOUDSTACK-10292:Hostname in metadata when using external DNS is inco…
URL: https://github.com/apache/cloudstack/pull/2455#discussion_r169939634
##
File path:
engine/orchestration/src/main/java/com/cloud/vm/VirtualMachineManagerImpl.java
##
@@ -2526,7 +2526,7 @@ private void orchestrateMigrateWithStorage(final String
vmUuid, final long srcHo
final String zoneName =
_dcDao.findById(vm.getDataCenterId()).getName();
boolean isWindows =
_guestOSCategoryDao.findById(_guestOSDao.findById(vm.getGuestOSId()).getCategoryId()).getName().equalsIgnoreCase("Windows");
-vmData =
_networkModel.generateVmData(userVm.getUserData(), serviceOffering, zoneName,
vm.getInstanceName(), vm.getId(),
+vmData =
_networkModel.generateVmData(userVm.getUserData(), serviceOffering, zoneName,
vm.getInstanceName(), vm.getHostName(), vm.getId(),
Review comment:
@mrunalinikankariya you want to send the name set by the user for the given
VM, right? They are the parameters "displayname" and "name" that the user can
enter when deploying a VM.
Even though this "hostName" contains that parameter "name", I get the
feeling that it is not the right one to use. It looks like an inconsistent sent
of value that can and should be fixed in the future. If you look into the VM's
POJO, we have hostId and hostName; for sanity, I would consider them the same
thing. Therefore, hostId is the id of the host where the VM is running, and the
hostName is the name of the host where the VM is running.
Therefore, I believe you should use "displayName" or "name" attributes
instead of the "hostName".
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
> Hostname in metadata when using external DNS is incorrect
> -
>
> Key: CLOUDSTACK-10292
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10292
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
>Reporter: mrunalini
>Priority: Major
>
> In the current implementation, both the local-hostname and instance-id in the
> metadata are pointing to same thing when VM is deployed in a network with
> Network Offering that has no services.
> The metadata for the VM is presented in configdrive.iso for a VM having
> network with network offering that has no services. However the metadata
> doesn't have any info around the name of the VM user has passed when
> deploying the VM, instead the local_hostname.txt in the metadata refers to VM
> internal name "i-12-254-VM" doesn't it needs to be the name of the VM user
> has passed when creating the VM?
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
[jira] [Commented] (CLOUDSTACK-10254) Require checkstyle to verify package names against directory structure
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10254?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16372574#comment-16372574 ] ASF GitHub Bot commented on CLOUDSTACK-10254: - marcaurele commented on issue #2422: [CLOUDSTACK-10254] checkstyle: add package name declaration validation URL: https://github.com/apache/cloudstack/pull/2422#issuecomment-367614531 @rafaelweingartner I'd rather push all together since it does not disturb the build. I had a hard time finding the solution for the generated classes. I'm down to the apidoc project, which requires a fix and it should all be good. 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 > Require checkstyle to verify package names against directory structure > -- > > Key: CLOUDSTACK-10254 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10254 > Project: CloudStack > Issue Type: Improvement > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Marc-Aurèle Brothier >Assignee: Marc-Aurèle Brothier >Priority: Major > > Enforce a new rule for checkstyle to verify that the java file location and > its package name match. -- This message was sent by Atlassian JIRA (v7.6.3#76005)
