[openstack-dev] [devstack] apache wsgi application support

Sean Dague sean at dague.net
Wed Jun 24 12:07:49 UTC 2015

On 06/24/2015 07:57 AM, Chris Dent wrote:
> On Wed, 24 Jun 2015, Sean Dague wrote:
>> So on https://review.openstack.org/#/c/194442 ... I was kind of thinking
>> we'd be able to get keystone-wsgi-public into a bin directory. I put up
>> a half baked sketch of this idea in
>> https://review.openstack.org/#/c/195044. Would be curious if some
>> version of that could be made to work here.
> I remain somewhat confused on why you want this?
> It's a fairly common convention for the module which has the wsgi
> 'application' global to live somewhere in the "web tree" (/var/www/ etc)
> or just some random location that is referenced from the hosting server.
> Putting in */bin doesn't has some risk of confusion because you
> shouldn't really run the wsgi script in any normal sense of the word
> (from the command line, from cron, whatever). If you've set your
> wsgi app up so that is possible then you're conflating purposes and
> that's bad mojo. Your patch has exceptions to watch out for that,
> but it seems...crufty?
> If the primary reason is so that we can rely on the console_scripts
> entry point to handle getting the application somewhere useful then
> that too feels a bit crufty, in the sense of "that's a hack".
> That may be perfectly reasonable stuff to do given the constraints
> and lack of other options but I thought I would check in.
> (I happen to be working on making this a reality for gnocchi's
> devstack plugin at the moment and your message popped up at exactly
> the moment when I needed a reference to in progress reviews on this
> topic. Thanks.)

The reason I want this is so that the upgrade process for keystone is:

pip install ./keystone

And not have to also have knowledge about the contents of the keystone
source directory. Today a lot of installation and upgrade logic for
packages is "left as an exercise for the reader", which means devstack,
ansible, rpms, debs all end up doing a bunch of work beyond pip install.
Minimizing that by bringing more of this back into what pip install does
will make for a more common base moving forward for everyone.


Sean Dague

More information about the OpenStack-dev mailing list