Should allow managing remctl-client

[antaflos]

It would be nice if this module featured a remctl::client class that allows managing the client-side of remctl. I don't think this entails much more than installing the remctl-client packages. A client node can then include 'remctl::client'.

The question is: should everything server-related be moved to a remctl::server namespace? As in something like this:

$ tree remctl/manifests/
remctl/manifests/
├── client
│   └── install.pp
├── client.pp
├── init.pp
├── params.pp
├── server
│   ├── acl.pp
│   ├── command.pp
│   ├── config.pp
│   ├── inetd.pp
│   └── install.pp
└── server.pp

This would be a pretty big change. What do you think? I'll gladly submit a PR if useful.

Edit: Hm, it seems on RedHat there is no separate remctl-client package, as opposed to Debian. This makes things a bit more complicated.

[antaflos]

I put something together in antaflos@f6605d3 which worked in my development environment on both CentOS 6.5 and Ubuntu 12.04.

I am not sure about the spec tests though. They seem to complete successfully no matter what, even when referencing variables/parameters that no don't exist in 'spec_helper.rb'. For example, the test for should contain_package succeeded even though the variable os[:package_name] no longer existed because I renamed it to server_package_name in 'spec_helper.rb' but forgot to do so in 'spec/classes/server_spec.rb'.

[nealian]

I guess I'll have to play with that a bit. But I do rather like the idea, even if it does break a bit of backwards compatibility.

[antaflos]

Should I submit a proper PR or can you evaluate things based on the changes in antaflos@f6605d3?

[nealian]

Yes. From there I will play with the spec and figure out what's up with
that, since I have to play with Travis anyway, why not do both at once?
On May 1, 2014 3:16 PM, "Andreas Ntaflos" notifications@github.com wrote:

Should I submit a proper PR or can you evaluate things based on the
changes in antaflos/puppet-remctl@f6605d3antaflos@f6605d3
?

—
Reply to this email directly or view it on GitHubhttps://github.com//issues/3#issuecomment-41957937
.

[antaflos]

Ok, I have created the PR in #4.

Another minor thing: is it really necessary to notify the remctl::inetd class in case the remctl package resource changes? Isn't the point of inetd that daemons are started on demand?

[antaflos]

Just wanted to bump this issue, in case it was forgotten. We have been using my changes in #4 quite productively for two months now (on Ubuntu 12.04) and haven't had any problems. Also another PR is on the way that adds support for managing the various Remctl language bindings (for Ruby, Python, Perl and PHP).

Are you still interested in merging these changes? Or should we keep using our fork?

[blhughes]

Nealian is out on internship for the summer, I'll get another programmer to look at this, this week.
Thanks.

[nealian]

I'm very interested; thanks for the reminder. I've been meaning to get
around to testing the testing, especially since it wasn't working reliably
to begin with. That's the only real reason this hasn't been merged, and
I'll admit it's not a very good one.
On Jun 30, 2014 9:05 AM, "Andreas Ntaflos" notifications@github.com wrote:

Just wanted to bump this issue, in case it was forgotten. We have been
using my changes in #4 #4
quite productively for two months now (on Ubuntu 12.04) and haven't had any
problems. Also another PR is on the way that adds support for managing the
various Remctl language bindings (for Ruby, Python, Perl and PHP).

Are you still interested in merging these changes? Or should we keep using
our fork?

—
Reply to this email directly or view it on GitHub
#3 (comment).

[antaflos]

Ok, great. I'll be updating this PR soon with some more documentation and an updated README for the changes in #4.

[antaflos]

I've updated PR #4 which now contains updated docs in README.md and comments, and a better commit message.

[antaflos]

Gently bumping this once more :)

[nealian]

Sorry; just got situated back at university and have had time to breathe. From the poking and prodding, it seems like everything is wonderful, with the minor exception of the spec tests. But, I'm really not sure the rhyme or reason behind them being not broken when they should be. I'm just going to go with good judgement for now, and say it's ready to merge. I've made the associated changes in a PR for our own manifests, to be merged in conjunction with this. (That should happen today.)

[nealian]

That said, it seems like you're much more on top of these things than me, and you're, of course, more than welcome to do with your fork what you will (and we'll probably just start using yours).