Re: cloudmonkey config file get reset to default settings
Correction from previous reply: "I'll see what I can do, in general you should NOT be replacing or changing the cloudmonkey config file outside of cloudmonkey itself." Regards, Rohit Yadav rohit.ya...@shapeblue.com www.shapeblue.com 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue On May 26 2016, at 11:27 am, Rohit Yadav wrote: Whenever a set command is called, it would save/update the config file. When you run set profile xyz; it needs to make that profile the default profile and update other parameters associated with the profile which may be set as well (such as url, username, password, apikey, secretkey etc). When cloudmonkey is running, and you replace the config file; on calling 'set' it would save the config file based on its in-memory config dictionary. I'll see what I can do, in general you should be replacing or changing the cloudmonkey config file outside of cloudmonkey itself. If you want to create new profile, set new rules; you should call cloudmonkey set either on command line or use puppet to execute them. The tool was intended for single user, in case of multi-user or concurrent usage, there is no concurrency control wrt configs. One solution could be that, each server profile has their own config file instead of a single config file, and you can start cloudmonkey to pick a server profile with a command line flag such as -p . I'll see how I may improve this, for this I would like to know how exactly you are using puppet or any other automation? Regards, Rohit Yadav On May 26 2016, at 3:40 am, ilya wrote: I've seen the similar behaviour. For some reason cloudmonkey try to persist the configs each time your run something. If i open cloudmonkey in multiple terminals and use different profiles and execute commands in mutliple terminals in parallel - i've seen cloudmonkey mess up the config for one of open profiles. Specifically, the URL of cloudstack in profile1 might be changed with url of cloudstack in profile2. Rohit, is there a reason why cloudmonkey tries to update the settings in config file each time something gets executed? On 5/24/16 1:31 PM, Yiping Zhang wrote: > Hi, > > We have a few scripts that use cloudmonkey to talk to CloudStack server. The > scripts are invoked by Puppet once per hour. > > However, every once a while, the /root/.cloudmonkey/config file would be over > written with default settings. That is, blank apikey/secretkey, default > password, default log file location etc. > > I am wondering by any chance that cloudmonkey would put a default config file > in place for some reason ? > > Thanks, > > Yiping >
Re: cloudmonkey config file get reset to default settings
Whenever a set command is called, it would save/update the config file. When you run set profile xyz; it needs to make that profile the default profile and update other parameters associated with the profile which may be set as well (such as url, username, password, apikey, secretkey etc). When cloudmonkey is running, and you replace the config file; on calling 'set' it would save the config file based on its in-memory config dictionary. I'll see what I can do, in general you should be replacing or changing the cloudmonkey config file outside of cloudmonkey itself. If you want to create new profile, set new rules; you should call cloudmonkey set either on command line or use puppet to execute them. The tool was intended for single user, in case of multi-user or concurrent usage, there is no concurrency control wrt configs. One solution could be that, each server profile has their own config file instead of a single config file, and you can start cloudmonkey to pick a server profile with a command line flag such as -p . I'll see how I may improve this, for this I would like to know how exactly you are using puppet or any other automation? Regards, Rohit Yadav On May 26 2016, at 3:40 am, ilya wrote: I've seen the similar behaviour. For some reason cloudmonkey try to persist the configs each time your run something. If i open cloudmonkey in multiple terminals and use different profiles and execute commands in mutliple terminals in parallel - i've seen cloudmonkey mess up the config for one of open profiles. Specifically, the URL of cloudstack in profile1 might be changed with url of cloudstack in profile2. Rohit, is there a reason why cloudmonkey tries to update the settings in config file each time something gets executed? On 5/24/16 1:31 PM, Yiping Zhang wrote: > Hi, > > We have a few scripts that use cloudmonkey to talk to CloudStack server. The > scripts are invoked by Puppet once per hour. > > However, every once a while, the /root/.cloudmonkey/config file would be over > written with default settings. That is, blank apikey/secretkey, default > password, default log file location etc. > > I am wondering by any chance that cloudmonkey would put a default config file > in place for some reason ? > > Thanks, > > Yiping > rohit.ya...@shapeblue.com www.shapeblue.com 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue
Re: The libvirt version for production
EL7.2 build of linux with all KVM dependencies works well.. On 5/23/16 5:01 PM, Lv Haijiao wrote: > hi, Community > > We are trying to upgrade libvirt from 1.2.2. to a higher version in our > production environment. > > As there are so many releases, anyone can share advice or experience for a > stable one ? or if we can always adopt the latest one ? > > Thanks in advance ! >
Re: cloudmonkey config file get reset to default settings
I've seen the similar behaviour. For some reason cloudmonkey try to persist the configs each time your run something. If i open cloudmonkey in multiple terminals and use different profiles and execute commands in mutliple terminals in parallel - i've seen cloudmonkey mess up the config for one of open profiles. Specifically, the URL of cloudstack in profile1 might be changed with url of cloudstack in profile2. Rohit, is there a reason why cloudmonkey tries to update the settings in config file each time something gets executed? On 5/24/16 1:31 PM, Yiping Zhang wrote: > Hi, > > We have a few scripts that use cloudmonkey to talk to CloudStack server. The > scripts are invoked by Puppet once per hour. > > However, every once a while, the /root/.cloudmonkey/config file would be over > written with default settings. That is, blank apikey/secretkey, default > password, default log file location etc. > > I am wondering by any chance that cloudmonkey would put a default config file > in place for some reason ? > > Thanks, > > Yiping >
RE: CloudStack installation error on CentOS_7: python2.6 & Apache6
Hey there, What are you using as your base url? It sounds like you're pointing to a repo which only contains RPMs for CentOS6 Kind regards, Paul Angus paul.an...@shapeblue.com www.shapeblue.com 53 Chandos Place, Covent Garden, London WC2N 4HSUK @shapeblue -Original Message- From: Star Guo [mailto:ghxand...@gmail.com] Sent: 25 May 2016 13:20 To: users@cloudstack.apache.org Subject: Re: CloudStack installation error on CentOS_7: python2.6 & Apache6 cloudstack-common-4.6.0-1.el6.x86_64，this package is for CentOS 6.x ,not for CentOS 7.2. Setup correct yum repo for CentOS 7.x and then install. Best Regards, Star Guo 2016-05-25 20:00 GMT+08:00 Osman, Taha : > Hello, > > I’ve been attempting to install CloudStack on CentOS 7. The > installation fails at the stage of the management server (# yum -y > install cloudstack-management). > The error report is below. It appears that the package dependencies do > not accept the CentOS updated versions of Python and Apache. > > Error: Package: cloudstack-common-4.6.0-1.el6.x86_64 (cloudstack) >Requires: python(abi) = 2.6 >Installed: python-2.7.5-34.el7.x86_64 (@anaconda) >python(abi) = 2.7 >python(abi) = 2.7 > Error: Package: cloudstack-management-4.6.0-1.el6.x86_64 (cloudstack) >Requires: tomcat6 > You could try using --skip-broken to work around the problem You > could try running: rpm -Va --nofiles --nodigest [root@localhost > Downloads]# rpm -Va --nofiles --nodigest > > The suggested workarounds didn’t solve the problem. Can anyone suggest > a solution? > > > Thanks > > Taha > > -- > > Taha Osman > > Computing and Technology > > School of Science and Technology > > Nottingham Trent University > > Nottingham NG11 8NS > > DISCLAIMER: This email is intended solely for the addressee. It may > contain private and confidential information. If you are not the > intended addressee, please take no action based on it nor show a copy > to anyone. In this case, please reply to this email to highlight the > error. Opinions and information in this email that do not relate to > the official business of Nottingham Trent University shall be > understood as neither given nor endorsed by the University. Nottingham > Trent University has taken steps to ensure that this email and any > attachments are virus-free, but we do advise that the recipient should > check that the email and its attachments are actually virus free. This is in > keeping with good computing practice. >
CLOUDSTACK-9238: Template download URL length really fixed ?
Hello,
I’m investigating an issue on CS 4.8.0 when registering an ISO with a
long URL (>255 chars). The only issue related to it that I could find
is https://issues.apache.org/jira/browse/CLOUDSTACK-9238.
Basically, the problem could be reproduced by entering an URL with
more that 255 chars in the ISO URL. The API fails with a parameter
error.
Since the database schema seems fine according to CLOUDSTACK-9238 - my
current database matches that at least - I tried to change the
Parameter annotation to length 2048 (see first patch below); Then the
API request is accepted, but the URL appears truncated in the SSVM
logs:
URL was:
https://github-cloud.s3.amazonaws.com/releases/28796010/774188bc-18fc-11e6-8140-4cf8a5632e15.iso?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAISTNZFOVBIJMK3TQ%2F20160525%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20160525T125103Z&X-Amz-Expires=300&X-Amz-Signature=d40de63959eed194d0bbb7c702cf71d65a7aa91f427e33714fde64b76aebf6d8&X-Amz-SignedHeaders=host&actor_id=0&response-content-disposition=attachment%3B%20filename%3Drancheros.iso&response-content-type=application%2Foctet-stream
SSVM gets a 255-char truncated URL (the management server logs shows
that it sends only 255 chars also).
2016-05-25 12:51:16,961 DEBUG [cloud.agent.Agent]
(agentRequest-Handler-1:null) Request:Seq 57-4400016835940974604: {
Cmd , MgmtId: 345049980494, via: 57, Ver: v1, Flags: 100011,
[{"org.apache.cloudstack.storage.command.DownloadCommand":{"hvm":true,"description":"ros","maxDownloadSizeInBytes":53687091200,"id":353,"resourceType":"TEMPLATE","installPath":"template/tmpl/2/353","_store":{"com.cloud.agent.api.to.NfsTO":{"_url":"nfs://10.87.80.250/cloudstack_secondary_z1","_role":"Image"}},"url":"https://github-cloud.s3.amazonaws.com/releases/28796010/774188bc-18fc-11e6-8140-4cf8a5632e15.iso?X-Amz-Algorithm=AWS4-HMAC-SHA256&X-Amz-Credential=AKIAISTNZFOVBIJMK3TQ%2F20160525%2Fus-east-1%2Fs3%2Faws4_request&X-Amz-Date=20160525T125103Z&X-Amz-Expires=30","format":"ISO","accountId":2,"name":"353-2-34ec5c80-b6ff-3d3d-8c09-7ac1f3755d3d","secUrl":"nfs://10.87.80.250/cloudstack_secondary_z1","wait":0}}]
}
I also tried setting the length of the fields in the *VO objects (see
second patch below), but I’m not exactly sure of what i’m doing there.
Does anyone have a hint at where to look to find where the string is
truncated and why ?
— Patch for API
diff -ru
a/apache-cloudstack-4.8.0-src/api/src/org/apache/cloudstack/api/command/user/iso/RegisterIsoCmd.java
b/apache-cloudstack-4.8.0-src/api/src/org/apache/cloudstack/api/command/user/iso/RegisterIsoCmd.java
---
a/apache-cloudstack-4.8.0-src/api/src/org/apache/cloudstack/api/command/user/iso/RegisterIsoCmd.java
2016-01-20 23:43:35.0 +0100
+++
b/apache-cloudstack-4.8.0-src/api/src/org/apache/cloudstack/api/command/user/iso/RegisterIsoCmd.java
2016-05-25 09:40:25.0 +0200
@@ -78,7 +78,11 @@
description = "the ID of the OS type that best
represents the OS of this ISO. If the ISO is bootable this parameter
needs to be passed")
private Long osTypeId;
-@Parameter(name = ApiConstants.URL, type = CommandType.STRING,
required = true, description = "the URL to where the ISO is currently
being hosted")
+@Parameter(name = ApiConstants.URL,
+ type = CommandType.STRING,
+ required = true,
+ description = "the URL to where the ISO is currently
being hosted",
+ length = 2048)
private String url;
@Parameter(name=ApiConstants.ZONE_ID, type=CommandType.UUID,
entityType = ZoneResponse.class,
— Patch for columns
diff -ru
a/apache-cloudstack-4.8.0-src/engine/schema/src/org/apache/cloudstack/storage/datastore/db/TemplateDataStoreVO.java
b/apache-cloudstack-4.8.0-src/engine/schema/src/org/apache/cloudstack/storage/datastore/db/TemplateDataStoreVO.java
---
a/apache-cloudstack-4.8.0-src/engine/schema/src/org/apache/cloudstack/storage/datastore/db/TemplateDataStoreVO.java
2016-01-20 23:43:35.0 +0100
+++
b/apache-cloudstack-4.8.0-src/engine/schema/src/org/apache/cloudstack/storage/datastore/db/TemplateDataStoreVO.java
2016-05-25 14:12:18.0 +0200
@@ -95,7 +95,7 @@
@Column(name = "install_path")
private String installPath;
-@Column(name = "url")
+@Column(name = "url", length = 2048)
private String downloadUrl;
@Column(name = "download_url")
Thanks,
Best regards,
--
Aurélien Guillaume
Re: CloudStack installation error on CentOS_7: python2.6 & Apache6
cloudstack-common-4.6.0-1.el6.x86_64，this package is for CentOS 6.x ,not for CentOS 7.2. Setup correct yum repo for CentOS 7.x and then install. Best Regards, Star Guo 2016-05-25 20:00 GMT+08:00 Osman, Taha : > Hello, > > I’ve been attempting to install CloudStack on CentOS 7. The installation > fails at the stage of the management server (# yum -y install > cloudstack-management). > The error report is below. It appears that the package dependencies do not > accept the CentOS updated versions of Python and Apache. > > Error: Package: cloudstack-common-4.6.0-1.el6.x86_64 (cloudstack) >Requires: python(abi) = 2.6 >Installed: python-2.7.5-34.el7.x86_64 (@anaconda) >python(abi) = 2.7 >python(abi) = 2.7 > Error: Package: cloudstack-management-4.6.0-1.el6.x86_64 (cloudstack) >Requires: tomcat6 > You could try using --skip-broken to work around the problem > You could try running: rpm -Va --nofiles --nodigest > [root@localhost Downloads]# rpm -Va --nofiles --nodigest > > The suggested workarounds didn’t solve the problem. Can anyone suggest a > solution? > > > Thanks > > Taha > > -- > > Taha Osman > > Computing and Technology > > School of Science and Technology > > Nottingham Trent University > > Nottingham NG11 8NS > > DISCLAIMER: This email is intended solely for the addressee. It may > contain private and confidential information. If you are not the intended > addressee, please take no action based on it nor show a copy to anyone. In > this case, please reply to this email to highlight the error. Opinions and > information in this email that do not relate to the official business of > Nottingham Trent University shall be understood as neither given nor > endorsed by the University. Nottingham Trent University has taken steps to > ensure that this email and any attachments are virus-free, but we do advise > that the recipient should check that the email and its attachments are > actually virus free. This is in keeping with good computing practice. >
CloudStack installation error on CentOS_7: python2.6 & Apache6
Hello, I’ve been attempting to install CloudStack on CentOS 7. The installation fails at the stage of the management server (# yum -y install cloudstack-management). The error report is below. It appears that the package dependencies do not accept the CentOS updated versions of Python and Apache. Error: Package: cloudstack-common-4.6.0-1.el6.x86_64 (cloudstack) Requires: python(abi) = 2.6 Installed: python-2.7.5-34.el7.x86_64 (@anaconda) python(abi) = 2.7 python(abi) = 2.7 Error: Package: cloudstack-management-4.6.0-1.el6.x86_64 (cloudstack) Requires: tomcat6 You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest [root@localhost Downloads]# rpm -Va --nofiles --nodigest The suggested workarounds didn’t solve the problem. Can anyone suggest a solution? Thanks Taha -- Taha Osman Computing and Technology School of Science and Technology Nottingham Trent University Nottingham NG11 8NS DISCLAIMER: This email is intended solely for the addressee. It may contain private and confidential information. If you are not the intended addressee, please take no action based on it nor show a copy to anyone. In this case, please reply to this email to highlight the error. Opinions and information in this email that do not relate to the official business of Nottingham Trent University shall be understood as neither given nor endorsed by the University. Nottingham Trent University has taken steps to ensure that this email and any attachments are virus-free, but we do advise that the recipient should check that the email and its attachments are actually virus free. This is in keeping with good computing practice.
