[Feature] Self sufficient/managed bundle image
As of now, once we start the VM using bundle image, crc perform following operation
- Update the ssh key with new generated ssh key
- set a password for core user for emergency login if configured by user
- Disk resize (growing the parition)
- stop ntp service based on a config
- add user provided nameservers to the vm
- mount shared dirs if enabled
- change permission of root podman socket to
777 - Setup crc-dnsmasq configuration and start
crc-dnsmasqservice - Start the kubelet service
- renew certs if expired
- configure proxy for the ocp cluster
- ensure routes-controller pod is started/running
- Update the user pull secret
- Update the new ssh key as part of machine config
- Update kubeadmin password if provided by user otherwise generate a random one
- Update cluster ID
- enable monitoring if requested
- Wait for the cluster to be stable
For local there is some more steps like check the certs validation and let user know about it and then wait until it is recovered. But for a cloud image it might be better to have a single bash script which can perform all those action and we can create a unit file to running that script. It will help in case of a cloud image once deployed and that unit is enabled then at the end user will get the running cluster directly.
This does not necessarily have to be a bash script, this could also be something written in golang/C/rust/... if that's deemed more convenient than bash, or python/... if the interpreters are already installed on the image (but I don't think they are).
Bash script would be much simpler to do and can be part of same repo, if we want to do same with golang/C/rust then it should be a different repo and create binary which need to be included during bundle creation. I would prefer to do it in bash so there is no dependency and done soonish.
This is my point, this is a choice which is being made, not a hard requirement we cannot change. I'm not arguing against bash, I'm only pointing out we have alternatives if (hypothetically) we realized at some point bash is not a great fit for what we want to do.
Consider how input can be given, as cloud-init will be used by some cloud providers
Just after talk to @praveenkumar add a note on one key benefit from adding the logic to the bundle is to self handle versioning support; this means if there are changes within a new OCP version and this requires the script to be adapted
...manage it externally could be tedious so the script should check the version and apply one logic or the other....
In other words adding it helps long term maintenance
@praveenkumar hey, what about moving the dnsmasq as dedicated service to the network manager dnsmasq plugin?
@praveenkumar hey, what about moving the dnsmasq as dedicated service to the network manager dnsmasq plugin?
We are now using the dnsmasq service directly instead of running it in the container. if we can have following config as part of dnsmasq plugin then sure it would be better to have it with NM.
here 192.168.130.11 is the vm IP address.
$ cat /etc/dnsmasq.d/crc-dnsmasq.conf
listen-address=192.168.130.11
expand-hosts
log-queries
local=/crc.testing/
domain=crc.testing
address=/apps-crc.testing/192.168.130.11
address=/api.crc.testing/192.168.130.11
address=/api-int.crc.testing/192.168.130.11
address=/crc.crc.testing/192.168.126.11