Refactor the world

[jbergstroem]

At some point, this will hopefully happen. The main objective is to streamline the way we deploy services by not abstracting per operating system, but per task.

This refactor lacks a lot of things and are even getting out of date in corners; but we need more people than me spending time on it, so I'm submitting it for review. It's pretty fancy in some areas, providing scripts to manage your ssh config, validate inventory and separate bootstrapping machines from job-specific tasks.

I guess the best way to get an insight into "todo" would be reviewing README.md. Nevertheless, hopefully this PR can lead to a merge in a month or three -- even without reviews I know I'll sleep one hour less knowing it's up critique 😄

Also: rebase/commit message massaging is another big todo.

[phillipj]

Kudos for getting these changes out in the open 👍

Really appreciate the effort you have put into the README.mds. The current lack of docs has been painful for a ansible rookie now and then.

Just wanted to give you a quick thumbs up so far, and do a more thorough review later.

[joaocgreis]

I've used this to deploy a Ubuntu server (for ChakraCore nightlies) and to generate my ssh config. This is amazing work and I believe our work going forward should be based on this as much as possible. I'd hate to see this bit rot in a PR.

Would it be easy to clean our current setup directory and leave only what is not included here? I would be happy to land this and remove what is no longer necessary in setup. We could add a note in the README (both this and setup/README.md perhaps) stating our intention to transition everything. For now, the setup/windows directory can be simply left there, there is no conflict nor overlap.

About the commit messages, since this is a major rewrite, I would be happy with squashing big parts (or all) of it. I do not care about authorship or integrity of my commit in this case (it's just 1 char!).

[gibfahn]

I'd hate to see this bit rot in a PR.

+100, this PR is awesome, and it's on my list of things to look at, but it'll be tough to review (at least for me). Also, I assume that the real proof will come from actually using it to provision and update machines.

Given that it's entirely additive, could we not just merge this in without removing any of the current stuff, and start trying it out for machines (perhaps on test machines that we have more than one of), and see how it goes? If we run into issues we should be able to iterate on what's already there right? Then we can start removing the old information once we know the refactored equivalent is stable.

[jbergstroem]

Thanks for your comments! Let me try and reduce a list of 'needs to be done' and work on those. I intentionally split up the folders so they could live alongside to have cover for things like windows and aix, but the main goal should obviously be having it support our entire infrastructure. We're already pretty close.

I guess a few aspects of this may or may not be "how to solve things in ansible" – for instance baking our own inventory parser or having plugins that extend the config. If there are better patterns, I'm all open for suggestions.

It's been a lot of fun building this but I fell a bit short of time at the end; but I will obviously finish it as well as keep maintaining it.

[gibfahn]

@jbergstroem I was trying to connect to test-requireio-osx1010-x64-1, and discovered I didn't have the ssh key in my .ssh/config. I reran the write-ssh-config playbook, but that didn't add the key.

Is this just something that needs to be added (or am I doing something wrong)?

[jbergstroem]

@gibfahn Is this just something that needs to be added (or am I doing something wrong)?

Did you first add the worker to inventory.yml? If so, perhaps file the diff below.

[jbergstroem]

After a quick "kick off" for the collab summit we agreed to land the refactor in a subfolder so we can start filing PR's against it.