<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On 12 January 2017 at 02:31, Charles Butler <span dir="ltr"><<a href="mailto:charles.butler@canonical.com" target="_blank">charles.butler@canonical.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Greetings,<div><br></div><div>I'm working on an update to the etcd snap so we can make the Kubernetes etcd2 -> etcd3 migration simple, transactional, and hopefully more bullet proof in iterations to come. I've got a question regarding the SystemD Daemon unitfile. </div><div><br></div><div>You can declare to snapcraft, that a bin should be treated as a daemon with very straightforward syntax</div><div><br></div><div><div>apps:</div><div>  etcd:</div><div>    command: bin/etcd</div><div>    plugs:</div><div>        - network</div><div>    daemon: simple</div><div>    restart-condition: on-abnormal</div></div><div><br></div><div>This was -almost magical-. I have need of customizing this output unit file based on conditions coming from Juju, such as TLS certificate paths will need to be passed as ENV, as well as peer connection strings. </div><div><br></div><div>I can template this in Juju and overwrite the systemd unit file, but I feel like this will be a continual issue as the snap upgrades, I can only presume the systemd unit file is upgraded along the way. Please correct me if my assumption is incorrect here. Is there a way I can declare ENV or template the systemd file with the snap? </div></div></blockquote><div><br></div><div>You don't have much control over the generated systemd service file. Its an open issue. So while you could have your snap accept configuration options, the snap can't rewrite its own systemd service file (or it could escape its containment). What you would need to do is write a wrapper for bin/etcd that sets the environment variables (pulled from snap configuration, or from a .ini file or similar stored in $SNAP_DATA or $SNAP_COMMON) before os.exec'ing the real bin/etcd<br><br></div><div>Since you are driving this from a charm though, you don't need it. systemd supports '.d' style directories, allowing you to extend a .service file owned by some other process. This is how the snap layer adds support for downloading snaps via proxies, so see <a href="https://git.launchpad.net/layer-snap/tree/reactive/snap.py#n62">https://git.launchpad.net/layer-snap/tree/reactive/snap.py#n62</a> for an example.<br></div></div><br></div><div class="gmail_extra"><br clear="all"></div><div class="gmail_extra"><br>-- <br><div class="gmail_signature" data-smartmail="gmail_signature">Stuart Bishop <<a href="mailto:stuart.bishop@canonical.com" target="_blank">stuart.bishop@canonical.com</a>></div>

</div></div>