[Openstack] Quantum and HTTPD
Over the past day or so, I've made an effort to get Quantum running in
HTTPD.
My rationale has been to provide:
1. Native SSL support
2. IPv6
3. Certificate based Authentication
My goal has been to do this all on Essex without changing the projects'
python code base. I'm attempting to do this for all of the Openstack
components, and since Quantum has no dependencies, it seemed a good
next step after Keystone.
The obvious way to set it up should be to use a wsgi file with just
from paste.deploy.loadwsgi import loadapp
application = loadapp('config:/etc/quantum/quantum.conf', 'quantum')
But it fails due to issues finding the plugins (error log at the end of
the message). It deploys cleanly once I made the following changes to
quantum.
--- a/quantum/extensions/extensions.py
+++ b/quantum/extensions/extensions.py
@@ -538,8 +538,9 @@ class ResourceExtension(object):
# Returns the extention paths from a config entry and the __path__
# of quantum.extensions
def get_extensions_path(config=None):
-paths = ':'.join(quantum.extensions.__path__)
-if config:
-paths = ':'.join([config.get('api_extensions_path', ''), paths])
+#paths = ':'.join(quantum.extensions.__path__)
+paths = /etc/quantum/plugins/
+#if config:
+#paths = ':'.join([config.get('api_extensions_path', ''), paths])
return paths
Without this, there is a spurious error message due to the leading ':'
which puts a blank first element to the path. It also fails to find the
extensions path regardless of values put into config files etc. It is
this last issue which leads me to highly suggest we push Quantum to get
on the openstack-common bandwagon, as its Config file processing is
confusing and, I think, broken for the general case.
The other issue which leads me to suspect this approach won't work is
the fact that the quantum command line client accepts a hostname and a
port, but not an URL. So, while we could deploy quantum behind HTTPD
and port 443, it would basically be the root of the HTTP directory,
and we wouldn't be able to share the HTTPD instance. We couldn't do
https://hostname/quantum
and put it next to
https://hostname/keystone
Again, not without a code change.
Finally, there seems to be some support for SSL in Quantum. I note
that the quantum client has the option
-s, --ssl use ssl
which leads me to believe that it has been at least attempted. It may
be that the quantum server would not be severely impacted by the
overhead of SSL in Python.
Here's the HTTP error log if I don't make the above change:
[Thu Apr 12 11:21:13 2012] [info] Initial (No.1) HTTPS request received
for chil
d 7 (server ayoungstack.bos.redhat.com:443)
[Thu Apr 12 11:21:13 2012] [info] [client 10.16.187.36] mod_wsgi
(pid=8747, proc
ess='', application='ayoungstack.bos.redhat.com|/quantum/api'): Loading
WSGI scr
ipt '/var/www/cgi-bin/quantum/api'.
[Thu Apr 12 11:21:13 2012] [error]
ERROR:quantum.extensions.extensions:Extension
path /etc/quantum/extension doesn't exist!
[Thu Apr 12 11:21:13 2012] [error]
WARNING:quantum.extensions.extensions:extensi
on file portstats.py wasnt loaded due to cannot import name extensions
[Thu Apr 12 11:21:13 2012] [error]
WARNING:quantum.extensions.extensions:extensi
on Cisco Nova Tenant not supported by plugin
quantum.plugins.openvswitch.ovs_qu
antum_plugin.OVSQuantumPlugin object at 0x7f1fae80e450
[Thu Apr 12 11:21:13 2012] [error]
WARNING:quantum.extensions.extensions:extensi
on Cisco Port Profile not supported by plugin
quantum.plugins.openvswitch.ovs_q
uantum_plugin.OVSQuantumPlugin object at 0x7f1fae80e450
[Thu Apr 12 11:21:13 2012] [error]
WARNING:quantum.extensions.extensions:extensi
on Cisco Multiport not supported by plugin
quantum.plugins.openvswitch.ovs_quan
tum_plugin.OVSQuantumPlugin object at 0x7f1fae80e450
[Thu Apr 12 11:21:13 2012] [error]
WARNING:quantum.extensions.extensions:Did not
find expected name Extensions in
/opt/stack/quantum/quantum/extensions/extens
ions.py
___
Mailing list: https://launchpad.net/~openstack
Post to : openstack@lists.launchpad.net
Unsubscribe : https://launchpad.net/~openstack
More help : https://help.launchpad.net/ListHelp
Re: [Openstack] Quantum and HTTPD
On 04/12/2012 01:05 PM, Dan Wendlandt wrote:
Hi Adam, cool stuff!
Thanks for reporting the issues. I'm in favor of both changes your
suggest. Any interest on working on the openstack common stuff? More
details inline.
I'll probably help out with common stuff across the board, especially
WRT to running in HTTPD and PKI/Cert issues come up. My sorter term
goal is to harden an Essex deploy so that it can be used in places where
the policies dictate SSL for all communications.
Thanks for validating what I saw. Nice to know I don't have to beat my
head against it for too long.
Any idea how mature the SSL support is that Quantum is using right now?
Dan
On Thu, Apr 12, 2012 at 8:26 AM, Adam Young ayo...@redhat.com
mailto:ayo...@redhat.com wrote:
from paste.deploy.loadwsgi import loadapp
application = loadapp('config:/etc/quantum/quantum.conf', 'quantum')
But it fails due to issues finding the plugins (error log at the
end of the message). It deploys cleanly once I made the following
changes to quantum.
--- a/quantum/extensions/extensions.py
+++ b/quantum/extensions/extensions.py
@@ -538,8 +538,9 @@ class ResourceExtension(object):
# Returns the extention paths from a config entry and the __path__
# of quantum.extensions
def get_extensions_path(config=None):
-paths = ':'.join(quantum.extensions.__path__)
-if config:
-paths = ':'.join([config.get('api_extensions_path', ''),
paths])
+#paths = ':'.join(quantum.extensions.__path__)
+paths = //etc/quantum/plugins//
+#if config:
+#paths = ':'.join([config.get('api_extensions_path', ''),
paths])
return paths
Without this, there is a spurious error message due to the leading
':' which puts a blank first element to the path. It also fails
to find the extensions path regardless of values put into config
files etc. It is this last issue which leads me to highly suggest
we push Quantum to get on the openstack-common bandwagon, as its
Config file processing is confusing and, I think, broken for the
general case.
I'm a big proponent of using openstack common as much as possible in
Quantum. Much of this existing code was ripped from nova/glance/etc.
and is probably now out of date. I created a page in the wiki
identifying areas in quantum that are ripe for using openstack-common:
http://wiki.openstack.org/QuantumOpenstackCommon . Config if right at
the top :)
The other issue which leads me to suspect this approach won't work
is the fact that the quantum command line client accepts a
hostname and a port, but not an URL. So, while we could deploy
quantum behind HTTPD and port 443, it would basically be the root
of the HTTP directory, and we wouldn't be able to share the HTTPD
instance. We couldn't do
https://hostname/quantum
and put it next to
https://hostname/keystone
Again, not without a code change.
Finally, there seems to be some support for SSL in Quantum. I
note that the quantum client has the option
-s, --ssl use ssl
which leads me to believe that it has been at least attempted. It
may be that the quantum server would not be severely impacted by
the overhead of SSL in Python.
The quantum client is going to get a complete re-write in Folsom, as
this is one of our key community projects listed on the wiki:
http://wiki.openstack.org/QuantumStarterBugs
This new client will match other openstack clients in terms of
options, etc. This should mean that you can specify the endpoint as a
URL, which should take care of both the SSL and the non-root issues,
if I'm understanding you correctly.
Jason Koelker will be leading a session in the Quantum track on
redesigning the client, if folks are interested in helping out.
Here's the HTTP error log if I don't make the above change:
[Thu Apr 12 11:21:13 2012] [info] Initial (No.1) HTTPS request
received for chil
d 7 (server ayoungstack.bos.redhat.com:443
http://ayoungstack.bos.redhat.com:443)
[Thu Apr 12 11:21:13 2012] [info] [client 10.16.187.36] mod_wsgi
(pid=8747, proc
ess='', application='ayoungstack.bos.redhat.com
http://ayoungstack.bos.redhat.com|/quantum/api'): Loading WSGI scr
ipt '/var/www/cgi-bin/quantum/api'.
[Thu Apr 12 11:21:13 2012] [error]
ERROR:quantum.extensions.extensions:Extension
path /etc/quantum/extension doesn't exist!
[Thu Apr 12 11:21:13 2012] [error]
WARNING:quantum.extensions.extensions:extensi
on file portstats.py wasnt loaded due to cannot import name extensions
[Thu Apr 12 11:21:13 2012] [error]
WARNING:quantum.extensions.extensions:extensi
on Cisco Nova Tenant not supported by plugin
quantum.plugins.openvswitch.ovs_qu
antum_plugin.OVSQuantumPlugin object at 0x7f1fae80e450
[Thu Apr 12 11:21:13 2012]
Re: [Openstack] Quantum and HTTPD
On Thu, Apr 12, 2012 at 10:16 AM, Adam Young ayo...@redhat.com wrote:
On 04/12/2012 01:05 PM, Dan Wendlandt wrote:
Hi Adam, cool stuff!
Thanks for reporting the issues. I'm in favor of both changes your
suggest. Any interest on working on the openstack common stuff? More
details inline.
I'll probably help out with common stuff across the board, especially WRT
to running in HTTPD and PKI/Cert issues come up. My sorter term goal is to
harden an Essex deploy so that it can be used in places where the policies
dictate SSL for all communications.
Thanks for validating what I saw. Nice to know I don't have to beat my
head against it for too long.
Any idea how mature the SSL support is that Quantum is using right now?
I do not. I don't know of any deployments using it right now. Its likely
that we just have whatever code came along for the ride when the web
framework was borrowed from nova/glance. Salvatore might know, as he did a
lot of the heavy lifting on the Quantum API side.
Dan
Dan
On Thu, Apr 12, 2012 at 8:26 AM, Adam Young ayo...@redhat.com wrote:
from paste.deploy.loadwsgi import loadapp
application = loadapp('config:/etc/quantum/quantum.conf', 'quantum')
But it fails due to issues finding the plugins (error log at the end of
the message). It deploys cleanly once I made the following changes to
quantum.
--- a/quantum/extensions/extensions.py
+++ b/quantum/extensions/extensions.py
@@ -538,8 +538,9 @@ class ResourceExtension(object):
# Returns the extention paths from a config entry and the __path__
# of quantum.extensions
def get_extensions_path(config=None):
-paths = ':'.join(quantum.extensions.__path__)
-if config:
-paths = ':'.join([config.get('api_extensions_path', ''), paths])
+#paths = ':'.join(quantum.extensions.__path__)
+paths = */etc/quantum/plugins/*
+#if config:
+#paths = ':'.join([config.get('api_extensions_path', ''),
paths])
return paths
Without this, there is a spurious error message due to the leading ':'
which puts a blank first element to the path. It also fails to find the
extensions path regardless of values put into config files etc. It is this
last issue which leads me to highly suggest we push Quantum to get on the
openstack-common bandwagon, as its Config file processing is confusing
and, I think, broken for the general case.
I'm a big proponent of using openstack common as much as possible in
Quantum. Much of this existing code was ripped from nova/glance/etc. and
is probably now out of date. I created a page in the wiki identifying
areas in quantum that are ripe for using openstack-common:
http://wiki.openstack.org/QuantumOpenstackCommon . Config if right at
the top :)
The other issue which leads me to suspect this approach won't work is the
fact that the quantum command line client accepts a hostname and a port,
but not an URL. So, while we could deploy quantum behind HTTPD and port
443, it would basically be the root of the HTTP directory, and we
wouldn't be able to share the HTTPD instance. We couldn't do
https://hostname/quantum
and put it next to
https://hostname/keystone
Again, not without a code change.
Finally, there seems to be some support for SSL in Quantum. I note that
the quantum client has the option
-s, --ssl use ssl
which leads me to believe that it has been at least attempted. It may be
that the quantum server would not be severely impacted by the overhead of
SSL in Python.
The quantum client is going to get a complete re-write in Folsom, as
this is one of our key community projects listed on the wiki:
http://wiki.openstack.org/QuantumStarterBugs
This new client will match other openstack clients in terms of options,
etc. This should mean that you can specify the endpoint as a URL, which
should take care of both the SSL and the non-root issues, if I'm
understanding you correctly.
Jason Koelker will be leading a session in the Quantum track on
redesigning the client, if folks are interested in helping out.
Here's the HTTP error log if I don't make the above change:
[Thu Apr 12 11:21:13 2012] [info] Initial (No.1) HTTPS request received
for chil
d 7 (server ayoungstack.bos.redhat.com:443)
[Thu Apr 12 11:21:13 2012] [info] [client 10.16.187.36] mod_wsgi
(pid=8747, proc
ess='', application='ayoungstack.bos.redhat.com|/quantum/api'): Loading
WSGI scr
ipt '/var/www/cgi-bin/quantum/api'.
[Thu Apr 12 11:21:13 2012] [error]
ERROR:quantum.extensions.extensions:Extension
path /etc/quantum/extension doesn't exist!
[Thu Apr 12 11:21:13 2012] [error]
WARNING:quantum.extensions.extensions:extensi
on file portstats.py wasnt loaded due to cannot import name extensions
[Thu Apr 12 11:21:13 2012] [error]
WARNING:quantum.extensions.extensions:extensi
on Cisco Nova Tenant not supported by plugin
quantum.plugins.openvswitch.ovs_qu
