7 ms·

Red Hat is buying Ansible

• leg100 11y ago
  This clearly is much more about Tower, consultancy, etc, than their main product, but their yaml encoded language is an abomination; masquerading as 'declarative' and easy to read, yet piling on loops and conditional statements and an unintuitive inheritance tree of global and local variables.
  • anton_gogolev 11y ago
    Spot on. I'm constantly amazed at how many projects use _serialization formats_ as a "programming language". LiquiBase, NAnt, MSBuild, Ansible.
    • raverbashing 11y ago
      Maven or pretty much anything XML based
      • reitanqild 11y ago
        In defense of maven it does provide neither branching nor looping statements so refering to it as a "programming language" is hard to justify.
        • collyw 11y ago
          Neither does HTML and the L stands for language.
          • detaro 11y ago
            "language" != "programming language"
          • executesorder66 11y ago
            Notice how the M stands for "Markup" and not "Programming"
      • roma1n 11y ago
        I haven't seen conditionals or loops widely used within Maven's XML.
    • crdoconnor 11y ago
      It can work but it works best when the language is kept dumb. A dumb declarative language is easier to understand and easier to maintain. It can be used to help maintain a strict separation of concerns. The smarter you try to make the language, the worse it becomes. Ant & MSBuild AFAIK are basically full programming languages in their own right so there was really no point to them actually being their own language.
    • TeMPOraL 11y ago
      That's people constantly reinventing Lisp, refusing to use the right tool for the job. Greenspun's Tenth Rule also comes to mind.
      • Jweb_Guru 11y ago
        Lisp is not and has never been the right tool for configuration management.
        • zeveb 11y ago
          > Lisp is not and has never been the right tool for configuration management. Why not? Configurations are collections of items, and among the things Lisp excels at is…lists of atoms. Take a look at https://github.com/ansible/ansible-examples/tree/master/lamp_simple https://github.com/ansible/ansible-examples/tree/master/lamp... (a simple LAMP stack implemented in Ansible). It uses a .ini-style file to manage lists of hosts, e.g.: [webservers] localhost [dbservers] bensible sensible Why not put that in a list? (hosts (webservers localhost) (dbservers bensible sensible)) The Ansible playbooks are YAML lists. There's no particular reason that: --- # This playbook deploys the whole application stack in this site - name: apply common configuration to all nodes hosts: all remote_user: root roles: - common … is more readable than: (playbook "This playbook deploys the whole application stack in this site" (play "apply common configuration to all nodes" (hosts all) (remote-user root) (roles common) …) or: (playbook '((all '(common) :user root :comment "apply common configuration to all nodes") …) :comment "This playbook deploys the whole application stack in this site") In fact, I'd argue that both Lispy representations are much more readable.
          • Jweb_Guru 11y ago
            Oh, I didn't mean to say that S-expressions can't be used for configuration. It's that in general you don't want a Turing-complete language to do configuration management, because you want to be able to reason about things like rollbacks, dependencies and diffs.
    • gerbilly 11y ago
      It seems like parsing is becoming a lost art. Maybe because it can't be easily approached by the iterative development style that is in fashion these days.
      • ufo 11y ago
        The real lost art here is scripting languages. Even if you parse things yourself, configuration files still have a natural tendency to evolve into a crappy programming language over time. So instead of writing your own config file format you should just make a couple a quick bindings for a scripting language like Lua, Python or Ruby.
  • bbrazil 11y ago
    Syntax and semantics are separate, not having to learn a new syntax is handy. Syntactically the problem I run into is that it's got it's own DSL in task definitions, so it can be hard to keep in mind what's YAML and what's the DSL. Semantically loops and conditions are essential features so I don't have a problem with that. The inheritance could use some clarification, I was hit last year by a regression that remains unresolved.
  • bryanlarsen 11y ago
    You missed the quoting mess, adding their own compact list and map grammar, the convention of having a comment on every line, and there's more I can't think of right now. I hate ansible, it's just better than any of the alternatives for different reasons. Luckily we're moving away from needing any of them. Scripting an image build is a lot easier than updating a machine using CI: you start from a blank slate every time, and an out of date script isn't the catastrophe it is with CI since you have the images saved.
  • dorfsmay 11y ago
    I think when ansible started it wasn't obvious that logic (loops, conditional etc...) would be needed eventually. By the time it became obvious it was going to be required, it was too late to change. Using jinja2 for markup compounded the issue in my opinion, as it has no loops and logic is less than obvious (compared to mako for example). Still I find its agentless model, the idempotent model, being able to use it on machines where you don't have root access etc... gives it a place that nobody had fulfilled.
    • SEJeff 11y ago
      """ Using jinja2 for markup compounded the issue in my opinion, as it has no loops and logic is less than obvious """ This comment makes pretty much no sense at all. Example of a loop in jinja2: {% for item in ("one", "two", "three") %} item is {{ item }} {% endfor %} The logic is pure python minus perhaps setting variables ie: {% set name = "dorfsmay" %} {% if name == "dorfsmay" or name.startswith("dorfs") %} You're spreading FUD about jinja2 {% endif %}
      • justingood 11y ago
        I'd agree that jinja2 has a perfectly fine way of handling loops, but the problem is that functionality only works in Ansible template files. The Ansible playbook can only make use jinja2 filters to act on variables: https://docs.ansible.com/ansible/playbooks_filters.html https://docs.ansible.com/ansible/playbooks_filters.html
        • SEJeff 11y ago
          Oh no disagreement there. I was just disagreeing with the GPs disparagement of jinja2, which is a limitation of how Ansible was implemented and has absolutely nothing to do with jinja2. Ansible is great stuff, but some of those decisions were quite weird.
          • d23 11y ago
            Jinja is great as a templating language. I find yaml by itself to be clean and readable. Cram all of it in to the same soup, mix in the global variables, and it quickly turns into a nightmare. It takes what's already a problem in a dynamically typed language and amplifies it.
