A few generations of DevOps teams down the road, no-one will be able to understand the ineffable contraptions of YAML-serialized control flow that somehow, magically, manage to stand up infrastructure made of reams of incomprehensible Cloud 4.0 service components that will be, at the very minimum, absolutely required to host a static website.
But it won't matter, since our benevolent robotic AI overlords will create them for you, the certified IBM Project Wisdom(TM) Prompt Engineer, dual-classed to Tech-Priest (but without any Warp to go mad in - that, you will have IT for).
I do not understand the incentive for this "Project Wisdom". From the official description in the project's home page:
> Project Wisdom will be able to read plain English entered by a user, and then generate automation content written in the Ansible syntax: Ansible Playbooks and Ansible Roles.
Do Ansible users really want to input plain English? I would not even know how to say what I need: "make sure journald is persistent, up to 1GB, then install zsh with my laptop config if it's in a laptop group..." That's awfully imprecise. Nobody wants to program in plain English. And the more technical the task, the less suitable plain English becomes.
And even worse: the goal is to convert plain English into yaml "code", mostly to "make it easier for beginners to learn Ansible". I think it is not helpful at all to throw blocks of generated code to a beginner.
There's a reason the languages that followed COBOL ditched the faux natural language part of the syntax. The language is practical for what it does, but the syntax is impractical. The same thing can be said about SQL.
I found it ironic when viewing the live demo on stage that the examples produced didn't have "FQCN"s (full names for modules, like ansible.builtin.copy), but rather shorthand names (like "copy") even though Ansible's lint tool will complain if you use the latter.
That's likely because the training data is Ansible Galaxy, and the vast majority of existing code doesn't use FQCNs. I still prefer not to, since it adds visual clutter to the playbook (not to mention a tiny bit of extra typing even with autocomplete), and playbooks work exactly the same 99.999% of the time.
Someone mentioned they were considering adding more lint-friendly inputs into the model, but as with all things AI, the way it's done could badly affect the output, too.
I still don't feel like there's a ton of value from any AI-driven code completion tools... writing out code (especially the initial bit) is often the first 1% of work when venturing out into new programming or automation work.
my only takeaway from this is cringe. IBM did the same thing with Watson for about a decade. find $thing, cobble watson onto it, gin up a presser, and kick it onto the stage to be unceremoniously ripped apart by the jackals of reasoned thought on places like HN whilst cloistered C levels gobble it up like a can of Dinki Di in the wasteland of AI/ML.
IBM nerfed Ansible when they pulled the community packages off it and made them a paid premium in their Red Hat Enterprise Linux. ansible-core, as they call it, is like a shaved cat: newcomers are going to find it offensive whilst veteran cat enjoyers are going to call it out for what it is and shame you for the misplaced effort with a set of shears while they download the EPEL fur you tucked under the couch cushions.
The reason we did ansible is because we dont have a good product that competes with Github...either that or the tech writing team is particularly bad this year after the recession cuts.
> IBM nerfed Ansible when they pulled the community packages off it and made them a paid premium in their Red Hat Enterprise Linux.
Ansible was split into Ansible Core and the separate collections to separate the lifecycle of collections from Ansible itself. It was not a nerfing of Ansible by IBM. You as an admin get to pick which collections and which versions of said collections fit your needs best, rather than having to wait for new Ansible versions to be released. This is the same argument developers have in programming languages about standard libraries, you can either have a relatively large one (Python) that changes slowly, or a small one (Rust) where libraries are offloaded to the ecosystem and nobody can agree on what's best.
In RHEL, Ansible Core is only provided (in the support sense) for the use with RHEL System Roles (upstream: linux-system-roles). It still provides all the same pieces to do normal Ansible administration workloads. You don't need the EPEL Ansible package unless you want the massive standard library. Full Ansible support is provided by Ansible Automation Platform subscriptions.
I'm interested to see how this works out because unlike Copilot where you're "merely" writing pieces of regular code, Ansible is uniquely in a position to trash your entire network and operations, making correct operation absolutely essential. The stakes seem very high to me.
(Disclosure: I work for Red Hat which was acquired by IBM, but not on anything related to this)
I'd rather iterate over bugs in Ansible code that I created directly than fear some AI will get something I said/typed wrong and completely break my production environment. It's the kind of work you need checks/validation on your thoughts rather than mindless bootstrapping.
Anytime I would typically be reaching for a shell script of medium to long length, it's typically easier to maintain in Ansible.
But, if I find my Ansible is getting rather long, I need to do things more complicated than simple loops, or there isn't an Ansible primitive to interact with the system I'm working with... time to start reaching for an actual programming language like Python or Go.
I gravitated to Ansible because it was language independent, simple to translate line-by-line scripts and didn't require an on server agent to work. Knowing that I could invest into Ansible and take it with me anywhere that I had SSH access was very motivating.
It's not perfect, but it's so much better than my previous experiences that I won't complain about the pain points too loudly.
Yes, this is 100% possible with the core ansible toolkit.
I don't have a copy of any of our playbooks on this as I'm at home and it's late. But it's basically just a couple of tasks.
Check out `ansible.builtin.pip` to setup and install the virtualenv and then just call `ansible.builtin.command` to run it explicitly. Implicit use of the venv can be accomplished via common task argument `env` which also lets one fiddle with PATH.
I don't like it much at all. I see the value of idempotency and so on, but it is a terrible "language" shoehorned into yaml. I am now migrating my home Ansible scripts to Nix and I won't look back.
I find it annoying that they've apparently chosen to rebrand it. It used to just be called "Ansible". Just because Red Hat sponsors it, doesn't mean it's name has to change. It's not a UK football ground (whose names change depending on which middle-eastern despot funds the resident club).
Readit News
But it won't matter, since our benevolent robotic AI overlords will create them for you, the certified IBM Project Wisdom(TM) Prompt Engineer, dual-classed to Tech-Priest (but without any Warp to go mad in - that, you will have IT for).
> Project Wisdom will be able to read plain English entered by a user, and then generate automation content written in the Ansible syntax: Ansible Playbooks and Ansible Roles.
Do Ansible users really want to input plain English? I would not even know how to say what I need: "make sure journald is persistent, up to 1GB, then install zsh with my laptop config if it's in a laptop group..." That's awfully imprecise. Nobody wants to program in plain English. And the more technical the task, the less suitable plain English becomes.
And even worse: the goal is to convert plain English into yaml "code", mostly to "make it easier for beginners to learn Ansible". I think it is not helpful at all to throw blocks of generated code to a beginner.
People have wanted that since at least as long as cobol has been a thing.
That's likely because the training data is Ansible Galaxy, and the vast majority of existing code doesn't use FQCNs. I still prefer not to, since it adds visual clutter to the playbook (not to mention a tiny bit of extra typing even with autocomplete), and playbooks work exactly the same 99.999% of the time.
Someone mentioned they were considering adding more lint-friendly inputs into the model, but as with all things AI, the way it's done could badly affect the output, too.
I still don't feel like there's a ton of value from any AI-driven code completion tools... writing out code (especially the initial bit) is often the first 1% of work when venturing out into new programming or automation work.
IBM nerfed Ansible when they pulled the community packages off it and made them a paid premium in their Red Hat Enterprise Linux. ansible-core, as they call it, is like a shaved cat: newcomers are going to find it offensive whilst veteran cat enjoyers are going to call it out for what it is and shame you for the misplaced effort with a set of shears while they download the EPEL fur you tucked under the couch cushions.
The reason we did ansible is because we dont have a good product that competes with Github...either that or the tech writing team is particularly bad this year after the recession cuts.
Ansible was split into Ansible Core and the separate collections to separate the lifecycle of collections from Ansible itself. It was not a nerfing of Ansible by IBM. You as an admin get to pick which collections and which versions of said collections fit your needs best, rather than having to wait for new Ansible versions to be released. This is the same argument developers have in programming languages about standard libraries, you can either have a relatively large one (Python) that changes slowly, or a small one (Rust) where libraries are offloaded to the ecosystem and nobody can agree on what's best.
In RHEL, Ansible Core is only provided (in the support sense) for the use with RHEL System Roles (upstream: linux-system-roles). It still provides all the same pieces to do normal Ansible administration workloads. You don't need the EPEL Ansible package unless you want the massive standard library. Full Ansible support is provided by Ansible Automation Platform subscriptions.
I'm interested to see how this works out because unlike Copilot where you're "merely" writing pieces of regular code, Ansible is uniquely in a position to trash your entire network and operations, making correct operation absolutely essential. The stakes seem very high to me.
(Disclosure: I work for Red Hat which was acquired by IBM, but not on anything related to this)
Anytime I would typically be reaching for a shell script of medium to long length, it's typically easier to maintain in Ansible.
But, if I find my Ansible is getting rather long, I need to do things more complicated than simple loops, or there isn't an Ansible primitive to interact with the system I'm working with... time to start reaching for an actual programming language like Python or Go.
I gravitated to Ansible because it was language independent, simple to translate line-by-line scripts and didn't require an on server agent to work. Knowing that I could invest into Ansible and take it with me anywhere that I had SSH access was very motivating.
It's not perfect, but it's so much better than my previous experiences that I won't complain about the pain points too loudly.
- create virtual env
- activate and install pip packages
- run command using that environment
I don't have a copy of any of our playbooks on this as I'm at home and it's late. But it's basically just a couple of tasks.
Check out `ansible.builtin.pip` to setup and install the virtualenv and then just call `ansible.builtin.command` to run it explicitly. Implicit use of the venv can be accomplished via common task argument `env` which also lets one fiddle with PATH.
What?