<div dir="ltr">This work is already being done by Clayton (and to a lesser extent me). From the openstack modules POV it mainly involves moving the packaging code into a separate place [1][2] and then integrating with puppet-os_docker[3]. This os_docker work is only done for designate and heat and of course requires os_docker which is not official and is rather specific to us.<div><br></div><div>As long as the external hooks are in place folks could plugin their own venv, docker, tarball, or whatever way to install code.<br><div><div><br></div><div>[1] - <a href="https://github.com/openstack/puppet-designate/commit/5a37cc81276cb8f8ee6dca9b9b532930e6ac86de">https://github.com/openstack/puppet-designate/commit/5a37cc81276cb8f8ee6dca9b9b532930e6ac86de</a></div><div>[2] - <a href="https://github.com/openstack/puppet-heat/commit/dca9fe942b99b9c30e31167e4736058767738f21">https://github.com/openstack/puppet-heat/commit/dca9fe942b99b9c30e31167e4736058767738f21</a></div><div>[3] - <a href="https://github.com/twc-openstack/puppet-os_docker">https://github.com/twc-openstack/puppet-os_docker</a></div></div><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Fri, Nov 13, 2015 at 11:13 AM, Cody Herriges <span dir="ltr"><<a href="mailto:cody@puppetlabs.com" target="_blank">cody@puppetlabs.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="HOEnZb"><div class="h5">Yanis Guenane wrote:<br>
><br>
> On 11/03/2015 02:57 PM, Emilien Macchi wrote:<br>
>> I'm seeing a lot of patches using the new $::os_service_default.<br>
>><br>
>> Please stop trying to using it at this time. The feature is not stable<br>
>> yet and we're testing it only for puppet-cinder module.<br>
>> I've heard Yanis found something that is not backward compatible with<br>
>> logging, but he's away this week so I suggest we wait next week.<br>
>><br>
>> In the meantime, please do not use $::os_service_default outside<br>
>> puppet-cinder.<br>
>><br>
>> Thanks a lot,<br>
> After a deeper investigation, the issue with logging[1] is only true if<br>
> a user is using the puppet-openstack to only configure the component and<br>
> not relying on it to install the RDO/UCA packages.<br>
><br>
> On RDO, the file /usr/lib/systemd/system/openstack-cinder-api.service is<br>
> provided. It specifies :<br>
><br>
>   ExecStart=/usr/bin/cinder-api --config-file<br>
> /usr/share/cinder/cinder-dist.conf \<br>
>     --config-file /etc/cinder/cinder.conf --logfile /var/log/cinder/api.log<br>
><br>
> On Ubuntu, the file /etc/init/cinder-api.conf is provided. It specfies :<br>
><br>
>   exec start-stop-daemon --start --chuid cinder --exec /usr/bin/cinder-api \<br>
>      -- --config-file=/etc/cinder/cinder.conf<br>
> --log-file=/var/log/cinder/cinder-api.log<br>
><br>
> In my understanding, this means that when using packages none of log-dir<br>
> and log-file will ever be taken in account.<br>
><br>
> So the only use case moving those values to $::os_service_default might<br>
> impact are for the people relying directly on the python package.<br>
><br>
> This raises two questions I'd like to ask :<br>
><br>
>   * Do lot of people use puppet-openstack modules relying on the python<br>
> package directly ?<br>
>   * Should we be opinionated here ? If user relies on the python<br>
> packages, we can consider that an advanced use-case and expect the user<br>
> to know exactly what she needs to configure. Plus we do not handle the<br>
> use case where we want a file for cinder-volume.log and cinder-backup.log.<br>
><br>
> [1]<br>
> <a href="https://trello.com/c/XLJJJBF0/71-move-modules-to-the-os-service-default-pattern" rel="noreferrer" target="_blank">https://trello.com/c/XLJJJBF0/71-move-modules-to-the-os-service-default-pattern</a><br>
><br>
<br>
</div></div>My opinion is that installing directly from python pip is not currently<br>
officially supported in the modules and specifically trying to take that<br>
use case into account when we do not support it either leaves us in a<br>
place where we have to go full in on supporting them or put the modules<br>
in a state that thoroughly frustrates and misleads users.<br>
<br>
If we were going to put priority on which packaging systems to support<br>
next; I'd prefer docker over pip.<br>
<span class="HOEnZb"><font color="#888888"><br>
<br>
--<br>
Cody<br>
<br>
</font></span><br>__________________________________________________________________________<br>
OpenStack Development Mailing List (not for usage questions)<br>
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>