Refactor ansible roles and support CentOS

[danizen]

I'm at NLM and am the author of a bunch of ansible code in https://github.com/NLM-OCCS/

I've been asked to bring up Metaproxy with marc2bibframe2 internally, but we have a bunch of work to do first. To me, it makes sense to refactor the ansible roles here and move them to their own repositories, because that way they can be installed via ansible galaxy, and/or depended on with git submodule.

I also need to support CentOS 7 at least and maybe CentOS 6 if it comes on-premise.

Do you have any objections? I'm hoping to package my changes so that you can accept them via pull request, but they could be quite structural, and so I need to establish this issue for conversation/tracking before I get too far in.

[wafschneider]

Hi, Dan. Please, feel free to use what you find here as a basis for a galaxy role; we had built the roles strictly for convenience in testing using a local Vagrant box, and left them in the repository in case they might be of use to anyone else. We're not using the roles in this repository in any kind of production workflow, so really have no investment in the current structure. Thanks for taking an interest! wayne

[danizen]

@wafschneider (Wayne), are you guys constrained to Debian jessie? For testing, would CentOS be just as good? I imagine that when Metaproxy gets to be deployed at LOC, it moves from guys with VirtualBox and laptops to guys with root, VmWare vSphere, etc. Is that so?

I found that the ansible on Debian essie is pretty old. For instance, my instinct is to use "become: true" only in a playbook, rather than in the module, but that appears needed in your ansible 1.7.4.

[wafschneider]

@danizen - CentOS would be just fine. LOC deployment is quite a bit more formal, we actually don't use these playbooks for that at all. This was truly a one-off for (my) convenience, AFAIK I'm the only one who's used them. Feel free to run with it!

[danizen]

@wafshneider, Thanks

[kirkhess]

@danizen Our metaproxy servers are RHEL 6 on VMWare - we have dev servers and then for prod the devops guys did it with yum root and a custom config. CentOS would be fine, it would prob. be nice to include once you finish your fork. Thanks!

[danizen]

I seem to have it installed, but how then do I use it? I haven't attempted as yet to point it at our Z39.50 server or changed any namespaces. However, I get XML back from port 9000.

[danizen]

Today, I started to work in my fork on an ant build.xml, because the guidelines for running xspec through ant seem pretty clear, and I guess Maven doesn't seem good because it would be opinionated about things going in src/main/xsl and stuff like that.

My feeling is that this project isn't ready for a true ansible role because the mp-bibframe role depends on other aspects - such as building a distribution and such.

I also think this sort of ant driven build makes the project a little easier to use. It isn't everyone who will read through .travis.yml to figure out how to test.

You can take a look at https://github.com/NLM-OCCS/marc2bibframe2/blob/master/build.xml if you want. Everything seems to work aside from actually getting test results, so I'll try that more tomorrow.

[danizen]

An ant based build that runs all the tests and then generates a marc2bibframe2-0.1.zip is complete. I now need to unwind my other changes so that I can contribute just that back.

It is philosophical - before you automate with a tool like travis CI, Jenkins, or anything else, you need to have a process you can run in your development environment. If you don't have that, then you are dependent on CI/CD entirely for your builds. This seems not a good thing, at least to me.

The CI part of the tool should be a task runner with reports and dashboards. The complicated part comes with CD.

[kirkhess]

Closing this out - it's not really a priority for us and if we do CD we'll do it in a way which matches our infrastructure at LC.