Feature #7464
openadd network awareness
Description
Based on the staypuft installer, I would like foreman-installer to be aware and configure a network interface for provisioning within foreman / external services (dhcp, dns etc).
Updated by Ohad Levy over 10 years ago
- Related to Feature #6840: publish a foreman live-cd added
Updated by The Foreman Bot over 10 years ago
- Status changed from New to Ready For Testing
- Target version set to 1.7.3
- Pull request https://github.com/Katello/katello.org/pull/46 added
- Pull request deleted (
)
Updated by Stephen Benjamin over 10 years ago
- Pull request added
- Pull request deleted (
https://github.com/Katello/katello.org/pull/46)
Updated by Stephen Benjamin over 10 years ago
- Status changed from Ready For Testing to New
Updated by Ohad Levy over 10 years ago
- Translation missing: en.field_release set to 21
Updated by Ewoud Kohl van Wijngaarden over 10 years ago
I'm not 100% sure I got the exact scope right. Do you mean that the installer should in some way ensure the subnet the smartproxy DHCP is in will be added to the foreman? In that case I might need to finish up https://github.com/theforeman/puppet-foreman/pull/111
Updated by Ewoud Kohl van Wijngaarden over 10 years ago
- Related to Feature #4994: create a subnet in foreman once a dhcp server is configured added
Updated by Ohad Levy over 10 years ago
Ewoud Kohl van Wijngaarden wrote:
I'm not 100% sure I got the exact scope right. Do you mean that the installer should in some way ensure the subnet the smartproxy DHCP is in will be added to the foreman? In that case I might need to finish up https://github.com/theforeman/puppet-foreman/pull/111
this is currently done via a kafo hook (see https://github.com/theforeman/foreman-installer-staypuft/blob/master/hooks/lib/provisioning_seeder.rb).
having it purely in puppet sounds promising, but not sure if kafo internally needs the information? @ares what do you think?
Updated by Ewoud Kohl van Wijngaarden over 10 years ago
We already do so for smartproxy registration, so the only potential problem I see is that there is no puppet fact for the gateway.
Updated by Marek Hulán over 10 years ago
We may want to do more complex things which is why I'm not sure about puppet to be the right tool to seed data into Foreman. E.g. if interactive mode is enabled we may want to handle situation when there's already subnet of same name, we may want to display user a diff, update just some of parameters etc. Also me will want to do association of other objects (subnet/domains/proxies). While the final save could be made by puppet, loading and other parts would need to use some other code.
I'd prefer using one codebase to work with Foreman resources. I'd use apipie-bindigs with the recent Ivan's work that adds helpers like find_or_create, reload, contexts, associations, multiple action on collections etc. There's still work to do (extract foreman specific configuration from hammer cli eval plugin to some foreman-bindings package). This way it would be very easy to manipulate with Foreman resources. As stated before, we could still use apipie bindings in puppet manifests just to save the record after user interaction but I don't see any pro here. Obviously one advantage of having Foreman resource configuration through puppet module is that you can use Foreman to manage other Foremen but if the module would depend on apipie bindigs, it does not make much sense.
Updated by Dominic Cleal over 10 years ago
- Translation missing: en.field_release deleted (
21)