Until Abiquo 2.2, all the NICs of the virtual machines were attached to
the same physical Network Interface in the target physical machine,
since only one NIC per Virtual Machine was 'enabled'.
Starting from Abiquo 2.3, managed hosts can assign different 'Network Service Types'
to their Network Interfaces. The goal is to define what type of network is attached to each
NIC and have more control about how public and external VLANs are managed.
- gson from 2.2 to 2.2.2
- guava from 13.0 to 13.0.1
- rocoto from 6.1 to 6.2
- log4j from 1.2.16 to 1.2.17
- log back from 1.0.0 to 1.0.7
- httpclient from 4.1.3 to 4.2.2
- netty from 3.3.1 to 3.5.9
- slf4j from 1.6.4 to 1.7.2
- testing from various to 6.8
- jetty from 8.1.1 to 8.1.7
- snakeyaml from 1.10 to 1.11
This commit formats all the Abiquo provider following the jclouds
formatting guidelines. It uses the Eclipse default formatting
configuration and a 3 spaces indentation and a line wrap fo 120
characters.
Made a few changes to adapt the Abiquo compute service
implementation to the most common use cases:
* Do not attempt to create a VDC. Regualr users may not have
permissions to create VDCs, so don't try to create them. A
VDC compatible with teh template being deployed must exist.
* Configure nodes with one public ip by default, and if no
public ip is available, assign one from the default private
VLAN for the selected virtual datacenter.
Also fixed some concept mappings between Abiquo and jclouds:
Virtual datacenter (zone) election should be performed by the
TemplateBuilder and not by the ComputeServiceAdapter. This commit
refactors the current adapter to implement the right behavior.
The two main concepts in this refactor are about locations. Now,
physical datacenters will be scoped to Region locations, and virtual
datacenters to Zones.
Images in Abiquo are scoped to Regions (each physical datacenter has a
set of available images), and hardware profiles will be used to scope
images to a particular virtual datacenter. Since a virtual datacenter in
Abiquo is just a container that provides compute resources in a specific
virtualization technology, each image will have one hardware profile
scoped to each compatible virtual datacenter (zone).
This way, the virtual datacenter election will be made using the
TemplateBuilder, by selecting the desired hardware profile.
Having a deep look at this class noticed that most of the tests were
duplicating tests in the AsyncMonitorTest class. All the functionallity
provided by the awaitCompletion and monitor methods is already tested
(and properly tested using mocks) in that class, so those methods have
been removed.
The BaseMonitoringService class just delegates to the AsyncMonitor one,
adding a bit of logic to validate input parameters, so the
BaseMonitoringServiceTest class now only tests the logic it is
responsible for.