Are there any confluent documentation so someone can follow through to get it installed for testing? thanks.
On Mon, May 13, 2024 at 6:58 PM Jarrod Johnson <jjohns...@lenovo.com> wrote: > > > 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 > -- Regards, *Imam Toufique* *213-700-5485*
_______________________________________________ xCAT-user mailing list xCAT-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/xcat-user
