Re: [Openstack-operators] Glance issues after rdo icehouse - juno

[Kris G. Lindgren]

What does the [database] section of the configs look like?

Not only was the string changed but it was moved from the Default section to 
[database]:
# The SQLAlchemy connection string used to connect to the
# database (string value)
# Deprecated group/name - [DEFAULT]/sql_connection
# Deprecated group/name - [DATABASE]/sql_connection
# Deprecated group/name - [sql]/connection
#connection = None


Kris Lindgren
Senior Linux Systems Engineer
GoDaddy, LLC.


From: Nathan Stratton nat...@robotics.netmailto:nat...@robotics.net
Date: Monday, March 23, 2015 at 8:50 AM
To: openstack-oper. 
openstack-operators@lists.openstack.orgmailto:openstack-operators@lists.openstack.org
Subject: [Openstack-operators] Glance issues after rdo icehouse - juno

Followed:
http://docs.openstack.org/openstack-ops/content/upgrade-icehouse-juno.html

On the surface everything looked great, I can do a glance image-list, can 
import an image into glance, but I can't cinder create from glance --image-id. 
I get the following error:

2015-03-23 10:35:57.703 2954 INFO urllib3.connectionpool [-] Starting new HTTP 
connection (1): 10.71.0.218
2015-03-23 10:35:57.719 2954 INFO keystonemiddleware.auth_token [-] Auth Token 
confirmed use of v3.0 apis
2015-03-23 10:35:58.129 2954 INFO glance.wsgi.server 
[44e7b400-64bc-4042-a699-7bf6ed7118e5 b4397deb6a884a8c8e70fbc255ce6d80 
0ebcdedac0a3480
ca81050bfedd97cf1 - - -] Traceback (most recent call last):
  File /usr/lib/python2.7/site-packages/eventlet/wsgi.py, line 433, in 
handle_one_response
result = self.application(self.environ, start_response)
  File /usr/lib/python2.7/site-packages/webob/dec.py, line 130, in __call__
resp = self.call_func(req, *args, **self.kwargs)
  File /usr/lib/python2.7/site-packages/webob/dec.py, line 195, in call_func
return self.func(req, *args, **kwargs)
  File /usr/lib/python2.7/site-packages/glance/common/wsgi.py, line 394, in 
__call__
response = req.get_response(self.application)
  File /usr/lib/python2.7/site-packages/webob/request.py, line 1296, in send
application, catch_exc_info=False)
  File /usr/lib/python2.7/site-packages/webob/request.py, line 1260, in 
call_application
app_iter = application(self.environ, start_response)
  File /usr/lib/python2.7/site-packages/webob/dec.py, line 130, in __call__
resp = self.call_func(req, *args, **self.kwargs)
  File /usr/lib/python2.7/site-packages/webob/dec.py, line 195, in call_func
return self.func(req, *args, **kwargs)
  File /usr/lib/python2.7/site-packages/osprofiler/web.py, line 99, in 
__call__
return request.get_response(self.application)
  File /usr/lib/python2.7/site-packages/webob/request.py, line 1296, in send
application, catch_exc_info=False)
  File /usr/lib/python2.7/site-packages/webob/request.py, line 1260, in 
call_application
app_iter = application(self.environ, start_response)
  File /usr/lib/python2.7/site-packages/keystonemiddleware/auth_token.py, 
line 748, in __call__
return self._call_app(env, start_response)
  File /usr/lib/python2.7/site-packages/keystonemiddleware/auth_token.py, 
line 684, in _call_app
return self._app(env, _fake_start_response)
  File /usr/lib/python2.7/site-packages/webob/dec.py, line 130, in __call__
resp = self.call_func(req, *args, **self.kwargs)
  File /usr/lib/python2.7/site-packages/webob/dec.py, line 195, in call_func
return self.func(req, *args, **kwargs)
  File /usr/lib/python2.7/site-packages/glance/common/wsgi.py, line 394, in 
__call__
response = req.get_response(self.application)
  File /usr/lib/python2.7/site-packages/webob/request.py, line 1296, in send
application, catch_exc_info=False)
  File /usr/lib/python2.7/site-packages/webob/request.py, line 1260, in 
