[openstack-dev] [all] service catalog: TNG
itzshamail at gmail.com
Fri Oct 9 17:01:20 UTC 2015
> On Oct 9, 2015, at 12:28 PM, Monty Taylor <mordred at inaugust.com> 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.
Thanks, that makes sense. I agree that it might be a good backend but not the overall solution... I was bringing it up to ensure we consider existing options (where possible) and spend cycles on the unsolved bits.
I am going to look into the scaling limitations for consul to educate myself.
>>> 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 -
>>> 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.
>>> Sean Dague
>>> OpenStack Development Mailing List (not for usage questions)
>>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
>> OpenStack Development Mailing List (not for usage questions)
>> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
More information about the OpenStack-dev