<div dir="ltr"><br><div class="gmail_extra"><br><div class="gmail_quote">On Wed, Dec 9, 2015 at 2:25 AM, Thomas Goirand <span dir="ltr"><<a href="mailto:zigo@debian.org" target="_blank">zigo@debian.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On 12/08/2015 04:09 AM, Dolph Mathews wrote:<br>
>     In Debian, many services/daemons are run, then their API is used by the<br>
>     package. In the case of Keystone, for example, it is possible to ask,<br>
>     via Debconf, that Keystone registers itself in the service catalog. If<br>
>     we get Keystone within Apache, it becomes at least harder to do so.<br>
><br>
><br>
> You start the next paragraph with "the other issue," but I'm not clear<br>
> on what the issue is here? This sounds like a bunch of complexity that<br>
> is working as you expect it to.<br>
<br>
</span>Ok, let me try again. If the only way to get Keystone up and running is<br>
through a web server like Apache, then starting Keystone and then using<br>
its API is not as easy as if it was a daemon on its own. For example,<br>
there may be some other types of configuration in use in the web server<br>
which the package doesn't control.<br></blockquote><div><br></div><div>I would make the assumption that the node is solely intended for use by keystone. Either it is solely for use by keystone and I care about uptime, or the node is not solely for use by keystone and thus I don't care about uptime.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
>     The other issue is that if all services are sharing the same web server,<br>
>     restarting the web server restarts all services. Or, said otherwise: if<br>
>     I need to change a configuration value of any of the services served by<br>
>     Apache, I will need to restart them all, which is very annoying: I very<br>
>     much prefer to just restart *ONE* service if I need.<br>
><br>
> As a deployer, I'd solve this by running one API service per server. As<br>
> a packager, I don't expect you to solve this outside of AIO<br>
> architectures, in which case, uptime is obviously not a concern.<br>
<br>
</span>Let's say there's a security issue in Keystone. One would expect that a<br>
simple "apt-get dist-upgrade" will do all. If Keystone is installed in a<br>
web server, should the package aggressively attempts to restart it? If<br>
not, what is the proposed solution to have Keystone restarted in this case?<br></blockquote><div><br></div><div>Yes, restart the web server aggressively, because I'm likely doing the upgrade with the intent of receiving the immediate benefit of updates.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
>     Also, something which we learned the hard way at Mirantis: it is *very*<br>
>     annoying that Apache restarts every Sunday morning by default in<br>
>     distributions like Ubuntu and Debian (I'm not sure for the other<br>
>     distros). No, the default config of logrotate and Apache can't be<br>
>     changed in distros just to satisfy OpenStack users: there's other users<br>
>     of Apache in these distros.<br>
><br>
> Yikes! Is the debian Apache package intended to be useful in production?<br>
> That doesn't sound like an OpenStack-specific problem at all. How is<br>
> logrotate involved? Link?<br>
<br>
</span>It is logrotate which restarts apache. From /etc/logrotate.d/apache2:<br>
<br>
/var/log/apache2/*.log {<br>
        daily<br>
        missingok<br>
        rotate 14<br>
        compress<br>
        delaycompress<br>
        notifempty<br>
        create 640 root adm<br>
        sharedscripts<br>
        postrotate<br>
                if /etc/init.d/apache2 status > /dev/null ; then \<br>
                    /etc/init.d/apache2 reload > /dev/null; \<br>
                fi;<br>
        endscript<br>
        prerotate<br>
                if [ -d /etc/logrotate.d/httpd-prerotate ]; then \<br>
                        run-parts /etc/logrotate.d/httpd-prerotate; \<br>
                fi; \<br>
        endscript<br>
}<br>
<br>
This is to be considered quite harmful. Yes, I am fully aware that this<br>
file can be tweaked. Though this is the default, and it is always best<br>
to provide a default which works for our users. And in this case, no<br>
OpenStack package maintainer controls it.<br>
<span class=""><br>
>     Then, yes, uWSGI becomes a nice option. I used it for the Barbican<br>
>     package, and it worked well. Though the uwsgi package in Debian isn't<br>
>     very well maintained, and multiple times, Barbican could have been<br>
>     removed from Debian testing because of RC bugs against uWSGI.<br>
><br>
> uWSGI is a nice option, but no one should be tied to that either-- in<br>
> the debian world or otherwise.<br>
<br>
</span>For Debian users, I intend to provide useful configuration so that<br>
everything works by default. OpenStack is complex enough. It is my role,<br>
as a package maintainer, to make it easier to use.<br>
<br>
One of the options I have is to create new packages like this:<br>
<br>
python-keystone -> Already exists, holds the Python code<br>
keystone -> Currently contains the Eventlet daemon<br>
<br>
I could transform the later into a meta package depending on any of the<br>
below options:<br>
<br>
keystone-apache -> Default configuration for Apache<br>
keystone-uwsgi -> An already configured startup script using uwsgi<br>
<br>
Though I'm not sure the FTP masters will love me if I create so many new<br>
packages just to create automated configurations... Also, maybe it's<br>
just best to provide *one* implementation which we all consider the<br>
best. I'm just not sure yet which one it is. Right now, I'm leaning<br>
toward uwsgi.<br></blockquote><div><br></div><div>Cool; I don't have a opinionated recommendation on which you should choose, but unless there are strong use cases to support both (or some third option), I would recommend choosing to support only one.</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<span class=""><br>
>     So, all together, I'm a bit reluctant to see the Eventlet based servers<br>
>     going away. If it's done, then yes, I'll work around it. Though I'd<br>
>     prefer if it didn't.<br>
><br>
> Think of it this way: keystone is moving towards using Python<br>
> where Python excels, and is punting up the stack where Python is<br>
> handicapped. Don't think of it as a work around, think of it as having<br>
> the freedom to architect your own deployment.<br>
<br>
</span>I'm ok with that, but as per the above, I'd like to provide something<br>
which just works for Debian users. And I'd love to gather opinions on<br>
what is best.<br>
<span class=""><br>
>     It is also my view that it's up to the deployers to decide how they want<br>
>     to implement things. For many small use cases, Eventlet performs well<br>
>     enough.<br>
><br>
> Unfortunately, "small" is not "all."<br>
<br>
</span>The reasoning that I have, is that for small deployments, using the<br>
package defaults is ok. For bigger deployments, you'd be using puppet<br>
and other kinds of tooling anyway, and then it's ok to expect this type<br>
of users to do what he/she thinks is best.<br>
<span class=""><br>
>     Finally, one thing which I never understood: if Eventlet is bad as an<br>
>     HTTP server, can't we use anything else written in Python? Isn't it<br>
>     possible to write a decent HTTP server in Python? Why are we forced into<br>
>     just Eventlet for doing the job? I haven't searched around, but there<br>
>     must be loads of alternatives, no?<br>
><br>
> Yep! There are many. Eventlet is a bit unique, but ("Core") OpenStack<br>
> services have historically been tightly bound to Eventlet for it's<br>
> native-ish threading support. As Keystone has broken free, you are then<br>
> free to deploy our generic WSGI app/s using any generic WSGI server in<br>
> any process / threading architecture that suits your requirements.<br>
><br>
> We only ever preferred Apache for two reasons:<br>
><br>
> 1) There was interest in using apache-based auth plugins with keystone.<br>
><br>
> 2) Everyone sysadmin and their mother knows how to configure Apache.<br>
><br>
> It was just well-documented and well-understood.<br>
<br>
</span>I really find using Apache the less convenient of all the options available.<br></blockquote><div><br></div><div>As I mentioned in the other reply to this thread, the choice should really come down to operability, etc, so I consider convenience to be totally sound reasoning :)</div><div> </div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="HOEnZb"><div class="h5"><br>
Cheers,<br>
<br>
Thomas Goirand (zigo)<br>
<br>
<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>
</div></div></blockquote></div><br></div></div>