Difference between revisions of "Agile testbed/Cloud"
(→Image repository: remove section) |
(add section: virtualisation setup) |
||
| Line 2: | Line 2: | ||
[[Agile testbed/Cloud/Installation notes|Installation notes]] | [[Agile testbed/Cloud/Installation notes|Installation notes]] | ||
| + | |||
| + | ==Virtualisation setup== | ||
| + | OpenNebula is the component that manages multiple nodes as a single object. For flexibility, it will use libvirt to access the hosts. This allows one to use virt-manager and virt-install on a single host without using OpenNebula, and makes it possible to use KVM, Xen and VMWare together in a single cloud. | ||
| + | |||
| + | With the possibility to run [http://www.opennebula.org/documentation:rel2.2:libvirtapi libvirt on top of OpenNebula], we have all possible flexibility. Now only hope all the layers work properly. | ||
| Line 16: | Line 21: | ||
[http://www.semicomplete.com/articles/dynamic-dns-with-dhcp/ Dynamic DNS] [http://www.cameratim.com/computing/linux/using-bind-as-a-local-dns-server DDNS on Fedora] | [http://www.semicomplete.com/articles/dynamic-dns-with-dhcp/ Dynamic DNS] [http://www.cameratim.com/computing/linux/using-bind-as-a-local-dns-server DDNS on Fedora] | ||
| − | |||
| − | |||
==Contextualisation== | ==Contextualisation== | ||
Revision as of 17:32, 9 December 2010
There is an effort to move our Agile testbed to a cloud-based infrastructure. It is based on OpenNebula and currently in development.
Virtualisation setup
OpenNebula is the component that manages multiple nodes as a single object. For flexibility, it will use libvirt to access the hosts. This allows one to use virt-manager and virt-install on a single host without using OpenNebula, and makes it possible to use KVM, Xen and VMWare together in a single cloud.
With the possibility to run libvirt on top of OpenNebula, we have all possible flexibility. Now only hope all the layers work properly.
Networking
- Plug'n'play networking
- MAC and IP addresses handed out by OpenNebula
- An OpenNebula hook will be added to register the machine's name with DNS dynamically
- There will be three networks, initially:
- Closed: no internet connection (10.198.5.0/24, domain .closed)
- Private: internet access, masqueraded to the outside world (10.198.6.0/24, .private)
- Public: public IP addresses, bridged (domain .nikhef.nl)
These networks are all connected via eth1, so that the networks across different physical hosts can reach each other safely. Autana then masquerades the internal range for internet connectivity. Autana also runs a nameserver on 10.198.x.240 that serves the dynamic DNS in addition to being a DNS cache.
Contextualisation
When a cloud machine is instantiated from a base image from the repository, the machine should still be configured for the specific instance. This is done by an init script that is present in all base images, which sets up the network and runs any machine-specific initialisation. The OpenNebula contextualisation features will be used for this.
Services in the Cloud
Continuous Integration: Hudson
A virtual machine will run Hudson with the EC2 Plugin so that builds are done on dynamic virtual machines. The current CruiseControl service for VL-e builds will migrate to this (see also RPM build area customisation).
Authentication will preferably be done using a custom client-side ssl certificate plugin, which has received some effort already.
Future directions
When the cloud is properly setup, future directions can be explored like:
- Secure networking: ebtables hooks to only allow allocated mac from node
- Using virtual machines from within Hudson
- for on-demand build slaves (multiple platforms)
- for tests running on virtual machines
- Moving other parts of the testbed to the cloud, if it turns out to be an improvement.
