Comments (2)
Alright, here are my opinions on the various points you brought up:
Vagrant throws an OCI Shim error.
I don't know what this is, can you post some output?
There is this permission issue.
In your issue, I asked what this problem even is, but you haven't responded yet, so I don't know what to think about this point. Is it connected to your first problem?
Starting from today, I even cannot rebuild the setup:
Tried it today, the error does not occur anymore (also in Docker). I think this has nothing to do with Vagrant or VirtualBox, this is just some ubuntu stuff.
VBox even discontinued the arm version for macOS
As far as I can tell, this was only a beta so far anyways and they are just not pushing any more beta builds for 7.0.x. From the thread, I would expect the builds to continue with versions 7.1.0 and 8. In any case, if Docker would still work on M1, I would not see this as an urgent motivation to move away from Vagrant.
Also, using docker with vagrant abuses the container idea.
No, it does not. I don't want to have files from apache, postgres etc. spread across my host filesystem, so I mock up a file system for these tools by using a container - exactly what containers are meant to do.
If we would fully change to a container setup we would reduce the dev setup complexity.
I think we would have to see an actual setup before judging this. My intuition would be that there isn't really a way to reduce complexity of the setup, afterall, we are just setting everything up as we need it. The configuration could possible be more robust with a declarative configuration instead of our imperative bash script though - again, would have to see a working setup.
All provisioning could go into an 15 line Dockerfile
How? Where does all the code we currently have go?
reproducible docker-compose file
Tempting, but I don't think plain docker is the way for reproducibility. If we run apt update
in the container (and we will), reproducibility goes out the window.
For new members, we could provide a prebuild development docker container
Interesting idea, I think that would be very cool, if it is turns out faster to setup than building it yourself.
Docker benefits from docker-layer-caching, to speedup rebuilds and save storage.
I don't see how it would be better than our single-layer docker image that is used by vagrant where we only have exactly the stuff that we need and is only rarely rebuilt.
We have talked about this before. There are some requirements for the development setup that vagrant has solved really well where other tools do not work too great:
- replicating the setup of the production server (not sure how we stand on running containers in production)
- has a way of running a sandbox in the development vm (for example for frontend tests; does not work in docker)
- few tools needed on the host to get it running (having small containers might lead to us installing more container-related tools in the host)
That said, I think you are well aware that I am also not too happy with our bash script that occasionally swallows errors from commands either. I have been looking into packaging evap with nix for some time now and I like to think that once I could get it to work, it would solve all problems. However, I can't really argue that it is better than what we currently have before I really have something to play around with and there are also some tradeoffs that I haven't made up my mind about yet.
The way I see it, is that there is no reason to abandon vagrant currently before we are sure that the next solution would really improve the aspects we are trying to fix. In that sense, I gladly take a look at any suggested changes to the setup, but can't promise that I will agree with them and even less that we get a consensus to merge it into evap. If I recall correctly, you did start to write a docker-compose file for evap some time back? What happened to that?
from evap.
Additional stuff I'd like to point out:
- You shouldn't have to reprovision the container every week, we intend stopping and restarting to work.
- The OCI Shim stuff seems to be a containerd problem. Keep in mind that Vagrant is basically just a CLI user of docker. If there is something wrong with the docker setup, removing Vagrant will not help.
- As you already said, the apt error is a ubuntu thing, possibly due to a corrupted apt cache. Instructions on how to fix this are available on the internet. I can see how this might happen if you interrupt the provisioning while apt is running. In any way, it has nothing to do with the provider that we use to make a containerized/virtualized ubuntu system available. Removing Vagrant will not help here.
- The file permission error happens because docker doesn't handle file permissions of mounted files consistently across implementations/platforms. This is a problem with docker, we will not fix it by removing Vagrant.
- The "ports keep being used after container is stopped" issue is also fundamentally a docker problem in my opinion. This also will not be fixed by removing Vagrant.
Overall, I think you blame Vagrant for a lot of problems that it is not responsible for.
Our current provisioning script is runnable documentation of how to setup an instance of evap. In the deployment folder, we currently have ~230 lines of setup-logic and configuration templates that are actively used and thus tested during each development-box-setup-procedure. In the developer box, we have a correctly named user with the correct permissions, and we provide python with a venv git, bash with autocompletion and colored output, access to the management script, apache with a working configuration and mod-wsgi, postgres, redis, the possibility to test production updates and rollbacks, the correct version of node.js, and the option to run frontend tests. We have all common linux tools available for debugging. (note: list non-exhaustive). In short: We provide executable setup instructions for a developer box for people wanting to develop evap. Vagrant allows us to turn these instructions into a ready-to-go environment with a 10-letter command (vagrant up
).
The developer-box in some way mismatches docker principles because we want to use it as an interactive environment while docker wants a container to non-interactively run one service while "removing" the environment. However, dropping Vagrant and VirtualBox doesn't change anything about this mismatch. We could remove Vagrant from the equation by just copy&pasting the handful of docker commands that it currently issues for us and it would not improve the situation.
That said: For most work on EvaP, you are completely free to build your own development setup the way you would like it to be. If you can replace everything with a 15 line Dockerfile, feel free to do that and use it. Just be aware that we will not easily merge a PR into our codebase if it lacks main features that the current development box has.
from evap.
Related Issues (20)
- JSON enrollment data importer (v1) HOT 2
- Preparation reminder text view
- Separate imported participants from manual changes
- "Delete Semester" (modal submit) button flicker-shows on staff semester page HOT 1
- Update Django Stubs on new release
- Bilingual RewardPointRedemptionEvent names
- Delete participations of long inactive users
- Database validation for model field choices
- Assertion failure due to weak signal receivers having no guarantee of being garbage collected in time HOT 2
- Package EvaP (with nix?) HOT 3
- Creating Superuser fails on a fresh install HOT 5
- Clear session of user on permission change HOT 2
- Replace print statements in enrollment preprocessor
- Questionnaire reordering fails HOT 1
- Participation progress bar HOT 1
- Student index page / `TestStudentIndexView` performance
- Group related settings in some nested struct
- Loading of backup fails due to nullable `natural_key`: the `USERNAME_FIELD`
- user delete form not working HOT 2
- Add configuration option in redemption events allowing redemption of reward points only in certain steps HOT 1
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from evap.