So, this problem:
Doing koan installs and allowing auto-register gives me a system with "localhost" as the host name and a weird floating point number as the system name in Cobbler, instead of what I expected, which was the value I provided to koan as --virt-name.
lead to this attempted solution:
I defined a system using the profile I wanted, and then try to run koan with --system=SYSTEM_NAME.
which lead to this problem:
System installs fine, but the kickstart meta data does not take affect; in this case, the chef job that was run when I installed via --profile was not run when I installed via a --system= that used the same previously mentioned profile.
which lead to this attempt:
koan --virt --profile=builder-el6-x86_64 --system=builder-el6-64-01\ --server=cobbler.example.com --virt-path=vg_group
which lead to this interesting bug:
- looking for Cobbler at http://cobbler.example.com:80/cobbler_api - reading URL: http://172.29.1.101/cblr/svc/op/ks/system/builder-el6- x86_64 Traceback (most recent call last): <snip> raise HTTPError(req.get_full_url(), code, msg, hdrs, fp) HTTPError: HTTP Error 404: NOT FOUND
Why was it trying to pull the profile from the system section of the API?
Can't you "override" the profile when you specify a system?
This is Cobbler/Koan 2.2.2 by the way.
Thanks for any help you can render!
j
On Wednesday, February 15, 2012 at 9:28 PM, Joshua J. Kugler wrote:
So, this problem:
Doing koan installs and allowing auto-register gives me a system with "localhost" as the host name and a weird floating point number as the system name in Cobbler, instead of what I expected, which was the value I provided to koan as --virt-name.
Sure, there's a reason for that:
if self.hostname != "" and self.hostname != "*AUTO*": hostname = self.hostname sysname = self.hostname else: hostname = socket.getfqdn() if hostname == "localhost.localdomain": if self.hostname == '*AUTO*': hostname = "" sysname = str(time.time()) else: raise InfoException("must specify --fqdn, could not discover") if sysname == "":
sysname = hostname
Basically socket.getfqdn() just returned localhost, since it was unable to get a hostname at that time, resulting in the time of registration being used as the system name. Using the IP wouldn't make sense because it might change.
lead to this attempted solution:
I defined a system using the profile I wanted, and then try to run koan with --system=SYSTEM_NAME.
which lead to this problem:
System installs fine, but the kickstart meta data does not take affect; in this case, the chef job that was run when I installed via --profile was not run when I installed via a --system= that used the same previously mentioned profile.
You might be using different kickstart templates if you assigned --kickstart to the system. Hard to tell without seeing more.
I would find it unlikely that the metadata merger is broken as that's a pretty core piece of functionality.
which lead to this attempt:
koan --virt --profile=builder-el6-x86_64 --system=builder-el6-64-01\ --server=cobbler.example.com (http://cobbler.example.com) --virt-path=vg_group
which lead to this interesting bug:
- looking for Cobbler at http://cobbler.example.com:80/cobbler_api
- reading URL: http://172.29.1.101/cblr/svc/op/ks/system/builder-el6-
x86_64 Traceback (most recent call last):
<snip> raise HTTPError(req.get_full_url(), code, msg, hdrs, fp) HTTPError: HTTP Error 404: NOT FOUND
Why was it trying to pull the profile from the system section of the API?
Can't you "override" the profile when you specify a system?
Kickstart metadata is hash merged such that ks meta values in the profile blend with the system, with the system replacing any keys defined in the system. Though if you had a key set in the profile and not in the system, it would obviously remain.
This is Cobbler/Koan 2.2.2 by the way.
Thanks for any help you can render!
j
-- Joshua J. Kugler - Fairbanks, Alaska Azariah Enterprises - Programming and Website Design joshua@azariah.com (mailto:joshua@azariah.com) - Jabber: pedahzur@gmail.com (mailto:pedahzur@gmail.com) PGP Key: http://pgp.mit.edu/ ID 0x73B13B6A _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org (mailto:cobbler@lists.fedorahosted.org) https://fedorahosted.org/mailman/listinfo/cobbler
Thanks for the quick reply! I appreciate your help, as I'm still learning cobbler. Reply inline.
On Thursday, February 16, 2012, Michael DeHaan elucidated thus:
On Wednesday, February 15, 2012 at 9:28 PM, Joshua J. Kugler wrote:
So, this problem:
Doing koan installs and allowing auto-register gives me a system with "localhost" as the host name and a weird floating point number as the system name in Cobbler, instead of what I expected, which was the value I provided to koan as --virt-name.
Sure, there's a reason for that:
if self.hostname != "" and self.hostname != "*AUTO*": hostname = self.hostname sysname = self.hostname else: hostname = socket.getfqdn() if hostname == "localhost.localdomain": if self.hostname == '*AUTO*': hostname = "" sysname = str(time.time()) else: raise InfoException("must specify --fqdn, could
not discover") if sysname == "":
sysname = hostname
Basically socket.getfqdn() just returned localhost, since it was unable to get a hostname at that time, resulting in the time of registration being used as the system name. Using the IP wouldn't make sense because it might change.
OK, I understand that that there was no hostname assigned. However, how do you assign one when you're installing with koan and --profile? I supplied a --virt-name, which I expected to be the name it used to auto- register the machine. There could be a way to specify a hostname when doing a 'koan --profile' install, but I'm not seeing it.
lead to this attempted solution:
I defined a system using the profile I wanted, and then try to run koan with --system=SYSTEM_NAME.
which lead to this problem:
System installs fine, but the kickstart meta data does not take affect; in this case, the chef job that was run when I installed via --profile was not run when I installed via a --system= that used the same previously mentioned profile.
You might be using different kickstart templates if you assigned --kickstart to the system. Hard to tell without seeing more.
I would find it unlikely that the metadata merger is broken as that's a pretty core piece of functionality.
In the profile I have:
Kickstart: /var/lib/cobbler/kickstarts/el6.ks
Kickstart Metadata: chef_args=-j http://ourbuildserver:8080/job/infra_lab/lastSuccessfulBuild/artifact/chef/s... user_packages=@Development Tools,koan
In the system, Kickstart and Kickstart Metadata are blank (I had tried putting <<inherit>> in there when I defined the system, but when I saved, it blanked it out.
My install command line was:
koan --virt --virt-name="test-jk-el6-64" --profile=builder-el6-x86_64 -- server=ourcobblerserver --virt-path=VolGroupName
It followed all the specs of the profile except for the Kickstart Metadata.
which lead to this attempt:
koan --virt --profile=builder-el6-x86_64 --system=builder-el6-64-01\ --server=cobbler.example.com (http://cobbler.example.com) --virt-path=vg_group
which lead to this interesting bug:
- looking for Cobbler at http://cobbler.example.com:80/cobbler_api
- reading URL:
http://172.29.1.101/cblr/svc/op/ks/system/builder-el6- x86_64 Traceback (most recent call last):
<snip> raise HTTPError(req.get_full_url(), code, msg, hdrs, fp) HTTPError: HTTP Error 404: NOT FOUND
Why was it trying to pull the profile from the system section of the API?
Can't you "override" the profile when you specify a system?
Kickstart metadata is hash merged such that ks meta values in the profile blend with the system, with the system replacing any keys defined in the system. Though if you had a key set in the profile and not in the system, it would obviously remain.
OK, I understand that. However, please look at the error again. When I specify both the profile and the builder, it tries to pull the *PROFILE* from /system/
/cblr/svc/op/ks/system/builder-el6-x86_64
instead of from
/cblr/svc/op/ks/profile/builder-el6-x86_64
The latter one works.
j
OK, I understand that that there was no hostname assigned. However, how do you assign one when you're installing with koan and --profile? I supplied a --virt-name, which I expected to be the name it used to auto- register the machine. There could be a way to specify a hostname when doing a 'koan --profile' install, but I'm not seeing it.
The system failed to detect the hostname from running *inside* the guest, it has nothing to do with what parameters you set on the hypervisor. It got "localhost.localdomain" back, more or less, and decided that wasn't going to be unique enough.
You could possibly use Cobbler with manage_dhcp and manage_dns to ensure you gave out a particular hostname, though ordinarily I'd expect you to at least get a dhcpXXX hostname if you have DHCP. In this way, you would procreate the system before it exists rather than using koan with --profile, you'd declare the system, assign a MAC and IP, and use koan with --system instead to bring that system to life. Much better, IMHO.
Keep in mind cobbler-register has *NOTHING* to do with koan at all, it's just something you run on any system, so don't expect the name of the virtual machine to be visible inside the guest. The guest doesn't really know it's virtualized.
cobbler-register is more for folks who have a large network of machines they already provisioned using something else, and need to get them into cobbler so they can reprovision, etc. In those cases, you could also pass --fqdn to register to name the systems. If you were doing that in the kickstart and deploying by system name (not --profile, but --system) the system name variable itself is made available to the kickstart, so you have some options.
If you don't like those options, the cobbler register script is very simple, so you could change it to work differently.
https://github.com/cobbler/cobbler/blob/master/koan/register.py
lead to this attempted solution:
I defined a system using the profile I wanted, and then try to run koan with --system=SYSTEM_NAME.
which lead to this problem:
System installs fine, but the kickstart meta data does not take affect; in this case, the chef job that was run when I installed via --profile was not run when I installed via a --system= that used the same previously mentioned profile.
You might be using different kickstart templates if you assigned --kickstart to the system. Hard to tell without seeing more.
I would find it unlikely that the metadata merger is broken as that's a pretty core piece of functionality.
In the profile I have:
Kickstart: /var/lib/cobbler/kickstarts/el6.ks
Kickstart Metadata: chef_args=-j http://ourbuildserver:8080/job/infra_lab/lastSuccessfulBuild/artifact/chef/s... user_packages=@Development Tools,koan
In the system, Kickstart and Kickstart Metadata are blank (I had tried putting <<inherit>> in there when I defined the system, but when I saved, it blanked it out.
My install command line was:
koan --virt --virt-name="test-jk-el6-64" --profile=builder-el6-x86_64 -- server=ourcobblerserver --virt-path=VolGroupName
It followed all the specs of the profile except for the Kickstart Metadata.
which lead to this attempt:
koan --virt --profile=builder-el6-x86_64 --system=builder-el6-64-01\ --server=cobbler.example.com (http://cobbler.example.com) (http://cobbler.example.com) --virt-path=vg_group
which lead to this interesting bug:
- looking for Cobbler at http://cobbler.example.com:80/cobbler_api
- reading URL:
http://172.29.1.101/cblr/svc/op/ks/system/builder-el6- x86_64 Traceback (most recent call last):
<snip> raise HTTPError(req.get_full_url(), code, msg, hdrs, fp) HTTPError: HTTP Error 404: NOT FOUND
Why was it trying to pull the profile from the system section of the API?
Can't you "override" the profile when you specify a system?
Kickstart metadata is hash merged such that ks meta values in the profile blend with the system, with the system replacing any keys defined in the system. Though if you had a key set in the profile and not in the system, it would obviously remain.
OK, I understand that. However, please look at the error again. When I specify both the profile and the builder, it tries to pull the *PROFILE* from /system/
/cblr/svc/op/ks/system/builder-el6-x86_64
instead of from
/cblr/svc/op/ks/profile/builder-el6-x86_64
The latter one works.
j
-- Joshua J. Kugler - Fairbanks, Alaska Azariah Enterprises - Programming and Website Design joshua@azariah.com (mailto:joshua@azariah.com) - Jabber: pedahzur@gmail.com (mailto:pedahzur@gmail.com) PGP Key: http://pgp.mit.edu/ ID 0x73B13B6A _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org (mailto:cobbler@lists.fedorahosted.org) https://fedorahosted.org/mailman/listinfo/cobbler
To answer your other question.
Don't specify --profile or --system. If you mean --system, just specify --system. Cobbler is treeish, the system already knows it's profile on the server.
This should probably be a "options conflict" error or something.
On Thursday, February 16, 2012 at 3:37 PM, Michael DeHaan wrote:
OK, I understand that that there was no hostname assigned. However, how do you assign one when you're installing with koan and --profile? I supplied a --virt-name, which I expected to be the name it used to auto- register the machine. There could be a way to specify a hostname when doing a 'koan --profile' install, but I'm not seeing it.
The system failed to detect the hostname from running *inside* the guest, it has nothing to do with what parameters you set on the hypervisor. It got "localhost.localdomain" back, more or less, and decided that wasn't going to be unique enough.
You could possibly use Cobbler with manage_dhcp and manage_dns to ensure you gave out a particular hostname, though ordinarily I'd expect you to at least get a dhcpXXX hostname if you have DHCP. In this way, you would procreate the system before it exists rather than using koan with --profile, you'd declare the system, assign a MAC and IP, and use koan with --system instead to bring that system to life. Much better, IMHO.
Keep in mind cobbler-register has *NOTHING* to do with koan at all, it's just something you run on any system, so don't expect the name of the virtual machine to be visible inside the guest. The guest doesn't really know it's virtualized.
cobbler-register is more for folks who have a large network of machines they already provisioned using something else, and need to get them into cobbler so they can reprovision, etc. In those cases, you could also pass --fqdn to register to name the systems. If you were doing that in the kickstart and deploying by system name (not --profile, but --system) the system name variable itself is made available to the kickstart, so you have some options.
If you don't like those options, the cobbler register script is very simple, so you could change it to work differently.
https://github.com/cobbler/cobbler/blob/master/koan/register.py
lead to this attempted solution:
I defined a system using the profile I wanted, and then try to run koan with --system=SYSTEM_NAME.
which lead to this problem:
System installs fine, but the kickstart meta data does not take affect; in this case, the chef job that was run when I installed via --profile was not run when I installed via a --system= that used the same previously mentioned profile.
You might be using different kickstart templates if you assigned --kickstart to the system. Hard to tell without seeing more.
I would find it unlikely that the metadata merger is broken as that's a pretty core piece of functionality.
In the profile I have:
Kickstart: /var/lib/cobbler/kickstarts/el6.ks
Kickstart Metadata: chef_args=-j http://ourbuildserver:8080/job/infra_lab/lastSuccessfulBuild/artifact/chef/s... user_packages=@Development Tools,koan
In the system, Kickstart and Kickstart Metadata are blank (I had tried putting <<inherit>> in there when I defined the system, but when I saved, it blanked it out.
My install command line was:
koan --virt --virt-name="test-jk-el6-64" --profile=builder-el6-x86_64 -- server=ourcobblerserver --virt-path=VolGroupName
It followed all the specs of the profile except for the Kickstart Metadata.
which lead to this attempt:
koan --virt --profile=builder-el6-x86_64 --system=builder-el6-64-01\ --server=cobbler.example.com (http://cobbler.example.com) (http://cobbler.example.com) --virt-path=vg_group
which lead to this interesting bug:
- looking for Cobbler at http://cobbler.example.com:80/cobbler_api
- reading URL:
http://172.29.1.101/cblr/svc/op/ks/system/builder-el6- x86_64 Traceback (most recent call last):
<snip> raise HTTPError(req.get_full_url(), code, msg, hdrs, fp) HTTPError: HTTP Error 404: NOT FOUND
Why was it trying to pull the profile from the system section of the API?
Can't you "override" the profile when you specify a system?
Kickstart metadata is hash merged such that ks meta values in the profile blend with the system, with the system replacing any keys defined in the system. Though if you had a key set in the profile and not in the system, it would obviously remain.
OK, I understand that. However, please look at the error again. When I specify both the profile and the builder, it tries to pull the *PROFILE* from /system/
/cblr/svc/op/ks/system/builder-el6-x86_64
instead of from
/cblr/svc/op/ks/profile/builder-el6-x86_64
The latter one works.
j
-- Joshua J. Kugler - Fairbanks, Alaska Azariah Enterprises - Programming and Website Design joshua@azariah.com (mailto:joshua@azariah.com) - Jabber: pedahzur@gmail.com (mailto:pedahzur@gmail.com) PGP Key: http://pgp.mit.edu/ ID 0x73B13B6A _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org (mailto:cobbler@lists.fedorahosted.org) https://fedorahosted.org/mailman/listinfo/cobbler
On Thursday, February 16, 2012, Michael DeHaan elucidated thus:
OK, I understand that that there was no hostname assigned. However, how do you assign one when you're installing with koan and --profile? I supplied a --virt-name, which I expected to be the name it used to auto- register the machine. There could be a way to specify a hostname when doing a 'koan --profile' install, but I'm not seeing it.
The system failed to detect the hostname from running *inside* the guest, it has nothing to do with what parameters you set on the hypervisor. It got "localhost.localdomain" back, more or less, and decided that wasn't going to be unique enough.
You could possibly use Cobbler with manage_dhcp and manage_dns to ensure you gave out a particular hostname, though ordinarily I'd expect you to at least get a dhcpXXX hostname if you have DHCP. In this way, you would procreate the system before it exists rather than using koan with --profile, you'd declare the system, assign a MAC and IP, and use koan with --system instead to bring that system to life. Much better, IMHO.
Yes, that is what I tried to do (pre-create the systems, configure the DHCP, hostname, etc.) then used koan --system, but the system did not inherit its profile's Kickstart Metadata. Is there a way I can troubleshoot this? Some way I can dump the information koan is passing to the install so I can see if the kickstart metadata is being "lost" somewhere in the process?
Keep in mind cobbler-register has *NOTHING* to do with koan at all,
<SNIP>
cobbler-register is more for folks who have a large network of machines they already provisioned using something else, and need to get them into cobbler so they can reprovision, etc.
Gotcha.
j
On Thursday, February 16, 2012, Joshua J. Kugler elucidated thus:
You could possibly use Cobbler with manage_dhcp and manage_dns to ensure you gave out a particular hostname, though ordinarily I'd expect you to at least get a dhcpXXX hostname if you have DHCP. In this way, you would procreate the system before it exists rather than using koan with --profile, you'd declare the system, assign a MAC and IP, and use koan with --system instead to bring that system to life. Much better, IMHO.
Yes, that is what I tried to do (pre-create the systems, configure the DHCP, hostname, etc.) then used koan --system, but the system did not inherit its profile's Kickstart Metadata. Is there a way I can troubleshoot this? Some way I can dump the information koan is passing to the install so I can see if the kickstart metadata is being "lost" somewhere in the process?
<bump> Is there a way to dump the merged data when I'm doing a koan --system
invocation?
Thanks!
j
no.
On Wednesday, February 22, 2012 at 6:21 PM, Joshua J. Kugler wrote:
On Thursday, February 16, 2012, Joshua J. Kugler elucidated thus:
You could possibly use Cobbler with manage_dhcp and manage_dns to ensure you gave out a particular hostname, though ordinarily I'd expect you to at least get a dhcpXXX hostname if you have DHCP. In this way, you would procreate the system before it exists rather than using koan with --profile, you'd declare the system, assign a MAC and IP, and use koan with --system instead to bring that system to life. Much better, IMHO.
Yes, that is what I tried to do (pre-create the systems, configure the DHCP, hostname, etc.) then used koan --system, but the system did not inherit its profile's Kickstart Metadata. Is there a way I can troubleshoot this? Some way I can dump the information koan is passing to the install so I can see if the kickstart metadata is being "lost" somewhere in the process?
<bump> Is there a way to dump the merged data when I'm doing a koan --system
invocation?
Thanks!
j
-- Joshua J. Kugler - Fairbanks, Alaska Azariah Enterprises - Programming and Website Design joshua@azariah.com (mailto:joshua@azariah.com) - Jabber: pedahzur@gmail.com (mailto:pedahzur@gmail.com) PGP Key: http://pgp.mit.edu/ ID 0x73B13B6A _______________________________________________ cobbler mailing list cobbler@lists.fedorahosted.org (mailto:cobbler@lists.fedorahosted.org) https://fedorahosted.org/mailman/listinfo/cobbler
On Wednesday, February 22, 2012, Michael DeHaan elucidated thus:
<bump> Is there a way to dump the merged data when I'm doing a koan --system invocation?
no.
OK, how can I best help you debug this? When I do koan --profile=XYZ, the information in kickstart meta is passed in, and the chef run is done. When I do koan --system=ABC, which is a sytem that uses the XYZ profile, the kickstart meta information is not passed in (or something else keeps the chef run from happening.
How can I best go about pinpointing the cause?
j
Joshua J. Kugler <joshua <at> azariah.com> writes:
On Wednesday, February 22, 2012, Michael DeHaan elucidated thus:
<bump> Is there a way to dump the merged data when I'm doing a koan --system invocation?
no.
OK, how can I best help you debug this? When I do koan --profile=XYZ, the information in kickstart meta is passed in, and the chef run is done. When I do koan --system=ABC, which is a sytem that uses the XYZ profile, the kickstart meta information is not passed in (or something else keeps the chef run from happening.
How can I best go about pinpointing the cause?
j
Did you ever get a resolution to this?
We're trying to set up autotest to provision existing KVM clients and allow the users to specify a profile other than the default in cobbler. We have run into the same issues you did.
Thanks, ray spear
cobbler@lists.fedorahosted.org