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

[Thomas Goirand]

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.

> 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?

> 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.

> 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 

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

[Thomas Goirand]

On 12/08/2015 06:39 AM, Jamie Lennox wrote:
> The main problem I see with running Keystone (or any other service) in a
> web server, is that *I* (as a package maintainer) will loose the control
> over when the service is started. Let me explain why that is important
> for me.
> 
> 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.
> 
> I was going to leave this up to others to comment on here, but IMO -
> excellent. Anyone that is doing an even semi serious deployment of
> OpenStack is going to require puppet/chef/ansible or some form of
> orchestration layer for deployment. Even for test deployments it seems
> to me that it's crazy for this sort of functionality be handled from
> debconf. The deployers of the system are going to understand if they
> want to use eventlet or apache and should therefore understand what
> restarting apache on a system implies.

It is often what everyone from within the community says. However,
there's lots of users who hardly do a single deployment, maybe 2. I
don't agree that they should all invest a huge amount of time in some
automation tools, and for them, packages should be enough.

Anyway, the debconf handling is completely optional, and most of the
helpers are completely disabled by default. So it is *not* in the way of
using any deployment tool like puppet.

Cheers,

Thomas Goirand (zigo)


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

[Adam Young]

On 12/07/2015 06:53 PM, Thomas Goirand wrote:

On 12/01/2015 07:57 AM, Steve Martinelli wrote:

Trying to summarize here...

- There isn't much interest in keeping eventlet around.
- Folks are OK with running keystone in a WSGI server, but feel they are
constrained by Apache.
- uWSGI could help to support multiple web servers.

My opinion:

- Adding support for uWSGI definitely sounds like it's worth
investigating, but not achievable in this release (unless someone
already has something cooked up).
- I'm tempted to let eventlet stick around another release, since it's
causing pain on some of our operators.
- Other folks have managed to run keystone in a web server (and
hopefully not feel pain when doing so!), so it might be worth getting
technical details on just how it was accomplished. If we get an OK from
the operator community later on in mitaka, I'd still be OK with removing
eventlet, but I don't want to break folks.

stevemar

From: John Dewey 
100% agree.

We should look at uwsgi as the reference architecture. Nginx/Apache/etc
should be interchangeable, and up to the operator which they choose to
use. Hell, with tcp load balancing now in opensource Nginx, I could get
rid of Apache and HAProxy by utilizing uwsgi.

John

The main problem I see with running Keystone (or any other service) in a
web server, is that *I* (as a package maintainer) will loose the control
over when the service is started. Let me explain why that is important
for me.

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.

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.

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.

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.

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.


You can run one instance of Apache for each service, and have the listen 
on different ports.  Its not how the distros set up apache, but then 
again, the distros only set up Eventlet with  the work we;'ve done.


Eventlet has threading issues I'd rather not debug anymore.




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.


And for these, Apache is still a better approach, all things considered.

Every way has some pain...we are trying to chose the lesser.



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?


Crypto.  Crypto should not be done in Python.  Also, GIL and multi 
threading make it hard to do in Python.  Hence the userland threading 
approach.  Which has an impact on all blocking IO calls.


There are many ways to get what you want.  Each service in their own 
container is probably the one that maps closest to the type of 
insulation we'd like to see.  Each in their own VM probably makes sense 
for a non-trivial sized cloud.




Cheers,

Thomas Goirand (zigo)


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

[Rich Megginson]

On 12/07/2015 07:49 PM, Adam Young wrote:

On 12/07/2015 06:53 PM, Thomas Goirand wrote:

On 12/01/2015 07:57 AM, Steve Martinelli wrote:

Trying to summarize here...

- There isn't much interest in keeping eventlet around.
- Folks are OK with running keystone in a WSGI server, but feel they 
are

constrained by Apache.
- uWSGI could help to support multiple web servers.

My opinion:

- Adding support for uWSGI definitely sounds like it's worth
investigating, but not achievable in this release (unless someone
already has something cooked up).
- I'm tempted to let eventlet stick around another release, since it's
causing pain on some of our operators.
- Other folks have managed to run keystone in a web server (and
hopefully not feel pain when doing so!), so it might be worth getting
technical details on just how it was accomplished. If we get an OK from
the operator community later on in mitaka, I'd still be OK with 
removing

