Skip to content
This repository has been archived by the owner on Dec 3, 2021. It is now read-only.

Return to Roots #79

Open
Mierdin opened this issue Jul 2, 2020 · 9 comments
Open

Return to Roots #79

Mierdin opened this issue Jul 2, 2020 · 9 comments

Comments

@Mierdin
Copy link
Member

Mierdin commented Jul 2, 2020

In my recent forum post I mentioned that I used a heavily modified form of the selfmedicate script that uses the kvm2 driver to play around with kata containers. It worked beautifully. This caused me to start thinking about how the role of selfmedicate has changed in the last year.

In particular, there are a few things that are very different now than they were when this project started:

  • We're no longer running guacamole, which appeared to have serious problems when running within the VM that was auto-provisioned. This was one of the bigger drivers in moving to a Vagrant setup, wherein we execute minikube with the none driver.
  • Selfmedicate is no longer in the critical path. Anyone that uses it should know what they're doing. With the preview service now the "official" method of contributing to the curriculum, selfmedicate no longer needs to be all things to all people. I believe the right course of action is to greatly simplify what selfmedicate does, and that means being opinionated about the environment. Given this new purpose, I think this more than acceptable.
  • Time. Minikube is more mature now, and a year is a long time to get bug fixes and stability improvements.
  • Images are getting lighter. Moving away from vQFX and in general getting leaner with image builds (because we don't have to add on as many security hacks).
  • Kata containers means that we now care a lot about nested virtualization performance, and kvm does this really well. I know virtualbox does this now as well, but it's another knob to configure, and as we've seen, not everyone wants to run virtualbox. If we're going to pick one hypervisor (which i think we should), picking kvm2 seems to make more sense, and on top of that, minikube just takes care of it for us.

I'm opening this issue because once I'm done with my "prod" work, I plan to open a PR to hyper-simplify things. Without context, it might look like I'm going on a killing spree, so I wanted to open this first to at least get my thoughts on paper, well in advance of a PR (which I won't have time for until at least a few weeks from now). I love the work that went into adding Vagrant support a year back, but I think the times have changed. It's time to return to the roots, where it really is just little more than a thin wrapper on top of minikube.

@smk4664
Copy link
Member

smk4664 commented Jul 7, 2020

The other main driver for Vagrant was Windows support. The CLI tool for generating curriculum and the preview help this issue.

@Mierdin
Copy link
Member Author

Mierdin commented Jul 10, 2020

@smk4664 Refresh my memory - what exactly didn't support windows? Minikube seems to, at least at this point: https://kubernetes.io/docs/tasks/tools/install-minikube/

@smk4664
Copy link
Member

smk4664 commented Jul 14, 2020

@Mierdin I don't remember what the old driver for minikube was, but Windows does not support the proposed kvm2 driver. The other issue was the old bash script to start self-medicate.

@Mierdin
Copy link
Member Author

Mierdin commented Jul 14, 2020

Hm, okay. Well in any case as you mentioned, the new tooling helps with this issue, and I'm inclined to take the stance that if someone still needs selfmedicate, the onus should be on them to make the necessary modifications to support their system if needed. I think this may even be made easier by thinning out what we put on top of minikube anyways.

@smk4664
Copy link
Member

smk4664 commented Jul 14, 2020

I am good with this.

@smk4664
Copy link
Member

smk4664 commented Oct 1, 2020

@Mierdin If you haven't started on this, I would like to take on some of this work. At least getting it back running with the original intent and updating the libraries.

@gbonnefille
Copy link

What about splitting this project in tow distinct parts:

  • one to deploy Antidote component in an existing Kubernetes (a sort of raw collection of manifests)
  • one to instantiate a K8S and provisioning the previous project on it.

As a soft-skilled K8S user, I have my K8S of choice. So I only need a collection of manifests to test/run Antidote.
Related to this, I suggest you to separate infrastructure requirement (like an Ingress controller) from the applicative manifest.

(Sorry if my comment is out-of-topic)

@Mierdin
Copy link
Member Author

Mierdin commented Oct 17, 2020

If you haven't started on this, I would like to take on some of this work. At least getting it back running with the original intent and updating the libraries.

@smk4664 I would say don't bother. Since what I have in mind is fairly destructive, I wouldn't want you to waste your time. I'll be hyper-simplifying things and then marking this repo read-only.

@gbonnefille Your comment isn't out-of-topic, but also isn't really the direction I'm aiming for here. If you know what you're doing, feel free to make the changes you're suggesting in your own copy. Selfmedicate was meant to be turnkey for those that didn't know k8s.

@smk4664
Copy link
Member

smk4664 commented Oct 17, 2020

That destructive! Good with me.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants