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 <s...@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-requ...@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-requ...@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-requ...@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-requ...@lists.openstack.org?subject:unsubscribe
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
