Description of problem: This is frustrating! When trying to create a series of hosts, sometimes the MAC address field under "Network" disappears for no seemingly no reason whatsoever? Version-Release number of selected component (if applicable): How reproducible: Steps to Reproduce: 1. Create a new host, "aaaaa". Host Organization: ACME_Corporation Deploy on: Libvirt Environment: some published definition Puppet Master: katello smart proxy Network MAC Address: (whatever you want) Domain (your domain) Subnet (your subnet) IP Address (autopopulate) Operating System ...enter all valid info in here... 2. Submit 3. Repeat step one, using hostname "bbbbb" Actual results: The MAC address line under Network subtab is gone! Expected results: This should not disappear Additional info: Sometimes(?) a force refresh of browser page fixes it but you have to reenter your stuff from scratch. Screenshot forthcoming.
* apr-util-ldap-1.3.9-3.el6_0.1.x86_64 * candlepin-0.8.9-1.el6_4.noarch * candlepin-scl-1-5.el6_4.noarch * candlepin-scl-quartz-2.1.5-5.el6_4.noarch * candlepin-scl-rhino-1.7R3-1.el6_4.noarch * candlepin-scl-runtime-1-5.el6_4.noarch * candlepin-selinux-0.8.9-1.el6_4.noarch * candlepin-tomcat6-0.8.9-1.el6_4.noarch * elasticsearch-0.19.9-8.el6sat.noarch * foreman-1.1.10002-44.noarch * foreman-ec2-1.1.10002-44.noarch * foreman-installer-puppet-concat-0-2.d776701.git.0.21ef926.el6sat.noarch * foreman-installer-puppet-dhcp-0-5.3a4a13c.el6sat.noarch * foreman-installer-puppet-dns-0-7.fcae203.el6sat.noarch * foreman-installer-puppet-foreman-0-6.568c5c4.el6sat.noarch * foreman-installer-puppet-foreman_proxy-0-8.bd1e35d.el6sat.noarch * foreman-installer-puppet-puppet-0-3.ab46748.el6sat.noarch * foreman-installer-puppet-tftp-0-5.ea6c5e5.el6sat.noarch * foreman-installer-puppet-xinetd-0-50a267b8.git.0.44aca6a.el6sat.noarch * foreman-libvirt-1.1.10002-44.noarch * foreman-postgresql-1.1.10002-44.noarch * foreman-proxy-1.1.10002-1.el6sat.noarch * foreman-proxy-installer-1.0.1-8.f5ae2cd.el6sat.noarch * katello-1.4.2-8.el6sat.noarch * katello-all-1.4.2-8.el6sat.noarch * katello-candlepin-cert-key-pair-1.0-1.noarch * katello-certs-tools-1.4.2-2.el6sat.noarch * katello-cli-1.4.2-6.el6sat.noarch * katello-cli-common-1.4.2-6.el6sat.noarch * katello-common-1.4.2-8.el6sat.noarch * katello-configure-1.4.3-12.el6sat.noarch * katello-configure-foreman-1.4.3-12.el6sat.noarch * katello-foreman-all-1.4.2-8.el6sat.noarch * katello-glue-candlepin-1.4.2-8.el6sat.noarch * katello-glue-elasticsearch-1.4.2-8.el6sat.noarch * katello-glue-pulp-1.4.2-8.el6sat.noarch * katello-qpid-broker-key-pair-1.0-1.noarch * katello-qpid-client-key-pair-1.0-1.noarch * katello-selinux-1.4.3-3.el6sat.noarch * openldap-2.4.23-32.el6_4.1.x86_64 * openldap-devel-2.4.23-32.el6_4.1.x86_64 * pulp-rpm-plugins-2.1.1-1.el6sat.noarch * pulp-selinux-2.1.1-1.el6sat.noarch * pulp-server-2.1.1-1.el6sat.noarch * python-ldap-2.3.10-1.el6.x86_64 * ruby193-rubygem-ldap_fluff-0.1.7-3.el6sat.noarch * ruby193-rubygem-net-ldap-0.2.2-7.el6_4.noarch * signo-0.0.15-1.el6sat.noarch * signo-katello-0.0.15-1.el6sat.noarch
Created attachment 757356 [details] see screenshot - note lack of MAC address field in UI
The field disappears when choosing libvirt but remains for baremetal. That said, it appears the first time a user chooses libvirt but does not appear for subsequent host creations. Something is very non-intuitive here.
Oh, and if user tries to submit without this field, s/he gets: " is not a supported nic type "
The MAC address field should be hidden when building on libvirt, but visible when building on bare metal. When building on a compute resource (non-image based), then Foreman will provide the MAC as you're not going to be able to enter it yourself. If it isn't disappearing, then that would be a bug. Please check Foreman's log file and the browser JS error window in this case to see if there are errors loading the form. The "not a supported nic type" might have been affected by a change in foreman-1.1.10002-45, so if you hit this on -44 as comment #1 suggests, could you please see if it's reproducible there?
Based on comment 5, I am moving this to ON_QA.
Moving this to be tested during MDP3, not critical for MDP2 success story
Cannot reproduce this anymore, closing.