• geerlingguy 11y ago
  Supposedly a > $100mm deal. Both companies are already headquartered in N.C., and Ansible has a ton of momentum in the RHEL and OpenStack arenas, so it would make sense to pull the project into the fold. One thing I wonder is how much the project's priorities would shift away from (if at all) anything non-RHEL-centric.
  • rodgerd 11y ago
    As a Red Hat customer I'll be interesting to see how it affects the complete fucking shambles that has been the Satellite 6 rollout, which was supposed to be full Foreman/Puppet integration for provisioning and config management. Apart from the fact that it's been a shambles, Red Hat have been solidly pushing customers down the puppet route. I expect there will be some grumpy meetings in the next few weeks.
    • dmourati 11y ago
      Consider yourself lucky in the long run.
    • tamasnet 11y ago
      Reminds me of their switch from Xen to KVM from RHEL 5 to 6, so I wouldn't put it past them to change course.
  • akurilin 11y ago
    Hopefully not too much, super heavy Ansible + Ubuntu user here.
  • creshal 11y ago
    > One thing I wonder is how much the project's priorities would shift away from (if at all) anything non-RHEL-centric. Going by projects like NetworkManager it'll work okay, but you'll need to be a paying RedHat customer to get any useful documentation.
• pdeva1 11y ago
  Wonder what caused such a high valuation. They definitely didnt seem to have enough revenues to justify it.
  • deleted 11y ago
    [deleted]
  • devnonymous 11y ago
    I would imagine it is not so much about Ansible's general valuation in the industry but about its value for Red Hat (a.k.a -- Red Hat is not buying Ansible for its revenues but for its technology).
    • marcoamorales 11y ago
      What are you buying when the technology is open source?
      • eeZi 11y ago
        The dev team?
      • bandrami 11y ago
        The team and the existing user base
      • deleted 11y ago
        [deleted]
      • devnonymous 11y ago
        The direction in which the technology evolves. That's also the reason why Red Hat hires a lot of upstream developers[1]. It is easier to tailor your services and offer better support (ie: the revenue stream for Red Hat) for OSS when the developers who write it are on your payroll. https://fedoraproject.org/wiki/Red_Hat_contributions http://www.redhat.com/en/about/blog/red-hat-leads-open-source-contributions-to-kernel
      • gsnedders 11y ago
