- Update base debian iso to version 7.11
- Upgrade ruby version to 2.3.0 (latest/stable)
- Fix Gemfile
- Update README
- Fix openswan pkg name with the same version
- Remove cloud-cleanup it's not available
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
- Adding keepalived installation in the right script. I added the change on the buildsystemvm.sh, which is no longer used.
Signed-off-by: wilderrodrigues <wrodrigues@schubergphilis.com>
The console-setup service brings a nice font to the console, but why would we want to use it. In most cases it takes a <10 seconds to set it up. When using nested hypervising, I found this takes much longer time that causes tests to time-out. I'd suggest turning off these services. They are not required for the services the systemvm provides.
/var/log fills up /var and fails operation of normal services. This fix
restricts /var/log to 100-200M. The fix for CLOUDSTACK-6885 tries to make sure
we don't keep a lot of logs.
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
Replace chef with a python script
configure.py will read the bags and (hopefully) create the desired state
At this stage this is ipassociation
This code should work for both VR and VPCrs
TODO:
iptables
ip route throw (present in VR but not in VPCr
Determine default route
Unit tests
----
Author: Ian Southam <isoutham@schubergphilis.com>
First commit towards moving systemvm to chef based configuration
In this commit
1. cmdline json databag is created
2. ip association data bag is created
3. Basic chef cookbook to manage ips and routes
Conflicts:
systemvm/patches/debian/config/etc/init.d/cloud-early-config
systemvm/patches/debian/config/var/chef/cookbooks/README
tools/appliance/definitions/systemvm64template/postinstall.sh
----
Because we've refactored the systemvm template the change to
postinstall.sh now gets its own chef.sh file.
Installed flask package and removed the disk expert recipe in
system vm template to keep only one partition
Signed-off-by: Frank Zhang <frank.zhang@citrix.com>
In 8e2d06153b3d5ec1540fac1c8fbc97b5d2b58a8e I mistakenly/accidentally
a apt-get update.
As
https://wiki.debian.org/Multiarch/HOWTO
explains, apt-get update is needed after adding a new architecture.
Create a new minimal 'debianbase' definition which is a veewee template
that's a lot like the systemvmtemplate, but does not have any
systemvm-ness in it. Use it to create a new test.sh which tests a few
common invocations of build.sh work as desired.
This is mainly useful for debugging whether the appliance build process
is working / consistent; in order to test a systemvm itself it should
really first be merged with systemvm.iso.
The current build downloads its script from master by fetching a cloudstack
tarball. Besides being an unneeded load on the apache git server, this is a
problem when working on a branch and wanting to inject a different set of
scripts. It also makes it pretty likely that the injected copy of the script
will not match what a production release wants, so there is very little
chance of not needing to overwrite the scripts.
Ideally we would just rsync over some files. However, veewee does not provide
an option to do that. In order to keep a 'cleanly veewee-only' build possible,
and work with any recent veewee version, in this change we restor to using
shar (http://en.wikipedia.org/wiki/Shar) to produce an archive which can
execute as a script, which we feed to veewee to execute.
When working on the systemvm in isolation, or using vagrant or similar tools,
it can be useful to inject a custom SSH key before merging a management server
systemvm.iso into it. This option allows that. It should _not_ have effect
on management-server-managed vms which always get their SSH keys injected.
In theory this _could_ have changed behavior (apt coming up with a different
solution, or one of the packages configuring a new apt repository), but in my
testing, the end result is the same.
