[jira] [Updated] (CLOUDSTACK-8398) Changing compute offering checks account quota instead of project quota
[ https://issues.apache.org/jira/browse/CLOUDSTACK-8398?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion updated CLOUDSTACK-8398: Affects Version/s: 4.7.1 > Changing compute offering checks account quota instead of project quota > --- > > Key: CLOUDSTACK-8398 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-8398 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Affects Versions: 4.4.1, 4.7.1 >Reporter: Francois Gaudreault > > When triggering a change compute offering on an instance, it check the > account quotas instead of the project quota. > To reproduce: > - Create account > - Set all account quota to 0 > - Create Project with some quotas, and add the account to it > - Create a VM > - Try to change to offering. > It will fail with a account quota error even if you have plenty of available > space in the project. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9489) When upgrading, Config.java new configuration are not updated.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9489?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre-Luc Dion updated CLOUDSTACK-9489:
Affects Version/s: 4.6.2
> When upgrading, Config.java new configuration are not updated.
> --
>
> Key: CLOUDSTACK-9489
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9489
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.6.2, 4.7.1, 4.8.0, 4.9.0
>Reporter: Pierre-Luc Dion
>
> When Upgrading CloudStack, new configurations (Global Settings) defined in
> {{server/src/com/cloud/configuration/Config.java}} are not populated.
> This file changed in 4.5 and 4.6 and those configurations are not applied
> when upgrading to post 4.6.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9489) When upgrading, Config.java new configuration are not updated.
Pierre-Luc Dion created CLOUDSTACK-9489:
---
Summary: When upgrading, Config.java new configuration are not
updated.
Key: CLOUDSTACK-9489
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9489
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Management Server
Affects Versions: 4.9.0, 4.8.0, 4.7.1
Reporter: Pierre-Luc Dion
When Upgrading CloudStack, new configurations (Global Settings) defined in
{{server/src/com/cloud/configuration/Config.java}} are not populated.
This file changed in 4.5 and 4.6 and those configurations are not applied when
upgrading to post 4.6.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9489) When upgrading, Config.java new configuration are not updated.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15458890#comment-15458890
]
Pierre-Luc Dion commented on CLOUDSTACK-9489:
-
When Upgrading CloudStack to apply changes from Config.java, we need to set
configuration::init to false
Prior to start CloudStack management server after upgrading is packages, we
must change the init value:
in MySQL database:
{code}
use cloud;
update configuration set value='false' where name='init';
{code}
> When upgrading, Config.java new configuration are not updated.
> --
>
> Key: CLOUDSTACK-9489
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9489
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.6.2, 4.7.1, 4.8.0, 4.9.0
>Reporter: Pierre-Luc Dion
>
> When Upgrading CloudStack, new configurations (Global Settings) defined in
> {{server/src/com/cloud/configuration/Config.java}} are not populated.
> This file changed in 4.5 and 4.6 and those configurations are not applied
> when upgrading to post 4.6.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9489) When upgrading, Config.java new configuration are not updated.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15464901#comment-15464901
]
Pierre-Luc Dion commented on CLOUDSTACK-9489:
-
I think I've wrongly describe the problem. I've experience the issue while
upgrading packages (rpm). But the resolution should not be fixed in the code
itself, not in package description, because the issue can be replicated when
building CloudStack from source and run it inside Jetty.
> When upgrading, Config.java new configuration are not updated.
> --
>
> Key: CLOUDSTACK-9489
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9489
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.6.2, 4.7.1, 4.8.0, 4.9.0
>Reporter: Pierre-Luc Dion
>
> When Upgrading CloudStack, new configurations (Global Settings) defined in
> {{server/src/com/cloud/configuration/Config.java}} are not populated.
> This file changed in 4.5 and 4.6 and those configurations are not applied
> when upgrading to post 4.6.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9500) VR configuration not clean properly after Public IP release
Pierre-Luc Dion created CLOUDSTACK-9500:
---
Summary: VR configuration not clean properly after Public IP
release
Key: CLOUDSTACK-9500
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9500
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Virtual Router
Affects Versions: 4.9.0, 4.7.0
Reporter: Pierre-Luc Dion
On a VPC, releasing a public IP that had Port Forwarding does not remove
configuration of the public IP on the VR configs
({{/etc/cloudstack/forwardingrules.json}}, {{/etc/cloudstack/ips.json}})
So, when this IP is reassign to another VPC, it cause arp table issues on
switches, because 2 MAC try to own this IP from 2 different VRs. the IP on the
old VR is not pignable but the switches arp table get updated every time the
previous VR have configuration changes.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-9489) When upgrading, Config.java new configuration are not updated.
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9489?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15513772#comment-15513772
]
Pierre-Luc Dion commented on CLOUDSTACK-9489:
-
Hi,
Here is the configuration table diff from a fresh 4.7 and my 4.4 upgraded to 4.7
Those settings are missing from my upgraded environment:
{code}
baremetal.internal.storage.server.ip
baremetal.provision.done.notification.enabled
baremetal.provision.done.notification.port
baremetal.provision.done.notification.timeout
enable.secure.session.cookie
ovm3.guest.network.device
ovm3.private.network.device
ovm3.public.network.device
ovm3.storage.network.device
publish.action.events
publish.alert.events
publish.async.job.events
publish.resource.state.events
publish.usage.events
xenserver.heartbeat.timeout
{code}
Those settings are defined and created in the Java.config file and not from a
.sql file. I did test changing the init settings to false but this seams to
reset the encryption of the database so login is not working anymore after the
restart of the management server.
> When upgrading, Config.java new configuration are not updated.
> --
>
> Key: CLOUDSTACK-9489
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9489
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
>Affects Versions: 4.6.2, 4.7.1, 4.8.0, 4.9.0
>Reporter: Pierre-Luc Dion
>Assignee: Pierre-Luc Dion
>Priority: Blocker
>
> When Upgrading CloudStack, new configurations (Global Settings) defined in
> {{server/src/com/cloud/configuration/Config.java}} are not populated.
> This file changed in 4.5 and 4.6 and those configurations are not applied
> when upgrading to post 4.6.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9651) Fix Docker image build of simulator, marvin and management-server.
Pierre-Luc Dion created CLOUDSTACK-9651: --- Summary: Fix Docker image build of simulator, marvin and management-server. Key: CLOUDSTACK-9651 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9651 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Packaging Affects Versions: 4.9.0, 4.8.0, 4.7.0 Reporter: Pierre-Luc Dion Assignee: Pierre-Luc Dion Fixe automated build of docker image for cloudstack-simulator, cloudstack-management and cloudstack-marvin. Automate release changes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Updated] (CLOUDSTACK-9651) Fix Docker image build of simulator, marvin and management-server.
[ https://issues.apache.org/jira/browse/CLOUDSTACK-9651?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion updated CLOUDSTACK-9651: Labels: docker (was: ) > Fix Docker image build of simulator, marvin and management-server. > -- > > Key: CLOUDSTACK-9651 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9651 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Packaging >Affects Versions: 4.7.0, 4.8.0, 4.9.0 >Reporter: Pierre-Luc Dion >Assignee: Pierre-Luc Dion > Labels: docker > > Fixe automated build of docker image for cloudstack-simulator, > cloudstack-management and cloudstack-marvin. > Automate release changes. -- This message was sent by Atlassian JIRA (v6.3.4#6332)
[jira] [Created] (CLOUDSTACK-9658) Load-Balancer (haproxy) should support timeout tuning when creating LB rules
Pierre-Luc Dion created CLOUDSTACK-9658:
---
Summary: Load-Balancer (haproxy) should support timeout tuning
when creating LB rules
Key: CLOUDSTACK-9658
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9658
Project: CloudStack
Issue Type: Improvement
Security Level: Public (Anyone can view this level - this is the default.)
Components: Network Controller, Virtual Router
Reporter: Pierre-Luc Dion
Priority: Trivial
current haproxy configuration when using Load-Balancing in a VPC scenario
contain hardcoded timeout parameter that could be define by the user:
current default values:
{code}
timeout connect5000
timeout client 5
timeout server 5
{code}
would be intereinst to support change of them via the API when creating
load-balancing.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
[jira] [Commented] (CLOUDSTACK-10089) log4j version 1 is (beyond) end of life
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10089?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16181768#comment-16181768 ] Pierre-Luc Dion commented on CLOUDSTACK-10089: -- +1, This should allow us to send logs into different format. > log4j version 1 is (beyond) end of life > > > Key: CLOUDSTACK-10089 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10089 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Daan Hoogland >Assignee: Daan Hoogland > > maintenance and more flexible configuration and in addition and some new > features like more advanced types of appenders make this upgrade lucrative, > It is crosscutting and will leed to conflicts for many developers. > (communication needed ;) -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CLOUDSTACK-10115) duplicate hostname in VPC dns service
Pierre-Luc Dion created CLOUDSTACK-10115:
Summary: duplicate hostname in VPC dns service
Key: CLOUDSTACK-10115
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10115
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Virtual Router
Affects Versions: 4.10.0.0
Reporter: Pierre-Luc Dion
in ACS 4.10.0.0 on a VPC, create a vm, destroy it create a new VM with the
same name and hostname as the first, then execute the command {dig
@}} and you will get multiple ip for the vm. this is problematic when
using hostname resolution inside a VPC where VMs has been recreated using old
hostname.
This issue has been introduced by the PR:
https://github.com/apache/cloudstack/pull/2082
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-9862) list template with id= no longer work as domain admin
[
https://issues.apache.org/jira/browse/CLOUDSTACK-9862?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16287687#comment-16287687
]
Pierre-Luc Dion commented on CLOUDSTACK-9862:
-
Since there is a work around with {{ids=}} I guest this is a low priority. but
the previous commit did break a params that was previously working from the
API. So I think this current issue is still valid and should be fixed.
> list template with id= no longer work as domain admin
> -
>
> Key: CLOUDSTACK-9862
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9862
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Template
>Affects Versions: 4.10.0.0
>Reporter: Pierre-Luc Dion
>Priority: Critical
>
> As domain admin, listTemplates templatefilter=featured no longer work if id=
> is specified.
> Using cloudmonkey with domain-admin credential:
> {code}
> (beta2r1-ninja) > list templates templatefilter=featured filter=name,id
> count = 9
> template:
> +--+-+
> | id | name |
> +--+-+
> | 513b3a6d-c011-46f0-a4a3-2a954cadb673 | CoreOS Alpha 1367.5.0 |
> | 0c04d876-1f85-45a7-b6f4-504de435bf12 |Debian 8.5 PV base (64bit) |
> | 285f2203-449a-428f-997a-1ffbebbf1382 | CoreOS Alpha |
> | 332b6ca8-b3d6-42c7-83e5-60fe87be6576 | CoreOS Stable |
> | 3b705008-c186-464d-ad59-312d902420af | Windows Server 2016 std SPLA |
> | 4256aebe-a1c1-4b49-9993-de2bc712d521 | Ubuntu 16.04.01 HVM |
> | 59e6b00a-b88e-4539-aa3c-75c9c7e9fa6c | Ubuntu 14.04.5 HVM base (64bit) |
> | 3ab936eb-d8c2-44d8-a64b-17ad5adf8a51 | CentOS 6.8 PV |
> | 7de5d423-c91e-49cc-86e8-9d6ed6abd997 | CentOS 7.2 HVM |
> +--+-+
> (beta2r1-ninja) > list templates templatefilter=featured
> id=7de5d423-c91e-49cc-86e8-9d6ed6abd997 filter=name,id
> Error 531: Acct[b285d62e-0ec2-4a7c-b773-961595ec6356-Ninja-5664] does not
> have permission to operate within domain
> id=c9b4f83d-16eb-11e7-a8b9-367e6fe958a9
> cserrorcode = 4365
> errorcode = 531
> errortext = Acct[b285d62e-0ec2-4a7c-b773-961595ec6356-Ninja-5664] does not
> have permission to operate within domain
> id=c9b4f83d-16eb-11e7-a8b9-367e6fe958a9
> uuidList:
> (beta2r1-ninja) > list templates templatefilter=featured
> ids=7de5d423-c91e-49cc-86e8-9d6ed6abd997 filter=name,id
> count = 1
> template:
> +--++
> | id | name |
> +--++
> | 7de5d423-c91e-49cc-86e8-9d6ed6abd997 | CentOS 7.2 HVM |
> +--++
> {code}
--
This message was sent by Atlassian JIRA
(v6.4.14#64029)
[jira] [Commented] (CLOUDSTACK-10001) host memorytotal invalid
[ https://issues.apache.org/jira/browse/CLOUDSTACK-10001?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16303907#comment-16303907 ] Pierre-Luc Dion commented on CLOUDSTACK-10001: -- [~sahmed] Didn't you submit a PR on this one ? I thought we solved it for 4.10. Thanks, > host memorytotal invalid > > > Key: CLOUDSTACK-10001 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-10001 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.10.0.0 >Reporter: Pierre-Luc Dion >Assignee: Rohit Yadav >Priority: Minor > Attachments: xenserver-invalidmemory size.png > > > on XenServer, memory total of a XenServer is not properly reported and match > the value of memoryallocated. > This regression seams to have been introduced by: > https://github.com/apache/cloudstack/pull/2120 -- This message was sent by Atlassian JIRA (v6.4.14#64029)
[jira] [Created] (CLOUDSTACK-6766) missing admin doc section: 5.2. Using SSH Keys for Authentication
Pierre-Luc Dion created CLOUDSTACK-6766: --- Summary: missing admin doc section: 5.2. Using SSH Keys for Authentication Key: CLOUDSTACK-6766 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6766 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Doc Affects Versions: 4.3.0 Reporter: Pierre-Luc Dion Assignee: Pierre-Luc Dion Priority: Minor Section missing on Admin guide: Using SSH Keys for Authentication on http://docs.cloudstack.apache.org/projects/cloudstack-administration the search does not find the section and is not showing in the left panel. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-6766) missing admin doc section: 5.2. Using SSH Keys for Authentication
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6766?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion closed CLOUDSTACK-6766. --- Resolution: Fixed documentation exist, the search does not sort it properly. > missing admin doc section: 5.2. Using SSH Keys for Authentication > - > > Key: CLOUDSTACK-6766 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6766 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.3.0 >Reporter: Pierre-Luc Dion >Assignee: Pierre-Luc Dion >Priority: Minor > Labels: documentation > > Section missing on Admin guide: Using SSH Keys for Authentication > on > http://docs.cloudstack.apache.org/projects/cloudstack-administration > the search does not find the section and is not showing in the left panel. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-5567) enable VPC at region level
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5567?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14019441#comment-14019441 ] Pierre-Luc Dion commented on CLOUDSTACK-5567: - Does region wide VPC will only work across OVS enabled zones only or will also work on VLAN isolated advanced networking zones? > enable VPC at region level > -- > > Key: CLOUDSTACK-5567 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5567 > Project: CloudStack > Issue Type: New Feature > Security Level: Public(Anyone can view this level - this is the > default.) >Reporter: Murali Reddy >Assignee: Murali Reddy > Fix For: 4.4.0 > > > Currently VPC in CloudStack is a zone level entity. So tiers with in the VPC > are confined to the zone to which VPC belongs. For an application deployed in > current model of VPC failure of the zone is a single point of failure. It is > desirable to make VPC a region level entity, where tiers in the VPC can be > created in different zones of the region. When tiers can be created in > different zones, application hosted in VPC can be architected to be highly > available masking zone failures by having redundant tiers in different zones. > This enhancement targets only VPC tiers built with overlay networking. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6880) cloudstack-usage: invalid installation instructions
Pierre-Luc Dion created CLOUDSTACK-6880: --- Summary: cloudstack-usage: invalid installation instructions Key: CLOUDSTACK-6880 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6880 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Doc Environment: RTD Reporter: Pierre-Luc Dion Assignee: Pierre-Luc Dion Priority: Trivial http://cloudstack-installation.readthedocs.org/en/latest/optional_installation.html#installing-the-usage-server-optional Invalid installation instruction of cloudstack-usage. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-6886) Cannot add SDX Netscaler device
Pierre-Luc Dion created CLOUDSTACK-6886: --- Summary: Cannot add SDX Netscaler device Key: CLOUDSTACK-6886 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6886 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Network Devices Affects Versions: 4.3.0 Environment: CloudStack 4.3 build with noredist packages Reporter: Pierre-Luc Dion on CloudStack 4.3 with noredist packages, Adding a Netscaler device in Network Service Providers as "NetScaler SDX LoadBalancer" type failed with following error message: "Failed to enable ssl feature on load balancer due to null" Test perform using CloudStack webui. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6886) Cannot add SDX Netscaler device
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion updated CLOUDSTACK-6886: Attachment: cs4.3_SDXfail.png > Cannot add SDX Netscaler device > --- > > Key: CLOUDSTACK-6886 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6886 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Devices >Affects Versions: 4.3.0 > Environment: CloudStack 4.3 build with noredist packages >Reporter: Pierre-Luc Dion > Attachments: cs4.3_SDXfail.png > > > on CloudStack 4.3 with noredist packages, Adding a Netscaler device in > Network Service Providers as "NetScaler SDX LoadBalancer" type failed with > following error message: > "Failed to enable ssl feature on load balancer due to null" > Test perform using CloudStack webui. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6886) Cannot add SDX Netscaler device
[
https://issues.apache.org/jira/browse/CLOUDSTACK-6886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14026494#comment-14026494
]
Pierre-Luc Dion commented on CLOUDSTACK-6886:
-
{code}
2014-06-10 09:51:27,311 INFO [o.a.c.f.j.i.AsyncJobMonitor]
(Job-Executor-39:ctx-10f9f920) Add job-685 into job monitoring
2014-06-10 09:51:27,311 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Job-Executor-39:ctx-10f9f920) Executing AsyncJobVO {id:685, userId: 2,
accountId: 2, instanceType: None, instanceId: null, cmd:
com.cloud.api.commands.AddNetscalerLoadBalancerCmd, cmdInfo:
{"physicalnetworkid":"a0091e19-63df-4147-abe7-da843444f656","sessionkey":"tzSipsZZFnJzPJSz0UAxUTLNJtY\u003d","cmdEventType":"PHYSICAL.LOADBALANCER.ADD","gslbprovider":"false","ctxUserId":"2","httpmethod":"POST","gslbproviderpublicip":"","password":"nsroot","url":"https://172.16.0.20?publicinterface\u003d1/1\u0026privateinterface\u003d1/2\u0026numretries\u003d2\u0026lbdevicededicated\u003dfalse","response":"json","username":"nsroot","networkdevicetype":"NetscalerSDXLoadBalancer","gslbproviderprivateip":"","ctxAccountId":"2","ctxStartEventId":"3420"},
cmdVersion: 0, status: IN_PROGRESS, processStatus: 0, resultCode: 0, result:
null, initMsid: 6692297244834, completeMsid: null, lastUpdated: null,
lastPolled: null, created: null}
2014-06-10 09:51:28,113 DEBUG [o.a.c.f.j.i.AsyncJobManagerImpl]
(Job-Executor-39:ctx-10f9f920) Complete async job-685, jobStatus: FAILED,
resultCode: 530, result:
org.apache.cloudstack.api.response.ExceptionResponse/null/{"uuidList":[],"errorcode":530,"errortext":"Failed
to enable ssl feature on load balancer due to null"}
{code}
> Cannot add SDX Netscaler device
> ---
>
> Key: CLOUDSTACK-6886
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6886
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Network Devices
>Affects Versions: 4.3.0
> Environment: CloudStack 4.3 build with noredist packages
>Reporter: Pierre-Luc Dion
> Attachments: cs4.3_SDXfail.png
>
>
> on CloudStack 4.3 with noredist packages, Adding a Netscaler device in
> Network Service Providers as "NetScaler SDX LoadBalancer" type failed with
> following error message:
> "Failed to enable ssl feature on load balancer due to null"
> Test perform using CloudStack webui.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6886) Cannot add SDX Netscaler device
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14027647#comment-14027647 ] Pierre-Luc Dion commented on CLOUDSTACK-6886: - Yes the license is installed. we are suspecting it's a new feature added in 4.3 that seams to affect only SDX unit for the moment. CLOUDSTACK-4821 We are investigating with Syed... > Cannot add SDX Netscaler device > --- > > Key: CLOUDSTACK-6886 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6886 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Devices >Affects Versions: 4.3.0 > Environment: CloudStack 4.3 build with noredist packages >Reporter: Pierre-Luc Dion > Attachments: cs4.3_SDXfail.png > > > on CloudStack 4.3 with noredist packages, Adding a Netscaler device in > Network Service Providers as "NetScaler SDX LoadBalancer" type failed with > following error message: > "Failed to enable ssl feature on load balancer due to null" > Test perform using CloudStack webui. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-4568) Need to add this to the release note of 4.2
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4568?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion resolved CLOUDSTACK-4568. - Resolution: Fixed information added in 4.4.0 release-notes in General Upgrade Notes. > Need to add this to the release note of 4.2 > --- > > Key: CLOUDSTACK-4568 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4568 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.2.0 >Reporter: Bharat Kumar >Assignee: Pierre-Luc Dion > Labels: releasenotes > Fix For: 4.4.0 > > > After upgrade to 4.2 the mem.overporvisioning.factor and > cpu.overporvisioning.factor will be set to one that is the default value and > are at cluster level now. > In case if some one prior to the 4.2 was usign mem.overporvisioning.factor > and cpu.overporvisioning.factor after the upgrade these will be reset to one > and can be changed by editing the cluster settings. > All the clusters created after the upgrade will get created with the values > overcomit values specified at the global config by default. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-3381) Wrong instruction in CloudStack release notes
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3381?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14030120#comment-14030120
]
Pierre-Luc Dion commented on CLOUDSTACK-3381:
-
Can I close this issue? The script and release-notes are updated and now use:
{code}
nohup cloudstack-sysvmadm -d IP address -u cloud -p password -a > sysvm.log
2>&1 &
{code}
> Wrong instruction in CloudStack release notes
> -
>
> Key: CLOUDSTACK-3381
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3381
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Doc
>Affects Versions: 4.1.0
> Environment: Link to particular documentation article:
> http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.1.0/html/Release_Notes/upgrade-instructions.html
>Reporter: Aabd
>Assignee: Pierre-Luc Dion
> Labels: documentation
>
> The CloudStack upgrade instructions contains an error.
> At some point the reader is instructed to execute the command:
> nohup cloud-sysvmadm -d 192.168.1.5 -u cloud -p password -c -r > sysvm.log
> 2>&1 &
> This should be:
> nohup cloudstack-sysvmadm -d 192.168.1.5 -u cloud -p password -s -r >
> sysvm.log 2>&1 &
> * The "cloud-sysvmadm" script does not exist, this should be
> "cloudstack-sysvmadm".
> * The -c argument does not exist in the sysvmadm script. As a result of this
> of this, only the virtual router vm is restarted. A quick glance at the code
> of the sysvmadm scripts reveals that a reboot of the secondary storage vm and
> console proxy vm is initiated by the -s parameter.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-6902) Document in the release notes that OVS plug-in functionality is disrupted if ovsdaemon crashes
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion reassigned CLOUDSTACK-6902: --- Assignee: Pierre-Luc Dion > Document in the release notes that OVS plug-in functionality is disrupted if > ovsdaemon crashes > -- > > Key: CLOUDSTACK-6902 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6902 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.4.0 >Reporter: Murali Reddy >Assignee: Pierre-Luc Dion > Fix For: 4.4.0 > > > A critical functionality issue came out with CLOUDSTACK-6779. On XenServer it > is observed that on VIF unplug Ovs-Vswitchd is crashing resulting in loosing > all the openflow rules added to the bridge. Ovs daemon gets started and > creates a bridge but configure openflow rules are lost resulting in the > disruption of connectivity for the VM's on the host. > We need to document it in the release notes as a known issue. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-4497) [doc] Update Installation Guide
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4497?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14030134#comment-14030134 ] Pierre-Luc Dion commented on CLOUDSTACK-4497: - Radhika, I think we can close this issue since all references to cloudstack-* have been updated in the documentation? > [doc] Update Installation Guide > --- > > Key: CLOUDSTACK-4497 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4497 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Reporter: Radhika Nair > > • Update the supported operating systems and hypervisor versions. > • Where the current documentation directs you to run the script > cloud-setup-databases, use the > following name instead: cloudstack-setup-databases. > • When seeding the system VM template, use the following new path to the > script: /usr/share/ > cloudstack-common/scripts/storage/secondary/cloud-install-sys-tmplt. > • The location of Management Server configuration and properties files is now > /etc/cloudstack/ management/. For example, in database failover setup (an > optional part of installation), where the current documentation shows > /etc/cloud/management/db.properties, use the following path instead: > /etc/cloudstack/management/db.properties. > • The names of the Management Server and Usage Server services have changed > to cloudstack- management and cloudstack-usage. Use this name in commands to > start, stop, or restart these services. > • System VM templates have changed. Be sure to download the latest templates > from Location: To Be Supplied > • The location of the Management Server log file is now > /var/log/cloudstack/management/. > • (XenServer only) The script cloud-setup-bonding.sh is now located at > /usr/share/cloudstack- common/scripts/vm/hypervisor/xenserver/. > • (XenServer only) In the procedure for upgrading XenServer versions, you > copy some files from the Management Server to the XenServer host. The new > location of these files on the Management Server is > /usr/share/cloudstack-common/scripts/vm/hypervisor/xenserver and > /usr/share/cloudstack- common/scripts/vm/hypervisor/xenserver/xenserver60. > • (KVM only) During network configuration, where the current documentation > shows /etc/cloud/agent/agent.properties, use the following path instead: > /etc/cloudstack/agent/agent.properties. > • (KVM only) The location of the CloudPlatform KVM agent log file is now > /var/log/cloudstack/agent/. > • (KVM only) The location of configuration and properties files is now > /etc/cloudstack/agent. > • (KVM only) The name of the CloudPlatform agent script has changed to > cloudstack-agent. Use this name if you need to stop or restart the agent on > the KVM host. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-4467) [Doc] Enhance the Upgrade Section for Clarity
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion reassigned CLOUDSTACK-4467: --- Assignee: Pierre-Luc Dion > [Doc] Enhance the Upgrade Section for Clarity > - > > Key: CLOUDSTACK-4467 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4467 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Reporter: Radhika Nair >Assignee: Pierre-Luc Dion >Priority: Critical > Fix For: Future > > > Suggestion from Frank > the upgrade instructions should be divided in two parts. mgmt server upgrade > and kvm agent upgrade. upgrading cloud-agent is actually upgrading KVM agent > running on host. Putting them together will confuse customers who don't use > KVM > the same applies to upgrading xenserver and usage server. we should put them > in dedicated chapter, now all stuff are in a single chapter which is quite > confusing. > can we arrange them like this: > Upgrade management server > 4.0 to 4.2 > 2.2.x to 4.2 > Upgrade cloud agent > 4.0 to 4.2 > 2.2.x to 4.2 > Upgrade usage server > 4.0 to 4.2 > 2.2.x to 4.2 > Upgrade Xenserver host -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-4467) [Doc] Enhance the Upgrade Section for Clarity
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4467?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion resolved CLOUDSTACK-4467. - Resolution: Fixed Fix Version/s: (was: Future) 4.4.0 The Release-notes upgrade sections of 4.4.0 split cloudstack-agent upgrade from management-server. There is also speration between CentOS and Ubuntu based OS. > [Doc] Enhance the Upgrade Section for Clarity > - > > Key: CLOUDSTACK-4467 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4467 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Reporter: Radhika Nair >Assignee: Pierre-Luc Dion >Priority: Critical > Fix For: 4.4.0 > > > Suggestion from Frank > the upgrade instructions should be divided in two parts. mgmt server upgrade > and kvm agent upgrade. upgrading cloud-agent is actually upgrading KVM agent > running on host. Putting them together will confuse customers who don't use > KVM > the same applies to upgrading xenserver and usage server. we should put them > in dedicated chapter, now all stuff are in a single chapter which is quite > confusing. > can we arrange them like this: > Upgrade management server > 4.0 to 4.2 > 2.2.x to 4.2 > Upgrade cloud agent > 4.0 to 4.2 > 2.2.x to 4.2 > Upgrade usage server > 4.0 to 4.2 > 2.2.x to 4.2 > Upgrade Xenserver host -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-3381) Wrong instruction in CloudStack release notes
[
https://issues.apache.org/jira/browse/CLOUDSTACK-3381?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre-Luc Dion resolved CLOUDSTACK-3381.
-
Resolution: Fixed
Fix Version/s: 4.4.0
command line instruction updated as follow:
{code}
nohup cloudstack-sysvmadm -d IPaddress -u cloud -p password -a > sysvm.log 2>&1
&
{code}
> Wrong instruction in CloudStack release notes
> -
>
> Key: CLOUDSTACK-3381
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3381
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Doc
>Affects Versions: 4.1.0
> Environment: Link to particular documentation article:
> http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.1.0/html/Release_Notes/upgrade-instructions.html
>Reporter: Aabd
>Assignee: Pierre-Luc Dion
> Labels: documentation
> Fix For: 4.4.0
>
>
> The CloudStack upgrade instructions contains an error.
> At some point the reader is instructed to execute the command:
> nohup cloud-sysvmadm -d 192.168.1.5 -u cloud -p password -c -r > sysvm.log
> 2>&1 &
> This should be:
> nohup cloudstack-sysvmadm -d 192.168.1.5 -u cloud -p password -s -r >
> sysvm.log 2>&1 &
> * The "cloud-sysvmadm" script does not exist, this should be
> "cloudstack-sysvmadm".
> * The -c argument does not exist in the sysvmadm script. As a result of this
> of this, only the virtual router vm is restarted. A quick glance at the code
> of the sysvmadm scripts reveals that a reboot of the secondary storage vm and
> console proxy vm is initiated by the -s parameter.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-6901) Document in the release notes that OVS plug-in functionality is disrupted if ovsdaemon crashes
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion reassigned CLOUDSTACK-6901: --- Assignee: Pierre-Luc Dion > Document in the release notes that OVS plug-in functionality is disrupted if > ovsdaemon crashes > -- > > Key: CLOUDSTACK-6901 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6901 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.4.0 >Reporter: Murali Reddy >Assignee: Pierre-Luc Dion > Fix For: 4.4.0 > > > A critical functionality issue came out with CLOUDSTACK-6779. On XenServer it > is observed that on VIF unplug Ovs-Vswitchd is crashing resulting in loosing > all the openflow rules added to the bridge. Ovs daemon gets started and > creates a bridge but configure openflow rules are lost resulting in the > disruption of connectivity for the VM's on the host. > We need to document it in the release notes as a known issue. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6902) Document in the release notes that OVS plug-in functionality is disrupted if ovsdaemon crashes
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6902?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14031360#comment-14031360 ] Pierre-Luc Dion commented on CLOUDSTACK-6902: - Here is the release-notes of 4.4: http://cloudstack-release-notes.readthedocs.org/en/latest/upgrade/upgrade_notes.html#ovs-plug-in > Document in the release notes that OVS plug-in functionality is disrupted if > ovsdaemon crashes > -- > > Key: CLOUDSTACK-6902 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6902 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.4.0 >Reporter: Murali Reddy >Assignee: Pierre-Luc Dion > Fix For: 4.4.0 > > > A critical functionality issue came out with CLOUDSTACK-6779. On XenServer it > is observed that on VIF unplug Ovs-Vswitchd is crashing resulting in loosing > all the openflow rules added to the bridge. Ovs daemon gets started and > creates a bridge but configure openflow rules are lost resulting in the > disruption of connectivity for the VM's on the host. > We need to document it in the release notes as a known issue. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6902) Document in the release notes that OVS plug-in functionality is disrupted if ovsdaemon crashes
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion updated CLOUDSTACK-6902: Status: Reviewable (was: In Progress) > Document in the release notes that OVS plug-in functionality is disrupted if > ovsdaemon crashes > -- > > Key: CLOUDSTACK-6902 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6902 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.4.0 >Reporter: Murali Reddy >Assignee: Pierre-Luc Dion > Fix For: 4.4.0 > > > A critical functionality issue came out with CLOUDSTACK-6779. On XenServer it > is observed that on VIF unplug Ovs-Vswitchd is crashing resulting in loosing > all the openflow rules added to the bridge. Ovs daemon gets started and > creates a bridge but configure openflow rules are lost resulting in the > disruption of connectivity for the VM's on the host. > We need to document it in the release notes as a known issue. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6901) Document in the release notes that OVS plug-in functionality is disrupted if ovsdaemon crashes
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion updated CLOUDSTACK-6901: Status: Reviewable (was: In Progress) > Document in the release notes that OVS plug-in functionality is disrupted if > ovsdaemon crashes > -- > > Key: CLOUDSTACK-6901 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6901 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.4.0 >Reporter: Murali Reddy >Assignee: Pierre-Luc Dion > Fix For: 4.4.0 > > > A critical functionality issue came out with CLOUDSTACK-6779. On XenServer it > is observed that on VIF unplug Ovs-Vswitchd is crashing resulting in loosing > all the openflow rules added to the bridge. Ovs daemon gets started and > creates a bridge but configure openflow rules are lost resulting in the > disruption of connectivity for the VM's on the host. > We need to document it in the release notes as a known issue. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-4354) 4.3.2. Host/Hypervisor System Requirements
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4354?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion resolved CLOUDSTACK-4354. - Resolution: Fixed Fix Version/s: 4.3.0 Assignee: Pierre-Luc Dion hypervisor installation are split in the new documentation. It address this issue. > 4.3.2. Host/Hypervisor System Requirements > -- > > Key: CLOUDSTACK-4354 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4354 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc > Environment: all >Reporter: Ron Wheeler >Assignee: Pierre-Luc Dion >Priority: Blocker > Fix For: 4.3.0 > > > Warning > Be sure you fulfill the additional hypervisor requirements and installation > steps > provided in this Guide. Hypervisor hosts must be properly prepared to work > with > CloudStack. For example, the requirements for XenServer are listed under > Citrix > XenServer Installation > Not sure that this rises to the level of a warning since it is right in the > middle of a section and says to keep going. > It should mention that the sections to be followed are listed below.below > No such things as Citrix XenServer Installation do you mean > "Section 8.2.1, “System Requirements for XenServer Hosts" > The following sections reference include things lie > 8.1.4. Install and configure the Agent which I am not sure is a system > requirement for the cloudstack server. > Are there other things in these reference sections that should NOT be done > prior to chapter 4 being completed? -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-3098) Location to copy vhd-util is wrong in docs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3098?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion closed CLOUDSTACK-3098. --- Resolution: Fixed Fix Version/s: 4.1.1 > Location to copy vhd-util is wrong in docs > -- > > Key: CLOUDSTACK-3098 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3098 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.1.0 >Reporter: Demetrius Tsitrelis >Priority: Critical > Fix For: 4.1.1 > > > In the Installation Guide, section 4.5.3.3 there is a note to copy the > vhd-util to /usr/lib64/cloud/common/scripts/vm/hypervisor/xenserver but in > 4.1 there is no longer a directory with that name. The corect directory is a > /usr/share/cloudstack-common/scripts/vm/hypervisor/xenserver. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Closed] (CLOUDSTACK-3866) Upgrade 4.0 to 4.1 docs need further clarification
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion closed CLOUDSTACK-3866. --- Resolution: Fixed Assignee: Pierre-Luc Dion Upgrade instruction from release-notes changed since doc migration to rtd.org. > Upgrade 4.0 to 4.1 docs need further clarification > -- > > Key: CLOUDSTACK-3866 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3866 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.1.0 >Reporter: Carlos Reategui >Assignee: Pierre-Luc Dion > > Section 4.1 > Step 5: This is redundant. Management server was already stopped in step 2 > Step 8: > - .d through .h: These are only necessary on KVM hosts. Text should explain > that like it does in 9.c > - should add instructions to purge old cloud-client and cloud-server using > dpkg --purge. > - missing instruction of when it is ok to start management server that was > installed in c. > Step 10: This will only work if unauthenticated API interface is enabled. > Should include a link to Developer Guide Section 4.3.1 to explain how to do > so > (http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.1.0/html/Developers_Guide/whats-new-in-api-3.0.html#enabling-port-8096). > Step 11: Add clarification that this is done on the management server. > Because the note is labeled "For Xen Hosts: Copy vhd-utils" it may cause > someone to think they need to do this on the hosts. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-3866) Upgrade 4.0 to 4.1 docs need further clarification
[ https://issues.apache.org/jira/browse/CLOUDSTACK-3866?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion updated CLOUDSTACK-3866: Fix Version/s: 4.4.0 > Upgrade 4.0 to 4.1 docs need further clarification > -- > > Key: CLOUDSTACK-3866 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-3866 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.1.0 >Reporter: Carlos Reategui >Assignee: Pierre-Luc Dion > Fix For: 4.4.0 > > > Section 4.1 > Step 5: This is redundant. Management server was already stopped in step 2 > Step 8: > - .d through .h: These are only necessary on KVM hosts. Text should explain > that like it does in 9.c > - should add instructions to purge old cloud-client and cloud-server using > dpkg --purge. > - missing instruction of when it is ok to start management server that was > installed in c. > Step 10: This will only work if unauthenticated API interface is enabled. > Should include a link to Developer Guide Section 4.3.1 to explain how to do > so > (http://cloudstack.apache.org/docs/en-US/Apache_CloudStack/4.1.0/html/Developers_Guide/whats-new-in-api-3.0.html#enabling-port-8096). > Step 11: Add clarification that this is done on the management server. > Because the note is labeled "For Xen Hosts: Copy vhd-utils" it may cause > someone to think they need to do this on the hosts. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-4351) [DOC] 4.3.2. Host/Hypervisor System Requirements has misleading or premature note
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion reassigned CLOUDSTACK-4351: --- Assignee: Pierre-Luc Dion (was: Radhika Nair) > [DOC] 4.3.2. Host/Hypervisor System Requirements has misleading or premature > note > -- > > Key: CLOUDSTACK-4351 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4351 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.2.0 > Environment: All >Reporter: Ron Wheeler >Assignee: Pierre-Luc Dion > Fix For: 4.2.1 > > > Note > If DHCP is used for hosts, ensure that no conflict occurs between DHCP server > used for these hosts and the DHCP router created by CloudStack. > How can you do this at this point? > Cloudstack does not have a DHCP server at this point. > There is nothing for the user to do at this point. > It should be moved to closer to the point where the DHCP server addresses are > specified. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-4351) [DOC] 4.3.2. Host/Hypervisor System Requirements has misleading or premature note
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4351?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion updated CLOUDSTACK-4351: Fix Version/s: (was: 4.2.1) 4.3.0 > [DOC] 4.3.2. Host/Hypervisor System Requirements has misleading or premature > note > -- > > Key: CLOUDSTACK-4351 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4351 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.2.0 > Environment: All >Reporter: Ron Wheeler >Assignee: Pierre-Luc Dion > Fix For: 4.3.0 > > > Note > If DHCP is used for hosts, ensure that no conflict occurs between DHCP server > used for these hosts and the DHCP router created by CloudStack. > How can you do this at this point? > Cloudstack does not have a DHCP server at this point. > There is nothing for the user to do at this point. > It should be moved to closer to the point where the DHCP server addresses are > specified. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-4351) [DOC] 4.3.2. Host/Hypervisor System Requirements has misleading or premature note
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4351?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14034782#comment-14034782 ] Pierre-Luc Dion commented on CLOUDSTACK-4351: - going to remove .. note:: If DHCP is used for hosts, ensure that no conflict occurs between DHCP server used for these hosts and the DHCP router created by CloudStack. from cloudstack-docs-install/source/installation.rst. This warning does not make sense, hypervisor installation instructions use static IP for hosts. > [DOC] 4.3.2. Host/Hypervisor System Requirements has misleading or premature > note > -- > > Key: CLOUDSTACK-4351 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4351 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.2.0 > Environment: All >Reporter: Ron Wheeler >Assignee: Pierre-Luc Dion > Fix For: 4.3.0 > > > Note > If DHCP is used for hosts, ensure that no conflict occurs between DHCP server > used for these hosts and the DHCP router created by CloudStack. > How can you do this at this point? > Cloudstack does not have a DHCP server at this point. > There is nothing for the user to do at this point. > It should be moved to closer to the point where the DHCP server addresses are > specified. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-1990) Docs: Update "Choosing a Hypervisor" feature matrix with new info
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion reassigned CLOUDSTACK-1990: --- Assignee: Pierre-Luc Dion (was: gavin lee) > Docs: Update "Choosing a Hypervisor" feature matrix with new info > - > > Key: CLOUDSTACK-1990 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1990 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.2.0 >Reporter: Jessica Tomechak >Assignee: Pierre-Luc Dion > Fix For: 4.4.0 > > > This section was added to the Installation Guide as a straight port from > older docs. It still needs someone to review it, remove outdated hypervisor > versions, and put in the additional hypervisors and versions that will be > supported in the next CloudStack release. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-1990) Docs: Update "Choosing a Hypervisor" feature matrix with new info
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1990?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14061498#comment-14061498 ] Pierre-Luc Dion commented on CLOUDSTACK-1990: - based on 4.4 here is the potential new content but I don't have all answers, could someone fill blanks? Thanks +--+---+--+-+-+++ | Feature | XenServer | vSphere | KVM | LXC | HyperV | Bare Metal | +==+===+==+=+=+++ | Network Throttling | Yes | Yes | No | No | No | N/A| +--+---+--+-+-+++ | Security groups in | Yes | No | Yes | Yes | No | No | | | | | | || | | zones that use basic | | | | || | | | | | | || | | networking | | | | || | +--+---+--+-+-+++ |iSCSI | Yes | Yes | Yes | Yes | Yes| N/A| +--+---+--+-+-+++ | FibreChannel | Yes | Yes | Yes | Yes | Yes| N/A| +--+---+--+-+-+++ | Local Disk | Yes | Yes | Yes | Yes | Yes| Yes| +--+---+--+-+-+++ | HA | Yes | Yes (Native) | Yes | No || N/A| +--+---+--+-+-+++ | Snapshots of local disk | Yes | Yes | Yes | || N/A| +--+---+--+-+-+++ | Local disk as data disk | Yes | No | No | No | Yes| N/A| +--+---+--+-+-+++ | Work load balancing | No| DRS | No | No || N/A| +--+---+--+-+-+++ | Manual live migration| Yes | Yes | Yes | No || N/A| | | | | | || | | of VMs from host to host | | | | || | +--+---+--+-+-+++ | Conserve management | Yes | No | Yes | Yes || N/A| | | | | | || | | traffic IP address | | | | || | | | | | | || | | by using link local | | | | || | | | | | | || | | network to communicate | | | | || | | | | | | || | | with virtual router | | | | || | +--+---+--+-+-+++ > Docs: Update "Choosing a Hypervisor" feature matrix with new info > - > > Key: CLOUDSTACK-1990 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1990 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.2.0 >Reporter: Jessica Tomechak >Assignee: Pierre-Luc Dion > Fix For: 4.4.0 > > > This section was added to the Installation Guide as a straight port from > older docs. It still needs someone to review it, remove outdated hypervisor > versions, and put in the additional hypervisors and versions that will be > supported in the next CloudStack release. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-5845) [doc] Document Heterogeneous Secondary Storage Not Supported in Region
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion reassigned CLOUDSTACK-5845: --- Assignee: Pierre-Luc Dion (was: Radhika Nair) > [doc] Document Heterogeneous Secondary Storage Not Supported in Region > -- > > Key: CLOUDSTACK-5845 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5845 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.2.0 >Reporter: Radhika Nair >Assignee: Pierre-Luc Dion > Labels: Documentation > Fix For: 4.4.0 > > Attachments: Apache_CloudStack-4.3.0-Admin_Guide-en-US.pdf > > > Current implementation cannot have two zones, one using NFS secondary, the > other using S3 secondary. CloudStack does not support heterogeneous secondary > storages in a Region. > There is a limitation of our support for using S3 as Region-wide secondary > storage. In a cloud, if you add S3 as a secondary storage, you cannot have > other zone-wide secondary storage existing; For example, if you have an NFS > secondary storage, you cannot add a S3 as secondary storage. If you want to > use S3 as secondary storage, then you can add your NFS as S3 staging store > only. > Details are > This is documented in the design doc published on ACS > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Storage+Backup+Object+Store+Plugin+Framework, > maybe release notes didn't state that clearly. In 4.3, we will support > migration NFS to S3 by automatically converting existing NFS secondary > storage to S3 staging stores. See > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Migration+of+NFS+Secondary+Storage+to+Object+Store > for details. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-5845) [doc] Document Heterogeneous Secondary Storage Not Supported in Region
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5845?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14061509#comment-14061509 ] Pierre-Luc Dion commented on CLOUDSTACK-5845: - Documentation for CS4.3 contain that issue. http://docs.cloudstack.apache.org/en/latest/concepts.html#about-secondary-storage > [doc] Document Heterogeneous Secondary Storage Not Supported in Region > -- > > Key: CLOUDSTACK-5845 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5845 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.2.0 >Reporter: Radhika Nair >Assignee: Radhika Nair > Labels: Documentation > Fix For: 4.4.0 > > Attachments: Apache_CloudStack-4.3.0-Admin_Guide-en-US.pdf > > > Current implementation cannot have two zones, one using NFS secondary, the > other using S3 secondary. CloudStack does not support heterogeneous secondary > storages in a Region. > There is a limitation of our support for using S3 as Region-wide secondary > storage. In a cloud, if you add S3 as a secondary storage, you cannot have > other zone-wide secondary storage existing; For example, if you have an NFS > secondary storage, you cannot add a S3 as secondary storage. If you want to > use S3 as secondary storage, then you can add your NFS as S3 staging store > only. > Details are > This is documented in the design doc published on ACS > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Storage+Backup+Object+Store+Plugin+Framework, > maybe release notes didn't state that clearly. In 4.3, we will support > migration NFS to S3 by automatically converting existing NFS secondary > storage to S3 staging stores. See > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Migration+of+NFS+Secondary+Storage+to+Object+Store > for details. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-5845) [doc] Document Heterogeneous Secondary Storage Not Supported in Region
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5845?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion resolved CLOUDSTACK-5845. - Resolution: Fixed Documentation for CS4.3 already address this issue. http://docs.cloudstack.apache.org/en/latest/concepts.html#about-secondary-storage > [doc] Document Heterogeneous Secondary Storage Not Supported in Region > -- > > Key: CLOUDSTACK-5845 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5845 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.2.0 >Reporter: Radhika Nair >Assignee: Pierre-Luc Dion > Labels: Documentation > Fix For: 4.4.0 > > Attachments: Apache_CloudStack-4.3.0-Admin_Guide-en-US.pdf > > > Current implementation cannot have two zones, one using NFS secondary, the > other using S3 secondary. CloudStack does not support heterogeneous secondary > storages in a Region. > There is a limitation of our support for using S3 as Region-wide secondary > storage. In a cloud, if you add S3 as a secondary storage, you cannot have > other zone-wide secondary storage existing; For example, if you have an NFS > secondary storage, you cannot add a S3 as secondary storage. If you want to > use S3 as secondary storage, then you can add your NFS as S3 staging store > only. > Details are > This is documented in the design doc published on ACS > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Storage+Backup+Object+Store+Plugin+Framework, > maybe release notes didn't state that clearly. In 4.3, we will support > migration NFS to S3 by automatically converting existing NFS secondary > storage to S3 staging stores. See > https://cwiki.apache.org/confluence/display/CLOUDSTACK/Migration+of+NFS+Secondary+Storage+to+Object+Store > for details. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6902) Document in the release notes that OVS plug-in functionality is disrupted if ovsdaemon crashes
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6902?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion resolved CLOUDSTACK-6902. - Resolution: Fixed > Document in the release notes that OVS plug-in functionality is disrupted if > ovsdaemon crashes > -- > > Key: CLOUDSTACK-6902 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6902 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.4.0 >Reporter: Murali Reddy >Assignee: Pierre-Luc Dion > Fix For: 4.4.0 > > > A critical functionality issue came out with CLOUDSTACK-6779. On XenServer it > is observed that on VIF unplug Ovs-Vswitchd is crashing resulting in loosing > all the openflow rules added to the bridge. Ovs daemon gets started and > creates a bridge but configure openflow rules are lost resulting in the > disruption of connectivity for the VM's on the host. > We need to document it in the release notes as a known issue. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6901) Document in the release notes that OVS plug-in functionality is disrupted if ovsdaemon crashes
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6901?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion resolved CLOUDSTACK-6901. - Resolution: Fixed > Document in the release notes that OVS plug-in functionality is disrupted if > ovsdaemon crashes > -- > > Key: CLOUDSTACK-6901 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6901 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.4.0 >Reporter: Murali Reddy >Assignee: Pierre-Luc Dion > Fix For: 4.4.0 > > > A critical functionality issue came out with CLOUDSTACK-6779. On XenServer it > is observed that on VIF unplug Ovs-Vswitchd is crashing resulting in loosing > all the openflow rules added to the bridge. Ovs daemon gets started and > creates a bridge but configure openflow rules are lost resulting in the > disruption of connectivity for the VM's on the host. > We need to document it in the release notes as a known issue. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-6880) cloudstack-usage: invalid installation instructions
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6880?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion resolved CLOUDSTACK-6880. - Resolution: Fixed Fix Version/s: 4.4.0 4.3.0 Rewrite the cloudstack-usage installation instruction to replace reference from cloudplatform instruction to Apache CloudStack instruction based on package repository. > cloudstack-usage: invalid installation instructions > --- > > Key: CLOUDSTACK-6880 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6880 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc > Environment: RTD >Reporter: Pierre-Luc Dion >Assignee: Pierre-Luc Dion >Priority: Trivial > Labels: documentation > Fix For: 4.3.0, 4.4.0 > > > http://cloudstack-installation.readthedocs.org/en/latest/optional_installation.html#installing-the-usage-server-optional > Invalid installation instruction of cloudstack-usage. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-295) Add instructions to modify limits.conf in installation directions
[
https://issues.apache.org/jira/browse/CLOUDSTACK-295?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14061581#comment-14061581
]
Pierre-Luc Dion commented on CLOUDSTACK-295:
does this issue is still relevant?
cloud.spec still contain:
{code}
# set max file descriptors for cloud user to 4096
sed -i /"cloud hard nofile"/d /etc/security/limits.conf
sed -i /"cloud soft nofile"/d /etc/security/limits.conf
echo "cloud hard nofile 4096" >> /etc/security/limits.conf
echo "cloud soft nofile 4096" >> /etc/security/limits.conf
{code}
> Add instructions to modify limits.conf in installation directions
> -
>
> Key: CLOUDSTACK-295
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-295
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Doc
>Affects Versions: pre-4.0.0
>Reporter: David Nalley
>Priority: Minor
> Fix For: Future
>
>
> Changing config files was deemed too unsavory to be done in a automated
> manner so that was removed from the spec file.
> Thus we need to add a section to installation documents that discusses
> modifying /etc/security/limits.conf
> Here is what was in the spec file, this should only be for the management
> server.
> # set max file descriptors for cloud user to 4096 sed -i /"cloud hard
> nofile"/d
> /etc/security/limits.conf sed -i /"cloud soft nofile"/d
> /etc/security/limits.conf
> echo "cloud hard nofile 4096" >> /etc/security/limits.conf echo "cloud soft
> nofile 4096" >> /etc/security/limits.conf rm -
> rf %{_localstatedir}/cache/%{name}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-482) Installation Guide Doc Error Section 4.5.7
[ https://issues.apache.org/jira/browse/CLOUDSTACK-482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion reassigned CLOUDSTACK-482: -- Assignee: Pierre-Luc Dion > Installation Guide Doc Error Section 4.5.7 > -- > > Key: CLOUDSTACK-482 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-482 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.0.0 > Environment: Ubuntu 12.04 LTS >Reporter: Jim Leary >Assignee: Pierre-Luc Dion > Fix For: Future > > > Section 4.5.7 of the Installation Guide: entries calling out > /usr/lib64/cloud/common/scripts/storage/secondary/cloud-install-sys-tmplt... > are incorrect. They should be: > /usr/lib/cloud/common/scripts/storage/secondary/cloud-install-sys-tmplt... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-482) Installation Guide Doc Error Section 4.5.7
[ https://issues.apache.org/jira/browse/CLOUDSTACK-482?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion resolved CLOUDSTACK-482. Resolution: Fixed Fix Version/s: (was: Future) 4.4.0 As been fixed while migrating documentation on readthedocs.org. > Installation Guide Doc Error Section 4.5.7 > -- > > Key: CLOUDSTACK-482 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-482 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.0.0 > Environment: Ubuntu 12.04 LTS >Reporter: Jim Leary >Assignee: Pierre-Luc Dion > Fix For: 4.4.0 > > > Section 4.5.7 of the Installation Guide: entries calling out > /usr/lib64/cloud/common/scripts/storage/secondary/cloud-install-sys-tmplt... > are incorrect. They should be: > /usr/lib/cloud/common/scripts/storage/secondary/cloud-install-sys-tmplt... -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-1255) Admin Guide and Install Guide Need a Revamp: Some Sections Are Common
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1255?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion resolved CLOUDSTACK-1255. - Resolution: Fixed Fix Version/s: (was: Future) 4.4.0 4.3.0 Assignee: Pierre-Luc Dion fixed while migrating documentation on readthedocs.org > Admin Guide and Install Guide Need a Revamp: Some Sections Are Common > - > > Key: CLOUDSTACK-1255 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1255 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Reporter: Radhika Nair >Assignee: Pierre-Luc Dion > Fix For: 4.3.0, 4.4.0 > > > Some sections are common across the guides. > For example: Managing Networks and Traffic > Probably, the Networking sections need a restructuring across the guides. > The guides need to be re-looked and revamped. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-586) exportfs -a gives 'no_subtree_check warning' when following the Installation guide
[
https://issues.apache.org/jira/browse/CLOUDSTACK-586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre-Luc Dion reassigned CLOUDSTACK-586:
--
Assignee: Pierre-Luc Dion
> exportfs -a gives 'no_subtree_check warning' when following the Installation
> guide
> --
>
> Key: CLOUDSTACK-586
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-586
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Doc
>Affects Versions: 4.0.0
> Environment: Ubuntu 12.04.1 LTS (GNU/Linux 3.2.0-29-generic x86_64)
>Reporter: Max Thoursie
>Assignee: Pierre-Luc Dion
>Priority: Minor
> Fix For: 4.3.0, 4.4.0
>
>
> The installation guide says, under 4.5.5.1 and 4.5.5.2
> 2. To configure the new directories as NFS exports, edit /etc/exports. Export
> the NFS share(s) with rw,async,no_root_squash. For example:
> # vi /etc/exports
> Insert the following line.
> /export *(rw,async,no_root_squash)
> Following these instructions, Ubuntu prints the following warning
> max@ubuntu:~$ sudo exportfs -a
> exportfs: /etc/exports [1]: Neither 'subtree_check' or 'no_subtree_check'
> specified for export "*:/export".
> Assuming default behaviour ('no_subtree_check').
> NOTE: this default has changed since nfs-utils version 1.0.x
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-586) exportfs -a gives 'no_subtree_check warning' when following the Installation guide
[
https://issues.apache.org/jira/browse/CLOUDSTACK-586?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Pierre-Luc Dion resolved CLOUDSTACK-586.
Resolution: Fixed
Fix Version/s: 4.4.0
4.3.0
Resolved while migration of documentation on readthedocs.org.
> exportfs -a gives 'no_subtree_check warning' when following the Installation
> guide
> --
>
> Key: CLOUDSTACK-586
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-586
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Doc
>Affects Versions: 4.0.0
> Environment: Ubuntu 12.04.1 LTS (GNU/Linux 3.2.0-29-generic x86_64)
>Reporter: Max Thoursie
>Assignee: Pierre-Luc Dion
>Priority: Minor
> Fix For: 4.3.0, 4.4.0
>
>
> The installation guide says, under 4.5.5.1 and 4.5.5.2
> 2. To configure the new directories as NFS exports, edit /etc/exports. Export
> the NFS share(s) with rw,async,no_root_squash. For example:
> # vi /etc/exports
> Insert the following line.
> /export *(rw,async,no_root_squash)
> Following these instructions, Ubuntu prints the following warning
> max@ubuntu:~$ sudo exportfs -a
> exportfs: /etc/exports [1]: Neither 'subtree_check' or 'no_subtree_check'
> specified for export "*:/export".
> Assuming default behaviour ('no_subtree_check').
> NOTE: this default has changed since nfs-utils version 1.0.x
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-1359) Clarify what we mean by GB in CloudStack documentation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-1359?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion reassigned CLOUDSTACK-1359: --- Assignee: Pierre-Luc Dion > Clarify what we mean by GB in CloudStack documentation > -- > > Key: CLOUDSTACK-1359 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-1359 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: pre-4.0.0, 4.0.0 > Environment: Here is an example page with this issue: > http://incubator.apache.org/cloudstack/docs/api/apidocs-4.0.0/root_admin/createDiskOffering.html >Reporter: Mike Tutkowski >Assignee: Pierre-Luc Dion > Labels: documentation > Fix For: pre-4.0.0, 4.0.0 > > > On the example page above, the disksize field lists that that it is in GB. > For some people GB means 10 raised to the 9th power (1,000,000,000) bytes > while for others it means 2 raised to the 30th power (1,073,741,824) bytes. > Check out Wiki here: http://en.wikipedia.org/wiki/Gigabyte. > I recommend we clarify documents to indicate we are talking about a GB being > equal to 1,073,741,824 bytes (which is often known as a GiB). -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7120) missing documentation regarding Cluster setttings and global settings
Pierre-Luc Dion created CLOUDSTACK-7120: --- Summary: missing documentation regarding Cluster setttings and global settings Key: CLOUDSTACK-7120 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7120 Project: CloudStack Issue Type: Task Security Level: Public (Anyone can view this level - this is the default.) Components: Doc Reporter: Pierre-Luc Dion Priority: Minor Modifying Global settings such as cpu.overprovisioning.factor does not affect already provisionned cluster. Some Global Settings are now use as default templates when creating new clusters and changing them will not affect existing clusters. To update settings like cpu.overprovisioning.factor it has to be change at the cluster level and not global settings. The documentation (admin guide) should cover this post installation type of tunning. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7120) missing documentation regarding Cluster setttings and global settings
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7120?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14065345#comment-14065345
]
Pierre-Luc Dion commented on CLOUDSTACK-7120:
-
from mailing list:
{code}
Harikrishna Patnala harikrishna.patn...@citrix.com via cloudstack.apache.org
to dev
Please create a doc bug only for two parameters cpu and memory overprovisioning
factors.
Because for the remaining parameters till the value is defined at granular
level, CS uses the value at global level.
So in your case if it would have some parameter other than cpu and memory over
provisioning factors, then changing the value at global level should affect at
cluster level also.
Thanks,
Harikrishna
{code}
> missing documentation regarding Cluster setttings and global settings
> -
>
> Key: CLOUDSTACK-7120
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7120
> Project: CloudStack
> Issue Type: Task
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Doc
>Reporter: Pierre-Luc Dion
>Priority: Minor
> Labels: documentation
>
> Modifying Global settings such as cpu.overprovisioning.factor does not affect
> already provisionned cluster. Some Global Settings are now use as default
> templates when creating new clusters and changing them will not affect
> existing clusters. To update settings like cpu.overprovisioning.factor it has
> to be change at the cluster level and not global settings.
> The documentation (admin guide) should cover this post installation type of
> tunning.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CLOUDSTACK-7140) Upgrade 4.2.1 -> 4.4.0rc2
Pierre-Luc Dion created CLOUDSTACK-7140: --- Summary: Upgrade 4.2.1 -> 4.4.0rc2 Key: CLOUDSTACK-7140 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7140 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Upgrade Affects Versions: 4.4.0 Environment: CloudStack 4.2.1 on CentOS 6.5 Reporter: Pierre-Luc Dion Attachments: catalina.out, management-server.log Upgrading CloudStack management 4.2.1 to 4.4.0rc2 fail to upgrade database. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7140) Upgrade 4.2.1 -> 4.4.0rc2
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion updated CLOUDSTACK-7140: Attachment: management-server.log catalina.out Logs files of the upgrade containing StackTraces. > Upgrade 4.2.1 -> 4.4.0rc2 > - > > Key: CLOUDSTACK-7140 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7140 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Upgrade >Affects Versions: 4.4.0 > Environment: CloudStack 4.2.1 on CentOS 6.5 >Reporter: Pierre-Luc Dion > Attachments: catalina.out, management-server.log > > > Upgrading CloudStack management 4.2.1 to 4.4.0rc2 fail to upgrade database. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7140) Upgrade 4.2.1 -> 4.4.0rc2
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14067591#comment-14067591 ] Pierre-Luc Dion commented on CLOUDSTACK-7140: - I was unable to reproduce the issue on a fresh install of CS4.2.1. I've also got the same error while trying to upgrade this environment to stable 4.3. > Upgrade 4.2.1 -> 4.4.0rc2 > - > > Key: CLOUDSTACK-7140 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7140 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Upgrade >Affects Versions: 4.4.0 > Environment: CloudStack 4.2.1 on CentOS 6.5 >Reporter: Pierre-Luc Dion >Priority: Minor > Attachments: catalina.out, management-server.log > > > Upgrading CloudStack management 4.2.1 to 4.4.0rc2 fail to upgrade database. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7140) Upgrade 4.2.1 -> 4.4.0rc2
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion updated CLOUDSTACK-7140: Priority: Minor (was: Major) > Upgrade 4.2.1 -> 4.4.0rc2 > - > > Key: CLOUDSTACK-7140 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7140 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Upgrade >Affects Versions: 4.4.0 > Environment: CloudStack 4.2.1 on CentOS 6.5 >Reporter: Pierre-Luc Dion >Priority: Minor > Attachments: catalina.out, management-server.log > > > Upgrading CloudStack management 4.2.1 to 4.4.0rc2 fail to upgrade database. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7140) Upgrade 4.2.1 -> 4.4.0rc2
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion updated CLOUDSTACK-7140: Priority: Critical (was: Minor) > Upgrade 4.2.1 -> 4.4.0rc2 > - > > Key: CLOUDSTACK-7140 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7140 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Upgrade >Affects Versions: 4.4.0 > Environment: CloudStack 4.2.1 on CentOS 6.5 >Reporter: Pierre-Luc Dion >Priority: Critical > Attachments: catalina.out, management-server.log > > > Upgrading CloudStack management 4.2.1 to 4.4.0rc2 fail to upgrade database. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Issue Comment Deleted] (CLOUDSTACK-7140) Upgrade 4.2.1 -> 4.4.0rc2
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion updated CLOUDSTACK-7140: Comment: was deleted (was: I was unable to reproduce the issue on a fresh install of CS4.2.1. I've also got the same error while trying to upgrade this environment to stable 4.3.) > Upgrade 4.2.1 -> 4.4.0rc2 > - > > Key: CLOUDSTACK-7140 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7140 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Upgrade >Affects Versions: 4.4.0 > Environment: CloudStack 4.2.1 on CentOS 6.5 >Reporter: Pierre-Luc Dion >Priority: Critical > Attachments: catalina.out, management-server.log > > > Upgrading CloudStack management 4.2.1 to 4.4.0rc2 fail to upgrade database. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7140) Upgrade 4.2.1 -> 4.4.0rc2
[
https://issues.apache.org/jira/browse/CLOUDSTACK-7140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14067674#comment-14067674
]
Pierre-Luc Dion commented on CLOUDSTACK-7140:
-
to reproduce this issue:
1. following release notes to upgrade 4.2.x to 4.4.
2. after upgrading package starting CloudStack fail with following error in
managment-server.log:
{code}
com.cloud.utils.exception.CloudRuntimeException:
updateSystemVmTemplates:Exception:4.3.0 XenServer SystemVm template not found.
Cannot upgrade system Vms
{code}
3. then restarting cloudstack-management cause the db upgrade issue:
{code}
2014-07-19 16:45:22,132 ERROR [c.c.u.DatabaseUpgradeChecker] (main:null) Unable
to execute upgrade script:
/usr/share/cloudstack-management/setup/db/schema-421to430.sql
com.mysql.jdbc.exceptions.jdbc4.MySQLSyntaxErrorException: Duplicate column
name 'related'
{code}
> Upgrade 4.2.1 -> 4.4.0rc2
> -
>
> Key: CLOUDSTACK-7140
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7140
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Upgrade
>Affects Versions: 4.4.0
> Environment: CloudStack 4.2.1 on CentOS 6.5
>Reporter: Pierre-Luc Dion
>Priority: Critical
> Attachments: catalina.out, management-server.log
>
>
> Upgrading CloudStack management 4.2.1 to 4.4.0rc2 fail to upgrade database.
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7140) Upgrade 4.2.1 -> 4.4.0rc2
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion updated CLOUDSTACK-7140: Attachment: 4.2.1-to-4.3_management-server.log first start of cloudstack-management after packages upgrade. > Upgrade 4.2.1 -> 4.4.0rc2 > - > > Key: CLOUDSTACK-7140 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7140 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Upgrade >Affects Versions: 4.4.0 > Environment: CloudStack 4.2.1 on CentOS 6.5 >Reporter: Pierre-Luc Dion >Priority: Critical > Attachments: 4.2.1-to-4.3_management-server.log, catalina.out, > management-server.log > > > Upgrading CloudStack management 4.2.1 to 4.4.0rc2 fail to upgrade database. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7140) Upgrade 4.2.1 -> 4.4.0rc2
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14069370#comment-14069370 ] Pierre-Luc Dion commented on CLOUDSTACK-7140: - The systemvm template was downloaded prior to the upgrade but named systemvm-xenserver-4.4 and not systemvm-xenserver-4.3 since the upgrade was to 4.4. Should 4.4 use systemvm-xenserver-4.3? if so I'll update the release-notes. Thanks. > Upgrade 4.2.1 -> 4.4.0rc2 > - > > Key: CLOUDSTACK-7140 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7140 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Upgrade >Affects Versions: 4.4.0 > Environment: CloudStack 4.2.1 on CentOS 6.5 >Reporter: Pierre-Luc Dion >Priority: Critical > Attachments: 4.2.1-to-4.3_management-server.log, catalina.out, > management-server.log > > > Upgrading CloudStack management 4.2.1 to 4.4.0rc2 fail to upgrade database. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7140) Upgrade 4.2.1 -> 4.4.0rc2
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7140?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14069575#comment-14069575 ] Pierre-Luc Dion commented on CLOUDSTACK-7140: - Alena, Do you know if 4.4 require a new system-vm ? so upgrading from 4.2.x would require to install 2 system-vm prior to upgrade packages? Thanks, > Upgrade 4.2.1 -> 4.4.0rc2 > - > > Key: CLOUDSTACK-7140 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7140 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Upgrade >Affects Versions: 4.4.0 > Environment: CloudStack 4.2.1 on CentOS 6.5 >Reporter: Pierre-Luc Dion >Priority: Critical > Attachments: 4.2.1-to-4.3_management-server.log, catalina.out, > management-server.log > > > Upgrading CloudStack management 4.2.1 to 4.4.0rc2 fail to upgrade database. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6886) Cannot add SDX Netscaler device
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion updated CLOUDSTACK-6886: Assignee: Will Stevens > Cannot add SDX Netscaler device > --- > > Key: CLOUDSTACK-6886 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6886 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Devices >Affects Versions: 4.3.0 > Environment: CloudStack 4.3 build with noredist packages >Reporter: Pierre-Luc Dion >Assignee: Will Stevens > Attachments: cs4.3_SDXfail.png > > > on CloudStack 4.3 with noredist packages, Adding a Netscaler device in > Network Service Providers as "NetScaler SDX LoadBalancer" type failed with > following error message: > "Failed to enable ssl feature on load balancer due to null" > Test perform using CloudStack webui. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6886) Cannot add SDX Netscaler device
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14070985#comment-14070985 ] Pierre-Luc Dion commented on CLOUDSTACK-6886: - ask Daan in the latest 4.4 thread and see... *Pierre-Luc DION* Architecte de Solution Cloud | Cloud Solutions Architect t 855.652.5683 *CloudOps* Votre partenaire infonuagique* | *Cloud Solutions Experts 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|* tw @CloudOps_ On Tue, Jul 22, 2014 at 5:36 PM, Will Stevens (JIRA) > Cannot add SDX Netscaler device > --- > > Key: CLOUDSTACK-6886 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6886 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Devices >Affects Versions: 4.3.0 > Environment: CloudStack 4.3 build with noredist packages >Reporter: Pierre-Luc Dion >Assignee: Will Stevens > Attachments: cs4.3_SDXfail.png > > > on CloudStack 4.3 with noredist packages, Adding a Netscaler device in > Network Service Providers as "NetScaler SDX LoadBalancer" type failed with > following error message: > "Failed to enable ssl feature on load balancer due to null" > Test perform using CloudStack webui. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6886) Cannot add SDX Netscaler device
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14070984#comment-14070984 ] Pierre-Luc Dion commented on CLOUDSTACK-6886: - usually I saw people asking the release manager for cherry pick. *Pierre-Luc DION* Architecte de Solution Cloud | Cloud Solutions Architect t 855.652.5683 *CloudOps* Votre partenaire infonuagique* | *Cloud Solutions Experts 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|* tw @CloudOps_ > Cannot add SDX Netscaler device > --- > > Key: CLOUDSTACK-6886 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6886 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Devices >Affects Versions: 4.3.0 > Environment: CloudStack 4.3 build with noredist packages >Reporter: Pierre-Luc Dion >Assignee: Will Stevens > Attachments: cs4.3_SDXfail.png > > > on CloudStack 4.3 with noredist packages, Adding a Netscaler device in > Network Service Providers as "NetScaler SDX LoadBalancer" type failed with > following error message: > "Failed to enable ssl feature on load balancer due to null" > Test perform using CloudStack webui. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6886) Cannot add SDX Netscaler device
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6886?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14070986#comment-14070986 ] Pierre-Luc Dion commented on CLOUDSTACK-6886: - btw, RM per release: Daan = 4.4 Sebgoa or ilya = 4.3.1 *Pierre-Luc DION* Architecte de Solution Cloud | Cloud Solutions Architect t 855.652.5683 *CloudOps* Votre partenaire infonuagique* | *Cloud Solutions Experts 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|* tw @CloudOps_ > Cannot add SDX Netscaler device > --- > > Key: CLOUDSTACK-6886 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6886 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Devices >Affects Versions: 4.3.0 > Environment: CloudStack 4.3 build with noredist packages >Reporter: Pierre-Luc Dion >Assignee: Will Stevens > Attachments: cs4.3_SDXfail.png > > > on CloudStack 4.3 with noredist packages, Adding a Netscaler device in > Network Service Providers as "NetScaler SDX LoadBalancer" type failed with > following error message: > "Failed to enable ssl feature on load balancer due to null" > Test perform using CloudStack webui. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-4912) API docs are missing some APIs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion updated CLOUDSTACK-4912: Fix Version/s: (was: Future) 4.4.0 > API docs are missing some APIs > -- > > Key: CLOUDSTACK-4912 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4912 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Doc >Affects Versions: 4.2.0, 4.3.0 >Reporter: Demetrius Tsitrelis >Assignee: David Nalley >Priority: Critical > Fix For: 4.4.0 > > > I grep’ed the source code and came up with a list of the APIs which the UI > uses. Many of them (addNetscalerLoadBalancer, addVmwareDc, etc.) are not in > the generated API documentation which appears at > http://cloudstack.apache.org/docs/api/apidocs-4.2/TOC_Root_Admin.html > Here’s the list of APIs used by the UI: > activateProject > addAccountToProject > addBaremetalDhcp > addBaremetalPxeKickStartServer > addCluster > addHost > addImageStore > addIpToNic > addLdapConfiguration > addNetscalerLoadBalancer > addNetworkServiceProvider > addNicToVirtualMachine > addRegion > addTrafficType > addUcsManager > addVmwareDc > addVpnUser > archiveAlerts > archiveEvents > assignToGlobalLoadBalancerRule > assignToLoadBalancerRule > assignVirtualMachine > associateIpAddress > associateUcsProfileToBlade > attachIso > attachVolume > authorizeSecurityGroupEgress > authorizeSecurityGroupIngress > cancelHostMaintenance > cancelStorageMaintenance > configureInternalLoadBalancerElement > configureVirtualRouterElement > copyIso > copyTemplate > createAccount > createAffinityGroup > createAutoScalePolicy > createAutoScaleVmGroup > createAutoScaleVmProfile > createCondition > createDiskOffering > createDomain > createEgressFirewallRule > createFirewallRule > createGlobalLoadBalancerRule > createIpForwardingRule > createLBHealthCheckPolicy > createLBStickinessPolicy > createLoadBalancer > createLoadBalancerRule > createNetwork > createNetworkACL > createNetworkACLList > createNetworkOffering > createPhysicalNetwork > createPod > createPortableIpRange > createPortForwardingRule > createPrivateGateway > createProject > createRemoteAccessVpn > createSecondaryStagingStore > createSecurityGroup > createServiceOffering > createSnapshot > createSnapshotPolicy > createStaticRoute > createStorageNetworkIpRange > createStoragePool > createTags > createTemplate > createUser > createVlanIpRange > createVMSnapshot > createVolume > createVPC > createVpnConnection > createVpnCustomerGateway > createVpnGateway > createZone > dedicateCluster > dedicateGuestVlanRange > dedicateHost > dedicatePod > dedicatePublicIpRange > dedicateZone > deleteAccount > deleteAccountFromProject > deleteAffinityGroup > deleteAlerts > deleteBigSwitchVnsDevice > deleteCiscoNexusVSM > deleteCluster > deleteCondition > deleteDiskOffering > deleteDomain > deleteEgressFirewallRule > deleteEvents > deleteF5LoadBalancer > deleteFirewallRule > deleteGlobalLoadBalancerRule > deleteHost > deleteImageStore > deleteIpForwardingRule > deleteIso > deleteLBHealthCheckPolicy > deleteLBStickinessPolicy > deleteLdapConfiguration > deleteLoadBalancer > deleteLoadBalancerRule > deleteNetscalerLoadBalancer > deleteNetwork > deleteNetworkACL > deleteNetworkACLList > deleteNetworkOffering > deleteNetworkServiceProvider > deleteNiciraNvpDevice > deletePhysicalNetwork > deletePod > deletePortableIpRange > deletePortForwardingRule > deletePrivateGateway > deleteProject > deleteProjectInvitation > deleteRemoteAccessVpn > deleteSecondaryStagingStore > deleteSecurityGroup > deleteServiceOffering > deleteSnapshot > deleteSnapshotPolicies > deleteSrxFirewall > deleteStaticRoute > deleteStorageNetworkIpRange > deleteStoragePool > deleteTags > deleteTemplate > deleteUcsManager > deleteUser > deleteVlanIpRange > deleteVMSnapshot > deleteVolume > deleteVPC > deleteVpnConnection > deleteVpnCustomerGateway > deleteVpnGateway > deleteZone > deployVirtualMachine > destroyRouter > destroySystemVm > destroyVirtualMachine > detachIso > detachVolume > disableAccount > disableAutoScaleVmGroup > disableCiscoNexusVSM > disableStaticNat > disableUser > disassociateIpAddress > disassociateUcsProfileFromBlade > enableAccount > enableAutoScaleVmGroup > enableCiscoNexusVSM > enableStaticNat > enableStorageMaintenance > enableUser > extractVolume > findHostsForMigration > findStoragePoolsForMigration > ldapCreateAccount > listAccounts > listAffinityGroups > listAffinityGroupTypes > listAlerts > listAutoScaleVmGroups > listAutoScaleVmProfiles > listBaremetalDhcp > listBaremetalPxeServers > listBigSwitchVnsDevices > listCapabilities > listCapacity > listCiscoNexusVSMs > listClusters > listConfigurations > li
[jira] [Resolved] (CLOUDSTACK-4912) API docs are missing some APIs
[ https://issues.apache.org/jira/browse/CLOUDSTACK-4912?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion resolved CLOUDSTACK-4912. - Resolution: Fixed API doc for ACS4.4.0 has ben build with noredist and contain all APIs. > API docs are missing some APIs > -- > > Key: CLOUDSTACK-4912 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-4912 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API, Doc >Affects Versions: 4.2.0, 4.3.0 >Reporter: Demetrius Tsitrelis >Assignee: David Nalley >Priority: Critical > Fix For: 4.4.0 > > > I grep’ed the source code and came up with a list of the APIs which the UI > uses. Many of them (addNetscalerLoadBalancer, addVmwareDc, etc.) are not in > the generated API documentation which appears at > http://cloudstack.apache.org/docs/api/apidocs-4.2/TOC_Root_Admin.html > Here’s the list of APIs used by the UI: > activateProject > addAccountToProject > addBaremetalDhcp > addBaremetalPxeKickStartServer > addCluster > addHost > addImageStore > addIpToNic > addLdapConfiguration > addNetscalerLoadBalancer > addNetworkServiceProvider > addNicToVirtualMachine > addRegion > addTrafficType > addUcsManager > addVmwareDc > addVpnUser > archiveAlerts > archiveEvents > assignToGlobalLoadBalancerRule > assignToLoadBalancerRule > assignVirtualMachine > associateIpAddress > associateUcsProfileToBlade > attachIso > attachVolume > authorizeSecurityGroupEgress > authorizeSecurityGroupIngress > cancelHostMaintenance > cancelStorageMaintenance > configureInternalLoadBalancerElement > configureVirtualRouterElement > copyIso > copyTemplate > createAccount > createAffinityGroup > createAutoScalePolicy > createAutoScaleVmGroup > createAutoScaleVmProfile > createCondition > createDiskOffering > createDomain > createEgressFirewallRule > createFirewallRule > createGlobalLoadBalancerRule > createIpForwardingRule > createLBHealthCheckPolicy > createLBStickinessPolicy > createLoadBalancer > createLoadBalancerRule > createNetwork > createNetworkACL > createNetworkACLList > createNetworkOffering > createPhysicalNetwork > createPod > createPortableIpRange > createPortForwardingRule > createPrivateGateway > createProject > createRemoteAccessVpn > createSecondaryStagingStore > createSecurityGroup > createServiceOffering > createSnapshot > createSnapshotPolicy > createStaticRoute > createStorageNetworkIpRange > createStoragePool > createTags > createTemplate > createUser > createVlanIpRange > createVMSnapshot > createVolume > createVPC > createVpnConnection > createVpnCustomerGateway > createVpnGateway > createZone > dedicateCluster > dedicateGuestVlanRange > dedicateHost > dedicatePod > dedicatePublicIpRange > dedicateZone > deleteAccount > deleteAccountFromProject > deleteAffinityGroup > deleteAlerts > deleteBigSwitchVnsDevice > deleteCiscoNexusVSM > deleteCluster > deleteCondition > deleteDiskOffering > deleteDomain > deleteEgressFirewallRule > deleteEvents > deleteF5LoadBalancer > deleteFirewallRule > deleteGlobalLoadBalancerRule > deleteHost > deleteImageStore > deleteIpForwardingRule > deleteIso > deleteLBHealthCheckPolicy > deleteLBStickinessPolicy > deleteLdapConfiguration > deleteLoadBalancer > deleteLoadBalancerRule > deleteNetscalerLoadBalancer > deleteNetwork > deleteNetworkACL > deleteNetworkACLList > deleteNetworkOffering > deleteNetworkServiceProvider > deleteNiciraNvpDevice > deletePhysicalNetwork > deletePod > deletePortableIpRange > deletePortForwardingRule > deletePrivateGateway > deleteProject > deleteProjectInvitation > deleteRemoteAccessVpn > deleteSecondaryStagingStore > deleteSecurityGroup > deleteServiceOffering > deleteSnapshot > deleteSnapshotPolicies > deleteSrxFirewall > deleteStaticRoute > deleteStorageNetworkIpRange > deleteStoragePool > deleteTags > deleteTemplate > deleteUcsManager > deleteUser > deleteVlanIpRange > deleteVMSnapshot > deleteVolume > deleteVPC > deleteVpnConnection > deleteVpnCustomerGateway > deleteVpnGateway > deleteZone > deployVirtualMachine > destroyRouter > destroySystemVm > destroyVirtualMachine > detachIso > detachVolume > disableAccount > disableAutoScaleVmGroup > disableCiscoNexusVSM > disableStaticNat > disableUser > disassociateIpAddress > disassociateUcsProfileFromBlade > enableAccount > enableAutoScaleVmGroup > enableCiscoNexusVSM > enableStaticNat > enableStorageMaintenance > enableUser > extractVolume > findHostsForMigration > findStoragePoolsForMigration > ldapCreateAccount > listAccounts > listAffinityGroups > listAffinityGroupTypes > listAlerts > listAutoScaleVmGroups > listAutoScaleVmProfiles > listBaremetalDhcp > listBaremetalPxeServers > listBigSwitchVnsDevices > listCapabilities > listCapacity > listCiscoNexusVSMs > list
[jira] [Commented] (CLOUDSTACK-7216) Cloudstack 4.4 on Xen 6.2 ERROR: Java process not running
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7216?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14082440#comment-14082440 ] Pierre-Luc Dion commented on CLOUDSTACK-7216: - Documentation has been updated, Installation or Upgrade to acs4.4.0 require following systemvm-template for xenserver: http://cloudstack.apt-get.eu/systemvm/4.4/systemvm64template-4.4.0-6-xen.vhd.bz2 > Cloudstack 4.4 on Xen 6.2 ERROR: Java process not running > - > > Key: CLOUDSTACK-7216 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7216 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.4.0 > Environment: CS 4.4 / XenServer 6.2 >Reporter: Dean Kamali > > Using SSVM template in documentation > http://download.cloud.com/templates/4.3/systemvm64template-2014-06-23-master-xen.vhd.bz2 > Running SSVM check on secondary storage VM will reveal that JAVA process is > not running. > This will result in inability to setup templates or take snapshots > # /usr/local/cloud/systemvm/ssvm-check.sh > root@s-29-VM:~# /usr/local/cloud/systemvm/ssvm-check.sh > > First DNS server is 8.8.8.8 > PING 8.8.8.8 (8.8.8.8): 48 data bytes > 56 bytes from 8.8.8.8: icmp_seq=0 ttl=49 time=8.900 ms > 56 bytes from 8.8.8.8: icmp_seq=1 ttl=49 time=8.525 ms > --- 8.8.8.8 ping statistics --- > 2 packets transmitted, 2 packets received, 0% packet loss > round-trip min/avg/max/stddev = 8.525/8.713/8.900/0.188 ms > Good: Can ping DNS server > > Good: DNS resolves download.cloud.com > > nfs is currently mounted > > Management server is 172.16.0.68. Checking connectivity. > Good: Can connect to management server port 8250 > > ERROR: Java process not running. Try restarting the SSVM. > root@s-29-VM:~# service cloud status > CloudStack cloud service is not running > root@s-29-VM:~# service cloud start > Starting CloudStack cloud service (type=secstorage) Success > root@s-29-VM:~# service cloud status > CloudStack cloud service is not running > root@s-29-VM:~# cat /etc/cloudstack-release > Cloudstack Release 4.4.0 Wed Jul 30 15:11:52 UTC 2014 > root@s-29-VM:~#tail /var/log/cloud.log > ERROR [cloud.agent.AgentShell] (main:null) Unable to start agent: Resource > class not found: com.cloud.storage.resource.PremiumSecondaryStorageResource > due to: java.lang.ClassNotFoundException: > com.cloud.storage.resource.PremiumSecondaryStorageResource -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7225) SystemVM paused in a new 4.4.0 installation
Pierre-Luc Dion created CLOUDSTACK-7225: --- Summary: SystemVM paused in a new 4.4.0 installation Key: CLOUDSTACK-7225 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7225 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: SystemVM Affects Versions: 4.4.0 Environment: XenServer 6.2, acs4.4.0 Reporter: Pierre-Luc Dion While creating a new zone on a new CloudStack Installation using XenServer 6.2, one of the systemVM will end with a "pause"state in XenServer. somthing CloudStack create a new systemVM, something it stock like that forever. I've observed this behavior multiple time on new install of 4.4.0 using the latest template : http://cloudstack.apt-get.eu/systemvm/4.4/systemvm64template-4.4.0-6-xen.vhd.bz2 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7225) SystemVM paused in a new 4.4.0 installation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14082472#comment-14082472 ] Pierre-Luc Dion commented on CLOUDSTACK-7225: - This environment use local storage for system VMs. > SystemVM paused in a new 4.4.0 installation > --- > > Key: CLOUDSTACK-7225 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7225 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM >Affects Versions: 4.4.0 > Environment: XenServer 6.2, acs4.4.0 >Reporter: Pierre-Luc Dion > Attachments: 44firststart.png, management-server.log.tgz, > xenserver62-new-acs44.png > > > While creating a new zone on a new CloudStack Installation using XenServer > 6.2, one of the systemVM will end with a "pause"state in XenServer. somthing > CloudStack create a new systemVM, something it stock like that forever. > I've observed this behavior multiple time on new install of 4.4.0 using the > latest template : > http://cloudstack.apt-get.eu/systemvm/4.4/systemvm64template-4.4.0-6-xen.vhd.bz2 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7225) SystemVM paused in a new 4.4.0 installation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion updated CLOUDSTACK-7225: Attachment: xenserver62-new-acs44.png management-server.log.tgz 44firststart.png > SystemVM paused in a new 4.4.0 installation > --- > > Key: CLOUDSTACK-7225 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7225 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM >Affects Versions: 4.4.0 > Environment: XenServer 6.2, acs4.4.0 >Reporter: Pierre-Luc Dion > Attachments: 44firststart.png, management-server.log.tgz, > xenserver62-new-acs44.png > > > While creating a new zone on a new CloudStack Installation using XenServer > 6.2, one of the systemVM will end with a "pause"state in XenServer. somthing > CloudStack create a new systemVM, something it stock like that forever. > I've observed this behavior multiple time on new install of 4.4.0 using the > latest template : > http://cloudstack.apt-get.eu/systemvm/4.4/systemvm64template-4.4.0-6-xen.vhd.bz2 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7219) Cannot display Cluster Settings after 4.4 Upgrade
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion updated CLOUDSTACK-7219: Attachment: cluster.png having the same issue after upgrading from 4.3 to 4.4. > Cannot display Cluster Settings after 4.4 Upgrade > - > > Key: CLOUDSTACK-7219 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7219 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM, Management Server >Affects Versions: 4.4.0 > Environment: CentOS 6, KVM Hypervisor >Reporter: Prieur Leary > Attachments: cluster.png > > > After upgrading MS to 4.4, when you to go: > Home -> Infrastructure -> Clusters -> Cluster 1 - > Settings > It does not display the settings underneath the column heading just, "ERROR". -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7225) SystemVM paused in a new 4.4.0 installation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7225?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion updated CLOUDSTACK-7225: Fix Version/s: 4.4.1 > SystemVM paused in a new 4.4.0 installation > --- > > Key: CLOUDSTACK-7225 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7225 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM >Affects Versions: 4.4.0 > Environment: XenServer 6.2, acs4.4.0 >Reporter: Pierre-Luc Dion > Fix For: 4.4.1 > > Attachments: 44firststart.png, management-server.log.tgz, > xenserver62-new-acs44.png > > > While creating a new zone on a new CloudStack Installation using XenServer > 6.2, one of the systemVM will end with a "pause"state in XenServer. somthing > CloudStack create a new systemVM, something it stock like that forever. > I've observed this behavior multiple time on new install of 4.4.0 using the > latest template : > http://cloudstack.apt-get.eu/systemvm/4.4/systemvm64template-4.4.0-6-xen.vhd.bz2 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-6886) Cannot add SDX Netscaler device
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion updated CLOUDSTACK-6886: Fix Version/s: (was: 4.4.0) 4.4.1 > Cannot add SDX Netscaler device > --- > > Key: CLOUDSTACK-6886 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6886 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Network Devices >Affects Versions: 4.3.0 > Environment: CloudStack 4.3 build with noredist packages >Reporter: Pierre-Luc Dion >Assignee: Will Stevens > Fix For: 4.5.0, 4.3.1, 4.4.1 > > Attachments: cs4.3_SDXfail.png > > > on CloudStack 4.3 with noredist packages, Adding a Netscaler device in > Network Service Providers as "NetScaler SDX LoadBalancer" type failed with > following error message: > "Failed to enable ssl feature on load balancer due to null" > Test perform using CloudStack webui. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7140) Upgrade 4.2.1 -> 4.4.0rc2
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion updated CLOUDSTACK-7140: Fix Version/s: 4.4.1 > Upgrade 4.2.1 -> 4.4.0rc2 > - > > Key: CLOUDSTACK-7140 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7140 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Upgrade >Affects Versions: 4.4.0 > Environment: CloudStack 4.2.1 on CentOS 6.5 >Reporter: Pierre-Luc Dion >Priority: Critical > Fix For: 4.4.1 > > Attachments: 4.2.1-to-4.3_management-server.log, catalina.out, > management-server.log > > > Upgrading CloudStack management 4.2.1 to 4.4.0rc2 fail to upgrade database. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Reopened] (CLOUDSTACK-7140) Upgrade 4.2.1 -> 4.4.0rc2
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7140?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion reopened CLOUDSTACK-7140: - This will be fixed in 4.4.1 > Upgrade 4.2.1 -> 4.4.0rc2 > - > > Key: CLOUDSTACK-7140 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7140 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Upgrade >Affects Versions: 4.4.0 > Environment: CloudStack 4.2.1 on CentOS 6.5 >Reporter: Pierre-Luc Dion >Priority: Critical > Fix For: 4.4.1 > > Attachments: 4.2.1-to-4.3_management-server.log, catalina.out, > management-server.log > > > Upgrading CloudStack management 4.2.1 to 4.4.0rc2 fail to upgrade database. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7219) Cannot display Cluster Settings after 4.4 Upgrade
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7219?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion updated CLOUDSTACK-7219: Fix Version/s: 4.4.1 > Cannot display Cluster Settings after 4.4 Upgrade > - > > Key: CLOUDSTACK-7219 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7219 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: KVM, Management Server >Affects Versions: 4.4.0 > Environment: CentOS 6, KVM Hypervisor >Reporter: Prieur Leary > Fix For: 4.4.1 > > Attachments: cluster.png > > > After upgrading MS to 4.4, when you to go: > Home -> Infrastructure -> Clusters -> Cluster 1 - > Settings > It does not display the settings underneath the column heading just, "ERROR". -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6323) GetUser API always returns admin info
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6323?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14090701#comment-14090701 ] Pierre-Luc Dion commented on CLOUDSTACK-6323: - I'll update the Release-note accordingly. it only affect GetUser API call right ? *Pierre-Luc DION* Architecte de Solution Cloud | Cloud Solutions Architect t 855.652.5683 *CloudOps* Votre partenaire infonuagique* | *Cloud Solutions Experts 420 rue Guy *|* Montreal *|* Quebec *|* H3J 1S6 w cloudops.com *|* tw @CloudOps_ On Fri, Aug 8, 2014 at 7:16 AM, Rohit Yadav > GetUser API always returns admin info > - > > Key: CLOUDSTACK-6323 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6323 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: API >Affects Versions: 4.0.0, 4.1.0, 4.2.0, 4.3.0, 4.4.0 >Reporter: Chiradeep Vittal >Assignee: Rohit Yadav > Fix For: 4.4.1 > > > The annotation is API_KEY for the parameter apikey which automatically gets > set to the requesters api key instead of the requested API key. The > annotation should be USER_API_KEY instead. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7342) Fail to delete template while using Swift as Secondary Storage
Pierre-Luc Dion created CLOUDSTACK-7342:
---
Summary: Fail to delete template while using Swift as Secondary
Storage
Key: CLOUDSTACK-7342
URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7342
Project: CloudStack
Issue Type: Bug
Security Level: Public (Anyone can view this level - this is the default.)
Components: Management Server
Affects Versions: 4.4.0, 4.4.1
Reporter: Pierre-Luc Dion
Priority: Minor
When trying to delete Templates using Swift as secondary storage. Delete fail
with following error message:
{code}
Unable to execute API command deletetemplate due to invalid value. Invalid
parameter zoneid value=undefined due to incorrect long value format, or entity
does not exist or due to incorrect parameter annotation for the field in api
cmd class.
{code}
--
This message was sent by Atlassian JIRA
(v6.2#6252)
[jira] [Created] (CLOUDSTACK-7343) cannot create Instance from template using Swift as secondary storage
Pierre-Luc Dion created CLOUDSTACK-7343: --- Summary: cannot create Instance from template using Swift as secondary storage Key: CLOUDSTACK-7343 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7343 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.4.0, 4.4.1 Environment: acs4.4.1-snapshot Reporter: Pierre-Luc Dion Priority: Minor Fail to create Instance from Template or ISOS when using Swift as secondary storage. The templates is show as ready in Cloudstack UI, when creating the new instance the template is created on the staging NFS share at the SSVM, but the vm will still fail to create. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7343) cannot create Instance from template using Swift as secondary storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion updated CLOUDSTACK-7343: Attachment: cloud.log_fromtemplate ssvm log. > cannot create Instance from template using Swift as secondary storage > - > > Key: CLOUDSTACK-7343 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7343 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.4.0, 4.4.1 > Environment: acs4.4.1-snapshot >Reporter: Pierre-Luc Dion >Priority: Minor > Labels: swift > Attachments: cloud.log_fromtemplate > > > Fail to create Instance from Template or ISOS when using Swift as secondary > storage. > The templates is show as ready in Cloudstack UI, when creating the new > instance the template is created on the staging NFS share at the SSVM, but > the vm will still fail to create. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7225) SystemVM paused in a new 4.4.0 installation
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7225?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14098668#comment-14098668 ] Pierre-Luc Dion commented on CLOUDSTACK-7225: - This problem is resolved for XenServer in 4.4.1-snapshot for the moment with latest systemvm from jenkins. > SystemVM paused in a new 4.4.0 installation > --- > > Key: CLOUDSTACK-7225 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7225 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: SystemVM >Affects Versions: 4.4.0 > Environment: XenServer 6.2, acs4.4.0 >Reporter: Pierre-Luc Dion >Priority: Critical > Fix For: 4.4.1 > > Attachments: 44firststart.png, management-server.log.tgz, > xenserver62-new-acs44.png > > > While creating a new zone on a new CloudStack Installation using XenServer > 6.2, one of the systemVM will end with a "pause"state in XenServer. somthing > CloudStack create a new systemVM, something it stock like that forever. > I've observed this behavior multiple time on new install of 4.4.0 using the > latest template : > http://cloudstack.apt-get.eu/systemvm/4.4/systemvm64template-4.4.0-6-xen.vhd.bz2 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7087) [VR] [VPN] Downgrade openswan to previous version for VPN services to fix OSX client
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14099031#comment-14099031 ] Pierre-Luc Dion commented on CLOUDSTACK-7087: - Can this be ported to 4.4.1 and 4.5 ? 4.4.1 seams the have the same issue. > [VR] [VPN] Downgrade openswan to previous version for VPN services to fix OSX > client > > > Key: CLOUDSTACK-7087 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7087 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.2.0, 4.3.0 >Reporter: Sheng Yang >Assignee: Harikrishna Patnala > Fix For: 4.2.1, 4.3.1 > > > Latest OpenSwan fail to work with OSX/IOS after latest Debian security > update(Mar 2014, https://www.debian.org/security/2014/dsa-2893 ). > And why Debian didn’t fix it officially, is because Debian decided to drop > the support for OpenSwan(since nobody is maintaining it and it hasn’t been > updated for 2 years before this security fix). We would need to move to other > VPN software in the future. > Here is the Debian bugzilla for the issue. > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744717 > So far, downgrade openswan is only an intermediate solution. We need to move > to other VPN software(e.g. StrongSwan) which is still maintained by Debain in > the near future. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-7087) [VR] [VPN] Downgrade openswan to previous version for VPN services to fix OSX client
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7087?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14099040#comment-14099040 ] Pierre-Luc Dion commented on CLOUDSTACK-7087: - This fix resolve the issue if systemvm templates from http://jenkins.buildacloud.org/view/4.3/job/cloudstack-4.3-systemvm64/193/ are used. Tested on xenserver. > [VR] [VPN] Downgrade openswan to previous version for VPN services to fix OSX > client > > > Key: CLOUDSTACK-7087 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7087 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Virtual Router >Affects Versions: 4.2.0, 4.3.0 >Reporter: Sheng Yang >Assignee: Harikrishna Patnala > Fix For: 4.2.1, 4.3.1 > > > Latest OpenSwan fail to work with OSX/IOS after latest Debian security > update(Mar 2014, https://www.debian.org/security/2014/dsa-2893 ). > And why Debian didn’t fix it officially, is because Debian decided to drop > the support for OpenSwan(since nobody is maintaining it and it hasn’t been > updated for 2 years before this security fix). We would need to move to other > VPN software in the future. > Here is the Debian bugzilla for the issue. > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=744717 > So far, downgrade openswan is only an intermediate solution. We need to move > to other VPN software(e.g. StrongSwan) which is still maintained by Debain in > the near future. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-722) Using a certificate chain for the Console Proxy is not documented
[ https://issues.apache.org/jira/browse/CLOUDSTACK-722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion updated CLOUDSTACK-722: --- Status: Reviewable (was: In Progress) > Using a certificate chain for the Console Proxy is not documented > - > > Key: CLOUDSTACK-722 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-722 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.0.0 >Reporter: Chip Childers >Assignee: Radhika Nair >Priority: Minor > Fix For: 4.3.0 > > Attachments: update-ssl.png > > > It would be nice if the uploadCustomCertificate (and specifically the id > parameter) to import a certificate chain into CloudStack was documented. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Resolved] (CLOUDSTACK-722) Using a certificate chain for the Console Proxy is not documented
[ https://issues.apache.org/jira/browse/CLOUDSTACK-722?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion resolved CLOUDSTACK-722. Resolution: Fixed Fix Version/s: 4.3.0 Closing the issue, The documentation is in RTD: http://docs.cloudstack.apache.org/projects/cloudstack-administration/en/latest/systemvm.html?highlight=ssl#changing-the-console-proxy-ssl-certificate-and-domain > Using a certificate chain for the Console Proxy is not documented > - > > Key: CLOUDSTACK-722 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-722 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.0.0 >Reporter: Chip Childers >Assignee: Radhika Nair >Priority: Minor > Fix For: 4.3.0 > > Attachments: update-ssl.png > > > It would be nice if the uploadCustomCertificate (and specifically the id > parameter) to import a certificate chain into CloudStack was documented. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-7343) cannot create Instance from template using Swift as secondary storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion reassigned CLOUDSTACK-7343: --- Assignee: Pierre-Luc Dion > cannot create Instance from template using Swift as secondary storage > - > > Key: CLOUDSTACK-7343 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7343 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.4.0, 4.4.1 > Environment: acs4.4.1-snapshot >Reporter: Pierre-Luc Dion >Assignee: Pierre-Luc Dion >Priority: Minor > Labels: swift > Attachments: cloud.log_fromtemplate > > > Fail to create Instance from Template or ISOS when using Swift as secondary > storage. > The templates is show as ready in Cloudstack UI, when creating the new > instance the template is created on the staging NFS share at the SSVM, but > the vm will still fail to create. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7343) cannot create Instance from template using Swift as secondary storage
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7343?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion updated CLOUDSTACK-7343: Status: Reviewable (was: In Progress) > cannot create Instance from template using Swift as secondary storage > - > > Key: CLOUDSTACK-7343 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7343 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.4.0, 4.4.1 > Environment: acs4.4.1-snapshot >Reporter: Pierre-Luc Dion >Assignee: Pierre-Luc Dion >Priority: Minor > Labels: swift > Attachments: cloud.log_fromtemplate > > > Fail to create Instance from Template or ISOS when using Swift as secondary > storage. > The templates is show as ready in Cloudstack UI, when creating the new > instance the template is created on the staging NFS share at the SSVM, but > the vm will still fail to create. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Assigned] (CLOUDSTACK-5879) Document on how to use RabbitMq event bus with spring modularisation done in 4.3, also document how to use encrypted password in the config file
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion reassigned CLOUDSTACK-5879: --- Assignee: Pierre-Luc Dion (was: Radhika Nair) > Document on how to use RabbitMq event bus with spring modularisation done in > 4.3, also document how to use encrypted password in the config file > > > Key: CLOUDSTACK-5879 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5879 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.3.0 >Reporter: Murali Reddy >Assignee: Pierre-Luc Dion > Fix For: 4.5.0 > > > Document on how to use RabbitMq event bus with spring modularisation done in > 4.3, also document how to use encrypted password in the config file. > From 4.3 RabbitMq event bus plug-in configuration need to be specified > differently (in 4.2 and 4.1 it was specified in componenetConext file) in > separate file. This doc bug is to get the necessary details required for 4.3 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-5879) Document on how to use RabbitMq event bus with spring modularisation done in 4.3, also document how to use encrypted password in the config file
[ https://issues.apache.org/jira/browse/CLOUDSTACK-5879?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion updated CLOUDSTACK-5879: Assignee: Radhika Nair (was: Pierre-Luc Dion) > Document on how to use RabbitMq event bus with spring modularisation done in > 4.3, also document how to use encrypted password in the config file > > > Key: CLOUDSTACK-5879 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-5879 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Doc >Affects Versions: 4.3.0 >Reporter: Murali Reddy >Assignee: Radhika Nair > Fix For: 4.5.0 > > > Document on how to use RabbitMq event bus with spring modularisation done in > 4.3, also document how to use encrypted password in the config file. > From 4.3 RabbitMq event bus plug-in configuration need to be specified > differently (in 4.2 and 4.1 it was specified in componenetConext file) in > separate file. This doc bug is to get the necessary details required for 4.3 -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Commented] (CLOUDSTACK-6409) Upgrade from 4.2.1 to 4.3.0 failed due to database upgrade script
[ https://issues.apache.org/jira/browse/CLOUDSTACK-6409?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14100740#comment-14100740 ] Pierre-Luc Dion commented on CLOUDSTACK-6409: - Could it be possible this issue has been resolved ? > Upgrade from 4.2.1 to 4.3.0 failed due to database upgrade script > - > > Key: CLOUDSTACK-6409 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-6409 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Upgrade >Affects Versions: 4.3.0 > Environment: CentOS 6.4, MySQL >Reporter: Yong Chen > Labels: patch > > Upgrade failed due to SQL upgrade script for 421-to-430 tries to add many > columns and tables that are exist already in 4.2.1. > Tried to modify DB manually (see below SQL commands) to satisfy the upgrade > script. However it seems there are a lot more than a few. This upgrade script > needs to be reviewed to be able to detect existence of columns and tables or > remove them if needed rather than fail. > ALTER TABLE async_job CHANGE related session_key INT; > ALTER TABLE async_job ADD job_cmd_originator INT; > ALTER TABLE async_job ADD callback_type INT; > ALTER TABLE async_job ADD callback_address INT; > ALTER TABLE async_job DROP job_type; > ALTER TABLE async_job DROP job_dispatcher; > ALTER TABLE async_job DROP job_executing_msid; > ALTER TABLE async_job DROP job_pending_signals; > ALTER TABLE network_offerings DROP keep_alive_enabled; > ALTER TABLE vm_instance DROP power_state; > ALTER TABLE vm_instance DROP power_state_update_time; > ALTER TABLE vm_instance DROP power_state_update_count; > ALTER TABLE vm_instance DROP FOREIGN KEY fk_vm_instance__power_host; > ALTER TABLE vm_instance DROP power_host; > ALTER TABLE load_balancing_rules DROP lb_protocol; > DROP TABLE vm_work_job; > DROP TABLE async_job_journal; > DROP TABLE async_job_join_map; > ALTER TABLE configuration DROP default_value; -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Created] (CLOUDSTACK-7365) Upgrading without proper systemvm template corrupt cloudstack management server
Pierre-Luc Dion created CLOUDSTACK-7365: --- Summary: Upgrading without proper systemvm template corrupt cloudstack management server Key: CLOUDSTACK-7365 URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7365 Project: CloudStack Issue Type: Bug Security Level: Public (Anyone can view this level - this is the default.) Components: Management Server Affects Versions: 4.3.0, 4.4.1 Reporter: Pierre-Luc Dion Since 4.3.0, also affecting 4.4.0 and 4.4.1. When upgrading CloudStack management server, it is required to have systemvm template properly named prior to the upgrade. otherwise the management server will fail to restart with after upgrading database schema. The possible repair method is to revert packages to previously installed CloudStack and restore the database which have been upgraded. This is not a viable upgrade path since management servers packages could be accidentally upgraded after a "yum upgrade" or "apt-get update". Upgrading CloudStack management-server without previously uploading systemvm template should not fail to start the management-server. if the systemvm template is not in place, then the management-server cannot start. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7365) Upgrading without proper systemvm template corrupt cloudstack management server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion updated CLOUDSTACK-7365: Affects Version/s: 4.4.0 Labels: upgrade (was: ) > Upgrading without proper systemvm template corrupt cloudstack management > server > --- > > Key: CLOUDSTACK-7365 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7365 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0, 4.4.0, 4.4.1 >Reporter: Pierre-Luc Dion > Labels: upgrade > > Since 4.3.0, also affecting 4.4.0 and 4.4.1. When upgrading CloudStack > management server, it is required to have systemvm template properly named > prior to the upgrade. otherwise the management server will fail to restart > with after upgrading database schema. > The possible repair method is to revert packages to previously installed > CloudStack and restore the database which have been upgraded. > This is not a viable upgrade path since management servers packages could be > accidentally upgraded after a "yum upgrade" or "apt-get update". > Upgrading CloudStack management-server without previously uploading systemvm > template should not fail to start the management-server. if the systemvm > template is not in place, then the management-server cannot start. -- This message was sent by Atlassian JIRA (v6.2#6252)
[jira] [Updated] (CLOUDSTACK-7365) Upgrading without proper systemvm template corrupt cloudstack management server
[ https://issues.apache.org/jira/browse/CLOUDSTACK-7365?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ] Pierre-Luc Dion updated CLOUDSTACK-7365: Attachment: 4.4.0to4.4.1_mgtlogissue.txt Post upgrade management-server.log. > Upgrading without proper systemvm template corrupt cloudstack management > server > --- > > Key: CLOUDSTACK-7365 > URL: https://issues.apache.org/jira/browse/CLOUDSTACK-7365 > Project: CloudStack > Issue Type: Bug > Security Level: Public(Anyone can view this level - this is the > default.) > Components: Management Server >Affects Versions: 4.3.0, 4.4.0, 4.4.1 >Reporter: Pierre-Luc Dion > Labels: upgrade > Attachments: 4.4.0to4.4.1_mgtlogissue.txt > > > Since 4.3.0, also affecting 4.4.0 and 4.4.1. When upgrading CloudStack > management server, it is required to have systemvm template properly named > prior to the upgrade. otherwise the management server will fail to restart > with after upgrading database schema. > The possible repair method is to revert packages to previously installed > CloudStack and restore the database which have been upgraded. > This is not a viable upgrade path since management servers packages could be > accidentally upgraded after a "yum upgrade" or "apt-get update". > Upgrading CloudStack management-server without previously uploading systemvm > template should not fail to start the management-server. if the systemvm > template is not in place, then the management-server cannot start. -- This message was sent by Atlassian JIRA (v6.2#6252)
