Jump to content


mcru

Member Since 30 Nov 2016
Offline Last Active Today, 02:26 AM
-----

Posts I've Made

In Topic: Using a Broker to route traffic based on depot paths?

Today, 12:22 AM

We're upwards of 10x that, currently at ~120k lines, and will likely at minimum double it as we continue migrating to Perforce. I can definitely reduce the protect line count with smart use of groups, but did a 1:1 port of our old ACL model to Perforce that explicitly adds and removes access for individual users. We're very ACL heavy, and need to let users control the ACLs themselves via an overlay that generates protect table lines under delegated paths. We did run into protects table related performance issues with git-fusion, and patched git-fusion to reduce the number of checks it runs that process the protect table on each iteration. I suspect we'll run into it on p4d itself eventually as well.

A big reason we're moving this depot to a new instance is because we need to allow access to the triggers table to a group of admins, which will be editing the triggers table as needed for automation surrounding change.

Originally, this was going to be a stand-alone instance, but global changelists and not replicating/reconciling users across both instances won out. I'll have to read more about a commit/edge architecture to see if it's a decent fit. If it is, we can probably migrate to it. If for any reason the current architecture causes issues, we're going to break the two instances fully apart and keep the new instance completely discrete.

For p4 administration - we're currently provisioned with the SDP, which was a great time saver to get up and running, but I'm finding has some major issues (straight up bugs) when getting creative with the architecture. I'm in the process of adding everything to ansible so we can easily reproduce the architecture, check for config drift, and have defined state vs. trusting the SDP generated scripts. Though, I will be leveraging the SDP and templating it so we can still use the built in scripts.  

The plan is to upgrade to the latest p4d for the automatic failover - it looks awesome, with the only limitation being how p4 port is re-pointed. I'll let you know how it goes once I get to it.

In Topic: Using a Broker to route traffic based on depot paths?

06 November 2019 - 10:43 PM

BTW - I came to the same conclusion about the Broker. What I ended up doing is splitting the depot out to a stand alone instance that uses a centralized auth and change server that is the old 'master' instance. I'll probably add an empty instance to the architecture to act purely as a centralized auth and change server for any additional instances we add. Each instance will also have a read only replica for failover and read only requests. I'll likely add a broker to each cluster to handle failover and to direct reads and writes to their appropriate servers.

I think Perforce would prefer a single server + commit edges, but this seems to work nicely. My major concern is large DVCS pushes locking up instances if anyone does one that pushes all RCS objects and locks the server while the central change server generates CLs for every RCS/commit on the target instance.

In Topic: Using a Broker to route traffic based on depot paths?

06 November 2019 - 10:32 PM

Quote

Why do you want to do split these depots out?
Politics mostly. We also have insane ACL requirements, including a port of a home grown ACL model to p4 which generates a *lot* of protect lines.