Re: [xcat-user] [External] Announcement: xCAT Project End-Of-Life planned for December 1, 2023
Jared, just to clarify , is confluent available for anyone as an opensource tool? Or is this geared to do lenovo specific installations? >From what I understand, it would be great to get a general demo of the installation/configuration , etc. . I have a test environment in our cluster where I can test things for HPE, Dell, SuperMicro, ASUS, Gigabyte servers. Thanks. --imam On Fri, Sep 1, 2023 at 5:07 PM Jarrod Johnson wrote: > In light of this announcement, I'll take a moment to at least mention > Lenovo's strategy here, for those that are not yet aware. > > I had refrained from posting too much on xcat-user about it because I > didn't want to intrude too much on xCAT users' mailboxes, but it seems > potentially important. > > Back in 2014, my team started work on confluent ( > https://github.com/xcat2/confluent). We promptly found out that we'd be > going over to Lenovo, which admittedly complicated our relationship to the > larger xCAT project. The general idea was "spiritual successor to xCAT 2". > > So why not "xCAT 3"? To have the freedom to reimagine some things in a > not quite compatible way, and not be too pushy about this "new xCAT" being > the way forward for those that didn't like it. In part thinking of the > transition between Gnome 2 and Gnome 3 that was just dramatically different > vision, which I thought warranted a new name, for better or worse, so my > stance was similar about "xCAT 2" to "confluent". > > When going from xCAT 1 to xCAT 2, we didn't quite match up either, more > migration tools were available for CSM users than xCAT 1 users. However a > lot of the design sensibilities were similar. The filesystem layout of an > OS image was similar, the SQL databases resembled xCAT tab files, etc. > Gaps in this strategy were handled with things like the osimage table (to > gather OS profile information into... fewer places, not one place) and the > objdef layer to bring node attributes together and os image attributes > together. > > With confluent, we wanted to change some things up: > -While we liked the 'category.attribute' scheme of tabular structure, the > organization of objdef seemed to be more friendly. So confluent node > attributes are key value like objdef, but with a naming scheme of > 'category.attribute'. > > -OS images assembled from various places in the filesystem, with only the > OS image tables to guide where on disk things were was always a struggle, > so confluent has OS profiles be entirely described as one or two > directiories (/var/lib/confluent/public/os/ and sometimes > /var/lib/confluent/private/os/). Customization can be done > with no worry about rpm updates trouncing customization, and the entire > structure of the OS profile is more self explanatory. > > -Most of the deployment logic moved "target side", where the API provides > the same data in the same format to any deploying OS, and code in the > respective OS deployment is responsible for integrating the information > into the right tools/format (debian-installer, kickstart, autoyast, > subiquity, netplan, wicked, networkmanager, etc). Compared to xCAT where we > would do a form fill sort of thing on kickstart and similar. > > -More hardened approach to security: > -Confluent does not run as root > -tftp is now optional (firmware permitting) > -Secureboot is now supported > -Diskless and cloning images are, by default, encrypted > -Diskless nodes, by default, use the TPM to persist trust for the > confluent API > -TLS is very carefully set up with validation (deployment is done over > https as well as all node API calls) > -A simplified, singular step serves as the path to getting a node API > token, instead of the xCAT myriad of moderately open functions > -No private user or host SSH keys are transfered. User keys are replaced > with host based authentication, known_hosts helping is handled through > providng SSH certificates to the host generated keys. Host keys never > leave the host that generates them nor are they replaced. They are unique, > but stability extended through the certificates, allowing for nice short > known_hosts files > -As a result, the "ssh zone" design where nodes are strictly grouped is > replaced with a scheme that allows asymmetric relationships (e.g. the > "compute" group may let the "storage" group access, but the converse is > blocked). Also, this relationship is easier to change after the fact, > without the excluded hosts ever seeing a private credential that would > persist. > > -Different approach to "service nodes". > -Instead of relying upon the multi-host access of an external SQL server, > confluent internalizes the data store and has integrated replication across > collective members > -Collective members may all be equal, or some may be 'non-voting' to have > a quorum from a subset of systems > -Inherently HA for up to n/2-1 failure of voting collective members. > -Clear delineation where /var/lib/confluent is expected to be identical > across
Re: [xcat-user] [External] Announcement: xCAT Project End-Of-Life planned for December 1, 2023
In light of this announcement, I'll take a moment to at least mention Lenovo's strategy here, for those that are not yet aware. I had refrained from posting too much on xcat-user about it because I didn't want to intrude too much on xCAT users' mailboxes, but it seems potentially important. Back in 2014, my team started work on confluent (https://github.com/xcat2/confluent). We promptly found out that we'd be going over to Lenovo, which admittedly complicated our relationship to the larger xCAT project. The general idea was "spiritual successor to xCAT 2". So why not "xCAT 3"? To have the freedom to reimagine some things in a not quite compatible way, and not be too pushy about this "new xCAT" being the way forward for those that didn't like it. In part thinking of the transition between Gnome 2 and Gnome 3 that was just dramatically different vision, which I thought warranted a new name, for better or worse, so my stance was similar about "xCAT 2" to "confluent". When going from xCAT 1 to xCAT 2, we didn't quite match up either, more migration tools were available for CSM users than xCAT 1 users. However a lot of the design sensibilities were similar. The filesystem layout of an OS image was similar, the SQL databases resembled xCAT tab files, etc. Gaps in this strategy were handled with things like the osimage table (to gather OS profile information into... fewer places, not one place) and the objdef layer to bring node attributes together and os image attributes together. With confluent, we wanted to change some things up: -While we liked the 'category.attribute' scheme of tabular structure, the organization of objdef seemed to be more friendly. So confluent node attributes are key value like objdef, but with a naming scheme of 'category.attribute'. -OS images assembled from various places in the filesystem, with only the OS image tables to guide where on disk things were was always a struggle, so confluent has OS profiles be entirely described as one or two directiories (/var/lib/confluent/public/os/ and sometimes /var/lib/confluent/private/os/). Customization can be done with no worry about rpm updates trouncing customization, and the entire structure of the OS profile is more self explanatory. -Most of the deployment logic moved "target side", where the API provides the same data in the same format to any deploying OS, and code in the respective OS deployment is responsible for integrating the information into the right tools/format (debian-installer, kickstart, autoyast, subiquity, netplan, wicked, networkmanager, etc). Compared to xCAT where we would do a form fill sort of thing on kickstart and similar. -More hardened approach to security: -Confluent does not run as root -tftp is now optional (firmware permitting) -Secureboot is now supported -Diskless and cloning images are, by default, encrypted -Diskless nodes, by default, use the TPM to persist trust for the confluent API -TLS is very carefully set up with validation (deployment is done over https as well as all node API calls) -A simplified, singular step serves as the path to getting a node API token, instead of the xCAT myriad of moderately open functions -No private user or host SSH keys are transfered. User keys are replaced with host based authentication, known_hosts helping is handled through providng SSH certificates to the host generated keys. Host keys never leave the host that generates them nor are they replaced. They are unique, but stability extended through the certificates, allowing for nice short known_hosts files -As a result, the "ssh zone" design where nodes are strictly grouped is replaced with a scheme that allows asymmetric relationships (e.g. the "compute" group may let the "storage" group access, but the converse is blocked). Also, this relationship is easier to change after the fact, without the excluded hosts ever seeing a private credential that would persist. -Different approach to "service nodes". -Instead of relying upon the multi-host access of an external SQL server, confluent internalizes the data store and has integrated replication across collective members -Collective members may all be equal, or some may be 'non-voting' to have a quorum from a subset of systems -Inherently HA for up to n/2-1 failure of voting collective members. -Clear delineation where /var/lib/confluent is expected to be identical across all systems (no awkwardness of /tftpboot contents to manage, no weird disconnect of /install/autoinst versus everything else) -Enhancements to diskless -By default, diskless images are tethered in a multipath way to the servers they boot from. This means memory usage is much lower than xCAT diskless, with no penalty for large images -As a result, a diskless image does not look as "weird" compared to a normal disk system. In some scenarios,
Re: [xcat-user] Announcement: xCAT Project End-Of-Life planned for December 1, 2023
On Fri, Sep 01, 2023 at 04:49:46PM +, Nathan A Besaw via xCAT-user wrote: > 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. Can you describe what you'd like to see in such a proposal in order for you to consider it viable? Thanks, khm ___ xCAT-user mailing list xCAT-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcat-user
Re: [xcat-user] Announcement: xCAT Project End-Of-Life planned for December 1, 2023
Really sad news. Sent from my iPhone On 1 Sep 2023, at 13:52, 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 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
Re: [xcat-user] Announcement: xCAT Project End-Of-Life planned for December 1, 2023
Wow !! its really said to read that friends . Wish you all the best . From: Nathan A Besaw via xCAT-user Sent: Friday, 1 September 2023 19:50 To: xCAT Users Mailing list Cc: Nathan A Besaw Subject: [xcat-user] Announcement: xCAT Project End-Of-Life planned for December 1, 2023 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. זהירות: מקור הדואל הזה הוא מחוץ למטריקס. חל איסור ללחוץ על קישורים או לפתוח קבצים מצורפים אלא אם כן השולח מוכר והתוכן בטוח Caution: The source of this email is from outside Matrix. it is forbidden to click on links or open attachments unless you recognize the sender and know the content is safe. ___ xCAT-user mailing list xCAT-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcat-user
[xcat-user] Announcement: xCAT Project End-Of-Life planned for December 1, 2023
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 https://lists.sourceforge.net/lists/listinfo/xcat-user
