Re: [openstack-dev] [Nova][Glance] Support of v1 and v2 glance APIs in Nova
On 11/22/2013 09:07 PM, Matt Riedemann wrote: On Friday, November 22, 2013 5:52:17 PM, Russell Bryant wrote: On 11/22/2013 06:01 PM, Christopher Yeoh wrote: On Sat, Nov 23, 2013 at 8:33 AM, Matt Riedemann mrie...@linux.vnet.ibm.com mailto:mrie...@linux.vnet.ibm.com wrote: ... 21:51:42 dolphm i just hope that the version discovery mechanism is smart enough to realize when it's handed a versioned endpoint, and happily run with that ... 21:52:00 dolphm (by calling that endpoint and doing proper discovery) ... 21:52:24 russellb dolphm: yeah, need to handle that gracefully ... Just one point here (and perhaps I'm misunderstanding what was meant), but if the catalog points to a versioned endpoint shouldn't we just use that version rather than trying to discover what other versions may be available. Although we'll have cases of it just being set to a versioned endpoint because thats how it has been done in the past I think we should be making the assumption that if we're pointed to a specific version, that is the one we should be using. Agreed, and I think that's what Dolph and I meant. That also covers the override case that was expressed a few different times in this thread, giving the admin the ability to pin his environment to the version he knows and trusts during, for example, upgrades, and then slowly transitioning to a newer API. The nice thing with that approach is it should keep config options with hard-coded versions out of nova.conf which is what was being proposed in the glance and cinder v2 blueprint patches. There may still be value in the config options. The service catalog is also exposed to end users, so they may not appreciate having it tweaked to add and remove a version while working through an upgrade. If we updated services to always use the internalURL from the service catalog, then you could only mess with this version pinning on the internalURL and not the publicURL. It would be nice if we had a more concrete defition (and a matching implementation) of when each of these fields from the service catalog is used. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Glance] Support of v1 and v2 glance APIs in Nova
On Fri, 2013-11-22 at 20:07 -0600, Matt Riedemann wrote: On Friday, November 22, 2013 5:52:17 PM, Russell Bryant wrote: On 11/22/2013 06:01 PM, Christopher Yeoh wrote: On Sat, Nov 23, 2013 at 8:33 AM, Matt Riedemann mrie...@linux.vnet.ibm.com mailto:mrie...@linux.vnet.ibm.com wrote: ... 21:51:42 dolphm i just hope that the version discovery mechanism is smart enough to realize when it's handed a versioned endpoint, and happily run with that ... 21:52:00 dolphm (by calling that endpoint and doing proper discovery) ... 21:52:24 russellb dolphm: yeah, need to handle that gracefully ... Just one point here (and perhaps I'm misunderstanding what was meant), but if the catalog points to a versioned endpoint shouldn't we just use that version rather than trying to discover what other versions may be available. Although we'll have cases of it just being set to a versioned endpoint because thats how it has been done in the past I think we should be making the assumption that if we're pointed to a specific version, that is the one we should be using. Agreed, and I think that's what Dolph and I meant. That also covers the override case that was expressed a few different times in this thread, giving the admin the ability to pin his environment to the version he knows and trusts during, for example, upgrades, and then slowly transitioning to a newer API. The nice thing with that approach is it should keep config options with hard-coded versions out of nova.conf which is what was being proposed in the glance and cinder v2 blueprint patches. So the way we have this in keystone at least is that querying GET / will return all available API versions and querying /v2.0 for example is a similar result with just the v2 endpoint. So you can hard pin a version by using the versioned URL. I spoke to somebody the other day about the discovery process in services. The long term goal should be that the service catalog contains unversioned endpoints and that all clients should do discovery. For keystone the review has been underway for a while now: https://review.openstack.org/#/c/38414/ the basics of this should be able to be moved into OSLO for other projects if required. Jamie -- Thanks, Matt Riedemann ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Glance] Support of v1 and v2 glance APIs in Nova
On Thursday, November 21, 2013 9:56:41 AM, Matt Riedemann wrote: On 11/3/2013 5:22 AM, Joe Gordon wrote: On Nov 1, 2013 6:46 PM, John Garbutt j...@johngarbutt.com mailto:j...@johngarbutt.com wrote: On 29 October 2013 16:11, Eddie Sheffield eddie.sheffi...@rackspace.com mailto:eddie.sheffi...@rackspace.com wrote: John Garbutt j...@johngarbutt.com mailto:j...@johngarbutt.com said: Going back to Joe's comment: Can both of these cases be covered by configuring the keystone catalog? +1 If both v1 and v2 are present, pick v2, otherwise just pick what is in the catalogue. That seems cool. Not quite sure how the multiple glance endpoints works in the keystone catalog, but should work I assume. We hard code nova right now, and so we probably want to keep that route too? Nova doesn't use the catalog from Keystone when talking to Glance. There is a config value glance_api_servers which defines a list of Glance servers that gets randomized and cycled through. I assume that's what you're referring to with we hard code nova. But currently there's nowhere in this path (internal nova to glance) where the keystone catalog is available. Yes. I was not very clear. I am proposing we change that. We could try shoehorn the multiple glance nodes in the keystone catalog, then cache that in the context, but maybe that doesn't make sense. This is a separate change really. FYI: We cache the cinder endpoints from keystone catalog in the context already. So doing something like that with glance won't be without president. But clearly, we can't drop the direct configuration of glance servers for some time either. I think some of the confusion may be that Glanceclient at the programmatic client level doesn't talk to keystone. That happens happens higher in the CLI level which doesn't come into play here. From: Russell Bryant rbry...@redhat.com mailto:rbry...@redhat.com On 10/17/2013 03:12 PM, Eddie Sheffield wrote: Might I propose a compromise? 1) For the VERY short term, keep the config value and get the change otherwise reviewed and hopefully accepted. 2) Immediately file two blueprints: - python-glanceclient - expose a way to discover available versions - nova - depends on the glanceclient bp and allowing autodiscovery of glance version and making the config value optional (tho not deprecated / removed) Supporting both seems reasonable. At least then *most* people don't need to worry about it and it just works, but the override is there if necessary, since multiple people seem to be expressing a desire to have it available. +1 Can we just do this all at once? Adding this to glanceclient doesn't seem like a huge task. I worry about us never getting the full solution, but it seems to have got complicated. The glanceclient side is done, as far as allowing access to the list of available API versions on a given server. It's getting Nova to use this info that's a bit sticky. Hmm, OK. Could we not just cache the detected version, to reduce the impact of that decision. On 28 October 2013 15:13, Eddie Sheffield eddie.sheffi...@rackspace.com mailto:eddie.sheffi...@rackspace.com wrote: So...I've been working on this some more and hit a bit of a snag. The Glanceclient change was easy, but I see now that doing this in nova will require a pretty huge change in the way things work. Currently, the API version is grabbed from the config value, the appropriate driver is instantiated, and calls go through that. The problem comes in that the actually glance server isn't communicated with until very late in the process. Nothing sees the servers at the level where the driver is determined. Also there isn't a single glance server but a list of them, and in the even of certain communication failures the list is cycled through until success or a number of retries has passed. So to change this to auto configuring will require turning this upside down, cycling through the servers at a higher level, choosing the appropriate driver for that server, and handling retries at that same level. Doable, but a much larger task than I first was thinking. Also, I don't really want the added overhead of getting the api versions before every call, so I'm thinking that going through the list of servers at startup and discovering the versions then and caching that somehow would be helpful as well. Thoughts? I do worry about that overhead. But with Joe's comment, does it not just boil down to caching the keystone catalog in the context? I am not a fan of all the specific talk to glance code we have in nova, moving more of that into glanceclient can only be a good thing. For the XenServer itegration, for efficiency reasons, we need glance to talk from dom0, so it has dom0 making the final HTTP call.
Re: [openstack-dev] [Nova][Glance] Support of v1 and v2 glance APIs in Nova
On Sat, Nov 23, 2013 at 8:33 AM, Matt Riedemann mrie...@linux.vnet.ibm.comwrote: ... 21:51:42 dolphm i just hope that the version discovery mechanism is smart enough to realize when it's handed a versioned endpoint, and happily run with that ... 21:52:00 dolphm (by calling that endpoint and doing proper discovery) ... 21:52:24 russellb dolphm: yeah, need to handle that gracefully ... Just one point here (and perhaps I'm misunderstanding what was meant), but if the catalog points to a versioned endpoint shouldn't we just use that version rather than trying to discover what other versions may be available. Although we'll have cases of it just being set to a versioned endpoint because thats how it has been done in the past I think we should be making the assumption that if we're pointed to a specific version, that is the one we should be using. Chris ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Glance] Support of v1 and v2 glance APIs in Nova
On 11/3/2013 5:22 AM, Joe Gordon wrote: On Nov 1, 2013 6:46 PM, John Garbutt j...@johngarbutt.com mailto:j...@johngarbutt.com wrote: On 29 October 2013 16:11, Eddie Sheffield eddie.sheffi...@rackspace.com mailto:eddie.sheffi...@rackspace.com wrote: John Garbutt j...@johngarbutt.com mailto:j...@johngarbutt.com said: Going back to Joe's comment: Can both of these cases be covered by configuring the keystone catalog? +1 If both v1 and v2 are present, pick v2, otherwise just pick what is in the catalogue. That seems cool. Not quite sure how the multiple glance endpoints works in the keystone catalog, but should work I assume. We hard code nova right now, and so we probably want to keep that route too? Nova doesn't use the catalog from Keystone when talking to Glance. There is a config value glance_api_servers which defines a list of Glance servers that gets randomized and cycled through. I assume that's what you're referring to with we hard code nova. But currently there's nowhere in this path (internal nova to glance) where the keystone catalog is available. Yes. I was not very clear. I am proposing we change that. We could try shoehorn the multiple glance nodes in the keystone catalog, then cache that in the context, but maybe that doesn't make sense. This is a separate change really. FYI: We cache the cinder endpoints from keystone catalog in the context already. So doing something like that with glance won't be without president. But clearly, we can't drop the direct configuration of glance servers for some time either. I think some of the confusion may be that Glanceclient at the programmatic client level doesn't talk to keystone. That happens happens higher in the CLI level which doesn't come into play here. From: Russell Bryant rbry...@redhat.com mailto:rbry...@redhat.com On 10/17/2013 03:12 PM, Eddie Sheffield wrote: Might I propose a compromise? 1) For the VERY short term, keep the config value and get the change otherwise reviewed and hopefully accepted. 2) Immediately file two blueprints: - python-glanceclient - expose a way to discover available versions - nova - depends on the glanceclient bp and allowing autodiscovery of glance version and making the config value optional (tho not deprecated / removed) Supporting both seems reasonable. At least then *most* people don't need to worry about it and it just works, but the override is there if necessary, since multiple people seem to be expressing a desire to have it available. +1 Can we just do this all at once? Adding this to glanceclient doesn't seem like a huge task. I worry about us never getting the full solution, but it seems to have got complicated. The glanceclient side is done, as far as allowing access to the list of available API versions on a given server. It's getting Nova to use this info that's a bit sticky. Hmm, OK. Could we not just cache the detected version, to reduce the impact of that decision. On 28 October 2013 15:13, Eddie Sheffield eddie.sheffi...@rackspace.com mailto:eddie.sheffi...@rackspace.com wrote: So...I've been working on this some more and hit a bit of a snag. The Glanceclient change was easy, but I see now that doing this in nova will require a pretty huge change in the way things work. Currently, the API version is grabbed from the config value, the appropriate driver is instantiated, and calls go through that. The problem comes in that the actually glance server isn't communicated with until very late in the process. Nothing sees the servers at the level where the driver is determined. Also there isn't a single glance server but a list of them, and in the even of certain communication failures the list is cycled through until success or a number of retries has passed. So to change this to auto configuring will require turning this upside down, cycling through the servers at a higher level, choosing the appropriate driver for that server, and handling retries at that same level. Doable, but a much larger task than I first was thinking. Also, I don't really want the added overhead of getting the api versions before every call, so I'm thinking that going through the list of servers at startup and discovering the versions then and caching that somehow would be helpful as well. Thoughts? I do worry about that overhead. But with Joe's comment, does it not just boil down to caching the keystone catalog in the context? I am not a fan of all the specific talk to glance code we have in nova, moving more of that into glanceclient can only be a good thing. For the XenServer itegration, for efficiency reasons, we need glance to talk from dom0, so it has dom0 making the final HTTP call. So we would need a way of extracting that info from the glance
[openstack-dev] [Nova][Glance] Support of v1 and v2 glance APIs in Nova
Hi all, I see you are discussing that enabling glance API in Nova using Keystone catalog. I think there is one topic related to it that needs to be mentioned here. Hope we can take consideration. Current, Nova use config value glance_api_servers to talk to Glance, but there is one limitation using this configure that glance_api_servers has hard coded Glance API format, we can not configure arbitrary url using this configure, I have created a blueprint to track it. You can get more information https://blueprints.launchpad.net/nova/+spec/nova-enable-glance-arbitrary-url The related bug is https://bugs.launchpad.net/nova/+bug/1220131 On Nov 1, 2013 6:46 PM, John Garbutt j...@johngarbutt.com wrote: On 29 October 2013 16:11, Eddie Sheffield eddie.sheffi...@rackspace.com wrote: John Garbutt j...@johngarbutt.com said: Going back to Joe's comment: Can both of these cases be covered by configuring the keystone catalog? +1 If both v1 and v2 are present, pick v2, otherwise just pick what is in the catalogue. That seems cool. Not quite sure how the multiple glance endpoints works in the keystone catalog, but should work I assume. We hard code nova right now, and so we probably want to keep that route too? Nova doesn't use the catalog from Keystone when talking to Glance. There is a config value glance_api_servers which defines a list of Glance servers that gets randomized and cycled through. I assume that's what you're referring to with we hard code nova. But currently there's nowhere in this path (internal nova to glance) where the keystone catalog is available. Yes. I was not very clear. I am proposing we change that. We could try shoehorn the multiple glance nodes in the keystone catalog, then cache that in the context, but maybe that doesn't make sense. This is a separate change really. FYI: We cache the cinder endpoints from keystone catalog in the context already. So doing something like that with glance won't be without president. But clearly, we can't drop the direct configuration of glance servers for some time either. I think some of the confusion may be that Glanceclient at the programmatic client level doesn't talk to keystone. That happens happens higher in the CLI level which doesn't come into play here. From: Russell Bryant rbry...@redhat.com On 10/17/2013 03:12 PM, Eddie Sheffield wrote: Might I propose a compromise? 1) For the VERY short term, keep the config value and get the change otherwise reviewed and hopefully accepted. 2) Immediately file two blueprints: - python-glanceclient - expose a way to discover available versions - nova - depends on the glanceclient bp and allowing autodiscovery of glance version and making the config value optional (tho not deprecated / removed) Supporting both seems reasonable. At least then *most* people don't need to worry about it and it just works, but the override is there if necessary, since multiple people seem to be expressing a desire to have it available. +1 Can we just do this all at once? Adding this to glanceclient doesn't seem like a huge task. I worry about us never getting the full solution, but it seems to have got complicated. The glanceclient side is done, as far as allowing access to the list of available API versions on a given server. It's getting Nova to use this info that's a bit sticky. Hmm, OK. Could we not just cache the detected version, to reduce the impact of that decision. On 28 October 2013 15:13, Eddie Sheffield eddie.sheffi...@rackspace.com wrote: So...I've been working on this some more and hit a bit of a snag. The Glanceclient change was easy, but I see now that doing this in nova will require a pretty huge change in the way things work. Currently, the API version is grabbed from the config value, the appropriate driver is instantiated, and calls go through that. The problem comes in that the actually glance server isn't communicated with until very late in the process. Nothing sees the servers at the level where the driver is determined. Also there isn't a single glance server but a list of them, and in the even of certain communication failures the list is cycled through until success or a number of retries has passed. So to change this to auto configuring will require turning this upside down, cycling through the servers at a higher level, choosing the appropriate driver for that server, and handling retries at that same level. Doable, but a much larger task than I first was thinking. Also, I don't really want the added overhead of getting the api versions before every call, so I'm thinking that going through the list of servers at startup and discovering the versions then and caching that somehow would be helpful as well. Thoughts? I do worry about that overhead. But with Joe's comment, does it not just boil down
Re: [openstack-dev] [Nova][Glance] Support of v1 and v2 glance APIs in Nova
On Nov 1, 2013 6:46 PM, John Garbutt j...@johngarbutt.com wrote: On 29 October 2013 16:11, Eddie Sheffield eddie.sheffi...@rackspace.com wrote: John Garbutt j...@johngarbutt.com said: Going back to Joe's comment: Can both of these cases be covered by configuring the keystone catalog? +1 If both v1 and v2 are present, pick v2, otherwise just pick what is in the catalogue. That seems cool. Not quite sure how the multiple glance endpoints works in the keystone catalog, but should work I assume. We hard code nova right now, and so we probably want to keep that route too? Nova doesn't use the catalog from Keystone when talking to Glance. There is a config value glance_api_servers which defines a list of Glance servers that gets randomized and cycled through. I assume that's what you're referring to with we hard code nova. But currently there's nowhere in this path (internal nova to glance) where the keystone catalog is available. Yes. I was not very clear. I am proposing we change that. We could try shoehorn the multiple glance nodes in the keystone catalog, then cache that in the context, but maybe that doesn't make sense. This is a separate change really. FYI: We cache the cinder endpoints from keystone catalog in the context already. So doing something like that with glance won't be without president. But clearly, we can't drop the direct configuration of glance servers for some time either. I think some of the confusion may be that Glanceclient at the programmatic client level doesn't talk to keystone. That happens happens higher in the CLI level which doesn't come into play here. From: Russell Bryant rbry...@redhat.com On 10/17/2013 03:12 PM, Eddie Sheffield wrote: Might I propose a compromise? 1) For the VERY short term, keep the config value and get the change otherwise reviewed and hopefully accepted. 2) Immediately file two blueprints: - python-glanceclient - expose a way to discover available versions - nova - depends on the glanceclient bp and allowing autodiscovery of glance version and making the config value optional (tho not deprecated / removed) Supporting both seems reasonable. At least then *most* people don't need to worry about it and it just works, but the override is there if necessary, since multiple people seem to be expressing a desire to have it available. +1 Can we just do this all at once? Adding this to glanceclient doesn't seem like a huge task. I worry about us never getting the full solution, but it seems to have got complicated. The glanceclient side is done, as far as allowing access to the list of available API versions on a given server. It's getting Nova to use this info that's a bit sticky. Hmm, OK. Could we not just cache the detected version, to reduce the impact of that decision. On 28 October 2013 15:13, Eddie Sheffield eddie.sheffi...@rackspace.com wrote: So...I've been working on this some more and hit a bit of a snag. The Glanceclient change was easy, but I see now that doing this in nova will require a pretty huge change in the way things work. Currently, the API version is grabbed from the config value, the appropriate driver is instantiated, and calls go through that. The problem comes in that the actually glance server isn't communicated with until very late in the process. Nothing sees the servers at the level where the driver is determined. Also there isn't a single glance server but a list of them, and in the even of certain communication failures the list is cycled through until success or a number of retries has passed. So to change this to auto configuring will require turning this upside down, cycling through the servers at a higher level, choosing the appropriate driver for that server, and handling retries at that same level. Doable, but a much larger task than I first was thinking. Also, I don't really want the added overhead of getting the api versions before every call, so I'm thinking that going through the list of servers at startup and discovering the versions then and caching that somehow would be helpful as well. Thoughts? I do worry about that overhead. But with Joe's comment, does it not just boil down to caching the keystone catalog in the context? I am not a fan of all the specific talk to glance code we have in nova, moving more of that into glanceclient can only be a good thing. For the XenServer itegration, for efficiency reasons, we need glance to talk from dom0, so it has dom0 making the final HTTP call. So we would need a way of extracting that info from the glance client. But that seems better than having that code in nova. I know in Glance we've largely taken the view that the client should be as thin and lightweight as possible so users of the client can make use of it however they best see fit. There was an earlier patch that would have moved
Re: [openstack-dev] [Nova][Glance] Support of v1 and v2 glance APIs in Nova
On 29 October 2013 16:11, Eddie Sheffield eddie.sheffi...@rackspace.com wrote: John Garbutt j...@johngarbutt.com said: Going back to Joe's comment: Can both of these cases be covered by configuring the keystone catalog? +1 If both v1 and v2 are present, pick v2, otherwise just pick what is in the catalogue. That seems cool. Not quite sure how the multiple glance endpoints works in the keystone catalog, but should work I assume. We hard code nova right now, and so we probably want to keep that route too? Nova doesn't use the catalog from Keystone when talking to Glance. There is a config value glance_api_servers which defines a list of Glance servers that gets randomized and cycled through. I assume that's what you're referring to with we hard code nova. But currently there's nowhere in this path (internal nova to glance) where the keystone catalog is available. Yes. I was not very clear. I am proposing we change that. We could try shoehorn the multiple glance nodes in the keystone catalog, then cache that in the context, but maybe that doesn't make sense. This is a separate change really. But clearly, we can't drop the direct configuration of glance servers for some time either. I think some of the confusion may be that Glanceclient at the programmatic client level doesn't talk to keystone. That happens happens higher in the CLI level which doesn't come into play here. From: Russell Bryant rbry...@redhat.com On 10/17/2013 03:12 PM, Eddie Sheffield wrote: Might I propose a compromise? 1) For the VERY short term, keep the config value and get the change otherwise reviewed and hopefully accepted. 2) Immediately file two blueprints: - python-glanceclient - expose a way to discover available versions - nova - depends on the glanceclient bp and allowing autodiscovery of glance version and making the config value optional (tho not deprecated / removed) Supporting both seems reasonable. At least then *most* people don't need to worry about it and it just works, but the override is there if necessary, since multiple people seem to be expressing a desire to have it available. +1 Can we just do this all at once? Adding this to glanceclient doesn't seem like a huge task. I worry about us never getting the full solution, but it seems to have got complicated. The glanceclient side is done, as far as allowing access to the list of available API versions on a given server. It's getting Nova to use this info that's a bit sticky. Hmm, OK. Could we not just cache the detected version, to reduce the impact of that decision. On 28 October 2013 15:13, Eddie Sheffield eddie.sheffi...@rackspace.com wrote: So...I've been working on this some more and hit a bit of a snag. The Glanceclient change was easy, but I see now that doing this in nova will require a pretty huge change in the way things work. Currently, the API version is grabbed from the config value, the appropriate driver is instantiated, and calls go through that. The problem comes in that the actually glance server isn't communicated with until very late in the process. Nothing sees the servers at the level where the driver is determined. Also there isn't a single glance server but a list of them, and in the even of certain communication failures the list is cycled through until success or a number of retries has passed. So to change this to auto configuring will require turning this upside down, cycling through the servers at a higher level, choosing the appropriate driver for that server, and handling retries at that same level. Doable, but a much larger task than I first was thinking. Also, I don't really want the added overhead of getting the api versions before every call, so I'm thinking that going through the list of servers at startup and discovering the versions then and caching that somehow would be helpful as well. Thoughts? I do worry about that overhead. But with Joe's comment, does it not just boil down to caching the keystone catalog in the context? I am not a fan of all the specific talk to glance code we have in nova, moving more of that into glanceclient can only be a good thing. For the XenServer itegration, for efficiency reasons, we need glance to talk from dom0, so it has dom0 making the final HTTP call. So we would need a way of extracting that info from the glance client. But that seems better than having that code in nova. I know in Glance we've largely taken the view that the client should be as thin and lightweight as possible so users of the client can make use of it however they best see fit. There was an earlier patch that would have moved the whole image service layer into glanceclient that was rejected. So I think there is a division in philosophies here as well Hmm, I would be a fan of supporting both use cases, nova style and more complex. Just seems better for glance to own as much as
Re: [openstack-dev] [Nova][Glance] Support of v1 and v2 glance APIs in Nova
Mark Washenberger mark.washenber...@markwash.net said: ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I am not a fan of all the specific talk to glance code we have in nova, moving more of that into glanceclient can only be a good thing. For the XenServer itegration, for efficiency reasons, we need glance to talk from dom0, so it has dom0 making the final HTTP call. So we would need a way of extracting that info from the glance client. But that seems better than having that code in nova. I know in Glance we've largely taken the view that the client should be as thin and lightweight as possible so users of the client can make use of it however they best see fit. There was an earlier patch that would have moved the whole image service layer into glanceclient that was rejected. So I think there is a division in philosophies here as well. Indeed, I think I was being a bit of a stinker on this issue. Mea culpa. I've had some time to think and I realized that there is a bit of complexity here that needs to be untangled. Historically, the glance client (and I think *most* openstack clients) have had versioned directories that attempt to be as faithful a representation of the given version of an API as possible. That was a history I was trying to maintain for continuity's sake in the past. However, with some more thought, this historical objective seems literally insane to me. In fact, it makes it basically impossible to publish a useful client library because such a library has no control to smooth over backwards incompatibility from one major version to the next. At this point I'm a lot more interested in Ghe's patch ( https://review.openstack.org/#/c/33327/) I'm a bit concerned that we might need to make the image client interface even more stripped down in order to focus support on the intersection of v1 and v2 of the image api. In particular, I'm not sure how well the old nova image service api will deal with invalid property values (v2 has property schemas). And there's no support AFAICT for image sharing, and image sharing should not be used in v1 for security reasons. On the other hand, maybe we don't really want to move forward based on how nova viewed the image repository in the past. There might be a better image client api waiting to be discovered by some intrepid openstacker. This could make sense as well if there is some traction for eventually deprecating the v1 api. But in any case, it does sound like we need an image client with its own proper api that can be ported from version to version. /ramble Hmmm, pretty big turnaround but one I mostly agree with. I would like to see more discussion on what this unified interface would look like rather than just pulling in what's in Nova (tho we might converge on that anyway.) I do worry about what to do about unique functionality in the various API versions. It might be that the most common functionality is exposed in the service interface, and if you need some of the more API specific functionality you can use the lower-level client interfaces. Alternatively the interface might contain everything possible; and where it can, smooth over the differences and where it can't, raise NotImplemented exceptions. Mark, can we get some discussion of this in our Glance meeting tomorrow (10/31)? Eddie ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Glance] Support of v1 and v2 glance APIs in Nova
On Wed, Oct 30, 2013 at 9:04 AM, Eddie Sheffield eddie.sheffi...@rackspace.com wrote: Mark Washenberger mark.washenber...@markwash.net said: ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev I am not a fan of all the specific talk to glance code we have in nova, moving more of that into glanceclient can only be a good thing. For the XenServer itegration, for efficiency reasons, we need glance to talk from dom0, so it has dom0 making the final HTTP call. So we would need a way of extracting that info from the glance client. But that seems better than having that code in nova. I know in Glance we've largely taken the view that the client should be as thin and lightweight as possible so users of the client can make use of it however they best see fit. There was an earlier patch that would have moved the whole image service layer into glanceclient that was rejected. So I think there is a division in philosophies here as well. Indeed, I think I was being a bit of a stinker on this issue. Mea culpa. I've had some time to think and I realized that there is a bit of complexity here that needs to be untangled. Historically, the glance client (and I think *most* openstack clients) have had versioned directories that attempt to be as faithful a representation of the given version of an API as possible. That was a history I was trying to maintain for continuity's sake in the past. However, with some more thought, this historical objective seems literally insane to me. In fact, it makes it basically impossible to publish a useful client library because such a library has no control to smooth over backwards incompatibility from one major version to the next. At this point I'm a lot more interested in Ghe's patch ( https://review.openstack.org/#/c/33327/) I'm a bit concerned that we might need to make the image client interface even more stripped down in order to focus support on the intersection of v1 and v2 of the image api. In particular, I'm not sure how well the old nova image service api will deal with invalid property values (v2 has property schemas). And there's no support AFAICT for image sharing, and image sharing should not be used in v1 for security reasons. On the other hand, maybe we don't really want to move forward based on how nova viewed the image repository in the past. There might be a better image client api waiting to be discovered by some intrepid openstacker. This could make sense as well if there is some traction for eventually deprecating the v1 api. But in any case, it does sound like we need an image client with its own proper api that can be ported from version to version. /ramble Hmmm, pretty big turnaround but one I mostly agree with. I would like to see more discussion on what this unified interface would look like rather than just pulling in what's in Nova (tho we might converge on that anyway.) I do worry about what to do about unique functionality in the various API versions. It might be that the most common functionality is exposed in the service interface, and if you need some of the more API specific functionality you can use the lower-level client interfaces. Alternatively the interface might contain everything possible; and where it can, smooth over the differences and where it can't, raise NotImplemented exceptions. Mark, can we get some discussion of this in our Glance meeting tomorrow (10/31)? Definitely, adding it to the agenda now. Eddie ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Glance] Support of v1 and v2 glance APIs in Nova
Going back to Joe's comment: Can both of these cases be covered by configuring the keystone catalog? +1 If both v1 and v2 are present, pick v2, otherwise just pick what is in the catalogue. That seems cool. Not quite sure how the multiple glance endpoints works in the keystone catalog, but should work I assume. We hard code nova right now, and so we probably want to keep that route too? From: Russell Bryant rbry...@redhat.com On 10/17/2013 03:12 PM, Eddie Sheffield wrote: Might I propose a compromise? 1) For the VERY short term, keep the config value and get the change otherwise reviewed and hopefully accepted. 2) Immediately file two blueprints: - python-glanceclient - expose a way to discover available versions - nova - depends on the glanceclient bp and allowing autodiscovery of glance version and making the config value optional (tho not deprecated / removed) Supporting both seems reasonable. At least then *most* people don't need to worry about it and it just works, but the override is there if necessary, since multiple people seem to be expressing a desire to have it available. +1 Can we just do this all at once? Adding this to glanceclient doesn't seem like a huge task. I worry about us never getting the full solution, but it seems to have got complicated. On 28 October 2013 15:13, Eddie Sheffield eddie.sheffi...@rackspace.com wrote: So...I've been working on this some more and hit a bit of a snag. The Glanceclient change was easy, but I see now that doing this in nova will require a pretty huge change in the way things work. Currently, the API version is grabbed from the config value, the appropriate driver is instantiated, and calls go through that. The problem comes in that the actually glance server isn't communicated with until very late in the process. Nothing sees the servers at the level where the driver is determined. Also there isn't a single glance server but a list of them, and in the even of certain communication failures the list is cycled through until success or a number of retries has passed. So to change this to auto configuring will require turning this upside down, cycling through the servers at a higher level, choosing the appropriate driver for that server, and handling retries at that same level. Doable, but a much larger task than I first was thinking. Also, I don't really want the added overhead of getting the api versions before every call, so I'm thinking that going through the list of servers at startup and discovering the versions then and caching that somehow would be helpful as well. Thoughts? I do worry about that overhead. But with Joe's comment, does it not just boil down to caching the keystone catalog in the context? I am not a fan of all the specific talk to glance code we have in nova, moving more of that into glanceclient can only be a good thing. For the XenServer itegration, for efficiency reasons, we need glance to talk from dom0, so it has dom0 making the final HTTP call. So we would need a way of extracting that info from the glance client. But that seems better than having that code in nova. John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Glance] Support of v1 and v2 glance APIs in Nova
I haven't look at the review proposed yet one week ago, but some time ago, we needed something similar for Ironic (nova, ironic and cinder share almost the same code for the glance driver), but didn't make it. In case someone wants to take a look: https://review.openstack.org/#/c/33327/ I'll take a look to the bp and the solutions proposed to see if something can be reused. Ghe Rivero On Tue, Oct 29, 2013 at 1:19 PM, John Garbutt j...@johngarbutt.com wrote: Going back to Joe's comment: Can both of these cases be covered by configuring the keystone catalog? +1 If both v1 and v2 are present, pick v2, otherwise just pick what is in the catalogue. That seems cool. Not quite sure how the multiple glance endpoints works in the keystone catalog, but should work I assume. We hard code nova right now, and so we probably want to keep that route too? From: Russell Bryant rbry...@redhat.com On 10/17/2013 03:12 PM, Eddie Sheffield wrote: Might I propose a compromise? 1) For the VERY short term, keep the config value and get the change otherwise reviewed and hopefully accepted. 2) Immediately file two blueprints: - python-glanceclient - expose a way to discover available versions - nova - depends on the glanceclient bp and allowing autodiscovery of glance version and making the config value optional (tho not deprecated / removed) Supporting both seems reasonable. At least then *most* people don't need to worry about it and it just works, but the override is there if necessary, since multiple people seem to be expressing a desire to have it available. +1 Can we just do this all at once? Adding this to glanceclient doesn't seem like a huge task. I worry about us never getting the full solution, but it seems to have got complicated. On 28 October 2013 15:13, Eddie Sheffield eddie.sheffi...@rackspace.com wrote: So...I've been working on this some more and hit a bit of a snag. The Glanceclient change was easy, but I see now that doing this in nova will require a pretty huge change in the way things work. Currently, the API version is grabbed from the config value, the appropriate driver is instantiated, and calls go through that. The problem comes in that the actually glance server isn't communicated with until very late in the process. Nothing sees the servers at the level where the driver is determined. Also there isn't a single glance server but a list of them, and in the even of certain communication failures the list is cycled through until success or a number of retries has passed. So to change this to auto configuring will require turning this upside down, cycling through the servers at a higher level, choosing the appropriate driver for that server, and handling retries at that same level. Doable, but a much larger task than I first was thinking. Also, I don't really want the added overhead of getting the api versions before every call, so I'm thinking that going through the list of servers at startup and discovering the versions then and caching that somehow would be helpful as well. Thoughts? I do worry about that overhead. But with Joe's comment, does it not just boil down to caching the keystone catalog in the context? I am not a fan of all the specific talk to glance code we have in nova, moving more of that into glanceclient can only be a good thing. For the XenServer itegration, for efficiency reasons, we need glance to talk from dom0, so it has dom0 making the final HTTP call. So we would need a way of extracting that info from the glance client. But that seems better than having that code in nova. John ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev -- Pinky: Gee, Brain, what do you want to do tonight? The Brain: The same thing we do every night, Pinky—try to take over the world! .''`. Pienso, Luego Incordio : :' : `. `' `-www.debian.orgwww.openstack.com GPG Key: 26F020F7 GPG fingerprint: 4986 39DA D152 050B 4699 9A71 66DB 5A36 26F0 20F7 ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Glance] Support of v1 and v2 glance APIs in Nova
John Garbutt j...@johngarbutt.com said: Going back to Joe's comment: Can both of these cases be covered by configuring the keystone catalog? +1 If both v1 and v2 are present, pick v2, otherwise just pick what is in the catalogue. That seems cool. Not quite sure how the multiple glance endpoints works in the keystone catalog, but should work I assume. We hard code nova right now, and so we probably want to keep that route too? Nova doesn't use the catalog from Keystone when talking to Glance. There is a config value glance_api_servers which defines a list of Glance servers that gets randomized and cycled through. I assume that's what you're referring to with we hard code nova. But currently there's nowhere in this path (internal nova to glance) where the keystone catalog is available. I think some of the confusion may be that Glanceclient at the programmatic client level doesn't talk to keystone. That happens happens higher in the CLI level which doesn't come into play here. From: Russell Bryant rbry...@redhat.com On 10/17/2013 03:12 PM, Eddie Sheffield wrote: Might I propose a compromise? 1) For the VERY short term, keep the config value and get the change otherwise reviewed and hopefully accepted. 2) Immediately file two blueprints: - python-glanceclient - expose a way to discover available versions - nova - depends on the glanceclient bp and allowing autodiscovery of glance version and making the config value optional (tho not deprecated / removed) Supporting both seems reasonable. At least then *most* people don't need to worry about it and it just works, but the override is there if necessary, since multiple people seem to be expressing a desire to have it available. +1 Can we just do this all at once? Adding this to glanceclient doesn't seem like a huge task. I worry about us never getting the full solution, but it seems to have got complicated. The glanceclient side is done, as far as allowing access to the list of available API versions on a given server. It's getting Nova to use this info that's a bit sticky. On 28 October 2013 15:13, Eddie Sheffield eddie.sheffi...@rackspace.com wrote: So...I've been working on this some more and hit a bit of a snag. The Glanceclient change was easy, but I see now that doing this in nova will require a pretty huge change in the way things work. Currently, the API version is grabbed from the config value, the appropriate driver is instantiated, and calls go through that. The problem comes in that the actually glance server isn't communicated with until very late in the process. Nothing sees the servers at the level where the driver is determined. Also there isn't a single glance server but a list of them, and in the even of certain communication failures the list is cycled through until success or a number of retries has passed. So to change this to auto configuring will require turning this upside down, cycling through the servers at a higher level, choosing the appropriate driver for that server, and handling retries at that same level. Doable, but a much larger task than I first was thinking. Also, I don't really want the added overhead of getting the api versions before every call, so I'm thinking that going through the list of servers at startup and discovering the versions then and caching that somehow would be helpful as well. Thoughts? I do worry about that overhead. But with Joe's comment, does it not just boil down to caching the keystone catalog in the context? I am not a fan of all the specific talk to glance code we have in nova, moving more of that into glanceclient can only be a good thing. For the XenServer itegration, for efficiency reasons, we need glance to talk from dom0, so it has dom0 making the final HTTP call. So we would need a way of extracting that info from the glance client. But that seems better than having that code in nova. I know in Glance we've largely taken the view that the client should be as thin and lightweight as possible so users of the client can make use of it however they best see fit. There was an earlier patch that would have moved the whole image service layer into glanceclient that was rejected. So I think there is a division in philosophies here as well. Eddie ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Glance] Support of v1 and v2 glance APIs in Nova
I am not a fan of all the specific talk to glance code we have in nova, moving more of that into glanceclient can only be a good thing. For the XenServer itegration, for efficiency reasons, we need glance to talk from dom0, so it has dom0 making the final HTTP call. So we would need a way of extracting that info from the glance client. But that seems better than having that code in nova. I know in Glance we've largely taken the view that the client should be as thin and lightweight as possible so users of the client can make use of it however they best see fit. There was an earlier patch that would have moved the whole image service layer into glanceclient that was rejected. So I think there is a division in philosophies here as well. Indeed, I think I was being a bit of a stinker on this issue. Mea culpa. I've had some time to think and I realized that there is a bit of complexity here that needs to be untangled. Historically, the glance client (and I think *most* openstack clients) have had versioned directories that attempt to be as faithful a representation of the given version of an API as possible. That was a history I was trying to maintain for continuity's sake in the past. However, with some more thought, this historical objective seems literally insane to me. In fact, it makes it basically impossible to publish a useful client library because such a library has no control to smooth over backwards incompatibility from one major version to the next. At this point I'm a lot more interested in Ghe's patch ( https://review.openstack.org/#/c/33327/) I'm a bit concerned that we might need to make the image client interface even more stripped down in order to focus support on the intersection of v1 and v2 of the image api. In particular, I'm not sure how well the old nova image service api will deal with invalid property values (v2 has property schemas). And there's no support AFAICT for image sharing, and image sharing should not be used in v1 for security reasons. On the other hand, maybe we don't really want to move forward based on how nova viewed the image repository in the past. There might be a better image client api waiting to be discovered by some intrepid openstacker. This could make sense as well if there is some traction for eventually deprecating the v1 api. But in any case, it does sound like we need an image client with its own proper api that can be ported from version to version. /ramble ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Glance] Support of v1 and v2 glance APIs in Nova
I'd just like to echo Tim Bell's comments. From a rolling upgrade perspective where you have Glance nodes behind a load balancer we'd probably need a way to manually 'hold back' on v1 until all nodes are upgraded to support v2 aswell. (Otherwise your auto-discovery may hit an upgraded node but your subsequent API request could hit a node which hasn't been upgraded yet.) On 10/17/2013 03:12 PM, Eddie Sheffield wrote: I don't oppose having the version autodiscovered. But I do feel the option should be available to override if desired. I've had many problems with over the years with autoconfiguring systems not doing what I need to be willing to depend on them 100% without a manual override available if at all possible. I'm thinking particularly for testing or upgrade evaluation scenarios. For example, you want to turn on v2 in glance and evaluate it for a bit before committing to using it for all of your nova nodes. The current patch also had a couple of comments from Dan Prince and Chris Behrens early on when this was brought up there supporting the use of a config value. From the implementation side of things, to do this properly would require some changes to the glanceclient to allow querying of available versions. Lacking that ability currently is one reason this is currently a config value. Once the client supports this, the nova side change would likely be quite small. Might I propose a compromise? 1) For the VERY short term, keep the config value and get the change otherwise reviewed and hopefully accepted. 2) Immediately file two blueprints: - python-glanceclient - expose a way to discover available versions - nova - depends on the glanceclient bp and allowing autodiscovery of glance version and making the config value optional (tho not deprecated / removed) Supporting both seems reasonable. At least then *most* people don't need to worry about it and it just works, but the override is there if necessary, since multiple people seem to be expressing a desire to have it available. Can we just do this all at once? Adding this to glanceclient doesn't seem like a huge task. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
[openstack-dev] [Nova][Glance] Support of v1 and v2 glance APIs in Nova
The following blueprint has been proposed for Nova: https://blueprints.launchpad.net/nova/+spec/use-glance-v2-api It proposes a new config option for Nova to allow choosing whether Nova should use v1 or v2 of the Glance API. I'd like to know if we can do this without a config option. Can Nova just discover which versions and pick one (v2) ? And if you don't like the way Nova picks one, a deployer can just only expose one of the APIs on the API endpoint that Nova uses. Thoughts? -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Glance] Support of v1 and v2 glance APIs in Nova
I don't oppose having the version autodiscovered. But I do feel the option should be available to override if desired. I've had many problems with over the years with autoconfiguring systems not doing what I need to be willing to depend on them 100% without a manual override available if at all possible. I'm thinking particularly for testing or upgrade evaluation scenarios. For example, you want to turn on v2 in glance and evaluate it for a bit before committing to using it for all of your nova nodes. The current patch also had a couple of comments from Dan Prince and Chris Behrens early on when this was brought up there supporting the use of a config value. From the implementation side of things, to do this properly would require some changes to the glanceclient to allow querying of available versions. Lacking that ability currently is one reason this is currently a config value. Once the client supports this, the nova side change would likely be quite small. Might I propose a compromise? 1) For the VERY short term, keep the config value and get the change otherwise reviewed and hopefully accepted. 2) Immediately file two blueprints: - python-glanceclient - expose a way to discover available versions - nova - depends on the glanceclient bp and allowing autodiscovery of glance version and making the config value optional (tho not deprecated / removed) Thanks, Eddie Sheffield -Original Message- From: Russell Bryant rbry...@redhat.com Sent: Thursday, October 17, 2013 2:00pm To: OpenStack Development Mailing List openstack-dev@lists.openstack.org Subject: [openstack-dev] [Nova][Glance] Support of v1 and v2 glance APIs in Nova The following blueprint has been proposed for Nova: https://blueprints.launchpad.net/nova/+spec/use-glance-v2-api It proposes a new config option for Nova to allow choosing whether Nova should use v1 or v2 of the Glance API. I'd like to know if we can do this without a config option. Can Nova just discover which versions and pick one (v2) ? And if you don't like the way Nova picks one, a deployer can just only expose one of the APIs on the API endpoint that Nova uses. Thoughts? -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
Re: [openstack-dev] [Nova][Glance] Support of v1 and v2 glance APIs in Nova
On 10/17/2013 03:12 PM, Eddie Sheffield wrote: I don't oppose having the version autodiscovered. But I do feel the option should be available to override if desired. I've had many problems with over the years with autoconfiguring systems not doing what I need to be willing to depend on them 100% without a manual override available if at all possible. I'm thinking particularly for testing or upgrade evaluation scenarios. For example, you want to turn on v2 in glance and evaluate it for a bit before committing to using it for all of your nova nodes. The current patch also had a couple of comments from Dan Prince and Chris Behrens early on when this was brought up there supporting the use of a config value. From the implementation side of things, to do this properly would require some changes to the glanceclient to allow querying of available versions. Lacking that ability currently is one reason this is currently a config value. Once the client supports this, the nova side change would likely be quite small. Might I propose a compromise? 1) For the VERY short term, keep the config value and get the change otherwise reviewed and hopefully accepted. 2) Immediately file two blueprints: - python-glanceclient - expose a way to discover available versions - nova - depends on the glanceclient bp and allowing autodiscovery of glance version and making the config value optional (tho not deprecated / removed) Supporting both seems reasonable. At least then *most* people don't need to worry about it and it just works, but the override is there if necessary, since multiple people seem to be expressing a desire to have it available. Can we just do this all at once? Adding this to glanceclient doesn't seem like a huge task. -- Russell Bryant ___ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
