[openstack-dev] [keystone] Removing functionality that was deprecated in Kilo and upcoming deprecated functionality in Mitaka

Dolph Mathews dolph.mathews at gmail.com
Wed Dec 9 13:49:24 UTC 2015


On Wed, Dec 9, 2015 at 2:25 AM, Thomas Goirand <zigo at 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-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20151209/f1d6119b/attachment.html>


More information about the OpenStack-dev mailing list