fc1b42c60d
Adds support for using UEFI boot mode for nodes. This is done via node capabilities, as it is in Ironic. The default boot mode is now configurable via the default_boot_mode variable. The default boot mode remains legacy BIOS for now, although this may change. Updates the existing CI jobs, with the OVS jobs using BIOS boot mode, and the linuxbridge jobs using UEFI boot mode. Depends-On: https://github.com/stackhpc/ansible-role-libvirt-vm/pull/83 Depends-On: https://github.com/stackhpc/ansible-role-libvirt-host/pull/50 Depends-On: https://review.opendev.org/c/openstack/kayobe/+/827486 Change-Id: Ifaf95ecfd4f6e925d3c69d4b324fdf2cd6b0ca52
2.9 KiB
Development
To-Do List
The following is a non-exhaustive list of features that are on the wishlist to be implemented in future.
More providers. It would be useful to extend Tenks to support providers other than Libvirt/QEMU/KVM - for example, VirtualBox, VMware or OpenStack.
More platform management systems. Redfish is gaining momentum in the Ironic community as an alternative to IPMI-over-LAN, so adding support for this to Tenks would widen its appeal. This would involve adding support for configuration of a Redfish BMC emulator, such as that which sushy-tools offers.
Increased networking complexity. As described in
assumptions, making the assumption that each network to which nodes are connected will have a physical counterpart imposes some limitations. For example, if a hypervisor has fewer interfaces than physical networks exist in Tenks, either one or more physical networks will not be usable by nodes on that hypervisor, or multiple networks will have to share the same interface, breaking network isolation.It would be useful for Tenks to support more complex software-defined networking. This could allow multiple 'physical networks' to safely share the same physical link on a hypervisor. VLAN tagging is used by certain OpenStack networking drivers (networking-generic-switch, for example) to provide tenant isolation for instance traffic. While this in itself is outside of the scope of Tenks, it would need to be taken into account if VLANs were also used for network separation in Tenks, due to potential gotchas when using nested VLANs.
More intelligent scheduling. The current system used to choose a hypervisor to host each node is rather naïve: it uses a round-robin approach to cycle through the hypervisors. If the next hypervisor in the cycle is not able to host the node, it will check the others as well. However, the incorporation of more advanced scheduling heuristics to inform more optimal placement of nodes would be desirable. All of Ansible's gathered facts about each hypervisor are available to the scheduling plugin, so it would be relatively straightforward to use facts about total/available memory or CPU load to shift the load balance towards more capable hypervisors.
Command-line interface. Currently, Tenks must be called by an
ansible-playbookinvocation with multiple parameters. It would be less clunky to introduce a simple CLI wrapper encapsulating some default commands.
Contribution
Contribution to Tenks' development is welcomed. Tenks uses the OpenStack development processes. Code reviews should be submitted to Gerrit, and bugs and RFEs submitted to StoryBoard.