eventlet, but I don't want to break folks.

stevemar

From: John Dewey 
100% agree.

We should look at uwsgi as the reference architecture. Nginx/Apache/etc
should be interchangeable, and up to the operator which they choose to
use. Hell, with tcp load balancing now in opensource Nginx, I could get
rid of Apache and HAProxy by utilizing uwsgi.

John

The main problem I see with running Keystone (or any other service) in a
web server, is that *I* (as a package maintainer) will loose the control
over when the service is started. Let me explain why that is important
for me.

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.

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.

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.

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.

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.


You can run one instance of Apache for each service, and have the 
listen on different ports.  Its not how the distros set up apache, but 
then again, the distros only set up Eventlet with  the work we;'ve done.


Eventlet has threading issues I'd rather not debug anymore.




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.


And for these, Apache is still a better approach, all things considered.

Every way has some pain...we are trying to chose the lesser.



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?


Crypto.  Crypto should not be done in Python.  Also, GIL and multi 
threading make it hard to do in Python.  Hence the userland threading 
approach.  Which has an impact on all blocking IO calls.


Kerberos.  Other forms of authn/authz - gssapi, federation, 
mod_lookup_identity, etc. that would need to be implemented in 
python/eventlet.




There are many ways to get what you want.  Each service in their own 
container is probably the one that maps closest to the type of 
insulation we'd like to see.  Each in their own VM probably makes 
sense for a non-trivial sized cloud.








Cheers,

Thomas Goirand (zigo)


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators



___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org

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

[Steve Martinelli]

... re-adding the operators mailing list.

sounds like we should document how to do this, with the assertion that it
is not tested with our CI.

with that said, we should try to have a job that sets up keystone with
nginx that is run periodically (similar to our eventlet job at the moment).

stevemar



From:   Brant Knudson 
To: "OpenStack Development Mailing List (not for usage questions)"

Date:   2015/12/07 05:52 PM
Subject:Re: [openstack-dev] [Openstack-operators] [keystone] Removing
functionality that was deprecated in Kilo and upcoming
deprecated functionality in Mitaka





On Tue, Dec 1, 2015 at 12:57 AM, Steve Martinelli 
wrote:
  Trying to summarize here...

  - There isn't much interest in keeping eventlet around.
  - Folks are OK with running keystone in a WSGI server, but feel they are
  constrained by Apache.
  - uWSGI could help to support multiple web servers.

  My opinion:

  - Adding support for uWSGI definitely sounds like it's worth
  investigating, but not achievable in this release (unless someone already
  has something cooked up).



What needs to change to support uWSGI? You can already run keystone in
python uwsgi and then front it with nginx:

 $ uwsgi --socket 127.0.0.1:5001 --wsgi-file $(which keystone-wsgi-public)
--honour-stdin --enable-threads --workers 6
 $ uwsgi --socket 127.0.0.1:35358 --wsgi-file $(which keystone-wsgi-admin)
--honour-stdin --enable-threads --workers 6

 $ sudo vi /etc/nginx/sites-available/keystone

server {
  listen 5000 default_server;
  server_name localhost;
  location / {
    include uwsgi_params;
    uwsgi_pass 127.0.0.1:5001;
    uwsgi_param SCRIPT_NAME /;
  }
}
server {
  listen 35357 default_server;
  server_name localhost;
  location / {
    include uwsgi_params;
    uwsgi_pass 127.0.0.1:35358;
    uwsgi_param SCRIPT_NAME /;
  }
}

 $ sudo ln -x /etc/nginx/sites-available/keystone /etc/nginx/sites-enabled/

 $ sudo nginx

and then you can make your regular curl calls.

Also, you can run keystone with regular http in python uwsgi (uwsgi --http)
and then just do normal reverse proxy (from Apache or nginx or whatever),
which I think would be adequate for keystone.

