confluent plans

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
  • Can we get away without declaring node architecture explicitly? PXE tells us on the fly, OS images being applied can be presumed that the user knows what they are doing... Gap is whether something crops up in the remote media flow, though the remote media provider should almost certainly be able to provide if needed...
  • Will assume tftp's role, if any, will be limited to transfer of iPXE
  • Will discontinue xNBA build, use iPXE without patches (using the feature advertisement to detect difference between mismatched iPXE client and desired iPXE client)
  • Investigate use of cloud-init compatible structure
  • Do more 'baked in' implementation of the frequent add-ons (GPFS, nVidia, IFS, MOFED) potentially, as possible move 'otherpackages' type work into the images and into the installer phase to accelerate deployment/boot.
  • Ascertain whether to carry forward custom postscript, do something different, or advocate for ansible/salt/etc for heavily custom flows.
• 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/bmcconfiguration - Data for in-band 'configbmc' to be able to run
    • /self/templates/?node= - Get a file from the currently associated 'deploy' image and apply template transform. This will be available more freely as OS installers won't authenticate, and will be limited by deployment state. If a file exists in a certain location with the node name, that will be used instead of expanding the template on the fly. The templates should not contain any sensitive data (e.g. rootpw will be externalized to read from /self/rootpassword or cloud-init data.
    • /self/netconfig - Network configuration info to configure networks
    • /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

One thing to either delegate to xCAT or to port-out from xCAT as verbatim as possible is stateless/statelite support. While we have ideas on how to revamp many things that xCAT does, we may have no particular thoughts on how to make stateless/statelite fundamentally better. Tweaks to integrate with some of the facilities mentioned above, but no fundamental changes.