Open Stack

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