Could you elaborate this a bit more? What should be changed to get this working? Is there an error message?

CentOS Linux release 7.2.1511 (Core)

Work fine.

This seems to be true for me, running under the patches I've mentioned in #216 to support easy-rsa 3.0. I'm unsure if it worked before that because I never tried under easy-rsa 2.0:

I get the following output after the configuration is successfully deployed:

Info: Openvpn::Deploy::Client[rmc-nms.rmcollege.local]: Scheduling refresh of Class[Openvpn::Deploy::Service]
Info: Class[Openvpn::Deploy::Service]: Scheduling refresh of Service[openvpn]
Error: Systemd start for openvpn failed!
journalctl log for openvpn:
-- No entries --

Error: /Stage[main]/Openvpn::Deploy::Service/Service[openvpn]/ensure: change from 'stopped' to 'running' failed: Systemd start for openvpn failed!
journalctl log for openvpn:
-- No entries --

My understanding is that the issue is the service name should be openvpn@${name} where $name is the name of the host (and hence the config file) that it loads on launch.

Using the hostname in the example above, I can run service openvpn@rmc-nms.rmcollege.local start and have it start with no problem. I've tried hacking something together to make this work but haven't really got anywhere.

An update on this that might be of assistance while people wait for this to be fixed properly. I've put together a not-very-clean hack that gets the service to start with no trouble. It's only good if you have a single host connection back to one server (one-to-one) and you name your connections the same as your $clientcert fact.

It's working for us in production now - and is far better than having services not start or restart when required (which meant manual intervention on all our nodes every time something fell off-line or we needed to make a change).

since #216 is closed, i suppose this issue can also be close.

I don't think so - the name of the service is still hard-coded to "openvpn" in openvpn::deploy::service.

The problem with recent versions of OpenVPN & CentOS is that there isn't a single "openvpn" service anymore. Instead, OpenVPN makes use of systemd's support for "Instantiated Services" to dynamically create a new logical service for each *.conf file under /etc/openvpn/.

So if I want to start an OpenVPN instance based on the contents of /etc/openvpn/myvpn.conf, I would need to start/stop it using systemctl start|stop openvpn@myvpn.service. You can also start/stop all openvpn instances using systemctl start|stop 'openvpn*.service'.

Out of interest, this is the content of the /usr/lib/systemd/system/openvpn@.service file on my system (note the use of %i):

Description=OpenVPN Robust And Highly Flexible Tunneling Application On %I
After=network.target

[Service]
Type=notify
PrivateTmp=true
ExecStart=/usr/sbin/openvpn --cd /etc/openvpn/ --config %i.conf

[Install]
WantedBy=multi-user.target

Currently, openvpn::deploy::service is declared as a class, so there can only be once instance of it. The easy fix will be to use a service name of openvpn* instead of openvpn in openvpn::deploy::service (for newer versions of CentOS/Red Hat). This will start/stop all openvpn service instances on the target machine.

Ideally though, openvpn::deploy::service would need to be re-worked as a define/resource instead of a class so that each openvpn service can be managed individually

Ah yes it makes sense. Are you interested in proposing a PR ?

I'm still experiencing this issue and I do wonder why the proposed PR #350 isn't merged at this point or fixed?

Same. This PR would be great if merged!