On 04/01/2016 09:39 AM, Sean Dague wrote:
On 04/01/2016 10:35 AM, Monty Taylor wrote:
On 04/01/2016 09:16 AM, Sean Dague wrote:
On 04/01/2016 10:08 AM, Monty Taylor wrote:
On 04/01/2016 08:45 AM, Sean Dague wrote:
The glance v2 work is currently blocked as there is no active spec,
would be great if someone from the glance team could get that rolling
again.
I started digging back through the patches in detail to figure out if
there are some infrastructure bits we could get in early regardless.
#1 - new methods for glance xenserver plugin
Let's take a simplified approach on this patch -
https://review.openstack.org/#/c/266933 and only change the
xenapi/etc/xapi.d/plugins/ content in the following ways.
- add upload/download_vhd_glance2 methods. Don't add an api parameter.
Add these methods mostly via copy/paste as we're optimizing for
deleting
v1 not for fixing v1.
That will put some infrastructure in place so we can just call the v2
actions based on decision from higher up the stack.
#2 - move discover major version back to glanceclient -
https://github.com/openstack/nova/blob/3cdaa30566c17a2add5d9163a0693c97dc1d065b/nova/image/glance.py#L108
I don't understand why this was ever in nova. This really should be
glanceclient.discover... something. It uses internal methods from
glanceclient and internal structures of the content returned.
FWIW, I use:
from glanceclient.common import utils as glance_utils
endpoint, detected_version = glance_utils.strip_version(endpoint)
To part of trying to figure this out as a consumer. Of course, that's
partially because like most of the openstack clients, there is no
exposed API for querying versions, since you have to tell the
constructor what major version you want to construct.
You can do that because you are using service catalogue entries for
glance. We're not there yet (and the path to get there is... odd for a
bunch of reasons).
The information that nova has is the config option api_servers -
https://github.com/openstack/nova/blob/3cdaa30566c17a2add5d9163a0693c97dc1d065b/nova/conf/glance.py#L25
Which are unversioned endpoints.
That just makes me want to cry.
Catching, if desired, should also be on the glanceclient side.
glanceclient.reset_version() could exist to clear any caching.
#3 - Ideally we'd also have a
client = glanceclient.AutoClient(endpoint, ... ) which basically does
glanceclient.discover and returns us the right client automatically.
client.version provides access to the version information if you
need to
figure out what version of a client you have.
You should just do:
import os_client_config
client = os_client_config.legacy_client('image') since all of that work
is pretty much already done.
If glanceclient grows the ability to be used without a priori knowledge
of the version, I'll certainly start to use it there.
That assumes credentials locally, right? Nova is building glance clients
with the context it received the request in as -
https://github.com/openstack/nova/blob/3cdaa30566c17a2add5d9163a0693c97dc1d065b/nova/image/glance.py#L78-L85
- so this is happening as the same user as initiated the Nova API call.
Yah- that totally works - keystoneauth has a token plugin which takes
these parameters. Also, all of the constructors can take endpoint
overrides and doing so will skip the catalog.
So perhaps an initial step towards getting to be able to use the catalog
to find the endpoint would be to start using the API in such a way that
takes either an auth_url or an image_endpoint.
I guess I don't see how those would all connect together, as
os-client-config requires clouds.yaml which isn't a part of how we
deploy servers (unless I'm missing something). If you want to propose a
patch to Nova demonstrating how this would all work, that might make it
clearer.
AH. I understand the misunderstanding. occ doesn't require a clouds.yaml
- that's just usually the most convenient way to express config in a
context where you either have complex settings or multiple clouds.
All of the things you can do can also be done directly by parameters to
the config constructor.
But I agree - the easiest way to take next step would be a patch - I'll
cook one up and we can talk about it. It may be a terrible idea ... it
just sounds so much like the problems overlap and solving them the first
time really sucked, so I'd hate to watch someone else have to solve them
again. I think I stabbed one of my eyes out the first time.
Monty
__________________________________________________________________________
OpenStack Development Mailing List (not for usage questions)
Unsubscribe: openstack-dev-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
