Re: Wrapper roles and interchangeable services

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA512 On 2020-07-26 13:59, Maciej Delmanowski wrote: Hi Maciej You went to great detail to draft a proposal how to move forward. So detailed that I had to think about it for a bit. Back when I wrote the Apache role, I had the same need and I remember discussing this with you on some medium (IRC) that is not archived publicly. My idea back than was already to have kind of a meta role that encapsulates different roles that serve the same function. As far as I remember, you did not want to introduce this level of complexity back then. Anyway, lets reconside r. What I think is a big plus for the wrapper role construct is that we can avoid exploding of the number of playbooks. As you already said, when we have one wrapper role (firewall), every application would need 2 playbooks. When we have another (webserver), we would need 4. You guessed it, exponential growth. Exponential growth is difficult to maintain/contain … Two playbook runs instead of one when one wants to switch to another alternative (ntp) in your case, instead of one with the user friendly all-containing ntp role currently is fine with me. The reason we are at this point is of course that DebOps is very configurable, compared to other projects which basically dictate how things are done. So this increased complexity is the price I guess we will have to pay. I don’t see a good way around this. Some things like Firewall config and Webserver will remain a matter of preference. Some input for how to design the wrapper role. Consider if common documentation can be shared as in only document it once in the wrapper role. This way it defines the "interface" (as in Java) of the wrapper role that would actually be implemented by the actual roles. That means of course that all alternative roles try to implement the same "interface" (needed/recommended anyway). We have extensive documentation, reducing redundancy should help us keep it maintainable. It still bugs me that I had to duplicate the nginx docs for apache ;-) A comment on the inventory approach. Possible but very custom. The wrapper role construct is something that I also come to naturally. My guess is that others would end up there as well when they would eventually come to a point where they need something like this. So my hope is that the wrapper role will receive more acceptance. Comments from someone "unbiased" ? :) And my take on what others are doing. You are right, I am not aware of others doing this dependency variable passing. But that is one of the things that make DebOps great for me. This really helps to deploy services. I don’t have to care about the host firewall or the webserver config for the application. The role contains sane defaults. Awesome. Also the official SaltStack formulas that I know of don’t handle webserver nor Firewall, so you have to do that yourself. So if you want, feel free to explore the wrapper role idea and see how to work around the shortcomings of Ansible. Ideally we can resolve the Ansible shortcomings over time. For my taste we don’t have to keep supporting stuff we don’t use. About ntp roles: I don’t really see the need for ntpd (ntp.org) anymore. chrony supersedes it. I propose you drop ntpd support and see who screams and if they have good reasons for it :) Kind of similar with Apache except that there are still valid use cases for it, but not in DebOps main application stacks. I would not spend too much time on it. - -- Live long and prosper Robin `ypid` Schneider -- https://me.ypid.de/ -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEE7eE3HRuH0o2l6AUVhv2YC78aQPgFAl8fRDYACgkQhv2YC78a QPgUMg//acg6lMygCY+VWvXr81pn1Eo58VUuQz7wkw7AWZgGqyKw9wGWTd3jBFps 1sgQLitn2HQz1oxMdJ5khL+7DfEvJW+eUYHEgZdhIhyzeon1KhMwe6k1SsGxqR5I HRrRY0edUsMTQJRsmta5StBkxI024WwDaRIPAA4qzkSZxDDQ3c1Hm7IicEQFKs1u fNizYe7idJy6ROEf6G25DkIiy7fiTLdO1U8cKlrrRjCMqktgNffTfmoZyYF6Ek16 /NsJG7Y0T9bi+m1/SSfWIKEoiOrsnF2eFKbrVvhsUsoMa478BMg+T5Ih3rQ9nqLu FW2iR+IMWXlu+ZBBQSh65V73l65vDygmxc3qEBuAkxLWKrO0hwAJlN2CughTvdD2 C8X0XxZ3BXhv/EuwqnOB2JdRTjvCQxBPwU2+G4/PMmz9xcIQKdF01m+Vt14MTdbG z4uZqdXk3EP58wij0ci118JBqcGR1/FmtymPf6xO2RQJAKhanIEBuD/kmNtLbHXr MkWGA3COVefXdXJ2x21iNn6Hru5Tld/39XcPHUAcu58gA/Ka3gOqte8j73x8NGly kCtLCI2oQLI9Am8GjENvKxdpNzy1yr7liELuTS572DuCDzyk+o/Xj+GK1EXYkl5v 2FRGQP0y4/ozZK0v6Ev4F+aDodqvJOmPW+9AzdPErwTMEmJAUmg= =7lWl -----END PGP SIGNATURE-----