>
>
> I'm unclear from that on whether you made a typo with "Cobble server" or
> you're planning to keep it for some services. I'm going to assume a typo
> based on the questions below about per-DC provisioning - do correct me and
> clarify otherwise 
>
> For Foreman provisioning, you can achieve a completely segregated
> provisioning network - the Foreman Proxy can relay templates. So long as
> the proxy (which you'd have for TFTP/DHCP management anyway) has a route to
> Foreman, it can retrieve rendered templates on behalf of the installing
> host. See Foreman :: Manual
> for more.
>
>
No, we'd be replacing the Cobbler server with a Foreman one entirely, I was
just reiterating that the only things that the installing hosts have access
to IS the 'Cobbler|Foreman' server, and in general, all we provide as a
service is HTTP/TFTP/DHCP to those installing hosts. The 'Cobbler|Foreman'
host would definitely have access to the Foreman server, which sounds like
it would work.
> - We only use DHCP for the provisioning process. Everything else has
>> static IPs. I assume that's ok, as long as we let Foreman control the DHCP
>> server on the prov vlan
>>
>
> Yes, that's fine. The default templates (for Kickstart anyway) come with
> static configuration snippets, and there's an IP allocation mode for the
> Subnet in the UI. Set that to static, and the templates should render
> correctly. For other OSs (you mentioned Windows? :p) then you may want to
> see how we're detected the IPAM mode and re-use it in templates of your own.
>
Yeah, Windows was… interesting. Basically, we iPXE, chainload into a
custom iPXE script, into a wimboot of a custom WinPE image, that figures
out the Cobbler server IP, downloads some scripts from it and runs them,
which then boots us into Windows, where we then download a Chef cookbook
and configure the host appropriately. I'm not super happy with it, as it
takes too many reboots ( and rebooting Dell R820's is a 5 minute process…
), so total provision time ends up at 30 min or so.
> That said, you'll want to think about scale, no doubt, with the number of
> systems you mentioned in the OP. It's quite possible to scale out the
> various parts of Foreman itself (in addition to the obvious scaling of the
> proxies) in different ways, so that's something we can go into if you need
> more info.
>
>
So I'm not sure we'd actually use too much of Foreman's lifecycle
management, as we have other tools for that. One of the main reasons we're
investigating it ( besides Cobbler's lack of development lately ) is
because the team in control of our yum repos is looking at deploying
Katello, which means we'd have Foreman anyways, so why not consolidate if
we can get it to work.
I did checkout the Salt plugin and it looks like it manages what we were
doing, although in a little bit of a intrusive way compared to our solution
( we just send an even through the salt-minion on the Cobbler host and the
master takes care of everything else… nothing installed on the master to
get it working )
Thanks for bearing with me Greg - sounds like I've got enough where we
could at least go to a POC stage on it.