Hello, On Sun, 1 Dec 2013 09:28:15 -0500 Michael DeHaan <[email protected]> wrote:
> All of this pseudo-academic confusing language is going to prevent > most everyone here in holding a conversation with you. Well, I'll leave "pseudo" part on your side, but configuration management has always been subject of academic research - CFEngine and Quattor touted that they have research and formal proofs behind their way of organization and implementation. I'm all for KISS and "radically simple" approach, but not for oversimplification and random gaps in functionality. But all in all, I started my original question (https://groups.google.com/forum/#!topic/ansible-project/zsudA_fQshk) with pretty simple 4-point description of what I'd like to achieve, hope it's on its own is not confusing. > Your conclusion that you somehow need 100 inventory files is > completely strange -- nobody does that. That's somewhat oversimplified. I made a hypothesis, that if some services need to be independently deployed to the same host, that would require a separate host inventory file per service. I'm not sure that's best solution, asking for other ways to do it. > Concepts like a "service axis" and "ambigious localhosts" are things > you are creating in your own mind, they are not Ansible concepts, and > I think you're really making this all too hard. But we both came to conclusion that standard Ansible concepts like "host groups" don't behave in the way which would be enabling for implementation of that 4-point host schedule. And to understand why is that and what to do about it, it takes to introduce more higher-level/detailed concepts. I'm still learning Ansible, and would be glad to know better terms/approaches for it, and appreciate following thru this and helpful hints. > Apologies if I'm seeing an educational empasse, but all of the above > is totally not neccessary -- if you can't reset back to basic > concepts and try to solve simple problems simply, perhaps it's not > for you? Simple solution for simple problem sounds good, but what about more complicated problems? As for the last part, we had a pretty detailed comparison of Salt and Ansible, and current versions of Salt lose in ease of bootstrapping for development use (that's often overlooked with configuration management tools!). This specific issue is also unlikely to be handled there better - granted, it's somewhere on advanced end of ConfigManagement stuff (so I don't expect any simple magical solution). With that, I'd prefer to stay on objective side - what Ansible can't do, what can, and how. What's good for people they certainly can decide on their own ;-). -- Best regards, Paul mailto:[email protected] -- You received this message because you are subscribed to the Google Groups "Ansible Project" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. For more options, visit https://groups.google.com/groups/opt_out.
