This message was deleted.
# cabpr
a
This message was deleted.
r
With the Kubeadm bootstrap provider the binaries are baked into the base image
This is a good option
c
That also means there is an image version for each binary version
👍 1
r
We could also support downloading, given a url in the spec and as you say download as part of cloud-init
Yep, if you bake the dependencies into a image then there will be an image for each rke2 version
c
I like the "baked into image" approach though it puts more pressure on project maintenance, because it does NOT suppose pre-requisites from the user's perspective
r
Its how CAPI currently works and is accepted
But if people want custom images then we need to supply a list of things they need to include
c
Well, the project maintenance overhead can be limited using proper automation
r
Agreed. We can adopt image-builder potentially….or whatever we currently use at SUSE (obs?) to build images
c
Yes
r
Having the option of downloading from an artefact server / registry is also a nice option
c
How does the standard image land on the user's environment ?
r
Depends on the infra provider being used. Some infra providers have a way to look up images / standard download location. Also most providers have a way to specify a custom image
c
Oh... so we just reference an image ID or something, and the infra provider figures out how to get our image ...
r
I’d say, that we publish images in a variety of formats with RKE2 builtin and then supply instructions on how to obtain/use those images.
But we can also support the download option as well as that will be fully contained in our provider 🙂
c
I would have liked to support that, as probably most of the community settings will NOT be air-gapped, but I see only two ways of doing both air-gapped and non-air-gapped: • We put in the API and explicit option for Air-Gapped environments which would create a completely different cloud-init config. • We do some magic in a complex bash script that is run by cloud-init to figured out if the node is air-gapped or not, and continue with the right approach...
r
If we support both baked into image and download from a specified location we should be able to cover most scenarios.
Air gapped or not
With air gapped guessing we need the container images as well or ability to set different registry / proxy
c
yes, I only fear the various scenarios users would want us to implement for their remote location download: • SSL with a custom CA • Basic Auth • Other Auth • S3 buckets • ...
r
Good point.
Lets start with the baked into image approach (like capi) then?
We can then think about downloading later?
c
We can have 2 things supported first: • baked into image • completely non-air-gapped : download from GitHub public URLs
what do you think ?
r
That could work. Although i’m wondering if we just do 1 to start with and then think about download later
Keep it simple initially to get to poc
c
Sure, that's what Orange did for their fork
r
Baked in?
c
yes
r
Good, that is the capi way 🙂
c
OK then! Let's do that!
r
So we start with issue 24 🙂 Shall we create a discussion in the repo around downloading
c
Makes sense to me
c
Do you have an example / reference I can look into ?
r
Or did you mean their actual usage?
c
no that's it
so what about forking that repo to add capbr ?
a
or maybe customizing it so we can reuse upstream code without forks
we might have conflicts later because of carry patches
r
In my last company we used it as a submodule and built on top of it
👍 1
@astonishing-stone-14417 - when you say customize, do you mean customizing the project directly? or using it and adding customization on top?
a
adding stuff on top
c
yes that was generally my suggestion, since submission upstream might take some time it could be some temp hack until you do it 'right' along the submission of the provider upstream
r
I don’t think it would be temp to be honest 🙂
c
but I mean ready for an upstream submission only when submitting the rest of the work
(you could only build images for AWS first, and take care of different kind of images later)
r
👍
Depending on the project it can be hard to get what is perceived as vendor specific stuff accepted. But we can cross that bridge later 🙂