Open Stack

On 06/12/16 12:15, Andrey Grebennikov wrote:
>
>     Just to clarify, the reason you want custom project IDs is so that
>     when you create a project in one region, you can create it again
>     with the same ID in another? Isn't that just manual replication
>     though?
>
>     What happens when there are projects in only one region? Or if
>     that isn't meant to happen, how would you make sure that doesn't
>     happen?
>
> Not quite sure I  understand the point...
> Yes, this is exactly the reason why I need this feature. Project
> creation/replication is supposed to be done via external scripts.
> Currently I already have 2 slightly different use cases which
> definitely require this feature.
>
>
My point was how is this any better than database replication? It pretty
much sounds like replication but at the API layer.

Do you just create a project normally in one region (keystone API) and
then a cron job or something triggers the replication script, or do you
have a queue of changes to replicate? Isn't that much the same as doing
asynchronous database replication? Or are you creating and duplicating
in the scope of the same script? If the latter, then that sounds like
synchronous DB replication.

How are you handling conflicts? Are you?

If networks are down, the same problem is present. If ProjectOne is
created in RegionOne, and ProjectTwo in RegionTwo, until the
inter-region network is restored, the two keystones will be different
until your script runs in both regions and actually gets through to the
opposite one.

What is the benefit to doing things this way rather than just trusting
your replication to the DB layer?

I'm genuinely curious about your approach as we've been looking at
moving to a multi-master like set up for our keystone so I'd love to
know what problems you found with DB replication. API level replication
sounds like a terrifying idea, so I'm curious what exactly your reasons
behind wanting to do it are.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20161206/51d52acc/attachment.html>