[BUG] Re-evaluate where to obtain the Hostname from
ArjanMyer opened this issue · 14 comments
When the 'name-label' which is displayed in the host-list is for example written in uppercase and the 'hostname' that is derived from /etc/sysconfig/network is written in lower-case then the script is not able to find the UUID. Changing the 'name-label' of the XenServer to lower-case by hand solved the issue. Proposal is to convert the 'name-label' and hostname to lowercase in the script.
Sounds reasonable; would just need to cross check that if we call anything directly using the 'name-label' that it's case insensitive... Else we'll just need to ignore case sensitivity for identifying the name-label, and store the 'PrOpEr' one.
Based on #30 - sounds like we need to reconsider where we get our hostname from again...
Hi, im have a look again.
in commenting on :
When the 'name-label' which is displayed in the host-list is for example written in uppercase and the 'hostname' that is derived from /etc/sysconfig/network is written in lower-case then the script is not able to find the UUID.
If you change the "name" in XenCenter and not the servers hostname, which i did in my case, than the script wil fail also.
running : xe host-list --minimal is in my opinion sufficient for getting the HOSTUUID.
and if you really need to match with hostname, then i suggest, to get the hostname variables and lowercase them all then do the compair.
I agree with your last point; but not necessarily in cases where the host is part of a pool- pretty sure it returns all pool nodes in that scenario?
thats a good one. I dont use pools over here, im running the free xenserver. So i cant test that.
Im testing now on xen 6.5
change the code to just : xe host-list params=uuid --minimal
and ./patcher -l reports nicely all patches back.
I've merged #36 in now; could someone affected by this confirm if this works as expected now? Any cases where it's still not working as desired? I'm hoping to spend a bit of time on this script the week after next, see if I can get the remaining issues closed off!
Ok, i have found the problem in the name detection of patcher i think.
( tested in single host environment )
The problem is, my server has a hostname: TEST-XEN1
In the XenCenter, i changed that to : TEST-XEN1 192.168.0.1
This is where the problem is.
running ./patcher -l
./patcher.py -l
Getting host list using: /opt/xensource/bin/xe host-list name-label=grep "^HOSTNAME=" /etc/sysconfig/network | awk -F= '{print$2}' params=uuid --minimal
Detected HOST UUID:
Error: Failed to obtain HOSTUUID from XE CLI
running the command :
xe host-list name-label=grep "^HOSTNAME=" /etc/sysconfig/network | awk -F= '{print$2}' params=uuid --minimal
returns nothing.
xe host-list name-label=TEST-XEN1
same, nothing
but this one :
xe host-list name-label='TEST-XEN1 192.168.0.1 '
retuns the needed info.
so if the hostname is different from the name you see in xencenter it fails.
and running : xe host-list name-label='TEST-XEN1 192.168.0.1 ' params=uuid --minimal
works as it should.
so if the name-label value in xencenter is different as "hostname" it cant detect the uuid.
as test, i renamed the server in xencenter back to the same as the hostname and patcher works fine then.
I hope this helps you.
Is there a legacy support reason we are using hostname to filter on the name-label to lookup the host UUID ?
The name label seems volatile and descriptive term in xencenter
Can we please use xe host-list hostname switch instead?
xecli host-list name-label=grep "^HOSTNAME=" /etc/sysconfig/network | awk -F= \'{print$2}\' params=uuid --minimal')
xecli host-list hostname=grep "^HOSTNAME=" /etc/sysconfig/network | awk -F= \'{print$2}\' params=uuid --minimal')
[root@server1~]# xe host-list name-label=server
server1\ Legacy\ Access\ Server
server2\ Legacy\ Access\ Server
server3\ Remote\ Access\ Servers
server4\ Database\ and\ User\ Clients
[root@server1 ~]# xe host-list hostname=server
server1 server2 server3 server4
@carlbb - assuming this is supported by XS6.2 onwards; this seems like the best approach, assuming it consistently matches the system/OS hostname?
I've switched to using ``xe host-list hostname=` in the code I have here which should be checked in shortly-ish. Seems like the logical approach.
Change has been committed now; can anyone confirm if this does/doesn't resolve the issue for them?
The change has worked on my testing pools
version 6.2 SP1
Hai, thanks for the change. !
Works great now for me also in a non pool environment.
Tested on Xen 6.2sp1 and 6.5 and 6.5sp1
Excellent stuff! I'll close this off for now then; but can reopen if we find it to still be an issue.