Open Stack

On 10/09/2015 07:14 PM, Clint Byrum wrote:
<snip>
> I don't think we're suggesting that we abandon the current one. We don't
> break userspace!
> 
> However, replacing the underpinnings of the current one with the new one,
> and leaving the current one as a compatibility layer _is_ a way to get
> progress on the new one without shafting users. So I think considerable
> consideration should be given to an approach where we limit working on
> the core of the current solution, and replace that core with the new
> solution + compatibility layer.
> 
>> And, as I've definitely discovered through this process the Service
>> Catalog today has been fluid enough that where it is used, and what
>> people rely on in it, isn't always clear all at once. For instance,
>> tenant_ids in urls are very surface features in Nova (we don't rely on
>> it, we're using the context), don't exist at all in most new services,
>> and are very corely embedded in Swift. This is part of what has also
>> required the service catalog is embedded in the Token, which causes toke
>> bloat, and has led to other features to try to shrink the catalog by
>> filtering it by what a user is allowed. Which in turn ended up being
>> used by Horizon to populate the feature matrix users see.
>>
>> So we're pulling on a thread, and we have to do that really carefully.
>>
>> I think the important thing is to focus on what we have in 6 months
>> doesn't break current users / applications, and is incrementally closer
>> to our end game. That's the lens I'm going to keep putting on this one.
>>
> 
> Right, so adopting a new catalog type that we see as the future, and
> making it the backend for the current solution, is the route I'd like
> to work toward. If we get the groundwork laid for that, but we don't
> make any user-visible improvement in 6 months, is that a failure or a win?

I consider it a fail. The issues with the service catalog today aren't
backend issues, they are front end issues. They are how that data is
represented and consumable. Changes in that representation will require
applications to adapt, so is the long pole in the tent.

I feel pretty strongly we have to start on the UX, and let backends
match once we get better interaction. That also lets you see whether or
not you are getting any uptake on the new approach before you go and
spend a ton of time retooling the backend.

	-Sean


-- 
Sean Dague
http://dague.net