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 <[email protected]> wrote: > > > >> On Wed, Jun 17, 2015 at 1:21 PM, Sean Dague <[email protected]> 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: [email protected]?subject:unsubscribe >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > __________________________________________________________________________ > OpenStack Development Mailing List (not for usage questions) > Unsubscribe: [email protected]?subject:unsubscribe > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
__________________________________________________________________________ OpenStack Development Mailing List (not for usage questions) Unsubscribe: [email protected]?subject:unsubscribe http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
