Closed bittner closed 5 years ago
My first finding:
The aim of this change was not to introduce a new way for users to install Foreman via containers (even if its possible) rather more as a development (or developers) tool.
This is bad. Wrong direction.
@ohadlevy, while I understand the motivation I believe the ultimate goal is fundamentally flawed.
Why? Think "Immutable infrastructure and applications": (source DZone)
"Immutable infrastructure provides stability, efficiency, and fidelity to your applications through automation... the basic idea is that you create and operate your infrastructure using the programming concept of immutability: once you instantiate something, you never change it. Instead, you replace it with another instance to make changes or ensure proper behavior."
We must stop upgrading systems. This causes systems to break.
Instead, we must make a habit out of building systems that are meant to be thrown away once a new version comes along. That's what containerization is about. That's what we need from the The Foreman project: Working software. The data must be on a volume (yeah, I know, that sounds ... stupid ... too trivial).
It must be safe to keep application code and created artifacts, including database content, separate.
My first finding:
The aim of this change was not to introduce a new way for users to install Foreman via containers (even if its possible) rather more as a development (or developers) tool.
This is bad. Wrong direction.
I'm more than happy to explain, Foreman currently has a robust installer and packaging system, simply moving to a container won't fully replace that required infrastructure, additionally, a lot of good people spend a lot of time managing those infrastructure, I really didn't want to send the wrong impression this is ready to replace all of the infrastructure in place.
Further, foreman has a pluginability model, that doesn't play nicely with containers, I believe we should explore that prior to making announcement to users, where I'm sure some of them will be surprised.
This is a first attempt to make developer see the value on containerizing foreman, without that, I don't think it would be possible to continuing in this path...?
BTW: This is a discussion that should be on foreman discourse, as if other feels like you, maybe its fair to challenge the existing workflows/tools/deployment models etc.
I'm glad you think that way. I fully agree on your approach. Just wanted to make things clear (for people thinking, 'that was it').
The Foreman installer is certainly an old-school approach that needs an overhaul (read: to be replaced). This was great for 1999-style automation, but the world around us has changed.
And yes, I posted this here - as some initial thoughts -, probably for the same reason why you're tackling the first step only for now. :smirk:
I don't feel like going into discussions with the RedHat-ty mindset now (the world should be all monoliths, enormous slow infrastructure is fine). I may do this later, one day. -- Sorry, if I hurt someone's feelings saying that; just a very personal impression.
You definitely didn't hurt my feelings and I'd still prefer you open this up on Foreman discourse :-) Not all Foreman devs are from Red Hat.
Honestly speaking, I think we as a Foreman community need to hear this feedback, to even think about it. Without it, we don't know what to focus our time on and just guess. If you start the discussion, great, in the worst case, we'll see if there's something really preventing us to move towards immutable infrastructure model.
Congratulations on the progress in theforeman/foreman! That really looks promising.
Looking at the related documentation the efforts of this project here seem to have been superseded now. :+1:
Ohad Levy has just announced that a "Dockerfile is now included in foreman core" and "a docker-compose ready to use production environment you can deploy". That sounds like exciting news!
We should review that setup, ensure that it's concise, sufficiently simple and complete. And maybe contribute in a way that a warning à la "Please don’t use it for real production environments" is not needed anymore.
If it makes sense we may include a reference on that thing in the README of this repository.