We don't do anything in keystone to stop deployments in web servers other
than Apache. Keystone is just a regular wsgi app. We document Apache since
it's popular and it provides mod_shib, which is the only saml2 module for
web servers that I know of. Keystone can work with other saml2 modules and
in different servers, it just takes the environment variables that the
module sets and runs it through some mapping code. The mapping code has
been shown to work alternative authentication modules (for ldap and
kerberos).

- Brant
__
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-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

[Matthew Treinish]

On Mon, Dec 07, 2015 at 06:18:04PM -0500, Steve Martinelli wrote:
> 
> ... re-adding the operators mailing list.
> 
> sounds like we should document how to do this, with the assertion that it
> is not tested with our CI.
> 
> with that said, we should try to have a job that sets up keystone with
> nginx that is run periodically (similar to our eventlet job at the moment).

So, we actually run keystone with eventlet on every tempest-dsvm-postgres-full
job. It runs way more than periodically:

http://status.openstack.org/openstack-health/#/job/gate-tempest-dsvm-postgres-full
 

That's just a 24 hr window in the gate queue, including check it's much more.

This has been long standing behavior ever since keystone under mod_wsgi support
was added to devstack:

https://github.com/openstack-infra/project-config/blob/master/jenkins/jobs/devstack-gate.yaml#L1395-L1429

It's 1 of 3 things that are different that make the postgres job different. I've
always viewed that job config overloading as a bug, for this exact reason.

-Matt Treinish
 
> 
> From: Brant Knudson 
> To:   "OpenStack Development Mailing List (not for usage questions)"
> 
> Date: 2015/12/07 05:52 PM
> Subject:  Re: [openstack-dev] [Openstack-operators] [keystone] Removing
> functionality that was deprecated in Kilo and upcoming
> deprecated functionality in Mitaka
> 
> 
> 
> 
> 
> On Tue, Dec 1, 2015 at 12:57 AM, Steve Martinelli 
> wrote:
>   Trying to summarize here...
> 
>   - There isn't much interest in keeping eventlet around.
>   - Folks are OK with running keystone in a WSGI server, but feel they are
>   constrained by Apache.
>   - uWSGI could help to support multiple web servers.
> 
>   My opinion:
> 
>   - Adding support for uWSGI definitely sounds like it's worth
>   investigating, but not achievable in this release (unless someone already
>   has something cooked up).
> 
> 
> 
> What needs to change to support uWSGI? You can already run keystone in
> python uwsgi and then front it with nginx:
> 
>  $ uwsgi --socket 127.0.0.1:5001 --wsgi-file $(which keystone-wsgi-public)
> --honour-stdin --enable-threads --workers 6
>  $ uwsgi --socket 127.0.0.1:35358 --wsgi-file $(which keystone-wsgi-admin)
> --honour-stdin --enable-threads --workers 6
> 
>  $ sudo vi /etc/nginx/sites-available/keystone
> 
> server {
>   listen 5000 default_server;
>   server_name localhost;
>   location / {
>     include uwsgi_params;
>     uwsgi_pass 127.0.0.1:5001;
>     uwsgi_param SCRIPT_NAME /;
>   }
> }
> server {
>   listen 35357 default_server;
>   server_name localhost;
>   location / {
>     include uwsgi_params;
>     uwsgi_pass 127.0.0.1:35358;
>     uwsgi_param SCRIPT_NAME /;
>   }
> }
> 
>  $ sudo ln -x /etc/nginx/sites-available/keystone /etc/nginx/sites-enabled/
> 
>  $ sudo nginx
> 
> and then you can make your regular curl calls.
> 
> Also, you can run keystone with regular http in python uwsgi (uwsgi --http)
> and then just do normal reverse proxy (from Apache or nginx or whatever),
> which I think would be adequate for keystone.
> 
> We don't do anything in keystone to stop deployments in web servers other
> than Apache. Keystone is just a regular wsgi app. We document Apache since
> it's popular and it provides mod_shib, which is the only saml2 module for
> web servers that I know of. Keystone can work with other saml2 modules and
> in different servers, it just takes the environment variables that the
> module sets and runs it through some mapping code. The mapping code has
> been shown to work alternative authentication modules (for ldap and
> kerberos).
> 
> - Brant
> __
> 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



