Yes, we are committed to it being open source ongoing. I won't rule out proprietary things built on top of it, but at least in all the ways that exist today and the CLI I don't imagine any changes. Currently, the GUI is not technically open sourced (though everyone gets the source code, but no redistribution). I do hope to at least open source our upcoming browser library that makes writing a webui with all the async behaviors a bit more trivial (which is what the next WebUI will be written with).
Yes, non-Lenovo functions are welcome. As of 3.8.1, after testing the redfish update on a 'generic' openbmc system and Bluefield 3 BMC, the push firmware updates have been placed in generic. Currently the only non-Lenovo vendor specific behavior is a bit to deal with a peculiar choice with Dell virtual media, other things are plain redfish. A target rich area would be the out-of-band discovery code, since I wager all the major implementations are capable. I did see one OpenBMC solution that wouldn't really work, but I've seen other OpenBMC implementations that were workable. Most other stuff is at least described by standards (uefi settings, firmware updates for example) and vendors that bother to implement it tend to stick to the standard, so far. The trickiest thing is 'nodehealth', where redfish provides a HealthRollup, but I feel like systems rarely use it well enough. Maybe that's just a motivation to push vendors to use that more consistently if it's a problem... In any event, configbmc (bmcsetup replacement) uses standard IPMI, should be easier to extend than the bmcsetup script has been, and PXE discovery works like it can in xCAT (though without the requirement to actually boot a Linux anymore, discovery happens on the DHCPDISCOVER packet in the PXE attempt). So the 'worst case' is as far as we ever bothered to push xCAT, discovery wise. Governance is a matter that can be discussed. Currently I am the arbiter of pulls, but we can discuss other options. With xCAT when we were still tied to xCAT, we maintained a Lenovo branch so that I was no longer arbiter of master, but we still had freedom to release changes without getting them in master (e.g. SHA256 IPMI support was one that we could drive into Lenovo, but didn't work hard enough to get into master). The 'lenovobuild' branch in xcat-core is what I reference, all still open source, just the ability to snag pull requests even if they don't make it through to main branch on time for one of our requirements. On the last, much depends on what is seen as missing that we want to continue. Off the top of my head, confluent doesn't push ISC dhcp configuration (because it has a built in PXE server that can work with either an uncontrolled DHCP server or in a static only fashion) or ISC BIND (it still, upon request, helps make /etc/hosts files, but shrugs and considers dnsmasq's direct use of /etc/hosts as serviceable), or POWER servers or significant virtualization management. ________________________________ From: Don Avart <dav...@redlineperf.com> Sent: Thursday, September 21, 2023 1:05 PM To: xCAT Users Mailing list <xcat-user@lists.sourceforge.net> Subject: Re: [xcat-user] [External] Re: Announcement: xCAT Project End-Of-Life planned for December 1, 2023 I couldn’t agree more with Brian’s sentiment about xCAT. We, RedLine, have been xCAT users, integrators and occasional contributors since the end of IBM’s CSM. We’ve deployed it on numerous vendor platforms and it just works. As a small business in the greater HPC marketplace we have many customers that rely on xCAT and we will need to work with them to identify an alternative should xCAT discontinue. I’ve reached out to the IBM team as well as Jarrod from Lenovo and others in the community. I am very interested in putting together a plan that would continue to provide an open source option that is platform agnostic. With respect to Jarrod’s comments about using Confluent as a starting point for future development of xCAT, there are a number of considerations. Here are a few. * Is Lenovo committed to keeping Confluent open-source * Is Lenovo open to integration of features/capabilities of non-Lenovo vendors * Governance. Who controls changes to the code base and future development directions * Does xCAT remain it’s own project and share code with Confluent or do they become one project There are definitely other considerations, but I just wanted to get a few thoughts out there. My opinion is that Jarrod’s idea is one that should be given significant thought and debate. xCAT2 was, according to everything I’ve read, a complete rewrite of the original xCAT. Therefore, adopting Confluent as the next version is not a bridge too far, in my opinion. I also can’t speak to the original intentions of IBM when xCAT2 was released with respect to multi-vendor support. I can say that as a member of the xCAT community I would like to see the project continue as open source and vendor agnostic. I would really like to hear from anyone that is interested in keeping the project alive. I’m hopeful that we can reach a solution as a community. Best Regards, ---- Don Avart CTO RedLine Performance Solutions, LLC (703) 634-5686 dav...@redlineperf.com On Sep 21, 2023, at 10:59 AM, Jarrod Johnson <jjohns...@lenovo.com> wrote: There are at least some options I've heard discussed, if anyone has feedback: -Someone to take over the xCAT 2.x codebase as-is, adding some missing stuff like Ubuntu 20+ support, RHEL9, etc. I don't know that anyone has volunteered to go all in on all that exactly yet. -Try to establish a community around confluent (potentially as 'xCAT 3'). This may suggest some sort of rebranding and/or governance changes, but basically starting from confluent instead of xCAT 2 for the xCAT-like experience. Not precisely xCAT-like but was designed "by one of the designers of xCAT 2" with a lot of sensibilities preserved. Given that there's not much in the way of 'backwards compatibility', I'm cautious about the 'xCAT 3' branding, and while I would be a consistent contributor across xCAT 2.0 through 2.8 and then confluent, it would technically be a change from an IBM to Lenovo contributions, which I could see being a challenge. -The current default trajectory is an archived project and people having to decide for themselves what to do next (only 'all-in-one' options that I know to be cross-platform are Bright and Confluent, if just OS deployment, then I commonly see Foreman used for diskful, with Warewulf being an option for mostly diskless scenario). Obviously, I like Confluent best, but of course I would. ________________________________ From: Brian Joiner <martinitime1...@gmail.com<mailto:martinitime1...@gmail.com>> Sent: Thursday, September 21, 2023 9:57 AM To: xcat-user@lists.sourceforge.net<mailto:xcat-user@lists.sourceforge.net> <xcat-user@lists.sourceforge.net<mailto:xcat-user@lists.sourceforge.net>> Subject: [External] Re: [xcat-user] Announcement: xCAT Project End-Of-Life planned for December 1, 2023 This is the saddest thing I've hear in some time. I've had the chance to support customers with Bright, HP cluster manager, and xCAT. xCAT was by far the best. Thank you for all your work, I hope that a transition can happen! Thanks, Brian J On 9/1/23 11:49 AM, Nathan A Besaw via xCAT-user wrote: Mark Gurevich, Peter Wong, and I have been the primary xCAT maintainers for the past few years. This year, we have moved on to new roles unrelated to xCAT and can no longer continue to support the project. As a result, we plan to archive the project on December 1, 2023. xCAT 2.16.5, released on March 7, 2023, is our final planned release. We would consider transitioning responsibility for the project to a new group of maintainers if members of the xCAT community can develop a viable proposal for future maintenance. Thank you all for you support of the project over the past 20+ years. _______________________________________________ xCAT-user mailing list xCAT-user@lists.sourceforge.net<mailto:xCAT-user@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/xcat-user _______________________________________________ xCAT-user mailing list xCAT-user@lists.sourceforge.net<mailto:xCAT-user@lists.sourceforge.net> https://lists.sourceforge.net/lists/listinfo/xcat-user
_______________________________________________ xCAT-user mailing list xCAT-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcat-user
