Hacker News Reader

Comment by spydum | Hacker News Reader

I... don’t get the use case for this? What am I missing?

To me it looks like a REPL for Ansible. If it does let you build each task in a cell then you could develop the whole playbook interactively and incrementally. It could reduce the turn around time of having to run a long playbook and waiting till the latest step you wrote.

Doesn't ansible core have ansible console already? This seems very bizarre and solution in search of a problem. An alexa skill for ansible would be interesting, but I wouldn't use it, either.

edit: https://docs.ansible.com/ansible/latest/cli/ansible-console.... "REPL console for executing Ansible tasks."

What Jupyter (regardless of its kernel: Ansible, Python etc...) does is just adding a GUI interface on top of an existing REPL console you mentioned. For example, you already have a working iPython REPL console, you don't really need the heavy Jupyter system to run scientific Python codes.

If you prefer to use the REPL consoles directly for your own propose then Jupyter will add no value on it. However, Jupyter let you save results for each commands without running them again, and you can add Markdown documentations. This is useful when you want document your codes (with results) and share them with others.

Jupyter is merely a productivity tool like an IDE, not a framework. Jupyter may not be suitable for running production codes anyway.

That makes sense, but you could also just tag that step and run it with the tag if you are testing it.

Notebooks allows you to have snippets of code next to the historic results of their execution

It is not just litterate programming, but more like an IDE that does not require your code to keep working (CI/CD... ) : you can refactor at your own pace, iterate, introspect past results, etc.

You prototype like crazy, iterate much faster, and can tweak much more.

However, notebooks are not popular with many programmers. They stick to IDEs. Their loss.

This isn't data science. The output of a playbook is dependent on a huge amount of external dependencies and state, and the execution can conditionally depend on that. Maybe programmers should use notebooks more (and I have no opinion on that) but this isn't a situation where they would confer much benefit.

I have more of an opinion there: Maybe programming should be more like data science. Prototypes are thrown away, but must exist at one point. They should be encouraged - like versionning, it is part of a core of good practices that admit few exceptions

External dependencies, state etc will all be handled, once excution is ironed out

Sure, but that's not super different that series of commits along a feature branch. I think they accomplish the same goal. But am not dismissing notebooks as a way of doing that. I'm more familiar with ipython than jupyter, but particularly for more algorithmically complex programming tasks I think notebooks are a good tool.

I disagree with you only that this might be a good way of prototyping for something like ansible playbooks/modules, chef recipes, puppet manifests, etc. So much of the state is external (and intrinsic to what is being built) that I don't think it's a match of the rhythm of development there. But just my two cents, the best process is what works for you.

I agree with you, ansible may not be the best showcase of the notebook (much is external) but I think it still remains practical for prototyping: I consider the notebook as a giant notepad, that shows you at the same time your code and the results of the code - in multiple versions, as many as tabs. Better than tabs, or terminals

I suppose it's a nice interface, like Ansible Tower.

Reply on news.ycombinator.com