signature.asc
Description: PGP signature
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

[Thomas Goirand]

On 12/01/2015 07:57 AM, Steve Martinelli wrote:
> Trying to summarize here...
> 
> - There isn't much interest in keeping eventlet around.
> - Folks are OK with running keystone in a WSGI server, but feel they are
> constrained by Apache.
> - uWSGI could help to support multiple web servers.
> 
> My opinion:
> 
> - Adding support for uWSGI definitely sounds like it's worth
> investigating, but not achievable in this release (unless someone
> already has something cooked up).
> - I'm tempted to let eventlet stick around another release, since it's
> causing pain on some of our operators.
> - Other folks have managed to run keystone in a web server (and
> hopefully not feel pain when doing so!), so it might be worth getting
> technical details on just how it was accomplished. If we get an OK from
> the operator community later on in mitaka, I'd still be OK with removing
> eventlet, but I don't want to break folks.
> 
> stevemar
> 
> From: John Dewey 
> 100% agree.
> 
> We should look at uwsgi as the reference architecture. Nginx/Apache/etc
> should be interchangeable, and up to the operator which they choose to
> use. Hell, with tcp load balancing now in opensource Nginx, I could get
> rid of Apache and HAProxy by utilizing uwsgi.
> 
> John

The main problem I see with running Keystone (or any other service) in a
web server, is that *I* (as a package maintainer) will loose the control
over when the service is started. Let me explain why that is important
for me.

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.

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.

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.

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.

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.

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.

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?

Cheers,

Thomas Goirand (zigo)


___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

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

[Jamie Lennox]

On 8 December 2015 at 07:53, Thomas Goirand  wrote:

> On 12/01/2015 07:57 AM, Steve Martinelli wrote:
> > Trying to summarize here...
> >
> > - There isn't much interest in keeping eventlet around.
> > - Folks are OK with running keystone in a WSGI server, but feel they are
> > constrained by Apache.
> > - uWSGI could help to support multiple web servers.
> >
> > My opinion:
> >
> > - Adding support for uWSGI definitely sounds like it's worth
> > investigating, but not achievable in this release (unless someone
> > already has something cooked up).
> > - I'm tempted to let eventlet stick around another release, since it's
> > causing pain on some of our operators.
> > - Other folks have managed to run keystone in a web server (and
> > hopefully not feel pain when doing so!), so it might be worth getting
> > technical details on just how it was accomplished. If we get an OK from
> > the operator community later on in mitaka, I'd still be OK with removing
> > eventlet, but I don't want to break folks.
> >
> > stevemar
> >
> > From: John Dewey 
> > 100% agree.
> >
> > We should look at uwsgi as the reference architecture. Nginx/Apache/etc
> > should be interchangeable, and up to the operator which they choose to
> > use. Hell, with tcp load balancing now in opensource Nginx, I could get
> > rid of Apache and HAProxy by utilizing uwsgi.
> >
> > John
>
> The main problem I see with running Keystone (or any other service) in a
> web server, is that *I* (as a package maintainer) will loose the control
> over when the service is started. Let me explain why that is important
> for me.
>
> 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.
>

I was going to leave this up to others to comment on here, but IMO -
excellent. Anyone that is doing an even semi serious deployment of
OpenStack is going to require puppet/chef/ansible or some form of
orchestration layer for deployment. Even for test deployments it seems to
me that it's crazy for this sort of functionality be handled from debconf.
The deployers of the system are going to understand if they want to use
eventlet or apache and should therefore understand what restarting apache
on a system implies.


>
> 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.
>
> 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.
>

:O


>
> 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.
>
> 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.
>
> 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.
>
> 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?
>
> Cheers,
>
> Thomas Goirand (zigo)
>

So I'd be ok with keeping eventlet around until after we can figure out
something for multiple virtual envs (i think you'd replace virtualenvs with
containers) , but i don't think the packaging should have anything to do
with this.


> ___
> OpenStack-operators mailing list
> OpenStack-operators@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators
>
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators