This introduces two new cloudstack packages: marvin and integration-tests.
The two packages will make it easier for CI systems to install Marvin for a
specific cloudstack release/build and run integration tests that are specific
for that version/build.
- maven: add explicit juniper-contrail-api maven repository
- marvin: build source distribution for both install and package mvn phases
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
* 4.7:
CLOUDSTACK-9376: Restrict listTemplates API with filter=all for root admin
CLOUDSTACK-9369: Restrict default login to ldap/native users
Add lsb-release dependency to mgmt server and agent on Debian/Ubuntu.
Emit template UUID and class type over event bus when deleting templates.
Add perl-modules as install dependency for cloudstack-agentRequired to run perl scripts that configure networking for VMs.
* pr/1495:
Add perl-modules as install dependency for cloudstack-agent
Signed-off-by: Will Stevens <williamstevens@gmail.com>
Support access to a host’s out-of-band management interface (e.g. IPMI, iLO,
DRAC, etc.) to manage host power operations (on/off etc.) and querying current
power state in CloudStack.
Given the wide range of out-of-band management interfaces such as iLO and iDRA,
the service implementation allows for development of separate drivers as plugins.
This feature comes with a ipmitool based driver that uses the
ipmitool (http://linux.die.net/man/1/ipmitool) to communicate with any
out-of-band management interface that support IPMI 2.0.
This feature allows following common use-cases:
- Restarting stalled/failed hosts
- Powering off under-utilised hosts
- Powering on hosts for provisioning or to increase capacity
- Allowing system administrators to see the current power state of the host
For testing this feature `ipmisim` can be used:
https://pypi.python.org/pypi/ipmisim
FS:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Out-of-band+Management+for+CloudStack
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
This feature allows root administrators to define new roles and associate API
permissions to them.
A limited form of role-based access control for the CloudStack management server
API is provided through a properties file, commands.properties, embedded in the
WAR distribution. Therefore, customizing API permissions requires unpacking the
distribution and modifying this file consistently on all servers. The old system
also does not permit the specification of additional roles.
FS:
https://cwiki.apache.org/confluence/display/CLOUDSTACK/Dynamic+Role+Based+API+Access+Checker+for+CloudStack
DB-Backed Dynamic Role Based API Access Checker for CloudStack brings following
changes, features and use-cases:
- Moves the API access definitions from commands.properties to the mgmt server DB
- Allows defining custom roles (such as a read-only ROOT admin) beyond the
current set of four (4) roles
- All roles will resolve to one of the four known roles types (Admin, Resource
Admin, Domain Admin and User) which maintains this association by requiring
all new defined roles to specify a role type.
- Allows changes to roles and API permissions per role at runtime including additions or
removal of roles and/or modifications of permissions, without the need
of restarting management server(s)
Upgrade/installation notes:
- The feature will be enabled by default for new installations, existing
deployments will continue to use the older static role based api access checker
with an option to enable this feature
- During fresh installation or upgrade, the upgrade paths will add four default
roles based on the four default role types
- For ease of migration, at the time of upgrade commands.properties will be used
to add existing set of permissions to the default roles. cloud.account
will have a new role_id column which will be populated based on default roles
as well
Dynamic-roles migration tool: scripts/util/migrate-dynamicroles.py
- Allows admins to migrate to the dynamic role based checker at a future date
- Performs a harder one-way migrate and update
- Migrates rules from existing commands.properties file into db and deprecates it
- Enables an internal hidden switch to enable dynamic role based checker feature
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
MySQLdb has been deprecated and is also not supported in Python 3.
mysql.connector is a connector written in Python which talks the
native MySQL protocol without any external code.
https://dev.mysql.com/doc/connector-python/en/
A few dependencies have been updated to their latest version and some
have been removed.
The ordering for some dependencies has been changed so that we will
depend on Java 8 over Java 7 when doing a new install.
This will install less packages on the system running CloudStack.
The -headless JRE doesn't include packages for running on desktops
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
This closes#588
This allows non-root users to add KVM hosts, the user should be an admin or
added to sudoers to execute sudo cloudstack-setup-agent.
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
Signed-off-by: Remi Bergsma <apache@remi.nl>
This closes#288
(cherry picked from commit d2b0c1a32b)
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
- Removes awsapi packaging rules for debian, centos63, centos7, fedora 20/21
- Removes catalina port 7080 service configs
- Fixes build replace properties for AWSAPILOG
- Removes maven profile for building awsapi and deploying db in developer profile
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
A better solution in future could be to pass the custom maven repo in local dir
from ACS_BUILD_OPTS instead of putting it here
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
By default it chooses a location based on $HOME which is not guranteed to
have a proper value on buildds.
We also need to take care of cleaning it up after the build.
Signed-off-by: Wido den Hollander <wido@widodh.nl>
The qemu-kvm package has become deprecated in Ubuntu 14.04 and
the right package to install would be qemu-system-x86
To maintain backwards compatibility for older Ubuntu LTS releases
we depend on qemu-system-x86 or qemu-kvm
Since we've agreed to use JDK/JRE 1.7, this enforces that for Ubuntu builds
- this fix remove usage of 1.6 paths in JDK_DIR for cloud-{agent, management, usage}.
- adds oracle jdk 1.7 path (in case a user is using that)
- adds mysql-connector-java path to CLASSPATH for usage server
- adds libmysql-java pkg dependency (tested and available for precise and trusty)
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
(cherry picked from commit 96d6a2a037)
Conflicts:
packaging/debian/init/cloud-usage
Adds pessimistic logic to try the hard coded paths if Rajani's logic fails
We now require at least Java 7 to build and run CloudStack.
Both the DEB and RPM packaging now also require Java 7 during installation
of the packages.
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.
This involves removing a couple of JAR files from these packages:
* cloud-deps
* cloud-agent-deps
* cloud-client
A couple of libraries no longer have the cloud-* prefix or go renamed otherwise.
We no longer include the following libraries:
* netscaler
* iControl
* manageontap
* jnetpcap
* junit
* jetty
* vmware
* xenserver
These are not required anymore or not allowed license wise.
By adding these files to the *.conffiles file we prevent them from being overwritten by dpkg.
We don't want to overwrite these files, since they can contain very specific information regarding the setup.