Just realized that "tense" is probably not a good word because it has far too many meanings...ASX wrote:No tense, my English is far less descriptive than what I would like, as a result my sentences may sound like that.kraileth wrote:Mind the tense!
I meant the linguistic one, tense as in "present tense", "past tense" etc ("il tempo" if I remember correctly). What I wanted to say is: "intended" is talking of the past and no longer current.I admit that this may be the case most of the time. And if there was proper documentation for everything, that would be less of a problem. But imagine anybody quitting the project who built one system in the past. I hate inheriting undocumented stuff and I'm sure just about everybody does. I made a suggestion about documentation but so far this didn't lead anywhere. With salt everything will be next to self-documenting. That should be one of the best reasons right now. Most other benefits are in fact "maybe" benefits just in case the project grows in the future.But the meaning is correct, so far I fail to see any real benefit from saltstack adoption in this context.
Setup a system, for us in GhostBSD is mostly a one time job, and when that would need to be repeated it is very likely that there will be differences, one way or the other.
Another thing that I'm not sure I've mentioned before - and hesitate to do so now - is monitoring. Salt can also be used to monitor services and even react if some of them go down. Of course it can also notify admins. This is a field that I'd like to explore in the future but I haven't done anything with it, yet. Still I think it would be great to get notifications if the webserver crashed, the server load in extremely high or a jail is stopped.
It's looking far worse than it actually is. I can setup the SaltStack infrastructure in a couple of minutes (done that before). What is taking a fair bit more of time here is thatMaintaining the saltstack setup, in this case, to me look like an unneeded addtional work. I doubt you will be able to change my mind.
a) I want to use jail for everything but had very little experience in that field
b) I'm trying to use "masterless" SaltStack to bootstrap the actual SaltStack infrastructure. This is - I admit that - likely overkill (or perhaps even just a "stunt"). But the result is something that everybody else could use, too, and it's documenting how the whole thing works.
It's definitely a much different environment and I don't claim that we need configuration management or the whole project will blow up.(peraphs I'm already ìimprinted', in fact I built my IT career on top of customization and flexibility: custom systems, custom software, ad hoc services, fast responses and so on.)
I understood you work in a datacenter, I guess that there the use of saltstack could be much more productive, but we are a tiny project with a minimal infrastructure, quite a different environment.
Customization is nice and interesting. But there's this paradigm that whatever you do you're quite possibly not a snow flake and there are others that have at least similar requirements. And there's this saying: "Good coders write code. Great coders reuse code!". Unless you are only doing extremely specialized work it's very likely actually that you will be able to reuse parts of what you did before. Configuration management allows for this, too.
Just consider this: We continue down the road and put more and more services in jails. More jails means more update work. Updates can potentially harm previously good installations. Always knowing that you can get back to a known working state anytime with minimal effort is - at least for me! - a great thing. But hey, we'll talk about this again in a couple of months. Then you can have some hands on experience with the whole thing and we can make a decision then, ok?
I'm pretty sure that I can do the remaining work in a several hours but I don't know when that will be. And even less do I know when you or Eric have time to take a look at it. Since both of you don't seem to be extremely keen on getting it done, I've pushed the assumed schedule way back. That's all.