I'm trying to come up with a solution that will allow us to provision
systems within the Azure cloud, but end up with them bespoked in a similar
way to the rest of our kickstarted estate.
It looks like we're stuck with having to create new Azure guests from set
images, so I was wondering if I can pause a kickstarting system just after
the point at which the package list has been installed, but before the rest
of the kickstart takes over. This would effectively allow us to upload an
image to Azure which has been built with our specific package list from the
relevant kickstart tree (RHEL 7.2 in the current case).
I know that booting this image as a new guest isn't going to run the rest
of the kickstart, but is there any way that this could be done? I'm
wondering if the booting image could have the rest of the kickstart run as
part of firstboot (or similar). This could allow our tailoring of the
image to still take place, all patches applied, puppet runs done,
katello-agent installed, registered to Satellite etc.
Or could the booting image contact the Satellite for it's kickstart in the
same way that other kickstarts are downloaded, then anaconda is instructed
to jump forward to the relevant sections and miss out the package
installation.
This might all be pie in the sky, but for cloud systems that only allow us
to boot from pre-defined images, we're looking for a solution that doesn't
require updating the image every time patches are applied.
Thoughts?
Duncan
Does anyone think that this is a viable idea? Even a "no, go back to bed
Duncan and don't get up until your brain is working" would let me know
whether to follow it at all.
Duncan
ยทยทยท
On Friday, 18 March 2016 09:48:47 UTC, Duncan Innes wrote:
>
> I'm trying to come up with a solution that will allow us to provision
> systems within the Azure cloud, but end up with them bespoked in a similar
> way to the rest of our kickstarted estate.
>
> It looks like we're stuck with having to create new Azure guests from set
> images, so I was wondering if I can pause a kickstarting system just after
> the point at which the package list has been installed, but before the rest
> of the kickstart takes over. This would effectively allow us to upload an
> image to Azure which has been built with our specific package list from the
> relevant kickstart tree (RHEL 7.2 in the current case).
>
> I know that booting this image as a new guest isn't going to run the rest
> of the kickstart, but is there any way that this could be done? I'm
> wondering if the booting image could have the rest of the kickstart run as
> part of firstboot (or similar). This could allow our tailoring of the
> image to still take place, all patches applied, puppet runs done,
> katello-agent installed, registered to Satellite etc.
>
> Or could the booting image contact the Satellite for it's kickstart in the
> same way that other kickstarts are downloaded, then anaconda is instructed
> to jump forward to the relevant sections and miss out the package
> installation.
>
> This might all be pie in the sky, but for cloud systems that only allow us
> to boot from pre-defined images, we're looking for a solution that doesn't
> require updating the image every time patches are applied.
>
> Thoughts?
>
> Duncan
>
