Ansible 0.8 plans

Archives Ansible Project
1

Ansible 0.7 was codenamed "Panama" and was largely about
orchestration/deployment features and extensibility.

Ansible 0.8, appropriately, will be called "Eruption", and will take a
bit different form than previous releases. There's a good chance it
might take longer than our usual 1-month iteration.

Why?

I'm actually going to start a GUI for Ansible. While we'll take other
pull requests as this occurs, the main focus will be on this new tool,
aimed at making it easy to visualize both your ansible setup and the
history of your ansible usage. Often a UI is a bottleneck that
restricts adoption of new tools -- even very simple tools like
Ansible, and even when they aren't, they can be nice to have. I'm
certainly more of a visual learner and I'd love to be able to explore
my inventory and playbooks in different ways.

Features will include:

* Beautiful web design that makes you want to lick your screen
* Add groups and subgroups, edit group and host variables, add hosts
to groups, etc
* View the results of previous playbook runs
* See a very easy dashboard of what nodes in your infrastructure have problems
* Look at shiny charts and graphs
* Trigger your playbook executions -- probably a future release and not in 0.8
* Team oriented management -- Take comments about your groups, hosts,
and playbook executions
* Do it all via REST or the UI -- the UI will only speak via REST
* ansible integration implemented via multiple plugins, rather than
any modifications on ansible-core

This will be a seperate project, not required for ansible usage, and
will be delivered along with a couple of ansible plugins
for wiring it up.

Technology choices -- Python and Javascript:

* Microframework -- Flask -- http://flask.pocoo.org/ seems to be the new hotness
* DB layer -- PostgreSQL -- we need to assume untrusted local clients,
so NoSQL options are unfortunately out
* UI layer -- Foundation -- Probably trying out
http://foundation.zurb.com/, Twitter Bootstrap if that doesn't work
out
* Protocol -- JSON/REST only

If I can get away with it, the web application will be essentially
purely DHTML and not use any templating engines, so literally
everything will be driven through the REST API.

Comments, questions, and ideas are all welcome.

--Michael

2

* Beautiful web design that makes you want to lick your screen

A new Logo is definitely required for Ansible to attain
world-domination. The current '90s design is, well, how shall I phrase
this politely... ? I won't.

Does anybody on this list know a good graphics designer who'd contribute
a design of a logo to a really cool Open Source project? Maybe Ansible
could get a logo that way... (Final decision to be taken by Michael
obviously.)

Just a thought.

        -JP