• ptio 11y ago
  Ansible creator, founder and CTO Michael DeHaan previously worked at Red Hat where he helped build Cobbler.
  • srvg 11y ago
    FYI- A lot of Ansible employees have a Red Hat past. The lead developer James Cammarata has, and is also the current Cobbler maintainer.
    • jimi_c 11y ago
      This is actually my first stint at Red Hat - as the Cobbler maintainer I just kickstarted RHEL (and some VMware) boxes a lot for my day job.
  • srvg 11y ago
    Also, Michael DeHaan stepped down and left the company early 2015.
    • AhtiK 11y ago
      So this could explain why his very active github activities suddenly stopped early 2015, I just presumed it was due to consciously allocating more time for management and leadership. His github contributions rate and depth for ansible while still the CEO in y2014 has been a great inspiration for me.
• nzoschke 11y ago
  Ansible is best of breed. But didn't Red Hat hear? Immutable infrastructure is the future! http://michaeldehaan.net/post/118717252307/immutable-infrastructure-is-the-future http://michaeldehaan.net/post/118717252307/immutable-infrast...
  • awjr 11y ago
    I was using ansible with packer https://www.packer.io/ https://www.packer.io/ to build AMIs (Amazon Machine Images). I'm spending a lot more time with docker these days though. I see Ansible as primarily an orchestration tool.
    • Gigablah 11y ago
      You could still use Ansible with Packer, since Packer can build Docker images.
  • rdeboo 11y ago
    I can see how that would work for stateless services. Just build a new image and discard the old one. But what do you do when you want to change my MySQL config file? Create a new image and somehow transfer the data? Or are the datastores somehow externalized? Then how do you synchronize shutting down the old image, then starting the new updated one, preventing them from accessing the store at the same time? The linked article kind of waves these issues away ('externalize state in Cassandra or RDS'). Then am I supposed to use two mechanisms/tools to run my infrastructure? Docker for stateless servers and something like Ansible for stateful servers?
    • ABS 11y ago
      I interviewed a few folks on the topic some time ago and published the results here: https://highops.com/insights/immutable-infrastructure-6-questions-6-experts/ https://highops.com/insights/immutable-infrastructure-6-ques... I particularly like the definition that emerged: 'I see it as conceptually dividing your infrastructure into "data" and "everything else". Data is the stuff that's created and modified by the services you're providing. The elements of your infrastructure that aren't managed by the services can be treated as immutable: you build them, use them, but don't make changes to them. If you need to change an infrastructure element, you build a new one and replace the old one' More in the actual full transcript and in the video
