nova should not need glance servers in nova.conf

Bug #1084138 reported by Darren Birkett
38
This bug affects 7 people
Affects Status Importance Assigned to Milestone
OpenStack Compute (nova)
Expired
Undecided
Unassigned

Bug Description

nova currently requires manual entering of glance servers ip addresses/ports in nova.conf in order for operations with images (via the nova api) to work.

Given that all glance endpoint information is in keystone, nova should be looking up glance endpoint info from keystone rather than it's own config file.

Tags: glance
Revision history for this message
Ken Pepple (ken-pepple) wrote :

This assumes that you are using keystone and that all of your glance end-points are publicly accessible, which may or may not be the case.

I think a better idea is:

1. Check if glance_api_servers is set in nova.conf, if so use them
2. If glance servers are not set in nova.conf, then look them up in keystone (assuming that keystone is being used) and set glance_api_servers to the result
3. If neither, set it to None

Does this work ?

AFAIK it should be a fairly trivial fix to nova/image/glance.py

Revision history for this message
Dan Prince (dan-prince) wrote :

I actually did a branch that implements this during the Folsom RC cycle. It just didn't make the cut....

It did something very similar to what Ken outlines above.

Let me see if I can resurrect the code and put a new patch up for review.

Changed in nova:
assignee: nobody → Dan Prince (dan-prince)
Revision history for this message
Joe Breu (breu) wrote :

Ken's recommendation is absolutely acceptable.

Changed in nova:
status: New → Confirmed
importance: Undecided → Medium
Revision history for this message
Dan Prince (dan-prince) wrote :

Okay. Finally taking a step towards doing this... First we'll need this I think:

https://bugs.launchpad.net/python-keystoneclient/+bug/1122156

Changed in nova:
status: Confirmed → In Progress
Revision history for this message
Rafi Khardalian (rkhardalian) wrote :

The glance endpoints don't necessarily need to be publicly accessible. We have 3 different endpoint locations for the same glance entry to choose from (public, internal, admin). I would think Nova uses the internal entry.

Revision history for this message
Sean Dague (sdague) wrote :

This does not look like it's been implemented, and clearly not in progress after 18 months.

Changed in nova:
status: In Progress → Confirmed
assignee: Dan Prince (dan-prince) → nobody
Revision history for this message
Liyingjun (liyingjun) wrote :
Changed in nova:
assignee: nobody → Justin Shepherd (jshepher)
Revision history for this message
Justin Shepherd (jshepher) wrote :

I dont think this bug can be completed until after this blueprint: https://blueprints.launchpad.net/nova/+spec/use-glance-v2-api

Changed in nova:
assignee: Justin Shepherd (jshepher) → nobody
chandra (mishracp20)
Changed in nova:
assignee: nobody → chandra (mishracp20)
assignee: chandra (mishracp20) → nobody
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Fix proposed to nova (master)

Fix proposed to branch: master
Review: https://review.openstack.org/251926

Changed in nova:
assignee: nobody → Morgan Fainberg (mdrnstm)
status: Confirmed → In Progress
Revision history for this message
OpenStack Infra (hudson-openstack) wrote : Change abandoned on nova (master)

Change abandoned by Morgan Fainberg (<email address hidden>) on branch: master
Review: https://review.openstack.org/251926

Revision history for this message
Sean Dague (sdague) wrote :

The current challenge for this bug is the fact that we have no anonymous access to the service catalog. It is hopeful we'll get there one day.

Changed in nova:
status: In Progress → Confirmed
assignee: Morgan Fainberg (mdrnstm) → nobody
tags: added: glance
Revision history for this message
Markus Zoeller (markus_z) (mzoeller) wrote : Cleanup EOL bug report

This is an automated cleanup. This bug report has been closed because it
is older than 18 months and there is no open code change to fix this.
After this time it is unlikely that the circumstances which lead to
the observed issue can be reproduced.

If you can reproduce the bug, please:
* reopen the bug report (set to status "New")
* AND add the detailed steps to reproduce the issue (if applicable)
* AND leave a comment "CONFIRMED FOR: <RELEASE_NAME>"
  Only still supported release names are valid (LIBERTY, MITAKA, OCATA, NEWTON).
  Valid example: CONFIRMED FOR: LIBERTY

Changed in nova:
importance: Medium → Undecided
status: Confirmed → Expired
To post a comment you must log in.
This report contains Public information  
Everyone can see this information.

Duplicates of this bug

Other bug subscribers

Remote bug watches

Bug watches keep track of this bug in other bug trackers.