Home

This will be some ad-hoc information about plans for the future.

We have ambition for confluent to support most used xCAT capability. Currently things being targeted:

• Improved interop
  • Requests for oneshot or ongoing integration of confluent into other software will be entertained
    • Current: confluent2lxca, confluent2xcat, confluent2ansible
    • LXCA and xCAT should benefit from phase of discovery plugins as an alternative to the oneshot commands
  • Confer discovery benefit to other software, possibilities could include: cobbler, warewulf, etc.
• OS boot management (install). Different from xCAT in:
  • Bulk OS transfer will default to https, with option to do http
  • autoconsole kernel command line support - no more nodehm.serialport/nodehm.serialspeed required, automatic based on usage
  • OS images will be a filesystem structured facility rather than database described
  • Can start from network or remote usb (former requires opt-in to weaker security policy)
  • Will be able to coexist with dhcp servers (except for fighting other PXE servers, which will be a race condition)
  • Will not require a DHCP server
  • root password will default to disabled rather than failing installs
  • More prominently support use of static IP addresses rather than leaving hosts DHCP
  • Will assume tftp's role, if any, will be limited to transfer of iPXE
  • Will discontinue xNBA build, use iPXE directly (using the feature advertisement to detect difference between mismatched iPXE client and desired iPXE client)
  • Investigate use of cloud-init compatible structure
• Node 'self' APIs:
  • autoyast/kickstart/preseed files shall no longer contain even the encrypted password (no way to control the requests to have nodes attempt authentication)
    • By default, will not be written to filesystem
      • Broadly try to avoid node specific or deployer-specific on-disk content for easier shared filesystem usage
      • Command to commit current would-be to filesystem, and if present use that, but normally allow last-minute changes
  • Will no longer rely even vaguely on reverse name lookup (nodes will more positively identify themselves)
  • All self API callbacks will be https from curl, wget, or python code
  • Bake in install phase reporting
  • Only one call is available to weakly authenticated peers, and will be policy configurable whether that is allowed
    • Call allows retrieving a one time 'bootstrap' credential that gets exchanged for a persistent credential that can be used
    • bootstrap credential passed either as part of initrd in network boot (policy permitting) or a nodemedia upload
  • Proposed APIs:
    • /self/apikey- Get using bootstrap credential in header, receive persistent credential and disable bootstrap - stateless may require an open ended variant
    • /self/sshcertificate - Post public key, receive signed certificate (repeat for each key type)
    • /self/tlscertificate - Post CSR, received signed certificate (for non-ssh oriented setups)
    • /self/rootpassword - Get crypted form of root password, or the fact that root password login is forbidden
    • /self/deploystatus- Post current install progress. Deploy workflow will be defined and 'self' will not be allowed to go backward. Transitioning to 'complete' will deactivate the self apis. 'complete' or 'booted stateless' may trigger external software, e.g. an ansible playbook.
• 'Genesis'
  • Strategy for bringing onboard generic BMCs and/or shared port XCC/IMMs (replace bmcsetup with a pyghmi based python script in 'genesis')
  • Context for in-band firmware updates without OS - runimage pretty much verbatim, not much to add