• mianos 11y ago
  If ansible is worth 100 what is saltstack worth?
  • kzhahou 11y ago
    Are you implying it's worth more or less? Or not implying anything but hoping someone here has an answer or analysis?
    • mianos 11y ago
      saltstack is a bit harder to get started but it is, IMHO, a much larger product. I am implying saltstack should be worth more. That said, ansible may prove to become more popular and grow to be bigger than saltstack.
  • hyperliner 11y ago
    Probably depends on who needs it. With almost no revenues, then it makes monetization only possible through enriching some platform. Maybe other major distro vendors will look at Chef, Puppet and Salt now and find them more expensive. Here is the financial disclosure from RedHat. NOTICE THE FIRST SENTENCE. The acquisition is expected to have no material impact to Red Hat's revenue for the third and fourth quarters of its fiscal year ending Feb. 29, 2016 (“fiscal 2016”). Management expects that non-GAAP operating expenses for fiscal 2016 will increase by approximately $2.0 million, or ($0.01) per share, in the third quarter and approximately $4.0 million, or ($0.02) per share, in the fourth quarter as a result of the transaction. Red Hat calculates non-GAAP operating expense by subtracting from GAAP operating expense the estimated impact of non-cash share-based compensation expense, which for fiscal 2016 is expected to increase by approximately $1 million for each of the third and fourth quarters, and amortization of intangible assets, which for fiscal 2016 is expected to increase by approximately $1 million for each of the third and fourth quarters, in addition to transaction costs related to business combinations, which are expected to increase by approximately $1 million in the third quarter. Management expects GAAP operating expense to increase for fiscal 2016 by approximately $5 million, or ($0.02) per share, in the third quarter and approximately $6 million, or ($0.02) per share, in the fourth quarter as a result of the transaction. Excluding the operating expense impact as noted above to GAAP and non-GAAP operating margin and GAAP and non-GAAP earnings per share, Red Hat is otherwise re-affirming its fiscal 2016 third quarter and full year guidance provided in its Sept. 21, 2015, earnings press release.
• srvg 11y ago
  Wondering if RH will let Tower become Open Source.
  • KrestenKjaer 11y ago
    They have a strong tradition of opensourcing their products. So they most probably will.
  • chr15p 11y ago
    Red Hat has a history of buying closed source software and releasing it as Open Source (KVM, Gluster, Cloudforms etc) so I would expect Tower to be open sourced. Assuming Ansible have the rights to all the code of course and dont license it from someone else of course.
    • rch 11y ago
      It's a pretty straightforward Django app, so they could open it up without issue. They might be more inclined to roll the functionality into one of their other product lines though.
    • gnurag 11y ago
      Gluster has always been an OpenSource project IIRC.
      • notacoward 11y ago
        Correct. There was a time, pre-acquisition, when some separate management-console bits were not open source, but nobody cared about those bits anyway and now they're long gone. The "GlusterFS" file system part, which is the part everyone except one misguided CEO (now at Docker) cared about, has always been completely open source.
