rexops / rex-recipes Goto Github PK

It can be very useful to be able to print continuously from a long running task and this feels like it should be in core rather than a recipe?

@melezhik on #26 provided a great example rex module to setup, configure and run a sparrow plugin on remote hosts. During our IRC discussions, we decided to aim for a more general approach due to high number of sparrow plugins (i.e. writing and maintaining a separate rex module for each sparrow plugin does not scale).

The idea is to have a single Rex::Misc::Sparrow module which can handle setup/configuration of a list of Sparrow plugins provided via a config file for the task (standard CMDB and/or custom file).

Basic usage examples for the idea:

• setting up everything: rex Misc:Sparrow:setup
• running all checks: rex Misc:Sparrow:check

Extended ideas (to be done at a later point):

• run some checks, but not all: rex Misc:Sparrow:check --plugins=check1,check2
• run all checks except some: rex Misc:Sparrow:check --except=check1,check2

Calling this task from another library or Rexfile does nothing.
The task is never called. It works if task name is changed (to 'install_pkg' for instance).

when your java system is updated, the java path (if you don't use alternatives) is changed. So this test will create a duplication entry for JAVA_HOME.
append_if_no_such_line "/etc/environment", "JAVA_HOME=$java_home";

The existing recipes in this repo probably would still be useful, so it sounds like a good idea to try and republish them elsewhere (on GitHub and/or CPAN).

I think primarily the author should be notified and asked to do it, but given a permissive enough license, a new maintainer might want to step and to take over the responsibility.

Before we can deprecate rex-recipes, we need to have a way for people to publish their own recipes.

I think the recipes should move into the Rex:: namespace.

firstly, so they won't conflict with non-rex perl modules that might be used - or worse, future CPAN modules that come into existance and then clash.

and secondly, so that when one of them becomes important enough to migrate into rex itself, no-one's code needs to change.

We should contact precpan to talk with them about a namespace that we can use to put recipes, plugins, extensions and other "third party" code into.

in my case, I'd love to just put my rex-recipes github fork into ./rex/recipes and have it be used, that way i don't have out of date duplicates whever i have a Rexfile that uses them

When trying to install Java module using rexify:

rexify --use=Rex::Lang::Java

I'm getting an error message:

Getting dependencies for Rex::Lang::Java...
JSON text must be an object or array (but found number, string, true, false or null, use allow_nonref to allow this) at /usr/bin/rexify line 361.

I think the problem is related with the Rex::Lang::Java meta.yml file and the empty list of dependencies.