Open Stack

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
>>> <mriedem at linux.vnet.ibm.com <mailto:mriedem at 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