On the confluent document, that collection is it. When it comes to documentation, we are a bit challenged trying to find the right way to glue it all together for a good flow, for arbitrary users. In addition to demos and discussion, I may spend a bit more time on video tutorials at the suggestion of some folks. I could also add some more narrowly scoped documents to cover: -Manually known MAC address or UUID and you want to just deploy an OS, no BMC involvement. Likely to use KVM virtual machine in this example to take all 'hardware' out of the picture. -You have a manually configured BMC and just want the BMC operations handled -You want to use PXE based MAC collection 'discovery' style. -You want to do BMC discovery instead of PXE based -Bringing it all together with scale
We are very happy about discovery, but particularly for folks looking to 'test the waters', it's more convenient to do 'manual' and discovery is something that is optional. Interestingly, there's nothing in common between the documentation development between onecli and confluent. With onecli, they actually do use the services of a technical writing group that specializes in documentation. In confluent, the developers also write most of the documentation, which on the plus side means the document writers understand the functionality, but on the severe minus side have a distinct lack of perspective for what it's like to not already know the functionality inside and out. I personally tend to be a start messing with something instead of trying to read documentation, so my perspective is a bit skewed. We will see about who is game for continuing xCAT 2, or xCAT 3 being a thing, and/or whether this is the impetus for us or someone else to do better documentation on confluent. Ultimately, better documentation may be through some collaboration, with some interactive instruction to someone that would like to write it up and bake it into better organized, connected, and appropriately detailed documentation. We can spend more hours on documentation ourselves, but personally I fear I could spend a month writing and rewriting documentation and still leave people wwonder what in the world I'm trying to say... ________________________________ From: Heckes, Frank <hec...@mps.mpg.de> Sent: Saturday, September 30, 2023 9:22 AM 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 Dear (remaining) List-Members, * First of all many thanks to Mark Gurevich, Peter Wong, Nathan Besaw and all contributors not mentioned explicitly for the xCAT tool and their great work. My questions are: * It’s seems to me that there’s no one (company, consortium, group of sw architects, group of HPC seniors …) who’s seriously able or willing to take over the xCAT project? There’s no schedule for a maintenance or bugfix release, covering new OS distro releases in my case SuSE 15.5 or redhat based distros? * As we and I think many others, have to rollout a new distro by Jan/Feb 2024, there’s only a short time slot before migration of many users to other tool sets have to start (or is it already completed?). * Concerning the Lenovo ‘confluence’ software. Does anyone knows whether the content that could be found here: https://hpc.lenovo.com/users/documentation/ is the complete documentation? Or does other sources exist? I hope I don’t overlooked something, but is there a documentation which maybe conceptually ‘glues’ these pages together? The documentation is written in the same style as for example the Lenovo oneCli user guide. Many thanks in advance for any hint. Cheers, -Frank From: Imam Toufique <techie...@gmail.com> Sent: Friday, 29 September 2023 22:07 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 Unrelated, but it’s a request. Would it be possible to get quick demo on confluent? I have been thinking about doing a test setup, but with a quick demo , I think we can benefit ( at least I can, ??) from it. Thanks for your continued help and support. On Fri, Sep 29, 2023 at 12:46 PM Jarrod Johnson <jjohns...@lenovo.com<mailto:jjohns...@lenovo.com>> wrote: How about 4011/udp? Note that I wouldn't think it would get to the ipxe boot, but 4011/udp I would expect to be used. ________________________________ From: Brian Joiner <martinitime1...@gmail.com<mailto:martinitime1...@gmail.com>> Sent: Friday, September 29, 2023 3:40 PM 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 I can get Confluent to deploy a node with the firewall off, but not on. Does anyone know the rule that should let this through? I have enabled all the relevant services in firewalld (with iptables backend) sshd, tftp, https, dhcp, etc. I even opened ports 69, but no joy. public (active) target: default icmp-block-inversion: no interfaces: ens192 ens224 sources: services: cockpit dhcp dhcpv6-client https ssh tftp ports: 427/udp 1900/udp 69/tcp 69/udp 4011/tcp protocols: forward: yes masquerade: no forward-ports: source-ports: icmp-blocks: rich rules: Success logs: Sep 29 14:11:05 confluent01 systemd[1]: Stopping firewalld - dynamic firewall daemon... Sep 29 14:11:06 confluent01 systemd[1]: firewalld.service: Deactivated successfully. Sep 29 14:11:06 confluent01 systemd[1]: Stopped firewalld - dynamic firewall daemon. Sep 29 14:11:06 confluent01 systemd[1]: firewalld.service: Consumed 12.819s CPU time. Sep 29 14:11:17 confluent01 dhcpd[4966]: DHCPDISCOVER from 00:0c:29:7f:c8:10 via ens224 Sep 29 14:11:18 confluent01 dhcpd[4966]: DHCPOFFER on 10.13.13.103 to 00:0c:29:7f:c8:10 via ens224 Sep 29 14:11:19 confluent01 dhcpd[4966]: DHCPREQUEST for 10.13.13.11 (10.13.13.5) from 00:0c:29:7f:c8:10 via ens224: unknown lease 10.13.13.11. Sep 29 14:11:20 confluent01 in.tftpd[13121]: tftp: client does not accept options Sep 29 14:11:20 confluent01 in.tftpd[13122]: Client ::ffff:10.13.13.11 finished confluent/x86_64/ipxe.kkpxe Sep 29 14:11:22 confluent01 dhcpd[4966]: DHCPDISCOVER from 00:0c:29:7f:c8:10 via ens224 Sep 29 14:11:22 confluent01 dhcpd[4966]: DHCPREQUEST for 10.13.13.11 (10.13.13.5) from 00:0c:29:7f:c8:10 via ens224: unknown lease 10.13.13.11. Sep 29 14:11:23 confluent01 dhcpd[4966]: DHCPOFFER on 10.13.13.104 to 00:0c:29:7f:c8:10 via ens224 Failed attempt: no in.tftpd Sep 29 14:23:00 confluent01 dhcpd[4966]: DHCPDISCOVER from 00:0c:29:7f:c8:10 via ens224 Sep 29 14:23:01 confluent01 dhcpd[4966]: DHCPOFFER on 10.13.13.103 to 00:0c:29:7f:c8:10 via ens224 Sep 29 14:23:02 confluent01 dhcpd[4966]: DHCPREQUEST for 10.13.13.11 (10.13.13.5) from 00:0c:29:7f:c8:10 via ens224: unknown lease 10.13.13.11. Sep 29 14:23:07 confluent01 dhcpd[4966]: DHCPRELEASE of 10.13.13.11 from 00:0c:29:7f:c8:10 via ens224 (not found) Sep 29 14:23:07 confluent01 dhcpd[4966]: DHCPDISCOVER from 00:0c:29:7f:c8:10 via ens224 Sep 29 14:23:07 confluent01 dhcpd[4966]: DHCPOFFER on 10.13.13.103 to 00:0c:29:7f:c8:10 via ens224 Sep 29 14:23:11 confluent01 dhcpd[4966]: DHCPREQUEST for 10.13.13.11 (10.13.13.5) from 00:0c:29:7f:c8:10 via ens224: unknown lease 10.13.13.11. Sep 29 14:23:19 confluent01 dhcpd[4966]: DHCPRELEASE of 10.13.13.11 from 00:0c:29:7f:c8:10 via ens224 (not found) Sep 29 14:23:19 confluent01 dhcpd[4966]: DHCPDISCOVER from 00:0c:29:7f:c8:10 via ens224 Sep 29 14:23:19 confluent01 dhcpd[4966]: DHCPOFFER on 10.13.13.103 to 00:0c:29:7f:c8:10 via ens224 Sep 29 14:23:27 confluent01 dhcpd[4966]: DHCPREQUEST for 10.13.13.11 (10.13.13.5) from 00:0c:29:7f:c8:10 via ens224: unknown lease 10.13.13.11. Sep 29 14:23:43 confluent01 dhcpd[4966]: DHCPRELEASE of 10.13.13.11 from 00:0c:29:7f:c8:10 via ens224 (not found) Sep 29 14:23:43 confluent01 dhcpd[4966]: DHCPDISCOVER from 00:0c:29:7f:c8:10 via ens224 Sep 29 14:23:43 confluent01 dhcpd[4966]: DHCPOFFER on 10.13.13.103 to 00:0c:29:7f:c8:10 via ens224 Other than this firewall rule, the setup was fairly easy. The next step will be the replacement method for postscripts. Thanks, Brian J On 9/21/23 8:57 AM, Brian Joiner wrote: 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
