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