openstack-foreman-installer: openstack-foreman-installer is starting dhcp server that answer to requests from non-registered nodes. Description: ------------- When installing openstack-foreman using foreman_server.sh - the default value for 'FOREMAN_PROVISIONING=true', the default value for dhcp_range => '${SECONDARY_PREFIX}.50 ${SECONDARY_PREFIX}.200', It means - after installation, openstack-foreman will act as dhcp and will answer to IP requests, not only from registered nodes - but any request. It's likely to create problems for those who choose to install openstack-foreman with provision=true and already have function dhcp on their network, I checked with Ohad levy how is it done in foreman upstream: foreman upstream will be installed with 'unattended_installation=true' but the 'dhcp=false'- it's need to be configured specifically to start working . I think in openstak-foremam we should consider that in case installing with 'provision=true', the default will be comment-out '#' of the dhcp_range line from foreman_server.sh, this way the foreman dhcp will only answer to requests coming from registered nodes. (*nodes that been added to openstack-foreman by running 'foreman_client.sh' or by 'Add-Host' in the openstack-foreman GUI), Steps: ------- 1) Install openstack-foreman using foreman_server.sh (leave the script with it's default value 'provision=true') 2) After installation complete - check ps -ef | grep dhcpd Results: --------- After installation (with provision=true) there will be running dhcpd with range 50-200. that dhcp answers any request not pnly register hosts/instances and likely to create problems on organizational networks that already dhcp running.
Note for others that this only pertains to Foreman in provisioning mode. So, it was intentional that Foreman "own" the dhcp server (as well as dns) on the provisioning network, but it should *only* be listening on the "foreman" subnet. I.e., only on its provisioning interface aka the "foreman provisioning" network as I described in https://bugzilla.redhat.com/show_bug.cgi?id=971539 . "this way the foreman dhcp will only answer to requests coming from registered nodes" -- I don't quite follow you here, the registered node had to get dhcp from somewhere before it actually became registered. I don't see how the foreman dhcpd server would not respond the first time the host makes a dhcp request but then respond the second time. Is the problem that foreman dhcp is providing ip addresses for hosts that have not been defined in the UI (note that defining a host in the UI in provisioning mode necessarily means providing a MAC addr)? Alternately, there is room for improvement here, perhaps as RFE(s)? We can eventually try to support multiple cases including "foreman provisioning with dhcp and dns" , "foreman provisioning using an existing dhcp server", "foreman provisioning using an existing dns server" and build out test cases for each.
Moving this to staypuft for evaluation.
So as I understand the direction here, the intent is to resolve this by supporting non-provisioning mode with staypuft. In other words, if you don't want foreman to run a DHCP server and auto discovery (and, essentially *own* the provisioning network), we should support installing staypuft in non-provisioning mode without auto-discovery enabled. Supporting this requires the following: 1) Sort out the puppetssh functionality, and modify orchestration to use puppetssh rather than orchestrating by controlling provisioning order. 2) Make sure that the foreman puppet registration script, used to add hosts when foreman is running in non-provisioning mode, works in the staypuft context as well 3) Staypuft installer needs to be modified to take a config option as to whether to work w/ provisioning and auto-discovery, or non-provisioning (in which case discovery is disabled, we don't set up a DHCP server, etc.)
Closing list of bugs for RHEL OSP Installer since its support cycle has already ended [0]. If there is some bug closed by mistake, feel free to re-open. For new deployments, please, use RHOSP director (starting with version 7). -- Jaromir Coufal -- Sr. Product Manager -- Red Hat OpenStack Platform [0] https://access.redhat.com/support/policy/updates/openstack/platform