• xorcist 11y ago
  Interesting! Ansible is great technology. Not as mature as Puppet or Chef, but it's getting there. However Red Hat is currently heavily pushing (what I understand to be) their own fork of Puppet inside Satellite 6. So quite a few RHEL customers in the process of rolling out the latest Satellite is probably going to want to hedge their investment in it. Perhaps there is some Red Hatter here who could comment?
  • chr15p 11y ago
    Its not a fork of Puppet, Satellite ships with its own copy of Puppet (3.6 iirc) which it integrates to provide the configuration management side of the product but its stock un-modified puppet. In fact the puppet side of Satellite is built around Foreman (http://theforeman.org/ http://theforeman.org/) which is an open source project that isn;t Red Hat controlled so even if Red Hat wanted to move 100% to Ansible it would be very hard work for little gain. It would also be a really bad commercial idea Puppet is by far the market leader and most of their customers buy satellite precisely because it integrates with their existing puppet manifiests. So I expect Puppet to stay as Red Hat's goto configuration management tool, and ansible to be used more for its ad-hoc remote execution capabilities where puppet is nowhere near as good. RH already uses ansible in the installer for Open Shift for example because it can set up multiple boxes without needing an agent pre-installed.
    • xorcist 11y ago
      Oh, I understand it's stock Puppet inside the thing. But much of the tooling around it (the Hiera syntax, the dashboard, the DB) acts as an alternative to the tooling around Puppet. Satellite 6 and Puppet Enterprise are direct competitors, and there is not much further upstream development on Puppet 3.6, so I expect Red Hat to have to take on the necessary development work during the life time of the product. So, in essence almost a fork already, and in the future much more so. You already have to choose, you have to port your old codebase and tooling to one or the other.
      • eLobato 11y ago
        Foreman is working on Puppet 4 support [1], and I'd say we'll try to push it forward sooner than later as soon as we complete the migration to Rails 4. Foreman is the upstream for Satellite 6. [1] http://projects.theforeman.org/issues/8447 http://projects.theforeman.org/issues/8447
• carlsborg 11y ago
  Congrats mpdehaan2. Good to see good engineering getting rewarded. Testament to a great project you conceived and started.
• Schiphol 11y ago
  I found this sentence funny "Representatives of Red Hat and Ansible did not immediately respond to requests for comment". I take it to mean: "we wanted to run the story as quickly as possible; still it would have been nice to get superquick comments by RH or Ansible; tough luck, though."
  • dspillett 11y ago
    To me "did not immediately respond to requests for comment" smacks of neediness and self importance on the reporter's part (answer me now, you fools, don't you know who I am and what power I behold?!) and the people that would respond to such comments being in the middle of dealing with something more important at the time (perhaps answering a queue of queries that came in first, or queries from people who are more important to their world view). If I were RedHat or Ansible and read that sentence the reporter and/or outlet would be added to a "never respond to these people for at least 24 hours" list...
    • djloche 11y ago
      The appropriate line for online publication is "We reached out to both x and y for comment and will update this article with any responses we receive."
    • curiouscats 11y ago
      Those quotes are found in a huge number of stories. Sure you can blame them for a rush to publish if you want. I think mainly they are trying to indicate they reached out to a relevant party and didn't hear back. And by saying didn't hear back immediately they are making clear that it may well be the party wasn't immediately available (not that they were not willing to respond at all). On some (maybe all, I don't know) sites, they then update the story if they get responses.
    • jacques_chester 11y ago
      > answer me now, you fools, don't you know who I am and what power I behold?! Alternatively, "Answer me now, before someone else beats me to publication, oh god please ... c'mmooon it's almost deadline, pickuppickuppickuppickup ah dammit, too late."
• poooogles 11y ago
  This does make me wonder how it'll impact their eventual move to Python3. They've been hesitant to move due to a lot of their customer base being on RHEL5/CentOS5, I can't imagine that this move will help matters.
• devit 11y ago
  Every time I use some "configuration management" tool I wonder whether it's really better than just using shell. Basically you lose a lot of time searching the web for how to do things that you already know how to do in shell, but the benefits are not so clear.
  • ericcholis 11y ago
    I've kept an eye on https://commando.io/ https://commando.io/ for the same reason.
  • objectified 11y ago
    Well, one of the main advantages of using a configuration management tool is that the configurations you're writing are actually repeatable, and these tools tend to provide you with a lot of modules that take this in regard for you. If you were to use pure shell, you'd have to take a lot of things in account just to take care of this aspect alone. Also, these tools provide abstractions that make it easier to execute things as a unit (such as adding a user and a number of things having to do with it) without having to think about all the details. Often, they can be used on multiple platforms in the same way, too. So yeah, I do think configuration management tools solve real problems.
  • togusa 11y ago
    That's ok if you have a known good baseline configuration. In that case it's no different to say a Dockerfile. However the config management stuff seems to come to light when you've got a mess on your hands and need to rationalise it and make it consistent. I'm slightly leaning towards the "rebuild with known good baseline" state of affairs these days however even as a long time Ansible user. Rather than upgrade stuff, I build something new alongside and then do a switcheroo nearly every time. One day, hopefully containers will allow us to have consistent state everywhere.
  • pilif 11y ago
    I thought so too for a long time. Until that time when I upgraded the RAID10 on our database servers from a 4 drive to a 8 drive configuration (which requires rebuilding the whole array if you want the performance benefits). Getting the intricate configuration of the two machines (postgres streaming replication works, but has a lot of moving parts to keep in mind) back without having to remember any details was absolutely priceless. Completely wiping and reinstalling the main database servers (one after another of course) during the day while the system was in active use and completing the process with zero user intervention, that felt amazing. Since then, whenever I had to reinstall a machine for one reason or another, I always appreciated the immense speed-up I gained by not having to ever manually re-do the configuration. Better yet: All the years of growing the configuration, all the small insights learned over time, all the small fixes to the configuration: All are preserved and readily available. Even better: By using git, I can even go back in time and learn why I did what and when. "Why am I using TCP for NFS? Oh right - that was back in december of 2012 when we were using UDP and we ran into that kernel deadlock" - that's next to impossible to do when you're configuring servers manually.
