#10: Machine pool at controller
-------------------------+-----------------------
Reporter: rpazdera | Owner: somebody
Type: enhancement | Status: new
Priority: major | Milestone:
Component: component1 | Version:
Keywords: | Blocked By:
Blocking: |
-------------------------+-----------------------
We discussed an idea concerning recipe execution today. Now you always
need to change some parameters of the recipe in case you want to run it on
a different set of test machines (which kinda sucks).
Jirka proposed, that we could have a local static configuration at each
controller, that would define a pool of available netmachineconfigs. Those
configs would be then
matched against some defined requirements for machines in the recipes and
allocated
for tests.
This would also solve the not-very-pretty <libvirt_create> tag, because it
would be abstracted within the pool. If there is a virtual machine in the
pool, the interfaces could be created automatically without any other
markup.
I thought about the pool and it could be a drop-in configuration directory
with netmachineconfig xmls. This approach would require a minimum of new
code. For instance a pool could look like this:
{{{
/etc/lnst.conf # ini or XML file with some general
# controller specific configuration
# like RPC ports, available IP/MAC addr ranges
/etc/lnst.pool.d/ # the drop-in netmachineconfig pool
/etc/lnst.pool.d/f14-peanut.xml # physical netmachineconfig
/etc/lnst.pool.d/RHEL6-clone.xml # virtual one
}}}
--
Ticket URL: <
https://fedorahosted.org/lnst/ticket/10>
lnst <
http://example.org/>
My example project