Ah, silly me: bad copy-paste.
That command gives:
File "/opt/confluent/bin/confluent_selfcheck", line 241
for rsp in sess.read(f'/nodes/{args.node}/attributes/all’):
^
SyntaxError: invalid syntax
Regardless, I (re-)ran the `nodeattrib` correctly, but that did not help. I
then removed all the “filename=…” stanzas in dhcpd.conf, did a restart, and the
system got (AFAICT) an IP from DHCPd, but Confluent gave it the PXE boot
parameters and the system launched into the Ubuntu 20.04 installer. The console
is prompting me a bunch of questions.
So I’ve think I’ve finally managed to muddle through this part of the
documentation:
https://hpc.lenovo.com/users/documentation/confluentosdeploy.html
Is there any documentation about automating Ubuntu installs with Confluent?
Does Confluent handle any cloud-init stuff (which was run during the boot
process), or is there some other method to send things that partitioning and
packing information to Ubuntu?
> On Nov 10, 2023, at 11:01, Jarrod Johnson <jjohns...@lenovo.com> wrote:
>
> The attribute name is plural, with s at the end.
> deployment.useinsecureprotocols rather than deployment.useinsecureprotocol.
>
> confluent_selfcheck -n MYHOST
>
> Say anything interesting?
>
>> From: David Magda <dmagda+x...@ee.torontomu.ca>
>> Sent: Friday, November 10, 2023 10:50 AM
>> To: xCAT Users Mailing list <xcat-user@lists.sourceforge.net>
>> Subject: Re: [xcat-user] [External] Re: xCAT-Confluent
>>
>> Looking in that file there was:
>>
>> Nov 09 09:02:06 {"info": "Boot attempt by MYHOST detected in
>> insecure
>> mode, but insecure mode is disabled. Set the attribute
>> `deployment.useinsecureprotocols` to `firmware` or `always` to
>> enable
>> support, or use UEFI HTTP boot with HTTPS." }
>>
>> Trying to tweak that attribute, I got:
>>
>> $ nodeattrib MYHOST deployment.useinsecureprotocol=firmware
>> Error: Bad Request - deployment.useinsecureprotocol attribute on
>> node MYHOST is invalid
>>
>> I tried using nodegroupattrib as well on a group that the host was in, and
>> got:
>>
>> Error: Bad Request - deployment.useinsecureprotocol attribute is
>> invalid
>>
>> I then edited the reply_dhcp4(() function in
>> /opt/confluent/lib/python/confluent/discovery/protocols/pxe.py to change
>> the default check to remove the “return;" in the "if insecuremode == 'never'
>> and not httpboot:" stanza so that it would continue going. The log message
>> still appears (so I know the code is getting there), but the events file now
>> has:
>>
>> Nov 09 09:18:34 {"info": "Offering PXE boot without address, served
>> from 172.17.15.254 to MYHOST"}
>>
>> And the system is still booting xCat (I have commented out "gpxe.no-pxedhcp
>> 1" in dhcpd.conf and restarted).
>>
>> Not running the dhcpd at all simply has the system timeout on its PXE
>> attempt. I told Confluent about the particular IP address the system should
>> have:
>>
>> $ nodeattrib MYHOST net.ipv4_address=172.17.15.223/21
>>
>> And that did not help.
>>
>> Per "lsof -i udp", Confluent is listening on (amongst many other ports)
>> *:bootps, *:dhcpv6-server, *:pxe (etc).
>>
>> Should I edit my dhcpd.conf and rip out things like:
>>
>> […]
>> if option user-class-identifier = "xNBA" and option
>> client-architecture = 00:00 { #x86, xCAT Network Boot Agent
>> always-broadcast on;
>> filename = "…"
>> […]
>>
>> to try to see if that will get things going with Confluent? Or are things
>> expected to work with all of that?
>>
>>
>>
>> > On Nov 8, 2023, at 16:19, Jarrod Johnson <jjohns...@lenovo.com> wrote:
>> >
>> > tail /var/log/confluent/events for a hint on why it might be ignoring the
>> > request.
>> >
>> >> From: David Magda <dma...@ee.torontomu.ca>
>> >> Sent: Wednesday, November 8, 2023 2:46 PM
>> >> To: xCAT Users Mailing list <xcat-user@lists.sourceforge.net>
>> >> Subject: Re: [xcat-user] [External] Re: xCAT-Confluent
>> >>
>> >>
>> >> I did a “service dhcpd stop” and a “service confluent restart”, and the
>> >> SuperMicro did not receive any reply to the DHCP/PXE packets it was
>> >> sending out. I then did a “service dhcpd start” and the “xcat/genesis”
>> >> file was loaded.
>> >>
>> >> The dhcpd.conf did have "gpxe.no-pxedhcp”, but removing it and restarting
>> >> did not change any behaviour. I noticed that
>> >> “http://IP:80/tftpboot/xcat/xnba/nets/172.17.8.0_21” is being referenced.
>> >>
>> >> Per “lsof -i udp”, the Confluent is listening on *:bootps, so I’m not
>> >> sure why it is not answering. I had run a “nodedeploy MYHOST -n
>> >> ubuntu-20.04.6-x86_64-default” earlier.
>> >>
>> >> $ nodeattrib MYHOST
>> >> MYHOST: console.method: ipmi
>> >> MYHOST: deployment.apiarmed: once
>> >> MYHOST: deployment.pendingprofile: ubuntu-20.04.6-x86_64-default
>> >> MYHOST: deployment.profile:
>> >> MYHOST: deployment.stagedprofile:
>> >> MYHOST: deployment.state:
>> >> MYHOST: deployment.state_detail:
>> >> MYHOST: groups: prox,ipmi,all,everything
>> >> MYHOST: hardwaremanagement.manager: MYHOST-ipmi
>> >> MYHOST: net.hwaddr: ac:1f:AA:BB:CC:DD
>> >> MYHOST: net.ipv4_method: dhcp
>> >> MYHOST: secret.hardwaremanagementpassword: ********
>> >> MYHOST: secret.hardwaremanagementuser: ********
>> >>
>> >>
>> >> > On Nov 7, 2023, at 13:40, Jarrod Johnson wrote:
>> >> >
>> >> > If dhcpd.conf is set to not send any 'filename', it's best. If you
>> >> > don't need a dhcp server, then you can turn it off. There's also
>> >> >
>> >> > If you have a dhcp server with a dynamic range on it, then:
>> >> > nodeattrib net.ipv4_method=firmwaredhcp
>> >> >
>> >> > If you have a dhcp server with static reservations, you could either
>> >> > have dhcp continue, or disallow dhcp for the confluent node.
>> >> >
>> >> > If you have no dhcp server, then it should just do the right thing
>> >> > directly.
>> >> >
>> >> > If you want to use dhcp ongoing, then 'net.ipv4_method=dhcp', however
>> >> > you own the IPAM sort of responsibility totally.
>> >> >
>> >> > If your dhcp has:
>> >> > option gpxe.no-pxedhcp 1;
>> >> > Please remove that to let confluent merge an offer with an
>> >> > uncoordinated dhcp server.
>> >> >
>> >> > I need to do a deeper right up on the detail about dhcp interaction,
>> >> > how it is now optional, and how it can coexist with an unmanaged dhcp
>> >> > server and free the dhcp server from 'filename'
>> >> >
>> >> >> From: David Magda
>> >> >> Sent: Tuesday, November 7, 2023 9:27 AM
>> >> >> To: xCAT Users Mailing list
>> >> >> Subject: Re: [xcat-user] [External] Re: xCAT-Confluent
>> >> >>
>> >> >> After running the first few commands, I have
>> >> >> /tftpboot/confluent/x86_64/ipxe* and /var/lib/confluent/public/{os,
>> >> >> distribution}/ubuntu* present, along with genesis-x86_64/.
>> >> >>
>> >> >> However the contents of the RHEL/CentOS /etc/dhcp/dhcpd.conf are such
>> >> >> that “filename” is “xcat/xnba.*”, so that’s what gets loaded.
>> >> >>
>> >> >> Do I need to tweak the dhcpd.conf just for the test system I’m playing
>> >> >> with, or should a completely new dhcpd.conf file be put in place for
>> >> >> using Confluent? (Moving the current one out of the way, perhaps
>> >> >> temporarily until I get an understanding of Confluent so I can revert
>> >> >> to xCat if need-be.)
>> >> >>
>> >> >>> On Oct 26, 2023, at 11:33, Jarrod Johnson wrote:
>> >> >>>
>> >> >>> I will say that EL7 hasn't been tested and thus we haven't pushed
>> >> >>> updates since 3.8.0, but 3.8.0 should be plenty.
>> >> >>>
>> >> >>> The confluent you have going is already enough to start examining OS
>> >> >>> deployment profiles. If you would like to, you can use commands like
>> >> >>> osdeploy initialize and osdeploy import and even imgutil build, and
>> >> >>> it won't mess with xCAT.
>> >> >>>
>> >> >>> When you get to nodedeploy, that is the time when you have to start
>> >> >>> planning around potential disruption as xCAT and confluent might
>> >> >>> fight over who gets to deploy a system, and that can be confusing.
>> >> >>> We should document formally how to mask a node from xCAT ('!*NOIP*'
>> >> >>> in mac table) to let one kick the tires with a node...
>> >> >>>
>> >> >>> I can help look at a few people kicking tires, certainly seems worthy
>> >> >>> of documentation or video example...
>> >> >>>> From: David Magda
>> >> >>>> Sent: Thursday, October 26, 2023 11:22 AM
>> >> >>>> To: xCAT Users Mailing list
>> >> >>>> Subject: [External] Re: [xcat-user] xCAT-Confluent
>> >> >>>>
>> >> >>>> Yes, there was perhaps auto-completion with regards
>> >> >>>> Confluent/Confluence.
>> >> >>>> I currently have a (legacy?) ‘joint’ xCAT-Confluent (3.6)
>> >> >>>> installation on RHEL 7 that I inherited; if one wants to fully move
>> >> >>>> from xCAT to Confluent, is there document on how to ‘extract’
>> >> >>>> oneself from xCAT? I don’t see anything that jumps out at:
>> >> >>>> https://hpc.lenovo.com/users/
>> >> >>>> https://hpc.lenovo.com/users/documentation/
>> >> >>>> Should I simply abandon the previous installation and do a fresh
>> >> >>>> install? While there is some documentation, the system leans towards
>> >> >>>> being heavily vendor-used so people completely new to it have a
>> >> >>>> steep learning curve (xCAT is/was also challenging to get into since
>> >> >>>> it was fairly vendor-focused).
>> >> >> […]
>>
_______________________________________________
xCAT-user mailing list
xCAT-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xcat-user
