- pointing to the new wiki page on 'How to build CloudStack'. Although
we shouldnt be using wiki sections on our docs.
- Also formatting the rpms built by cloudstack into a paramlisting
(cherry picked from commit c2afa0f03ce3c9a0f04dcc108039ba5ef2d9edf9)
The location on the downloads section points to the incubator pages and
the KEYS file used for GPG verify of the source points to the incubator
resource. Corrected both links
Signed-off-by: Prasanna Santhanam <tsp@apache.org>
There are three issues in resource_count table
(1) expunge a vm, the public_ip decreases and becomes -1 in basic zone.
(2) recover a vm, the volume increase.
(3) restore a vm, the volume decrease.
Reviwed-by: Kelven Yang <kelven.yang@citrix.com>
Description:
Change the criterion for overriding/preserving the vmware.create.full.clone
flag. The earlier criterion was simply the version numbers, but that is not
a good business logic basis for the change. With this fix, if past version
deployments have any deployments (data centers), this flag will be set to
false. Else, it will be set to true.
Changes:
- In the upgrade path, for a private zone, entry needs to be added in the affinity_group_domain_map to provide access to the private zone for the domains it belongs too.
when secondary storage is mounted as read-only, changing permission of files on it will fail. But we should still stick to current mount point instread of
returning a wrong mount point /mnt/sec
Since introducing pool of session contexts we no more have a dedicated context for each VMware hypervisor host.
Hence vsm credentials stored in session context cannot be retrieved always correctly. Fix is to register the vsm credentials after fetching context and the context gets recycled after use.
Signed-off-by: Sateesh Chodapuneedi <sateesh@apache.org>
On a fresh environment, some values in cloud.configuration table are persisted in com.cloud.server.ConfigurationServerImpl.persistDefaultValues()
A default value need to be set before com.cloud.upgrade.DatabaseUpgradeChecker
(cherry picked from commit 1a67750cb6)
Template url, hypervisor and format were defined in Service class to be Xenserver specific
and therefore registering a new template failed on Vmware and KVM.
Fixed this to get hypervisor specific info for registering new template.
Signed-off-by: Prasanna Santhanam <tsp@apache.org>
(cherry picked from commit 20256706b376551fe8993ee2e73c61df31dcb6de)
This works around the delay caused in adding Xen 6.1/6.2 hosts where
host takes two attempts to transition to Up state. We will wait for one
minute per cluster before attempting to add storage pool in the cluster.
Signed-off-by: Prasanna Santhanam <tsp@apache.org>
(cherry picked from commit 22ee499c3571b2a6b6921abb36c679128893c415)
Description:
Do not overwrite value of vmware.create.full.clone flag in the
cloud db if it already exists. This will preserve the configured
clone creation behaviour across upgrades.