| kata-irc-bot | <jose.carlos.venegas.m> @fidencio good afternoon, I was wondering the extra features of `sandboxed-containers-operator` over kata-deploy | 15:08 |
|---|---|---|
| kata-irc-bot | <jose.carlos.venegas.m> Ignoring of course that one is target for openshift | 15:09 |
| kata-irc-bot | <jose.carlos.venegas.m> I see uninstall and upgrades may be easier? | 15:09 |
| kata-irc-bot | <jose.carlos.venegas.m> @wmoschet I am not sure if you use it as well? | 15:10 |
| kata-irc-bot | <wmoschet> hi @jose.carlos.venegas.m Unfortunately I don't use neither kata-deploy nor sandboxed-containers-operator on the CI job I maintain. It is in my long term goals use either one of those | 17:43 |
| kata-irc-bot | <jose.carlos.venegas.m> @wmoschet thanks lets see if @fidencio has any experience with them | 20:44 |
| kata-irc-bot | <fidencio> Hey @jose.carlos.venegas.m! | 20:46 |
| kata-irc-bot | <jose.carlos.venegas.m> \o | 20:46 |
| kata-irc-bot | <fidencio> So, uninstall and upgrades may be easier, but the operator makes a few assumptions / takes a few paths that upstream may not take much advantage of. | 20:48 |
| kata-irc-bot | <fidencio> For instance, OCP (and hopefully, also OKD in the future) uninstall & upgrades of the kata-containers come for free as those are RPMs built-in in an OS image. | 20:48 |
| kata-irc-bot | <jose.carlos.venegas.m> some context, I was looking on how could we install latest (HEAD) kata in a kata-deploy way | 20:49 |
| kata-irc-bot | <jose.carlos.venegas.m> I have locally some patches to build a kata-static tarball with the latest in a local repository | 20:50 |
| kata-irc-bot | <jose.carlos.venegas.m> that is one part of the story, the other is how to deploy it | 20:50 |
| kata-irc-bot | <jose.carlos.venegas.m> or upgrade an installation | 20:50 |
| kata-irc-bot | <jose.carlos.venegas.m> Push all the time to a registry is not nice at least for dev | 20:51 |
| kata-irc-bot | <fidencio> I see your point and I agree. the operator *also* would require pushing to a registry, though. | 20:51 |
| kata-irc-bot | <fidencio> Let me think a little bit. | 20:51 |
| kata-irc-bot | <jose.carlos.venegas.m> I was thinking create a pod in a namespace push the tarball to the pod via `kubectl copy` | 20:52 |
| kata-irc-bot | <fidencio> @jose.carlos.venegas.m, where are you planning to store the kata-static binaries? | 20:52 |
| kata-irc-bot | <jose.carlos.venegas.m> in a pod that will serve a static http server inside a k8s namespace | 20:54 |
| kata-irc-bot | <jose.carlos.venegas.m> the way to push it could be by doing `kubectl copy` to this pod | 20:55 |
| kata-irc-bot | <jose.carlos.venegas.m> and then the `deployer pod` just pull from that server inside the namespace cluster | 20:55 |
| kata-irc-bot | <jose.carlos.venegas.m> Still need a containerd image published, but would be an empty wrapper, that pulls the `kata-static tarball+installation scripts` | 20:56 |
| kata-irc-bot | <jose.carlos.venegas.m> That is what I have in my mind to avoid being pushing to a registry | 20:57 |
| kata-irc-bot | <jose.carlos.venegas.m> at least for dev sounds not too bad | 20:58 |
| kata-irc-bot | <fidencio> So, let's take this in baby-steps, and bear with me as it may be too late for my brain to work properly. | 20:58 |
| kata-irc-bot | <fidencio> The first step everyone could benefit is the kata-static tarball being public, somewhere, on every PR merged. Do we agree with that? | 20:59 |
| kata-irc-bot | <jose.carlos.venegas.m> yep | 20:59 |
| kata-irc-bot | <jose.carlos.venegas.m> actually I already have github action, so on every PR we will have the binaries for that PR | 21:00 |
| kata-irc-bot | <jose.carlos.venegas.m> probably I should stop there and send the changes as I have and then talk about how to deploy them without an push to a registry | 21:01 |
| kata-irc-bot | <fidencio> Okay! Considering we have that, can't we just `curl` the binaries to the node? | 21:01 |
| kata-irc-bot | <jose.carlos.venegas.m> Yep, I was thinking something like that | 21:02 |
| kata-irc-bot | <fidencio> Because then we need one tag ... `:main` | 21:02 |
| kata-irc-bot | <fidencio> And that tag would always pull-in the latest content | 21:02 |
| kata-irc-bot | <jose.carlos.venegas.m> I got lost in the last comment | 21:02 |
| kata-irc-bot | <fidencio> So, let me take a step back and look at the scripts | 21:03 |
| kata-irc-bot | <jose.carlos.venegas.m> oh I see on every merge, create push to our registry | 21:03 |
| kata-irc-bot | <jose.carlos.venegas.m> sure let me push once again | 21:05 |
| kata-irc-bot | <fidencio> @jose.carlos.venegas.m I was actually thinking on something simpler, but maybe it doesn't even make sense. | 21:06 |
| kata-irc-bot | <fidencio> Right now, our Dockerfile assumes we have the kata-static content. My suggestion, at least for the main branch, is that we don't embedded that to our container anymore, but rather always pull it from the cluster (as in, `curl` the binaries from a well-known location). | 21:06 |
| kata-irc-bot | <fidencio> Is this too non-sense? | 21:07 |
| kata-irc-bot | <jose.carlos.venegas.m> yep, in a second pod maybe? | 21:07 |
| kata-irc-bot | <fidencio> but why do we need a pod? | 21:07 |
| kata-irc-bot | <jose.carlos.venegas.m> I am not a k8s expert but the curl could be a to a known nds name | 21:08 |
| kata-irc-bot | <jose.carlos.venegas.m> and that could be done via nds inside k8s ? | 21:09 |
| kata-irc-bot | <jose.carlos.venegas.m> a pod with a given nds name | 21:09 |
| kata-irc-bot | <jose.carlos.venegas.m> well I think its called service | 21:09 |
| kata-irc-bot | <fidencio> Like, here: https://github.com/kata-containers/kata-containers/blob/1faaf5f35dc6bfb0e7ebf1ec55[…]cf6627f15cdd/tools/packaging/kata-deploy/scripts/kata-deploy.sh Can't we just do `curl http://katacontainers.io/latest-binary.tar.gz` | 21:09 |
| kata-irc-bot | <jose.carlos.venegas.m> ```function install_artifacts() { echo "copying kata artifacts onto host" cp -a /opt/kata-artifacts/opt/kata/* /opt/kata/ chmod +x /opt/kata/bin/* }``` | 21:10 |
| kata-irc-bot | <jose.carlos.venegas.m> well we could inject the place to pull with env var as well | 21:11 |
| kata-irc-bot | <jose.carlos.venegas.m> agree the second pod may not be needed | 21:11 |
| kata-irc-bot | <jose.carlos.venegas.m> just a curl just before the cp | 21:11 |
| kata-irc-bot | <fidencio> ```function install_artifacts() { // curl the tarball from our jenkins // extract then in /tmp (for instance) // copy them from tmp to /opt/kata/ cp -a /opt/kata-artifacts/opt/kata/* /opt/kata/ chmod +x /opt/kata/bin/* }``` | 21:11 |
| kata-irc-bot | <jose.carlos.venegas.m> agree | 21:12 |
| kata-irc-bot | <jose.carlos.venegas.m> and we could modify the URL in case you want to provision with your local changes | 21:12 |
| kata-irc-bot | <jose.carlos.venegas.m> in your cluster | 21:12 |
| kata-irc-bot | <jose.carlos.venegas.m> even if is a single node cluster | 21:12 |
| kata-irc-bot | <jose.carlos.venegas.m> it is really easy | 21:12 |
| kata-irc-bot | <fidencio> yep, then it's up to you how you'll serve it to your single node cluster, but yeah | 21:12 |
| kata-irc-bot | <jose.carlos.venegas.m> I like the idea | 21:13 |
| kata-irc-bot | <jose.carlos.venegas.m> I wonder how dangerous could be even just reduce the docker file to a curl | 21:13 |
| kata-irc-bot | <jose.carlos.venegas.m> ```FROM alpine``` | 21:14 |
| kata-irc-bot | <fidencio> Yeah, that's for sure something I'm not able to evaluate at this time :slightly_smiling_face: | 21:14 |
| kata-irc-bot | <jose.carlos.venegas.m> well as first step I like it | 21:15 |
| kata-irc-bot | <fidencio> Okay, now let me call it a day. :slightly_smiling_face: | 21:17 |
| kata-irc-bot | <jose.carlos.venegas.m> :slightly_smiling_face: | 21:18 |
| kata-irc-bot | <jose.carlos.venegas.m> I need to cleanup my commits | 21:24 |
| kata-irc-bot | <jose.carlos.venegas.m> but where is the idea | 21:24 |
| kata-irc-bot | <jose.carlos.venegas.m> https://github.com/jcvenegas/kata-containers/blob/kdeploy-2021-06-08/.github/workflows/kata-deploy-push.yaml | 21:24 |
| kata-irc-bot | <jose.carlos.venegas.m> This is the action that builds an component | 21:24 |
| kata-irc-bot | <jose.carlos.venegas.m> this reuses current kata-deploy tarball generator to use in both actions and locally | 21:26 |
| kata-irc-bot | <jose.carlos.venegas.m> https://github.com/jcvenegas/kata-containers/blob/kdeploy-2021-06-08/tools/packaging/kata-deploy/local-build/kata-deploy-binaries.sh | 21:26 |
| kata-irc-bot | <jose.carlos.venegas.m> and I have a new wrapper script to build kata from docker | 21:27 |
| kata-irc-bot | <jose.carlos.venegas.m> https://github.com/jcvenegas/kata-containers/blob/kdeploy-2021-06-08/tools/packaging/kata-deploy/local-build/kata-deploy-binaries-in-docker.sh | 21:27 |
| kata-irc-bot | <jose.carlos.venegas.m> This is for folks like me that dont want to run all the CI scripts to have a kata build locally | 21:28 |
| kata-irc-bot | <jose.carlos.venegas.m> because it may be slow the actions could build the tarball in parallel | 21:28 |
Generated by irclog2html.py 2.17.2 by Marius Gedminas - find it at https://mg.pov.lt/irclog2html/!