Open Stack

On 10/09/2015 12:28 PM, Monty Taylor wrote:
> On 10/09/2015 11:21 AM, Shamail wrote:
>>
>>
>>> On Oct 9, 2015, at 10:39 AM, Sean Dague <sean at dague.net> wrote:
>>>
>>> It looks like some great conversation got going on the service catalog
>>> standardization spec / discussion at the last cross project meeting.
>>> Sorry I wasn't there to participate.
>>>
>> Apologize if this is a question that has already been address but why 
>> can't we just leverage something like consul.io?
>
> It's a good question and there have actually been some discussions 
> about leveraging it on the backend. However, even if we did, we'd 
> still need keystone to provide the multi-tenancy view on the subject. 
> consul wasn't designed (quite correctly I think) to be a user-facing 
> service for 50k users.
>
> I think it would be an excellent backend.

The better question is, "Why are we not using DNS for the service catalog?"

Right now, we have the aspect of "project filtering of endpoints" which 
means that a token does not need to have every endpoint for a specified 
service.  If we were to use DNS, how would that map to the existing 
functionality.


Can we make better use of regions to help in endpoint filtering/selection?

Do we still need a query to Keystone to play arbiter if there are two 
endpoints assigned for a specific use case to help determine which is 
appropriate?




>
>>
>>> A lot of that ended up in here (which was an ether pad stevemar and I
>>> started working on the other day) -
>>> https://etherpad.openstack.org/p/mitaka-service-catalog which is great.
>> I didn't see anything immediately in the etherpad that couldn't be 
>> covered with the tool mentioned above.  It is open-source so we could 
>> always try to contribute there if we need something extra (written in 
>> golang though).
>>>
>>> A couple of things that would make this more useful:
>>>
>>> 1) if you are commenting, please (ircnick) your comments. It's not easy
>>> to always track down folks later if the comment was not understood.
>>>
>>> 2) please provide link to code when explaining a point. Github supports
>>> the ability to very nicely link to (and highlight) a range of code by a
>>> stable object ref. For instance -
>>> https://github.com/openstack/nova/blob/2dc2153c289c9d5d7e9827a4908b0ca61d87dabb/nova/context.py#L126-L132 
>>>
>>>
>>> That will make comments about X does Y, or Z can't do W, more clear
>>> because we'll all be looking at the same chunk of code and start to
>>> build more shared context here. One of the reasons this has been long
>>> and difficult is that we're missing a lot of that shared context 
>>> between
>>> projects. Reassembling that by reading each other's relevant code will
>>> go a long way to understanding the whole picture.
>>>
>>>
>>> Lastly, I think it's pretty clear we probably need a dedicated 
>>> workgroup
>>> meeting to keep this ball rolling, come to a reasonable plan that
>>> doesn't break any existing deployed code, but lets us get to a better
>>> world in a few cycles. annegentle, stevemar, and I have been pushing on
>>> that ball so far, however I'd like to know who else is willing to 
>>> commit
>>> a chunk of time over this cycle to this. Once we know that we can 
>>> try to
>>> figure out when a reasonable weekly meeting point would be.
>>>
>>> Thanks,
>>>
>>>     -Sean
>>>
>>> -- 
>>> Sean Dague
>>> http://dague.net
>>>
>>> __________________________________________________________________________ 
>>>
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: 
>>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>> __________________________________________________________________________ 
>>
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: 
>> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> __________________________________________________________________________ 
>
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: 
> OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev