Move the vagrant-libvirt plugin into being combined directly with
vagrant which both prevents the plugin from being reinstalled by any
subsequent call to `vagrant plugin install <plugin>` and avoids the need
to create and manage symlinks to a /vagrant.d directory for boxes.
Add boot_order to the merge function to ensure that provider config
sections will persist the value if defined in earlier blocks. However to
ensure it is possible to override, definitions in latter sections will
replace the earlier definitions, but only if provided.
Fixes: #937
For testing certain scenarios with vagrant-libvirt, need in the guest system a
value for the systems serial number in the DMI/SMBIOS system information.
The domain https://libvirt.org/formatdomain.html#smbios-system-information
format of libvirt allows to specify those values.
While adding `-smbios type=1,serial=$serial_value` to the `qemuargs` parameter
of the libvirt provider is already able to achieve this, a dedicated provider config
value adds native support from the `Vagrantfile` layering system. For example,
in the .box included Vagrantfile a random serial number can be enforced by
adding the following:
require 'securerandom'
Vagrant.configure("2") do |config|
config.vm.provider :libvirt do |libvirt|
libvirt.dmi_system_serial = SecureRandom.alphanumeric(8).upcase
end
end
Then in an instance specific Vagrantfile this value can be overwritten by adding:
Vagrant.configure("2") do |config|
config.vm.provider :libvirt do |libvirt|
libvirt.dmi_system_serial = "ABCDEFGH"
end
end
Co-authored-by: Nils Ballmann <nils.ballmann.ext@siemens.com>
Co-authored-by: Darragh Bailey <daragh.bailey@gmail.com>
Move to manage the entire plugin version menu and dependencies from the
same script. This will allow the entire site to roll forward to newer
releases and bugfix the plugin versions menu as issues are found, mostly
without needing to touch any of the individual releases.
Rework the links provided and menu styling to allow for a clear menu
edge, and a slight highlighting when hovering. Ensures that clicking
anywhere in the highlighted section should bring you to the selected
version.
Always use the same version of the plugin versions menu script, loading
from the latest across all releases. This is to allow for updates to
this component to be deployed across any release at the same time to
allow for a consistent switching experience.
Replace the select options for the plugin versions with one managed
purely using div tags and style primarily using JavaScript so the entire
menu can be managed from loading from a single script.
Retain a simple base style in the generated css file to facilitate
switching themes.
Avoid the need to parse the main version switching menu creation and
handling code by moving the site constants to a separate file.
Additionally move more of the element construction into the JavaScript
code to make it closer to a web component and facilitate more control by
a common script to be loaded by all published versions.
Switch from having all documentation contained within the README to
publishing a jekyll static site of documentation under github pages.
This allows for configuration and installation guides to be handled
separately to make for the relevant pieces to be in smaller chunks and
therefore easier to follow for users. Additionally a table of contents
can now be included in a left navigation section that ensures it should
be possible to quickly jump from the start to any section and back
again.
Include support for publishing previews and releases under separate
directories to allow for them to exist at the same time as the other
latest version of the documents.
The navigation section also includes support for accessing any of the
other versions published so that it easier to see what configuration
options exist for a given release. These will be published automatically
when releases are added.
