Including following steps:
b. Run "cloudstack-agent-upgrade". This script will upgrade all the existing bridge name to new bridge name, and update related firewall rules.
c. install a libvirt hook:
c1. mkdir /etc/libvirt/hooks
c2. cp /usr/share/cloudstack-agent/lib/libvirtqemuhook /etc/libvirt/hooks/qemu
c3. chmod +x /etc/libvirt/hooks/qemu
c4. service libvirtd restart
(cherry picked from commit a0988780ad)
Signed-off-by: Wei Zhou <w.zhou@leaseweb.com>
(1) Replacing db.properties with management server db.properties
(2) Rename log4j-cloud_usage.xml to log4j-cloud.xml
(cherry picked from commit fb97e8e617)
This are symlinks to server-nonssl.xml and tomcat6-nonssl.conf, but
they are required for starting the management server.
Commit 2db7a4559e broke this.
We should be carefull what we package since all configuration should
be in /etc/cloudstack/management
Signed-off-by: Wido den Hollander <wido@widodh.nl>
working again.
The newly created package for cloudstack-management was not correctly
installing the service. This prevented cloud-setup-management from being
able to configure the service, and the init script didn't even believe
the service was installed. I also added sudo to the chmod command for
checking script permissions, as most scripts belong to root. It was
trying to configure the agent with cloudstack-setup-agent but the script
was still called cloud-setup-agent, so I renamed it to cloudstack-setup-agent.
The old packages used to write this data to the configuration
in a postinst file.
That was horrible to track since system administrators had no
idea what was going on.
We no longer symlink db.properties to the management server, but
we create a own db.properties for the usage server.
During a upgrade we copy the file to make the upgrade easier.
Detail: This gets rid of the patchdisk method of passing cmdline and
authorized_keys to KVM system VMs. It instead passes them to a virtio socket,
which the KVM guest reads from the character device /dev/vport0p1 during
cloud-early-config. Tested to work on CentOS 6.3 and Ubuntu 12.04. Should
work with even older versions of libvirt.
Signed-off-by: Marcus Sorensen <marcus@betterservers.com> 1362691685 -0700
For both the RPM and DEB packages are new directory for plugins
for the agent is created.
All JAR files in that directory will be added to the classpath
on boot of the agent.
Libvirt-java 0.4.9 works just fine with JNA 3.2.4 which is in
all distributions.
Future libvirt version require at least JNA 3.5.1 due to new methods
and memory management, but that is not our concern now.
By depending on the JNA in the distribution and adding it to the classpath
we can work just fine.
The new cloudstack-agent package wouldn't boot due to various issues.
Those all seem to be resolved.
Other changes include path changes like /etc/cloud -> /etc/cloudstack
The new package now installs, but the upgrade hasn't been tested yet.
This is FAR from perfect, but it works for now.
the VERSION variable returns 4.1 from the debian/changelog file, but in
the Maven configuration everything is already set to 4.2
So generated JAR files have 4.2.XX-SNAPSHOT in their name.
We probably want to find a better way to match this, extracting the version
somewhere out of Maven maybe?
Some concepts included:
* the replace.properties location used by maven is parameterized to allow
for a build that does not modify the currently git tracked files
* package naming is updated along the lines of what was discussed on the
-dev mailing list and between committers at the Build a Cloud Day in Belgi
* package version pattern is updated (since we redo all package names,
we might as well drop the epoch)
Detail: new script called cloud-ssh replaces the long
'ssh -i /root/.ssh/id_rsa.cloud -p 3922 root@169.254.0.12'
users can now just run 'cloud-ssh 169.254.0.12'. Also adds it to deb and rpm
builds.
Signed-off-by: Marcus Sorensen <marcus@betterservers.com> 1353086232 -0700
Right now it isn't working yet, but this is the way it should start working
like the RPM package building is.
This commit is to clean up the rules file a bit and lay the groundwork for
the Debian packaging
Both the Agent and Server require Google GSON. This is not available from
the Ubuntu repositories, so we have to package it ourselfs.
Due to the fact that people might choose to run the Hypervisor on the same
host as the management server we can't have cloud-agent-deps conflict with cloud-deps
cloud-agent-deps now depends on cloud-deps so the hypervisor has Google GSON 1.7.1
This results in a number of extra JAR files to be installed on the hypervisor.
The management server also depends on a couple of these scripts, so renaming
to cloud-scripts makes more sence then installing cloud-agent-scripts.
In the future we might want to split this up in two packages.
cglib 2.2.2 is available in Ubuntu and Debian from the repositories, no need
to ship it in the cloud-deps package.
It's also not used by cloud-agent, but by cloud-utils, so place the dependency there.
Ubuntu 12.04 and Debian (testing) both ship from their repository, so there is no need
for us to distribute it in our packages.
We depend on it externally for our logging.
Hugo Trippaers
Wei Zhou
Darren Shepherd
Wido den Hollander
ynojima
Wido den Hollander
Chip Childers
Rene Diepstraten
Hiroaki KAWAI
Chip Childers
Pradeep Soundararajan
Brian Spindler
Marcus Sorensen
Noa Resare
Rohit Yadav
Kanzhe Jiang
Edison Su
David Nalley