> Confluent and xCAT have diverged to a point they're now *very* different tools
This is true, and one reason why I was relieved we wouldn't try to call such an effort 'xCAT 3'. On the other hand, they are very similar in a lot of respects. My original goal back in 2013 with confluent was 'maybe replace xcatd one day'. I was hoping that the things that do change might be slightly annoying as a learning curve and migration, but ultimately at least as convenient if not easier to learn/understand/debug for those coming in cold. Particularly the OS image stuff both represents a pain for migration, but also something that for people coming in cold is a bit easier to follow/tweak/maintain. However, I would want to preserve and enhance coexistence, even on the same management server. If ultimately the community gravitates toward xCAT 2 codebase, then that's fine, it's just not a direction I'm able to personally facilitate. > Nor that moving existing xCAT users and installations to a new system down > the line will be a very easy transition path. Early days for me to venture much of an actionable opinion, but my guess is that we will have the current 'xcatd' as a package for people to install, largely to facilitate supporting existing OS profiles, particularly xCAT dialect of diskless. xCAT OS images would manifest as stub profiles in 'native confluent' and serviced largely by existing xCATd. I think 99% of the transition path for users will be the OS images, and I'm hoping that for the scope of currently supported major versions of OSes, this will work. Would have to go to a 'confluent' style when RHEL10 and clones come out, or other OS platforms that xCAT didn't support, but hoping that the learning curve and effort isn't too bad against the broader backdrop of migrating such an image to a major distribution release. confluent handling of DHCP feature with either some accommodations for xCAT use of DHCP or injecting some of the confluent logic into runtime of xCAT images. Note this coexistence applies to other OS deployment options, so we have to be careful not to step on toes that xCAT traditionally has been willing to step on. I suppose I should also confess that the out of the box confluent SSH strategy is a bit different, though I think 'adding on' xCAT style approach is easy to provide, though it may not be a very discouraged option versus adding confluent style SSH configuration to xCAT managed OSes (some security sensibilities are very opposed to the xCAT strategy) > trying to fix the existing xCAT issues and supporting newer distributions > over time. At least for me, this is a bit tricky. xCAT is a bit of a peculiar codebase (in large part my fault, I'm sure a lot of xCAT developers have cursed my name) and even trying to follow some of the code I myself wrote some time ago has been a challenge at times. Beyond that, the population of people comfortable dealing in perl is a tad more limited so this can be a challenge. I may be incorrect, but my feeling is that the manpower possibly available is more limited when it comes to the xCAT 2 codebase (e.g. I know at least a few people that are unlikely to be of practical help with it but could help with something stemming from the current confluent codebase, myself included). There are some fragile bits that aren't great on their best days that have some even bigger challenges in the wider ecosystem coming. Some of the xCAT issues are pretty core and I struggle to imagine how to improve them within reason. Some have mitigations that aimed to alleviate the problems best we could figure out at the time, and I at least haven't had bright ideas on clean approaches, though I'll admit to not having considered it other than trying to avoid them in confluent. > Adding I'm a bit concerned that adding configuration management tooling into > the mix I would like some clarification on that. We do have hooks to allow, for example, ansible, but confluent doesn't require or currently ship any ansible dependent options as of yet, and I'm also uncomfortable with mandating any particular configuration management in the core functionality even as we do better job supporting chosen configuration management tooling. I do want to support people to the extent they desire things like ansible and salt, but I don't want to be opinionated and demand any of them either. Currently the OS management capability mimics xCAT scope pretty closely, getting networking, basic node configuration, and ssh going, with exceptionally light 'post-deploy' capabilities, largely about fixing up those same basic features. In short, my hope is that we can provide something that minimizes the admitted pain of migration while catering to a lot of the use cases that people care about (and will be interested to see where people feel those gaps are today). Anyway, hope this was useful, sorry if I rambled on a bit. ________________________________ From: Kilian Cavalotti <kilian.cavalotti.w...@gmail.com> Sent: Monday, May 13, 2024 4:37 PM To: xCAT Users Mailing list <xcat-user@lists.sourceforge.net> Subject: [External] Re: [xcat-user] xCAT Consortium update On Fri, May 10, 2024 at 11:52 AM Laurence Horrocks-Barlow via xCAT-user <xcat-user@lists.sourceforge.net> wrote: > The future > The consortium is finalising: > - Its decision to rebase Confluent as it’s start for the next cluster > management and administration tooling. > - What features to port over from xCAT? > - Which configuration management tooling should be included as a base? > - Any Confluent rebase will likely be renamed to respect existing product > name and intellectual properties. (Yes we’re looking for names!) I know that ship has probably sailed already, and I don't want to challenge or question things that have already been decided, but Confluent and xCAT have diverged to a point they're now *very* different tools. I'm not sure that bringing features over from xCAT to Confluent will be less work or be more achievable with a limited team of volunteers than trying to fix the existing xCAT issues and supporting newer distributions over time. Nor that moving existing xCAT users and installations to a new system down the line will be a very easy transition path. Adding I'm a bit concerned that adding configuration management tooling into the mix and renaming it all doesn't really look like it's going in the direction of a xCAT project continuation, I'm afraid. :\ Cheers, -- Kilian _______________________________________________ xCAT-user mailing list xCAT-user@lists.sourceforge.net https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Flists.sourceforge.net%2Flists%2Flistinfo%2Fxcat-user&data=05%7C02%7Cjjohnson2%40lenovo.com%7Cf925cd1a48a243e1dbc908dc738cb044%7C5c7d0b28bdf8410caa934df372b16203%7C0%7C0%7C638512295321123041%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C0%7C%7C%7C&sdata=QgdDAk%2FvVZP1KcNaRgAUG70rkpH7v9WS%2BmQvTJQZzSI%3D&reserved=0<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
