Bug 1008868 - RFE: support non-provisioning mode for RHEL-OSP Installer
RFE: support non-provisioning mode for RHEL-OSP Installer
Status: CLOSED EOL
Product: Red Hat OpenStack
Classification: Red Hat
Component: rubygem-staypuft (Show other bugs)
3.0
x86_64 Linux
high Severity medium
: ---
: Installer
Assigned To: Jiri Stransky
Omri Hochman
: FutureFeature, ZStream
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-09-17 05:01 EDT by Omri Hochman
Modified: 2016-09-29 09:27 EDT (History)
8 users (show)

See Also:
Fixed In Version:
Doc Type: Enhancement
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2016-09-29 09:27:46 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Omri Hochman 2013-09-17 05:01:51 EDT
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.
Comment 2 Crag Wolfe 2013-11-26 21:28:15 EST
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.
Comment 3 Mike Orazi 2014-05-22 15:21:27 EDT
Moving this to staypuft for evaluation.
Comment 4 Scott Seago 2014-05-27 12:35:38 EDT
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.)
Comment 6 Jaromir Coufal 2016-09-29 09:27:46 EDT
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

Note You need to log in before you can comment on or make changes to this bug.