Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

aiiv3 RFC #97

Open
stdweird opened this issue Nov 20, 2014 · 4 comments
Open

aiiv3 RFC #97

stdweird opened this issue Nov 20, 2014 · 4 comments
Assignees

Comments

@stdweird
Copy link
Member

AII should provide support for iPXE. Main change is support for more then tftp pxeboot (eg http or iscsi).

However, to make proper usage of the new possibilities of iPXE, the current way of tracking the boot state of node needs to be replaced and made independent of the pxe implementation choosen by a site.

The actual implementation of the site pxe preference (syslinux or iPXE or ...) can then start from the state and required data:

  • the (existing) file and symlink code and structure for syslinux
  • webinterface to the data for iPXE
  • ...

State and data can use a DBI:: backend (simple sqlite for small sites should be enough; but can be replaced by actual database for reasons like speed and/or size); all other tools (and new tools) can interact with that.
The required database schema should be sufficiently simple.

  • state tracking involves a set of supported states and timestamps for bookkeeping (e.g. when did nonde migrate from install to boot?)
  • the required data to be stored is the profile data accessed by aii-pxelinux; it is kept in database to avoid having to access (and thus have access to) the full profile. data required for pxe phase is typically not sensitive and might not be as well secured as access to the full profile. A number of fixed fields can be choosen together with a text field to store literal JSON data for less common or non-fixed/non-mandatory fields.

Simplicity seems key in the AII code, sites are free to develop more complex machinery around these basics such as:

  • (rest) API
  • webinterface for admins to check/change state
  • more advanced databases that trigger an action upon state changes (e.g. when making modification via API webinterface)
  • generate DNS data
  • ...

The required code changes will mainly impact:

  • AII scripts
  • AII install ack cgi
  • aii-pxelinux

Additional proposal wrt DHCP:

  • any dhcpd data generated/modified by AII is done in separate file(s) that can be included by main dhpcd config files, to separate the static and the dynamic portions of the DHCP configuration. This very likely means that will require a recent enough DHCP server, possibly only supporting EL6 or later as base OS. This is to be investigated.
  • AII dhcp code should be designed to allow non-file dhcp configuration support at later stage (eg DHCP+LDAP or KEA)
    Since the DHCP data is also limited, we might also want to store with the pxe (or in different table) of the AII pxe database. No parsing of the dhcp config files by AII would be required anymore; the config files can be regenerated upon a database change. (If the proposal to use a database also for the dhcp data is unacceptable, we should serioulsy consider to augment the dhcp config files with comment blocks to allow better/easier parsing of the generated configfiles by AII)
@stdweird stdweird added this to the 15.4 milestone Nov 20, 2014
@stdweird stdweird self-assigned this Nov 20, 2014
@jrha
Copy link
Member

jrha commented Nov 21, 2014

👍

@stdweird
Copy link
Member Author

support for UEFI pxeboot configuration

@jrha jrha modified the milestones: 16.2, 15.8 Aug 11, 2015
@jrha jrha removed this from the 16.4 milestone Dec 12, 2015
@jouvin
Copy link
Contributor

jouvin commented Oct 28, 2016

This issue is almost 2 years old and I am not sure how we can progress on it. May be good to add in the description a list of the tasks that must be completed and potentially open sub-issues for some of them.

@jrha
Copy link
Member

jrha commented Nov 12, 2024

any dhcpd data generated/modified by AII is done in separate file(s) that can be included by main dhpcd config files, to separate the static and the dynamic portions of the DHCP configuration. This very likely means that will require a recent enough DHCP server, possibly only supporting EL6 or later as base OS. This is to be investigated.

This works fine and is in fact what we have been doing at RAL for many years.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Development

No branches or pull requests

3 participants