Open Stack

Brant,

We likely need to back port a simplified version of the wsgi files and/or make the Juno (and kilo) versions of dev stack use the same simplified / split files. Grenade doesn't re-run stack - so new files that are outside pip's purview won't be used afaik.

--Morgab

Sent via mobile

> On Jun 23, 2015, at 13:07, Brant Knudson <blk at acm.org> wrote:
> 
> 
> 
>> On Wed, Jun 17, 2015 at 1:21 PM, Sean Dague <sean at dague.net> wrote:
>> On 06/16/2015 05:25 PM, Chris Dent wrote:
>> > On Tue, 16 Jun 2015, Sean Dague wrote:
>> >
>> >> I was just looking at the patches that put Nova under apache wsgi for
>> >> the API, and there are a few things that I think are going in the wrong
>> >> direction. Largely I think because they were copied from the
>> >> lib/keystone code, which we've learned is kind of the wrong direction.
>> >
>> > Yes, that's certainly what I've done the few times I've done it.
>> > devstack is deeply encouraging of cargo culting for reasons that are
>> > not entirely clear.
>> 
>> Yeh, hence why I decided to put the brakes on a little here and get this
>> on the list.
>> 
>> >> The first is the fact that a big reason for putting {SERVICES} under
>> >> apache wsgi is we aren't running on a ton of weird unregistered ports.
>> >> We're running on 80 and 443 (when appropriate). In order to do this we
>> >> really need to namespace the API urls. Which means that service catalog
>> >> needs to be updated appropriately.
>> >
>> > So:
>> >
>> > a) I'm very glad to hear of this. I've been bristling about the weird
>> >    ports thing for the last year.
>> >
>> > b) You make it sound like there's been a plan in place to not use
>> >    those ports for quite some time and we'd get to that when we all
>> >    had some spare time. Where do I go to keep abreast of such plans?
>> 
>> Unfortunately, this is one of those "in the ether" kinds of plans. It's
>> been talked about for so long, but it never really got written down.
>> Hopefully this can be driven into the service catalog standardization
>> spec (or tag along somewhere close).
>> 
>> Or if nothing else, we're documenting it now on the mailing list as
>> permanent storage.
>> 
>> >> I also think this -
>> >> https://github.com/openstack-dev/devstack/blob/master/lib/nova#L266-L268
>> >> is completely wrong.
>> >>
>> >> The Apache configs should instead specify access rules such that the
>> >> installed console entry point of nova-api can be used in place as the
>> >> WSGIScript.
>> >
>> > I'm not able to parse this paragraph in any actionable way. The lines
>> > you reference are one of several ways of telling mod wsgi where the
>> > virtualenv is, which has to happen in some fashion if you are using
>> > a virtualenv.
>> >
>> > This doesn't appear to have anything to do with locating the module
>> > that contains the WSGI app, so I'm missing the connection. Can you
>> > explain please?
>> >
>> > (Basically I'm keen on getting gnocchi and ceilometer wsgi servers
>> > in devstack aligned with whatever the end game is, so knowing the plan
>> > makes it a bit easier.)
>> 
>> Gah, the problem of linking to 'master' with line numbers. The three
>> lines I cared about were:
>> 
>>     # copy proxy vhost and wsgi helper files
>>     sudo cp $NOVA_DIR/nova/wsgi/nova-api.py $NOVA_WSGI_DIR/nova-api
>>     sudo cp $NOVA_DIR/nova/wsgi/nova-ec2-api.py $NOVA_WSGI_DIR/nova-ec2-api
>> 
>> I don't think that we should be copying py files around to other
>> directories outside of normal pip install process. We should just have
>> mod_wsgi reference a thing that is installed in /usr/{local}/bin or
>> /usr/share via the python install process.
>> 
>> >> This should also make lines like -
>> >> https://github.com/openstack-dev/devstack/blob/master/lib/nova#L272 and
>> >> L274 uneeded. (The WSGI Script will be in a known place). It will also
>> >> make upgrades much more friendly.
>> >
>> > It sounds like maybe you are saying that the api console script and
>> > the module containing the wsgi 'application' variable ought to be the
>> > same thing. I don't reckon that's a great idea as the api console
>> > scripts will want to import a bunch of stuff that the wsgi application
>> > will not.
>> >
>> > Or I may be completely misreading you. It's been a long day, etc.
>> 
>> They don't need to be actually the same thing. They could be different
>> scripts, but they should be scripts that install via the normal pip
>> install process to a place, and we reference them by known name.
>> 
>> >> I think that we need to get these things sorted before any further
>> >> progression here. Volunteers welcomed to help get us there.
>> >
>> > Find me, happy to help. The sooner we can kill wacky port weirdness
>> > the better.
>> 
>> Agreed.
>> 
>>         -Sean
>> 
>> --
>> Sean Dague
>> http://dague.net
> 
> I've got a few related changes proposed to keystone and devstack:
> 
> https://review.openstack.org/#/c/193891/ - Changes Apache Httpd config so that /identity is the keystone public (aka main) handler and /identity_admin is the keystone admin handler. Httpd can have multiple aliases for the same wsgi handler so :5000 and :35357 still work. The follow-on patch at https://review.openstack.org/193894 shows some further work to change config so that the new endpoints are used by the tests. There are a lot of devstack variables that aren't going to apply or are going to be reinterpreted if we switch to this so I'll have to think about how that's going to work.
> 
> https://review.openstack.org/#/c/194442/ - Creates files keystone/httpd/admin.py and public.py , in addition to the old httpd/keystone.py that you had to copy and rename or symlink.
> 
> https://review.openstack.org/#/c/194729/ - Changes devstack to use keystone/httpd/admin.py and public.py rather than copying httpd/keystone.py. Grenade is failing so I'll need to figure that out.
> 
> - Brant
> 
>  
>> __________________________________________________________________________
>> 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
> 
> __________________________________________________________________________
> 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/20150623/ef69e94f/attachment.html>