Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Red Hat is buying Ansible

venturebeat.com

Post reply on HN
Print view View original

131–140 of 186 posts

Re: Red Hat is buying Ansible

#132

Post by zeveb »

Jweb_Guru wrote: post #112
TeMPOraL wrote: post #49

Earlier quoted context omitted.

That's people constantly reinventing Lisp, refusing to use the right tool for the job. Greenspun's Tenth Rule also comes to mind.

Lisp is not and has never been the right tool for configuration management.

> 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... (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.

Re: Red Hat is buying Ansible

#133

Post by SEJeff »

dorfsmay wrote: post #117
leg100 wrote: post #26

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.

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 o…

""" 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 %}

Re: Red Hat is buying Ansible

#134

Post by piffey »

atsaloli wrote: post #76
xorcist wrote: post #20

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?

Speaking of mature, CFEngine has been around since 1993 and is now in its third generation. I just wish they would do a little marketing.

Have you had to use CFEngine in production though? It's atrocious.

Re: Red Hat is buying Ansible

#135

Post by notacoward »

gnurag wrote: post #111
chr15p wrote: post #35

Earlier quoted context omitted.

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.

Gluster has always been an OpenSource project IIRC.

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.

Re: Red Hat is buying Ansible

#136

Post by sbierwagen »

WestCoastJustin wrote: post #58

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-ansibl... https://sysadmincasts.com/episodes/45-learning-ansible-with-... https://sysadmincasts.com/episodes/46-configuration-manageme... https://sysadmincasts.com/episodes/47-zero-downtime-deployme...

Wow, what's with all the spammy replies to this comment?

Re: Red Hat is buying Ansible

#137

Post by pm90 »

KarlPlatt wrote: post #78

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.…

If you're using Ansible for orchestration, you could try using the cloud's orchestration service instead. e.g. Rackspace Cloud Orchestration, AWS Cloudformation etc. In this specific case, you can use the orchestration api to spin up and manage the servers, and use ansible to manage the software (although there is a way to manage software as well [0]; I'm just not familiar enough with it to suggest it)

Disclaimer: I work in the Cloud Orchestration team at Rackspace.

[0]: https://github.com/openstack/heat-templates/tree/master/hot/...

Re: Red Hat is buying Ansible

#138

Post by justingood »

superuser2 wrote: post #118
mattzito wrote: post #55

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…

I really don't understand why an organization would want to use Docker (besides buzzword compliance) if they were planning on mutating running containers. What's the advantage?

I think one thing to keep in mind about Ansible is that it's an orchestration tool that also does configuration management. We've integrated Ansible into our workflows in such a way that it kicks off everything we need to do, even if that involves just coordinating some info between APIs. We don't mutate containers at all - merely get Ansible to make things happen around their deployment and communication.

Re: Red Hat is buying Ansible

#139

Post by jalons »

bovermyer wrote: post #113
KarlPlatt wrote: post #78

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.…

This has been my experience as well. Even using a small subset of a playbook via tags can take a long time, especially if you're doing a run in serial. One of our deployments that only affects six servers takes fifteen minutes. This can be mitigated somewhat by putting Ansible on the target machine, downloading all the necessary files to that machine, and then running Ansible locally... but that seems awfully fragile…

Saltstack is moving away from ZeroMQ. https://docs.saltstack.com/en/latest/topics/releases/2015.8....

Re: Red Hat is buying Ansible

#140

Post by justingood »

SEJeff wrote: post #133
dorfsmay wrote: post #117

Earlier quoted context omitted.

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 o…

""" 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…

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
Post reply on HN