call_application
app_iter = application(self.environ, start_response)
  File /usr/lib/python2.7/site-packages/paste/urlmap.py, line 203, in __call__
return app(environ, start_response)
  File /usr/lib/python2.7/site-packages/webob/dec.py, line 144, in __call__
return resp(environ, start_response)
  File /usr/lib/python2.7/site-packages/routes/middleware.py, line 131, in 
__call__
response = self.app(environ, start_response)
  File /usr/lib/python2.7/site-packages/webob/dec.py, line 144, in __call__
return resp(environ, start_response)
  File /usr/lib/python2.7/site-packages/webob/dec.py, line 130, in __call__
resp = self.call_func(req, *args, **self.kwargs)
  File /usr/lib/python2.7/site-packages/webob/dec.py, line 195, in call_func
return self.func(req, *args, **kwargs)
  File /usr/lib/python2.7/site-packages/glance/common/wsgi.py, line 683, in 
__call__
request, **action_args)
  File /usr/lib/python2.7/site-packages/glance/common/wsgi.py, line 707, in 
dispatch
return method(*args, **kwargs)
  File /usr/lib/python2.7/site-packages/glance/api/v2/images.py, line 111, in 
show
return image_repo.get(image_id)
  File 

Re: [Openstack-operators] [openstack-dev] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!

[Van Leeuwen, Robert]

I think there are valid reasons to not use namespaces:

  *   Fewer moving parts == less can potentialy fail
  *   Troubleshooting is easier due to less places to look / need no 
familiarity with namespaces  tools
  *   If I remember correctly setting up a namespace can get really slow when 
you have a lot of them on a single machine

 IMHO, those shouldn’t be valid reasons anymore, since they were due iproute, 
 or sudo issues
 that have been corrected long ago, and all distros installing neutron are 
 supporting netns at this

Well, you exactly made my point:
There is lots that can and will go wrong with more moving parts.
That they are fixed at the moment does not mean that there will not be a new 
bug in the future…

Cheers,
Robert van Leeuwen
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [openstack-dev] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!

[Van Leeuwen, Robert]

  Are the setups out there *not* using the use_namespaces option? I'm
  curious as
  to why, and if it would be difficult to migrate such a setup to use
  namespaces.

At my previous employer we did not use namespaces.
This was due to a installation a few years ago on SL6 which did not have name 
space support at that time.

I think there are valid reasons to not use namespaces:

  *   Fewer moving parts == less can potentialy fail
  *   Troubleshooting is easier due to less places to look / need no 
familiarity with namespaces  tools
  *   If I remember correctly setting up a namespace can get really slow when 
you have a lot of them on a single machine

If you have a requirement for having all networks to be routable disabling 
namespaces does make sense.
Since I’m currently in the design phase for such an install I’d surely like to 
know if it is going to be deprecated.
Thx for letting us know about this :)

Cheers,
Robert van Leeuwen
___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators

Re: [Openstack-operators] [Neutron] Deprecating the use_namespaces option - Now's the time to speak up!

[gustavo panizzo (gfa)]

On 2015-03-21 02:57, Assaf Muller wrote:

Hello everyone,

The use_namespaces option in the L3 and DHCP Neutron agents controls if you
can create multiple routers and DHCP networks managed by a single L3/DHCP agent,
or if the agent manages only a single resource.

Are the setups out there *not* using the use_namespaces option? I'm curious as
to why, and if it would be difficult to migrate such a setup to use namespaces.


i'm using it in CI/test environment, where i need to connect to the vm 
and the control plane at the same time. (vm network is gre)




I'm asking because use_namespaces complicates Neutron code for what I gather
is an option that has not been relevant for years. I'd like to deprecate the 
option
for Kilo and remove it in Liberty.


in production i use namespaces, but only because is the default.
we have many clouds and none of them share the same ip range.


as other have said, i think is better to have less moving parts, 
namespaces had problems with kernel and iproute2 before and may have 
problems again




--
1AE0 322E B8F7 4717 BDEA BF1D 44BB 1BA7 9F6C 6333

___
OpenStack-operators mailing list
OpenStack-operators@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-operators