+++ This bug was initially created as a clone of Bug #835791 +++ 1. Proposed title of this feature request Option to set MAC address while provisioning system profile from Satellite webui. 3. What is the nature and description of the request? Customer want to specify MAC address while provisioning system profile from satellite webui on provisioning page. 4. Why does the customer need this? (List the business requirements here) Business justifications: 1) In our environment to perform a kickstart of a machine we must enter a reservation into our windows AD DHCP infrastructure and configure the DHCP reservation to boot from our satellite server. To perform this task we must know the MAC address prior to performing the kickstart. At the moment in satellite there is no way of knowing this. 2) There is a vanishingly small but finite probability that virtualised guests built on different servers will select the same random MAC address to use - this will increase with the number of VM host machines and guests. By having a method of satellite controlling the MAC address allocation then we can ensure that MAC addresses are unique across all the VM hosts under control of the satellite servers. A MAC address collision has subtle effects and is very difficult to troubleshoot, anything that can prevent this happening is worthwhile. 3) Satellite gives the appearance of being able to build a fully virtualised guest automatically but appears to be missing some things that would make this work. Satellite should note the fact that a fully virtualised guest is being built and automatically associate a kickstart profile with a MAC address in cobbler (this ties in with satellite managing MAC addresses in 1&2 above). Doing this would mean that we can deploy a fully virtualised guest in a similar manner to a para-virtualised guest instead of doing what we do at the moment which is manually create the fully virtualised guest using virt-install, since this is a manual process it is prone to errors and requires more time and effort which is something that satellite is supposed to alleviate. Finally, not being able to build fully virtualised guests from within satellite automatically violates the principle of least astonishment. The interface gives all the appearances of being capable of performing the task and, indeed, satellite attempts to do what it is asked but, in reality, it will only function for a very narrow and specific set of circumstances which appears to be that you have a dhcp server set up that is configured to pxe boot any client from the satellite server and that cobbler is configured to have a default kickstart profile that will be applied. In an ideal world of homogenous red hat clients this would be fine but in a heterogenous network it is not acceptable to default install red hat linux on a machine attempting a pxe boot.
Committed to Spacewalk master: 8a0662ebdac23e411c8ba138fb0df489084eef92
Needed to add new column to initial table creation too (as opposed to just the upgrade script): 07e310a4bce0db22914fef7757c36f26853acb4d
Also needed: 02bc48e51f9666db9893eb166affdc6871a3b3f4 No functional changes, removes MAC Address column from Kickstart Profile list.
Moving ON_QA. Packages that address this bugzilla should now be available in yum repos at http://yum.spacewalkproject.org/nightly/
Spacewalk 1.8 has been released: https://fedorahosted.org/spacewalk/wiki/ReleaseNotes18