N.B.: I'd be willing to contribute in the form of an autographed
      hardcopy of my book [1] (including surface postage) if that
      helps... (but that's only really useful only to DNS aficionados)

      [1] http://mens.de/:/book

3

Hi Michael,

That’s very nice feature to have. I hope you can stick with your first “Key Feature”

→ Dead simple setup (and upgrade)

Regards,
Gerrit

4

I like these choices. How about ember.js or backbone.js on top of Foundation for the front end?

Why untrusted local clients? Surely Flask does authentication, and all communication to the DB happens through it? I think the simpler the setup, the better, and there are easier options.

Congrats on the release, by the way!

  • Mark
5

* Microframework -- Flask -- http://flask.pocoo.org/ seems to be the new
hotness
* DB layer -- PostgreSQL -- we need to assume untrusted local clients,
so NoSQL options are unfortunately out
* UI layer -- Foundation -- Probably trying out
http://foundation.zurb.com/, Twitter Bootstrap if that doesn't work
out
* Protocol -- JSON/REST only

I like these choices. How about ember.js or backbone.js on top of Foundation
for the front end?

I was looking for something like this, yeah. I will definitely be
needing some help when we get to starting the Javascript side of
things.

I've built out some Javascript architectures in the past, but nothing
this modern.

Sounds fantastic.

Why untrusted local clients? Surely Flask does authentication, and all
communication to the DB happens through it? I think the simpler the setup,
the better, and there are easier options.

Flask totally does authentication.

Riak and Redis will let you send things to the datastore on 127.0.0.1
all day though -- the problem is only with the datastore.

Correct me if I'm wrong, but SSL in Riak is only in the commercial
version and the free versions
expect trusted infrastructure.

When we want people to be able to log in to the machine running the
GUI, that's a bit of a problem.

We could require a seperate machine, but that is not something Ansible
should strive for, IMHO.

6

BTW, any experience with http://angularjs.org/ ?

At least with their "This is cleaner than JQuery" demo it also looks
pretty useful.

7

BTW, any experience with http://angularjs.org/ ?

NB: complete JS interface can generate problem, I think is better to
create static docs (eg. with jekyll/octopress) and add some JS feature
to improve usability (g. module search from list, ..)

At least with their "This is cleaner than JQuery" demo it also looks
pretty useful.

You can also take a loook to spinejs/backbone projects to create full
JS interface.

Bye
       Marco

8

It's ok. It also came from cooltext.com, and I paid exactly $0 for it.

That being said, if someone wants to contribute some leading-edge
graphic design to the project, I'll love you for it. Email me off
list and we can bounce some ideas around.

--Michael

9

A most interesting and ambitious plan. Looks of thoughts to share outloud.

Been looking for an excuse to dive in to this one.

  • DB layer – PostgreSQL – we need to assume untrusted local clients,
    so NoSQL options are unfortunately out

Just out of curiosity, what will the database be used for? Ansible currently does not require a database though they can be integrated without too much hassle. We find that very attractive.

Like Flask, I’ve been looking for a reason to dive in to Bootstrap and backbone.js (mentioned later in this thread). Foundation looks good, but I’m a bit wary that I haven’t heard more about it. Until I took my current gig a year or so ago, I was in web application development for 12 years. I still follow what’s going on in that space pretty closely. The community is one of, if not THE most important aspect to whether an open source project “succeeds” as in adoption and continued development. (This bodes very well for Ansible.) Somewhat remarkably, superior technology design has less impact. (Otherwise PHP and Wordpress should have been abject failures.) This is why I’d recommend giving Bootstrap a go before Foundation. Not that Boostrap’s design is lacking (I haven’t done a comparison) it’s that quite a community has grown up around it in a short time and there numerous screen-licking themes, tools and tutorials being release all the time. For instance…

http://bootswatch.com/
https://wrapbootstrap.com/
http://coenraets.org/blog/2012/02/sample-app-with-backbone-js-and-twitter-bootstrap/
http://www.alistapart.com/articles/building-twitter-bootstrap/
http://www.webappers.com/2012/09/06/10-new-professionally-designed-admin-templates/ (See #1 & #2)

  • Protocol – JSON/REST only

Excellent. I’ve been a pretty hardcore about REST for years.

Is the UI going to be a separate repo or part of the same code base?

10

Redis does support AUTH headers for basic authentication, but yeah, it may not be the best choice because it kinda wants to be in a trusted environment.

My suggestion is to use an abstraction layer, and by default use something super lightweight like SQLite 1, which will have zero setup cost for the user. Then, if a power user wants to run the DB in Postgres, they can configure that. Since the site won’t ever need to scale, SQLite is a good choice I’d say.

I’m not entirely sure what your best library choice is for abstraction - Python must have something, though.

  • Mark
11

Just out of curiosity, what will the database be used for? Ansible currently
does not require a database though they can be integrated without too much
hassle. We find that very attractive.

When using Ansible with the classifier system, rather than having the
UI interfact with the inventory file(s) directly, we'll have an
external inventory script (aka plugin)

This will source inventory out of a database.

This will be followed up with a callbacks plugin to log playbook/host
history in the same database.

Ansible by itself will not require this.

* UI layer -- Foundation -- Probably trying out

http://foundation.zurb.com/, Twitter Bootstrap if that doesn't work
out

Like Flask, I've been looking for a reason to dive in to Bootstrap and
backbone.js (mentioned later in this thread). Foundation looks good, but I'm
a bit wary that I haven't heard more about it. Until I took my current gig a
year or so ago, I was in web application development for 12 years. I still
follow what's going on in that space pretty closely. The community is one
of, if not THE most important aspect to whether an open source project
"succeeds" as in adoption and continued development. (This bodes very well
for Ansible.) Somewhat remarkably, superior technology design has less
impact. (Otherwise PHP and Wordpress should have been abject failures.) This
is why I'd recommend giving Bootstrap a go before Foundation. Not that
Boostrap's design is lacking (I haven't done a comparison) it's that quite a
community has grown up around it in a short time and there numerous
screen-licking themes, tools and tutorials being release all the time. For
instance...

