Open Stack

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.

>
>> 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
>