----
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.
- VRs are single CPU, so Threading based implementation favoured than Forking based
- Implements a Python based password server that does not use file based locks
- Saving password mechanism is provided by using secure token only to VR (localhost)
- Old serve_password implementation is removed
- Runs with Python 2.6+ with no external dependencies
- Locks used within threads for extra safety
This closes#106
(cherry picked from commit 4b45d25152a6661fcd1796670f0fb65bb4a32df5)
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
Set destination volume path as NULL while duplicating volume during migration.
If migration fails, destination volume will be marked as removed. And if migration succeeds, volume path will be rightly updated.
MigrateVMWithVolumes-
1. If ESXi host version is below 5.1, ensure destination datastore(s) is mounted on the source host, then migrate the storage and then finally migrate the VM.
If destination storage(s) is not mounted on the source host,
- In case of NFS storage mount the storage(s).
- In case of VMFS storage fail the request for migration.
2. If EXi host version is 5.1 or above, simultaneously migrate the VM and its storage to the destination host and storage(s) respectively for both NFS and VMFS storage.
This is a plugin that puts in ovm3 support ranging from 3.3.1 to 3.3.2. Basic
functionality is in here, advanced networking etc..
Snapshots only work when a VM is stopped now due to the semantics of OVM's raw
image implementation (so snapshots should work on a storage level underneath the
hypervisor shrug)
This closes#113
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
This commit produces event bus messages to a "cloudstack" topic
in Apache Kafka. Configuration is expected to be found in
/etc/cloudstack/management/kafka.producer.properties and will
generally be of the form:
bootstrap.servers=kafka-host1:9092,kafka-host2:9092
key.serializer=org.apache.kafka.common.serialization.StringSerializer
value.serializer=org.apache.kafka.common.serialization.StringSerializer
There is no way to parameterize the topic yet, and the consuming
code is just place-holder. I think adding a consumer within cloudstack
is very debatable and likely not needed.
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
- UI: use post when updating user
- S3: don't send s3 key in the response
- VPN: don't send preshared key in remoteaccessvpn api response
- Snapshot response should set zone id not volume's device id
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
(cherry picked from commit 02cadc3fb3fae7f5e8c87b7fafb977fb5eeae6eb)
Signed-off-by: Rohit Yadav <rohit.yadav@shapeblue.com>