I'm not sure I buy the community size theory. If I chose popular, I'd
have to pick PHP. Then I'd have to shoot myself. I'll pick whatever
makes me happier in the end.

I'll probably start down the foundation road, since I like their
marketing/docs literature, and see if I don't like it later -- if I
don't like it, I won't use it.

Regardless, evolutionary software progress requires mutations and
experimentation.

Is the UI going to be a separate repo or part of the same code base?

One repo for the both the UI and the Flask app. Repo will also
include one (and eventually more than one) ansible plugin.

12

[1]: http://flask.pocoo.org/docs/patterns/sqlite3/

I'm wanting to play with PostgreSQL hstore here, where sqlite3, while
otherwise fantastic, does not appear to offer ability to index JSON
blob columns.

--Michael

13

On the DB, I'm not sure if I'm not getting you or not buying it being required to have a GUI.

I'm not sure I buy the community size theory. If I chose popular, I'd
have to pick PHP. Then I'd have to shoot myself. I'll pick whatever
makes me happier in the end.

I feel the same way about PHP. I was not suggesting that community size is an absolute. It does mean more than any API features though. The MT made some poor choices in this regard and it became an albatross to contributions. Very few knew or cared to work with what made them happy and that created some real drag on its development and adoption.

One repo for the both the UI and the Flask app. Repo will also
include one (and eventually more than one) ansible plugin.

Hum, I'm of the mind that they should be separated.

I'm a big fan of web UIs, but let me play devil's advocate for a bit here. Does this UI have to be part of the core that it would/could delay/block 0.8?

It seems to me that the proposed UI should be a separate albeit very important and "official" extension of Ansible. I don't think everyone will need it -- as much as I've worked in web apps and UIs I have no use for it in my current work. I doubt that I'm entirely alone.

Others may also want to build their own UI for various reasons -- they've standardized on a different web/JS framework, they want to integrate it with an existing web app etc. It's been my experience that when the UI is developed as a separate code bases from the core (including web service API) the clarity of the code and API design is much better. It pretty easy to let UI concerns start seeping in to the core and vice versa even for the most dedicated and experienced developer. I'm not saying it's guaranteed to happen; it just takes extra thought and consideration to keep the two separate that sometimes is lacking when you're headlong in development. When they are separate that distinction becomes clear and obvious.

<tim/>

14

On the DB, I'm not sure if I'm not getting you or not buying it being required to have a GUI.

The REST service is going to require one whether you buy into it or not :slight_smile:

I'm a big fan of web UIs, but let me play devil's advocate for a bit here. Does this UI have to be part of the core that it would/could delay/block 0.8?

It seems to me that the proposed UI should be a separate albeit very important and "official" extension of Ansible. I don't think everyone will need it -- as much as I've worked in web apps and UIs I have no use for it in my current work. I doubt that I'm entirely alone.

I never said this would be part of the core. One repo for the UI and
the Flask portion -- "ansible-commander", but seperate from Ansible
core.

It could easily be two packages, but it will be one repo.

If you don't use it, don't use it.

That being said, this is hugely important, and it *will* potentially
block the 0.8 release and these two will share the same release cycle,
at least for the short term.

I anticipate some plugin improvements in core will be necessary to
support this project.

Others may also want to build their own UI for various reasons -- they've standardized on a different web/JS framework, they want to integrate it with an existing web app etc. It's been my experience that when the UI is developed as a separate code bases from the core (including web service API) the clarity of the code and API design is much better. It pretty easy to let UI concerns start seeping in to the core and vice versa even for the most dedicated and experienced developer. I'm not saying it's guaranteed to happen; it just takes extra thought and consideration to keep the two separate that sometimes is lacking when you're headlong in development. When they are separate that distinction becomes clear and obvious.

The only integration with ansible will be through the plugin system.

15

It's going to be fully dynamic, actually -- I'm going to do things
such that the UI is static and only requires Apache or Nginx (or
anything that can serve static content), and Flask only serves
"/rest".

In other words, there won't be an Flask side UI logic or content serving.

16

Sounds awesome! I just hope it doesn't slow down the development on
ansible (core) too much though. :slight_smile: .... After 0.8 though, it may
increase speed of development if more people are attracted to use
ansible due to the yummy UI.