Menu
▾
▴
xcat-user
|
From: Laurence Horrocks-B. <lho...@oc...> - 2024-05-10 18:51:00
|
Dear xCAT community,
First, we'd like to first start out with an apology, since the consortium's announcement in November, IBM's EoL extension and some smaller communications we haven't updated the mailing list. This is mostly due to the consortium finding it's feet with the project and transitioning the assets; for this we would like to thank IBM and Lenovo for their valued input and support.
To this effect we'd like this mail to serve as an update of where we are and invite the community to ask us questions.
What is the consortium about?
In September 2023 IBM announced it's End of Life plan for xCAT; this spur 'ed conversation within the community and lead to 3 independent companies Megware, OCF and Redline discussing the possibility of combining development resources to continue on the project; as each of the companies had committed to the xCAT project and each also had a vested interest in it's continuation. This led to the proposal of approaching IBM to discuss a formation of a consortium to take ownership of the xCAT project whilst also acknowledging that the consortium wanted to focus on the future for cluster management and administration tooling; this also led to further approaching Lenovo to discuss their willingness to contribute confluent to this cause. Both IBM and Lenovo have been fantastic in supporting the consortium and its goals.
What are the consortium's goals?
We have 3 main goals,
- Provide extended maintenance, development, and support for xCAT 2
- There are no plans to add "new" features the focus is around bug fixing and stability
- There are no plans to support any operating systems past those that are already supported, i.e. no EL10, no SLES16
- Create the next version cluster management and administration tooling
- We acknowledge both IBM xCAT and Lenovo Confluent being excellent cluster management tooling in their own rights with hours of committed development being applied to both; the consortium is aiming to take the best features from both projects to develop the next community driven tooling
- Some details of "where to start" is still being figured out
- Everything has to be free, open and vendor agnostic
What's been going on?
It's been a busy time for the consortium members, Megware, OCF, Redline and our supporting partners IBM and Lenovo; we've been meeting weekly to discuss:
Logistical/Commercial
Agree any transitions and how they will happen.
Contact other stakeholders and asset owners to seek agreement.
Discuss within all commercial entities of the consortium.
Create a new workspace for all members to collaborate in whilst providing everyone equal access to assets.
Finalising a memorandum of understanding between the consortium members to outline responsibilities and mutual goals.
Technical
Receive training on the current xCAT development and maintenance.
Implement testing services and CI pipelines.
Implement a new contribution license agreement system.
Update assets reflecting the new consortium.
Updating xCAT nightly build to include latest fixes and development - https://xcat.org/files/xcat/xcat-core/devel/Linux/core-snap/core-rpms-snap.tar.bz2
Target Summer 2024 for xCAT 2.17 (milestone 53) to include Better EL 9 supports, Support for more secure IPMI ciphers, Initial ARM support
The future
The consortium is finalising:
- Its decision to rebase Confluent as it's start for the next cluster management and administration tooling.
- The language to continue using?
- This will almost certainly be python.
- 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!)
How can you help?
We are looking for community input:
- What are your priorities? What features are you looking for?
- Can you help us bug fix? Document? Create features?
- Do you think we're doing the right thing? What would you do differently?
Let us know on the mailing list, or alternatively 2 of the consortium members are at ISC next week so why not come and talk to us in person?
ISC, Congress Center Hamburg from June 10-13, 2025.
Megware - B30
OCF - G50
Laurence Horrocks-Barlow | Technical Director
[https://ocf.co.uk/media/0i1lzfjz/ocf-logo-strapline-2022-blk.png]<https://www.ocf.co.uk/>
Phone:
0114 257 2200
Address:
OCF Limited, Unit 5 Rotunda Business Centre, Thorncliffe Park, Chapeltown, Sheffield S35 2PG
Website:
www.ocf.co.uk<http://www.ocf.co.uk/>
[LinkedIn icon]<https://www.linkedin.com/company/ocf-limited/> [Twitter icon] <https://twitter.com/ocf_hpc?lang=en>
[https://ocf.co.uk/media/imkoyi2j/line.jpg]
OCF Limited is a company registered in England and Wales. Registered number 4132533, VAT number GB 780 6803 14. Registered office address: OCF Limited, 5 Rotunda Business Centre, Thorncliffe Park, Chapeltown, Sheffield, S35 2PG.
This message is private and confidential. If you have received this message in error, please notify us immediately and remove it from your system.
-------------
Scheduled Annual Leave:
Click to see my full annual leave calendar<https://calendar.google.com/calendar/u/0/embed?src=j5g...@im...&ctz=Europe/London>
"It is well known that a vital ingredient of success is not knowing that what you're attempting can't be done."
-- Sir Terry Pratchett
|
|
From: Laurence Horrocks-B. <lho...@oc...> - 2024-05-10 18:53:30
|
Dear xCAT community,
First, we'd like to first start out with an apology, since the consortium's announcement in November, IBM's EoL extension and some smaller communications we haven't updated the mailing list. This is mostly due to the consortium finding it's feet with the project and transitioning the assets; for this we would like to thank IBM and Lenovo for their valued input and support.
To this effect we'd like this mail to serve as an update of where we are and invite the community to ask us questions.
What is the consortium about?
In September 2023 IBM announced it's End of Life plan for xCAT; this spur 'ed conversation within the community and lead to 3 independent companies Megware, OCF and Redline discussing the possibility of combining development resources to continue on the project; as each of the companies had committed to the xCAT project and each also had a vested interest in its continuation. This led to the proposal of approaching IBM to discuss a formation of a consortium to take ownership of the xCAT project whilst also acknowledging that the consortium wanted to focus on the future for cluster management and administration tooling; this also led to further approaching Lenovo to discuss their willingness to contribute confluent to this cause. Both IBM and Lenovo have been fantastic in supporting the consortium and its goals.
What are the consortium's goals?
We have 3 main goals,
- Provide extended maintenance, development, and support for xCAT 2
- There are no plans to add "new" features the focus is around bug fixing and stability
- There are no plans to support any operating systems past those that are already supported, i.e. no EL10, no SLES16
- Create the next version cluster management and administration tooling
- We acknowledge both IBM xCAT and Lenovo Confluent being excellent cluster management tooling in their own rights with hours of committed development being applied to both; the consortium is aiming to take the best features from both projects to develop the next community driven tooling
- Some details of "where to start" is still being figured out
- Everything has to be free, open and vendor agnostic
What's been going on?
It's been a busy time for the consortium members, Megware, OCF, Redline and our supporting partners IBM and Lenovo; we've been meeting weekly to discuss:
Logistical/Commercial
Agree any transitions and how they will happen.
Contact other stakeholders and asset owners to seek agreement.
Discuss within all commercial entities of the consortium.
Create a new workspace for all members to collaborate in whilst providing everyone equal access to assets.
Finalising a memorandum of understanding between the consortium members to outline responsibilities and mutual goals.
Technical
Receive training on the current xCAT development and maintenance.
Implement testing services and CI pipelines.
Implement a new contribution license agreement system.
Update assets reflecting the new consortium.
Updating xCAT nightly build to include latest fixes and development - https://xcat.org/files/xcat/xcat-core/devel/Linux/core-snap/core-rpms-snap.tar.bz2
Target Summer 2024 for xCAT 2.17 (milestone 53) to include Better EL 9 supports, Support for more secure IPMI ciphers, Initial ARM support.
The future
The consortium is finalising:
- Its decision to rebase Confluent as it's start for the next cluster management and administration tooling.
- The language to continue using?
- This will almost certainly be python.
- 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!)
How can you help?
We are looking for community input:
- What are your priorities? What features are you looking for?
- Can you help us bug fix? Document? Create features?
- Do you think we're doing the right thing? What would you do differently?
Let us know on the mailing list, or alternatively 2 of the consortium members are at ISC next week so why not come and talk to us in person?
ISC, Congress Center Hamburg from June 10-13, 2025.
Megware - B30
OCF - G50
Laurence Horrocks-Barlow | Technical Director
[https://ocf.co.uk/media/0i1lzfjz/ocf-logo-strapline-2022-blk.png]<https://www.ocf.co.uk/>
Phone:
0114 257 2200
Address:
OCF Limited, Unit 5 Rotunda Business Centre, Thorncliffe Park, Chapeltown, Sheffield S35 2PG
Website:
www.ocf.co.uk<http://www.ocf.co.uk/>
[LinkedIn icon]<https://www.linkedin.com/company/ocf-limited/> [Twitter icon] <https://twitter.com/ocf_hpc?lang=en>
[https://ocf.co.uk/media/imkoyi2j/line.jpg]
OCF Limited is a company registered in England and Wales. Registered number 4132533, VAT number GB 780 6803 14. Registered office address: OCF Limited, 5 Rotunda Business Centre, Thorncliffe Park, Chapeltown, Sheffield, S35 2PG.
This message is private and confidential. If you have received this message in error, please notify us immediately and remove it from your system.
-------------
Scheduled Annual Leave:
Click to see my full annual leave calendar<https://calendar.google.com/calendar/u/0/embed?src=j5g...@im...&ctz=Europe/London>
"It is well known that a vital ingredient of success is not knowing that what you're attempting can't be done."
-- Sir Terry Pratchett
|
|
From: Noah, S. <Stu...@cs...> - 2024-10-21 21:26:50
|
You could always name the new product, “Schrödinger.”
…neither x-cat or cat
😊
From: Laurence Horrocks-Barlow via xCAT-user <xca...@li...>
Sent: Friday, May 10, 2024 11:38 AM
To: xca...@li...
Cc: Laurence Horrocks-Barlow <lho...@oc...>
Subject: [External] [xcat-user] xCAT Consortium update
Dear xCAT community, First, we’d like to first start out with an apology, since the consortium’s announcement in November, IBM’s EoL extension and some smaller communications we haven’t updated the mailing list. This
Dear xCAT community,
First, we’d like to first start out with an apology, since the consortium’s announcement in November, IBM’s EoL extension and some smaller communications we haven’t updated the mailing list. This is mostly due to the consortium finding it’s feet with the project and transitioning the assets; for this we would like to thank IBM and Lenovo for their valued input and support.
To this effect we’d like this mail to serve as an update of where we are and invite the community to ask us questions.
What is the consortium about?
In September 2023 IBM announced it’s End of Life plan for xCAT; this spur ’ed conversation within the community and lead to 3 independent companies Megware, OCF and Redline discussing the possibility of combining development resources to continue on the project; as each of the companies had committed to the xCAT project and each also had a vested interest in its continuation. This led to the proposal of approaching IBM to discuss a formation of a consortium to take ownership of the xCAT project whilst also acknowledging that the consortium wanted to focus on the future for cluster management and administration tooling; this also led to further approaching Lenovo to discuss their willingness to contribute confluent to this cause. Both IBM and Lenovo have been fantastic in supporting the consortium and its goals.
What are the consortium’s goals?
We have 3 main goals,
- Provide extended maintenance, development, and support for xCAT 2
- There are no plans to add “new” features the focus is around bug fixing and stability
- There are no plans to support any operating systems past those that are already supported, i.e. no EL10, no SLES16
- Create the next version cluster management and administration tooling
- We acknowledge both IBM xCAT and Lenovo Confluent being excellent cluster management tooling in their own rights with hours of committed development being applied to both; the consortium is aiming to take the best features from both projects to develop the next community driven tooling
- Some details of “where to start” is still being figured out
- Everything has to be free, open and vendor agnostic
What’s been going on?
It’s been a busy time for the consortium members, Megware, OCF, Redline and our supporting partners IBM and Lenovo; we’ve been meeting weekly to discuss:
Logistical/Commercial
Agree any transitions and how they will happen.
Contact other stakeholders and asset owners to seek agreement.
Discuss within all commercial entities of the consortium.
Create a new workspace for all members to collaborate in whilst providing everyone equal access to assets.
Finalising a memorandum of understanding between the consortium members to outline responsibilities and mutual goals.
Technical
Receive training on the current xCAT development and maintenance.
Implement testing services and CI pipelines.
Implement a new contribution license agreement system.
Update assets reflecting the new consortium.
Updating xCAT nightly build to include latest fixes and development - https://xcat.org/files/xcat/xcat-core/devel/Linux/core-snap/core-rpms-snap.tar.bz2<https://urldefense.com/v3/__https:/xcat.org/files/xcat/xcat-core/devel/Linux/core-snap/core-rpms-snap.tar.bz2__;!!KOmnBZxC8_2BBQ!xoSBQ30C9KaE-v7MHNhN6_Ex_4vCMA1r9Lml7tsRNAimWTtDEGP4anvM1OE89L764RhIuX2jd4__85McEK9wp4RRdazHaA$>
Target Summer 2024 for xCAT 2.17 (milestone 53) to include Better EL 9 supports, Support for more secure IPMI ciphers, Initial ARM support.
The future
The consortium is finalising:
- Its decision to rebase Confluent as it’s start for the next cluster management and administration tooling.
- The language to continue using?
- This will almost certainly be python.
- 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!)
How can you help?
We are looking for community input:
- What are your priorities? What features are you looking for?
- Can you help us bug fix? Document? Create features?
- Do you think we’re doing the right thing? What would you do differently?
Let us know on the mailing list, or alternatively 2 of the consortium members are at ISC next week so why not come and talk to us in person?
ISC, Congress Center Hamburg from June 10-13, 2025.
Megware – B30
OCF – G50
Laurence Horrocks-Barlow | Technical Director
[https://ocf.co.uk/media/0i1lzfjz/ocf-logo-strapline-2022-blk.png]<https://urldefense.com/v3/__https:/www.ocf.co.uk/__;!!KOmnBZxC8_2BBQ!xoSBQ30C9KaE-v7MHNhN6_Ex_4vCMA1r9Lml7tsRNAimWTtDEGP4anvM1OE89L764RhIuX2jd4__85McEK9wp4QxS6Bm7g$>
Phone:
0114 257 2200
Address:
OCF Limited, Unit 5 Rotunda Business Centre, Thorncliffe Park, Chapeltown, Sheffield S35 2PG
Website:
www.ocf.co.uk<https://urldefense.com/v3/__http:/www.ocf.co.uk/__;!!KOmnBZxC8_2BBQ!xoSBQ30C9KaE-v7MHNhN6_Ex_4vCMA1r9Lml7tsRNAimWTtDEGP4anvM1OE89L764RhIuX2jd4__85McEK9wp4TZ35eqkw$>
[LinkedIn icon]<https://urldefense.com/v3/__https:/www.linkedin.com/company/ocf-limited/__;!!KOmnBZxC8_2BBQ!xoSBQ30C9KaE-v7MHNhN6_Ex_4vCMA1r9Lml7tsRNAimWTtDEGP4anvM1OE89L764RhIuX2jd4__85McEK9wp4Q0n7tZsg$> [Twitter icon] <https://urldefense.com/v3/__https:/twitter.com/ocf_hpc?lang=en__;!!KOmnBZxC8_2BBQ!xoSBQ30C9KaE-v7MHNhN6_Ex_4vCMA1r9Lml7tsRNAimWTtDEGP4anvM1OE89L764RhIuX2jd4__85McEK9wp4SINRAxDQ$>
[https://ocf.co.uk/media/imkoyi2j/line.jpg]
OCF Limited is a company registered in England and Wales. Registered number 4132533, VAT number GB 780 6803 14. Registered office address: OCF Limited, 5 Rotunda Business Centre, Thorncliffe Park, Chapeltown, Sheffield, S35 2PG.
This message is private and confidential. If you have received this message in error, please notify us immediately and remove it from your system.
-------------
Scheduled Annual Leave:
Click to see my full annual leave calendar<https://urldefense.com/v3/__https:/calendar.google.com/calendar/u/0/embed?src=j5g...@im...&ctz=Europe*London__;Lw!!KOmnBZxC8_2BBQ!xoSBQ30C9KaE-v7MHNhN6_Ex_4vCMA1r9Lml7tsRNAimWTtDEGP4anvM1OE89L764RhIuX2jd4__85McEK9wp4R6wJqhDg$>
"It is well known that a vital ingredient of success is not knowing that what you're attempting can't be done."
-- Sir Terry Pratchett
IMPORTANT WARNING: This message is intended for the use of the person or entity to which it is addressed and may contain information that is privileged and confidential, the disclosure of which is governed by applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this information is strictly prohibited. Thank you for your cooperation.
|
|
From: Jarrod J. <jjo...@le...> - 2024-10-21 21:29:43
|
I always love an excuse to throw some unicode at folks...
________________________________
From: Noah, Stuart via xCAT-user <xca...@li...>
Sent: Monday, October 21, 2024 5:26 PM
To: xCAT Users Mailing list <xca...@li...>
Cc: Noah, Stuart <Stu...@cs...>
Subject: [External] Re: [xcat-user] xCAT Consortium update
You could always name the new product, “Schrödinger.”
…neither x-cat or cat
😊
From: Laurence Horrocks-Barlow via xCAT-user <xca...@li...>
Sent: Friday, May 10, 2024 11:38 AM
To: xca...@li...
Cc: Laurence Horrocks-Barlow <lho...@oc...>
Subject: [External] [xcat-user] xCAT Consortium update
Dear xCAT community, First, we’d like to first start out with an apology, since the consortium’s announcement in November, IBM’s EoL extension and some smaller communications we haven’t updated the mailing list. This
Dear xCAT community,
First, we’d like to first start out with an apology, since the consortium’s announcement in November, IBM’s EoL extension and some smaller communications we haven’t updated the mailing list. This is mostly due to the consortium finding it’s feet with the project and transitioning the assets; for this we would like to thank IBM and Lenovo for their valued input and support.
To this effect we’d like this mail to serve as an update of where we are and invite the community to ask us questions.
What is the consortium about?
In September 2023 IBM announced it’s End of Life plan for xCAT; this spur ’ed conversation within the community and lead to 3 independent companies Megware, OCF and Redline discussing the possibility of combining development resources to continue on the project; as each of the companies had committed to the xCAT project and each also had a vested interest in its continuation. This led to the proposal of approaching IBM to discuss a formation of a consortium to take ownership of the xCAT project whilst also acknowledging that the consortium wanted to focus on the future for cluster management and administration tooling; this also led to further approaching Lenovo to discuss their willingness to contribute confluent to this cause. Both IBM and Lenovo have been fantastic in supporting the consortium and its goals.
What are the consortium’s goals?
We have 3 main goals,
- Provide extended maintenance, development, and support for xCAT 2
- There are no plans to add “new” features the focus is around bug fixing and stability
- There are no plans to support any operating systems past those that are already supported, i.e. no EL10, no SLES16
- Create the next version cluster management and administration tooling
- We acknowledge both IBM xCAT and Lenovo Confluent being excellent cluster management tooling in their own rights with hours of committed development being applied to both; the consortium is aiming to take the best features from both projects to develop the next community driven tooling
- Some details of “where to start” is still being figured out
- Everything has to be free, open and vendor agnostic
What’s been going on?
It’s been a busy time for the consortium members, Megware, OCF, Redline and our supporting partners IBM and Lenovo; we’ve been meeting weekly to discuss:
Logistical/Commercial
Agree any transitions and how they will happen.
Contact other stakeholders and asset owners to seek agreement.
Discuss within all commercial entities of the consortium.
Create a new workspace for all members to collaborate in whilst providing everyone equal access to assets.
Finalising a memorandum of understanding between the consortium members to outline responsibilities and mutual goals.
Technical
Receive training on the current xCAT development and maintenance.
Implement testing services and CI pipelines.
Implement a new contribution license agreement system.
Update assets reflecting the new consortium.
Updating xCAT nightly build to include latest fixes and development - https://xcat.org/files/xcat/xcat-core/devel/Linux/core-snap/core-rpms-snap.tar.bz2<https://urldefense.com/v3/__https:/xcat.org/files/xcat/xcat-core/devel/Linux/core-snap/core-rpms-snap.tar.bz2__;!!KOmnBZxC8_2BBQ!xoSBQ30C9KaE-v7MHNhN6_Ex_4vCMA1r9Lml7tsRNAimWTtDEGP4anvM1OE89L764RhIuX2jd4__85McEK9wp4RRdazHaA$>
Target Summer 2024 for xCAT 2.17 (milestone 53) to include Better EL 9 supports, Support for more secure IPMI ciphers, Initial ARM support.
The future
The consortium is finalising:
- Its decision to rebase Confluent as it’s start for the next cluster management and administration tooling.
- The language to continue using?
- This will almost certainly be python.
- 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!)
How can you help?
We are looking for community input:
- What are your priorities? What features are you looking for?
- Can you help us bug fix? Document? Create features?
- Do you think we’re doing the right thing? What would you do differently?
Let us know on the mailing list, or alternatively 2 of the consortium members are at ISC next week so why not come and talk to us in person?
ISC, Congress Center Hamburg from June 10-13, 2025.
Megware – B30
OCF – G50
Laurence Horrocks-Barlow | Technical Director
[https://ocf.co.uk/media/0i1lzfjz/ocf-logo-strapline-2022-blk.png]<https://urldefense.com/v3/__https:/www.ocf.co.uk/__;!!KOmnBZxC8_2BBQ!xoSBQ30C9KaE-v7MHNhN6_Ex_4vCMA1r9Lml7tsRNAimWTtDEGP4anvM1OE89L764RhIuX2jd4__85McEK9wp4QxS6Bm7g$>
Phone:
0114 257 2200
Address:
OCF Limited, Unit 5 Rotunda Business Centre, Thorncliffe Park, Chapeltown, Sheffield S35 2PG
Website:
www.ocf.co.uk<https://urldefense.com/v3/__http:/www.ocf.co.uk/__;!!KOmnBZxC8_2BBQ!xoSBQ30C9KaE-v7MHNhN6_Ex_4vCMA1r9Lml7tsRNAimWTtDEGP4anvM1OE89L764RhIuX2jd4__85McEK9wp4TZ35eqkw$>
[LinkedIn icon]<https://urldefense.com/v3/__https:/www.linkedin.com/company/ocf-limited/__;!!KOmnBZxC8_2BBQ!xoSBQ30C9KaE-v7MHNhN6_Ex_4vCMA1r9Lml7tsRNAimWTtDEGP4anvM1OE89L764RhIuX2jd4__85McEK9wp4Q0n7tZsg$> [Twitter icon] <https://urldefense.com/v3/__https:/twitter.com/ocf_hpc?lang=en__;!!KOmnBZxC8_2BBQ!xoSBQ30C9KaE-v7MHNhN6_Ex_4vCMA1r9Lml7tsRNAimWTtDEGP4anvM1OE89L764RhIuX2jd4__85McEK9wp4SINRAxDQ$>
[https://ocf.co.uk/media/imkoyi2j/line.jpg]
OCF Limited is a company registered in England and Wales. Registered number 4132533, VAT number GB 780 6803 14. Registered office address: OCF Limited, 5 Rotunda Business Centre, Thorncliffe Park, Chapeltown, Sheffield, S35 2PG.
This message is private and confidential. If you have received this message in error, please notify us immediately and remove it from your system.
-------------
Scheduled Annual Leave:
Click to see my full annual leave calendar<https://urldefense.com/v3/__https:/calendar.google.com/calendar/u/0/embed?src=j5g...@im...&ctz=Europe*London__;Lw!!KOmnBZxC8_2BBQ!xoSBQ30C9KaE-v7MHNhN6_Ex_4vCMA1r9Lml7tsRNAimWTtDEGP4anvM1OE89L764RhIuX2jd4__85McEK9wp4R6wJqhDg$>
"It is well known that a vital ingredient of success is not knowing that what you're attempting can't be done."
-- Sir Terry Pratchett
IMPORTANT WARNING: This message is intended for the use of the person or entity to which it is addressed and may contain information that is privileged and confidential, the disclosure of which is governed by applicable law. If the reader of this message is not the intended recipient, or the employee or agent responsible for delivering it to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this information is strictly prohibited. Thank you for your cooperation.
|
|
From: Jarrod J. <jjo...@le...> - 2024-05-10 22:38:42
|
> - Any Confluent rebase will likely be renamed to respect existing product name and intellectual properties. (Yes we’re looking for names!)
I'll throw into the ring:
Conflux (Confluent^H^H^HxCAT^H^H^H)
If Conflux is not unique enough, then it can have a "long name" of:
Conflux Administration Toolkit (CAT)
Of course, I'm sure IBM would also be cool with "Alternative Implementation of xCAT (AIX)".
________________________________
From: Laurence Horrocks-Barlow via xCAT-user <xca...@li...>
Sent: Friday, May 10, 2024 2:18 PM
To: xca...@li... <xca...@li...>
Cc: Laurence Horrocks-Barlow <lho...@oc...>
Subject: [External] [xcat-user] xCAT Consortium update
Dear xCAT community,
First, we’d like to first start out with an apology, since the consortium’s announcement in November, IBM’s EoL extension and some smaller communications we haven’t updated the mailing list. This is mostly due to the consortium finding it’s feet with the project and transitioning the assets; for this we would like to thank IBM and Lenovo for their valued input and support.
To this effect we’d like this mail to serve as an update of where we are and invite the community to ask us questions.
What is the consortium about?
In September 2023 IBM announced it’s End of Life plan for xCAT; this spur ’ed conversation within the community and lead to 3 independent companies Megware, OCF and Redline discussing the possibility of combining development resources to continue on the project; as each of the companies had committed to the xCAT project and each also had a vested interest in it’s continuation. This led to the proposal of approaching IBM to discuss a formation of a consortium to take ownership of the xCAT project whilst also acknowledging that the consortium wanted to focus on the future for cluster management and administration tooling; this also led to further approaching Lenovo to discuss their willingness to contribute confluent to this cause. Both IBM and Lenovo have been fantastic in supporting the consortium and its goals.
What are the consortium’s goals?
We have 3 main goals,
- Provide extended maintenance, development, and support for xCAT 2
- There are no plans to add “new” features the focus is around bug fixing and stability
- There are no plans to support any operating systems past those that are already supported, i.e. no EL10, no SLES16
- Create the next version cluster management and administration tooling
- We acknowledge both IBM xCAT and Lenovo Confluent being excellent cluster management tooling in their own rights with hours of committed development being applied to both; the consortium is aiming to take the best features from both projects to develop the next community driven tooling
- Some details of “where to start” is still being figured out
- Everything has to be free, open and vendor agnostic
What’s been going on?
It’s been a busy time for the consortium members, Megware, OCF, Redline and our supporting partners IBM and Lenovo; we’ve been meeting weekly to discuss:
Logistical/Commercial
Agree any transitions and how they will happen.
Contact other stakeholders and asset owners to seek agreement.
Discuss within all commercial entities of the consortium.
Create a new workspace for all members to collaborate in whilst providing everyone equal access to assets.
Finalising a memorandum of understanding between the consortium members to outline responsibilities and mutual goals.
Technical
Receive training on the current xCAT development and maintenance.
Implement testing services and CI pipelines.
Implement a new contribution license agreement system.
Update assets reflecting the new consortium.
Updating xCAT nightly build to include latest fixes and development - https://xcat.org/files/xcat/xcat-core/devel/Linux/core-snap/core-rpms-snap.tar.bz2
Target Summer 2024 for xCAT 2.17 (milestone 53) to include Better EL 9 supports, Support for more secure IPMI ciphers, Initial ARM support
The future
The consortium is finalising:
- Its decision to rebase Confluent as it’s start for the next cluster management and administration tooling.
- The language to continue using?
- This will almost certainly be python.
- 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!)
How can you help?
We are looking for community input:
- What are your priorities? What features are you looking for?
- Can you help us bug fix? Document? Create features?
- Do you think we’re doing the right thing? What would you do differently?
Let us know on the mailing list, or alternatively 2 of the consortium members are at ISC next week so why not come and talk to us in person?
ISC, Congress Center Hamburg from June 10-13, 2025.
Megware – B30
OCF – G50
Laurence Horrocks-Barlow | Technical Director
[https://ocf.co.uk/media/0i1lzfjz/ocf-logo-strapline-2022-blk.png]<https://www.ocf.co.uk/>
Phone:
0114 257 2200
Address:
OCF Limited, Unit 5 Rotunda Business Centre, Thorncliffe Park, Chapeltown, Sheffield S35 2PG
Website:
www.ocf.co.uk<http://www.ocf.co.uk/>
[LinkedIn icon]<https://www.linkedin.com/company/ocf-limited/> [Twitter icon] <https://twitter.com/ocf_hpc?lang=en>
[https://ocf.co.uk/media/imkoyi2j/line.jpg]
OCF Limited is a company registered in England and Wales. Registered number 4132533, VAT number GB 780 6803 14. Registered office address: OCF Limited, 5 Rotunda Business Centre, Thorncliffe Park, Chapeltown, Sheffield, S35 2PG.
This message is private and confidential. If you have received this message in error, please notify us immediately and remove it from your system.
-------------
Scheduled Annual Leave:
Click to see my full annual leave calendar<https://calendar.google.com/calendar/u/0/embed?src=j5g...@im...&ctz=Europe/London>
"It is well known that a vital ingredient of success is not knowing that what you're attempting can't be done."
-- Sir Terry Pratchett
|
|
From: Samveen G. <sa...@ya...> - 2024-05-11 01:40:53
|
Jarrod, Taking into account what you said about the history of naming of confluent back in the initial zoom meeting, xCAT has history and is unique with no namespace collisions. Why not use your previous suggestion of xCAT with a postfix like 3, or if not a number, then xcat-ng or even xcat-confluent? |
|
From: Don A. <da...@re...> - 2024-05-11 04:31:13
Attachments:
smime.p7s
|
Jarrod, Just a thought, and you’ve probably considered it already... How about Conflu-X … keeps the ex sound and IMHO sounds better than flux. With an official/long name Conflu-X Administration Toolkit (CAT) it keeps the CAT option open for logos, etc. My $.02 -Don ---- Don Avart CTO RedLine Performance Solutions, LLC (703) 634-5686 da...@re... > On May 10, 2024, at 5:01 PM, Jarrod Johnson <jjo...@le...> wrote: > > > - Any Confluent rebase will likely be renamed to respect existing product name and intellectual properties. (Yes we’re looking for names!) > > I'll throw into the ring: > Conflux (Confluent^H^H^HxCAT^H^H^H) > > If Conflux is not unique enough, then it can have a "long name" of: > Conflux Administration Toolkit (CAT) > > Of course, I'm sure IBM would also be cool with "Alternative Implementation of xCAT (AIX)". > From: Laurence Horrocks-Barlow via xCAT-user <xca...@li...> > Sent: Friday, May 10, 2024 2:18 PM > To: xca...@li... <xca...@li...> > Cc: Laurence Horrocks-Barlow <lho...@oc...> > Subject: [External] [xcat-user] xCAT Consortium update > > Dear xCAT community, > > First, we’d like to first start out with an apology, since the consortium’s announcement in November, IBM’s EoL extension and some smaller communications we haven’t updated the mailing list. This is mostly due to the consortium finding it’s feet with the project and transitioning the assets; for this we would like to thank IBM and Lenovo for their valued input and support. > > To this effect we’d like this mail to serve as an update of where we are and invite the community to ask us questions. > > What is the consortium about? > > In September 2023 IBM announced it’s End of Life plan for xCAT; this spur ’ed conversation within the community and lead to 3 independent companies Megware, OCF and Redline discussing the possibility of combining development resources to continue on the project; as each of the companies had committed to the xCAT project and each also had a vested interest in it’s continuation. This led to the proposal of approaching IBM to discuss a formation of a consortium to take ownership of the xCAT project whilst also acknowledging that the consortium wanted to focus on the future for cluster management and administration tooling; this also led to further approaching Lenovo to discuss their willingness to contribute confluent to this cause. Both IBM and Lenovo have been fantastic in supporting the consortium and its goals. > > What are the consortium’s goals? > > We have 3 main goals, > > - Provide extended maintenance, development, and support for xCAT 2 > - There are no plans to add “new” features the focus is around bug fixing and stability > - There are no plans to support any operating systems past those that are already supported, i.e. no EL10, no SLES16 > > - Create the next version cluster management and administration tooling > - We acknowledge both IBM xCAT and Lenovo Confluent being excellent cluster management tooling in their own rights with hours of committed development being applied to both; the consortium is aiming to take the best features from both projects to develop the next community driven tooling > - Some details of “where to start” is still being figured out > > - Everything has to be free, open and vendor agnostic > > What’s been going on? > > It’s been a busy time for the consortium members, Megware, OCF, Redline and our supporting partners IBM and Lenovo; we’ve been meeting weekly to discuss: > > Logistical/Commercial > Agree any transitions and how they will happen. > Contact other stakeholders and asset owners to seek agreement. > Discuss within all commercial entities of the consortium. > Create a new workspace for all members to collaborate in whilst providing everyone equal access to assets. > Finalising a memorandum of understanding between the consortium members to outline responsibilities and mutual goals. > > Technical > Receive training on the current xCAT development and maintenance. > Implement testing services and CI pipelines. > Implement a new contribution license agreement system. > Update assets reflecting the new consortium. > Updating xCAT nightly build to include latest fixes and development - https://xcat.org/files/xcat/xcat-core/devel/Linux/core-snap/core-rpms-snap.tar.bz2 > Target Summer 2024 for xCAT 2.17 (milestone 53) to include Better EL 9 supports, Support for more secure IPMI ciphers, Initial ARM support > > The future > The consortium is finalising: > > - Its decision to rebase Confluent as it’s start for the next cluster management and administration tooling. > - The language to continue using? > - This will almost certainly be python. > - 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!) > > How can you help? > > We are looking for community input: > > - What are your priorities? What features are you looking for? > - Can you help us bug fix? Document? Create features? > - Do you think we’re doing the right thing? What would you do differently? > > Let us know on the mailing list, or alternatively 2 of the consortium members are at ISC next week so why not come and talk to us in person? > > ISC, Congress Center Hamburg from June 10-13, 2025. > > Megware – B30 > OCF – G50 > > > Laurence Horrocks-Barlow | Technical Director > <https://www.ocf.co.uk/> > Phone: > > 0114 257 2200 > > Address: > > OCF Limited, Unit 5 Rotunda Business Centre, Thorncliffe Park, Chapeltown, Sheffield S35 2PG > > Website: > > www.ocf.co.uk <http://www.ocf.co.uk/> > <https://www.linkedin.com/company/ocf-limited/> <https://twitter.com/ocf_hpc?lang=en> > > OCF Limited is a company registered in England and Wales. Registered number 4132533, VAT number GB 780 6803 14. Registered office address: OCF Limited, 5 Rotunda Business Centre, Thorncliffe Park, Chapeltown, Sheffield, S35 2PG. > This message is private and confidential. If you have received this message in error, please notify us immediately and remove it from your system. > > ------------- > > Scheduled Annual Leave: > > Click to see my full annual leave calendar <https://calendar.google.com/calendar/u/0/embed?src=j5g...@im...&ctz=Europe/London> > > "It is well known that a vital ingredient of success is not knowing that what you're attempting can't be done." > -- Sir Terry Pratchett > > > _______________________________________________ > xCAT-user mailing list > xCA...@li... > https://lists.sourceforge.net/lists/listinfo/xcat-user |
|
From: Kilian C. <kil...@gm...> - 2024-05-13 20:37:49
|
On Fri, May 10, 2024 at 11:52 AM Laurence Horrocks-Barlow via xCAT-user <xca...@li...> 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 |
|
From: Jarrod J. <jjo...@le...> - 2024-05-14 01:57:49
|
> 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 <kil...@gm...> Sent: Monday, May 13, 2024 4:37 PM To: xCAT Users Mailing list <xca...@li...> Subject: [External] Re: [xcat-user] xCAT Consortium update On Fri, May 10, 2024 at 11:52 AM Laurence Horrocks-Barlow via xCAT-user <xca...@li...> 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 xCA...@li... 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> |
|
From: Imam T. <tec...@gm...> - 2024-05-14 02:06:19
|
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 <jjo...@le...> 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 <kil...@gm...> > *Sent:* Monday, May 13, 2024 4:37 PM > *To:* xCAT Users Mailing list <xca...@li...> > *Subject:* [External] Re: [xcat-user] xCAT Consortium update > > On Fri, May 10, 2024 at 11:52 AM Laurence Horrocks-Barlow via > xCAT-user <xca...@li...> 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 > xCA...@li... > > 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 > xCA...@li... > https://lists.sourceforge.net/lists/listinfo/xcat-user > -- Regards, *Imam Toufique* *213-700-5485* |
|
From: Jarrod J. <jjo...@le...> - 2024-05-14 11:51:33
|
It could use some work admittedly, but currently https://hpc.lenovo.com/ ________________________________ From: Imam Toufique <tec...@gm...> Sent: Monday, May 13, 2024 10:06 PM To: xCAT Users Mailing list <xca...@li...> Subject: Re: [xcat-user] [External] Re: xCAT Consortium update 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 <jjo...@le...<mailto:jjo...@le...>> 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 <kil...@gm...<mailto:kil...@gm...>> Sent: Monday, May 13, 2024 4:37 PM To: xCAT Users Mailing list <xca...@li...<mailto:xca...@li...>> Subject: [External] Re: [xcat-user] xCAT Consortium update On Fri, May 10, 2024 at 11:52 AM Laurence Horrocks-Barlow via xCAT-user <xca...@li...<mailto:xca...@li...>> 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 xCA...@li...<mailto:xCA...@li...> 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 xCA...@li...<mailto:xCA...@li...> https://lists.sourceforge.net/lists/listinfo/xcat-user -- Regards, Imam Toufique 213-700-5485 |
Thanks for helping keep SourceForge clean.
X