• thejerz 11y ago
  Ansible is a fantastic tool. I put it up there with Rails, Backbone, and jQuery. The shadow of Puppet and Chef is large, but many are starting to see the light. I hope that Redhat will accelerate the growth of this very well engineered platform. Congrats to the Ansible team!
• mattzito 11y ago
  I think the price point here is about a couple of things: - Chef and Puppet are too expensive for most companies to acquire, and have too much operational cost for too little revenue - Ansible got a strong following in the SMB space, Red Hat probably thinks they can move that upmarket some - Ansible's agentless configuration management has potentially strong applicability in a container world (why do I need a chunky agent to configure resources on my docker image? What if, for some reason, I need to affect change on running docker images? - I realize this is a bit of an anti-pattern for docker, but it was something I heard a lot from big enterprises) $100m still sounds very high, kudos to the ansible folks who have come a long way in the last few years. EDIT: one more piece I didn't think of here - the openstack side of things is an area where Red Hat has made big long-term bets for the future of the company, and it probably helps to justify the price in terms of backstopping their openstack support.
  • mugsie 11y ago
    Yeah, OpenStack support will be a big thing for them I think. Ansible is growing its OpenStack support, and they might see an opportunity for the RDO product.
    • kashyapc 11y ago
      A minor nit-pick: RDO is community project :-) If anyone is wondering what the 'RDO' acronym stands for, from the FAQ[1]: "RDO has no expansion or longer name, officially. It is not an acronym or abbreviation for anything. However, RDO does focus on building a distribution of OpenStack specific to Red Hat operating systems (and clones of Red Hat operating systems). So, in some sense you can think of RDO as being a project started by Red Hat to build a distribution of OpenStack. The 3 letter meaningless acronym sort of comes from that line of thinking." [1] https://www.rdoproject.org/Frequently_Asked_Questions https://www.rdoproject.org/Frequently_Asked_Questions
  • walrus 11y ago
    SMB = small business?
• WestCoastJustin 11y ago
  If you're new to Ansible. I've created about two hours of free screencasts on it. It's a very simple to use and understand configuration management tool. https://sysadmincasts.com/episodes/43-19-minutes-with-ansible-part-1-4 https://sysadmincasts.com/episodes/43-19-minutes-with-ansibl... https://sysadmincasts.com/episodes/45-learning-ansible-with-vagrant-part-2-4 https://sysadmincasts.com/episodes/45-learning-ansible-with-... https://sysadmincasts.com/episodes/46-configuration-management-with-ansible-part-3-4 https://sysadmincasts.com/episodes/46-configuration-manageme... https://sysadmincasts.com/episodes/47-zero-downtime-deployments-with-ansible-part-4-4 https://sysadmincasts.com/episodes/47-zero-downtime-deployme...
  • TheRealWatson 11y ago
    Major kudos. These look awesome.
  • occsceo 11y ago
    thanks for putting these together
  • dethos 11y ago
    Thanks for the videos, I'm starting to learn it right now and they couldn't have come in a better time.
  • dadoprso 11y ago
    Solid site, added it to my Feedly.
  • kangman 11y ago
    yeah really helpful. I paid for these lessons and Justin was kind enough to refund me the cost when he moved on to Docker.
  • sbierwagen 11y ago
    Wow, what's with all the spammy replies to this comment?
    • 11y ago
