(A) I strongly disagree with the theory that CFEngine making them complicated means things need to be made complicated, or that by in any means we must be constrained by that legacy. Making simple things *sound* complicated when they aren't is not something we believe in.
(B) This list is really not the place to discuss other tool comparisons, there is a limitation in my ability to respond out of professional courtesy that limits my responses. (C) I'm not sure where you are going with "random feature gaps", it's much better if you be explicit and ask "how I can do X". It's a problem though when we're unable to communicate effectively -- so yes, when I ask that you simplify a conversation I'm doing that because I can't understand what you are trying to do easily. (D) "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." It's hard to tell what's a hypothesis and what's not, but like I said, nobody has to do that. You don't need to define one inventory file per service ever. You might wish to have seperate playbooks or something and a master site.yml that includes multiple versions of them. On Mon, Dec 2, 2013 at 12:54 PM, Paul Sokolovsky <[email protected]> wrote: > 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. > -- Michael DeHaan <[email protected]> CTO, AnsibleWorks, Inc. http://www.ansibleworks.com/ -- 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.
