|
I would also be interested in such a demonstration, if a zoom
call is possible.
--Dani_L.
On 30/09/2023 21:54:40, Imam Toufique
wrote:
Jarrod,
I would like to set up a call with you, for a demonstration
, and understanding how the tool works. You mentioned you are
on the east coast, Let me know what would work for you for the
coming weeks.
If anyone else is interested, I can put a zoom link in this
thread so others can join.
--imam
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
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.
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.
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.
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!
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
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
_______________________________________________
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
--
Regards,
Daniel Letai
+972 (0)505 870 456
|