• qznc 11y ago
  I always wonder why cf-engine is so unpopular on HN. It has some nice advantages like no dependency on ssh or a scripting language. It is not as simple to get started, though.
  • atsaloli 11y ago
    I'm working on a CFEngine Tutorial to help people get started. I was inspired by Michael Hartl's "Learn Enough Tutorial Writing To Be Dangerous" talk at LA Ruby Conf to finally turn my CFEngine course materials into a book. It'll be my first commercial product so I'm excited! Edit: added link to mhartl's tutorial: http://www.learnenough.com/tutorial-writing http://www.learnenough.com/tutorial-writing
  • betaby 11y ago
    As a former user of puppet and chef, I would say cfengine has a higher entrance brier. It pays the efforts thought.
  • ybx 11y ago
    Is SSH really a dependency you have to worry about though? Basically every server out there runs SSH.
    • bovermyer 11y ago
      SSH's major problem here is performance. When you need to orchestrate dozens of servers with many separate tasks, then the slowdown is very noticeable.
• maweki 11y ago
  I think that this will fit nicely with the Cockpit project which should "revolutionize" remote administration (it isn't bad). So now Red Hat wants to add something for wholesome orchestration, which was really needed in that space.
• KarlPlatt 11y ago
  My experience with Ansible has not been so pleasant. Especially performance is a jobstopper. In my environment it takes 20 min for 12 Servers to be setup with some Redis, Elasticsearch stuff. Quite some become_user directives, but 20 min for this kind of stuff is just not acceptable. After all, application settings needs to be tuned and iterated over, too. My idea was to develop the infrastructure with Ansible, e.g. no ssh to change some httpd settings at all. Everything via Ansible. It worked very well as long as the playbooks and number of servers was very small.
  • crdoconnor 11y ago
    >After all, settings needs to be tuned and iterated over, too. That's why it has tags. So you can run just the settings states rather than running the whole 20 minute thing over and over again.
    • falcolas 11y ago
      You can just run portions of the playbooks, but then you lose the value of a descriptive infrastructure. What does X look like? Depends on when each tag was run.
      • crdoconnor 11y ago
        It shouldn't unless you're very careless. A tag that just updates all of the settings files and restarts the services should have the same effect as the full playbook run.
        • falcolas 11y ago
          And if you add a new machine to the cluster, which hasn't gotten all tags run against it? Or of a machine was temporarily offline when a tag was run, or... There are many potential situations where not running a full inventory against a running machine results in a machine not being properly configured.
          • 11y ago
• tomaac 11y ago
  It is official now https://www.redhat.com/en/about/press-releases/red-hat-acquire-it-automation-and-devops-leader-ansible https://www.redhat.com/en/about/press-releases/red-hat-acqui...
• lvandeyar 11y ago
  I hope they don't kill the free version of Ansible!
  • MrOwen 11y ago
    Has Red Hat ever done this with anything? I think a lot of their products exist as open-source versions. Satellite -> Katello, OpenShift is open-source, CloudForms -> ManageIQ, Red Hat Identity Management -> FreeIPA, RHEL -> CentOS. I suspect the list goes on and I have a hunch they will open-source Tower in the near future.
• homulilly 11y ago
  I like what I've seen of ansible but a lot of their modules are a complete mess. I've run into problems with both their AWS and Docker modules and ended up resorting to a series of tasks running shell commands because it was more reliable and didn't require me to install a specific version of some python library on every single machine.
• JanusBifrons 11y ago
  Hi all. I am a GM at Red Hat, and I have been deeply involved in the acquisition of Ansible. It's great to see so much interest and so many good questions. I hope that my blog post can help answering some of them: http://www.redhat-cloudstrategy.com/why-did-red-hat-acquire-ansible/ http://www.redhat-cloudstrategy.com/why-did-red-hat-acquire-... Alessandro