Jump to content


Helix4Git requirements

helix4git installation

  • Please log in to reply
1 reply to this topic

#1 UnstoppableDrew

UnstoppableDrew

    Advanced Member

  • Members
  • PipPipPip
  • 53 posts

Posted 17 December 2018 - 07:59 PM

I'm looking into what it would take to setup Helix4Git at our company, but the admin guide is really vague about a number of things.
  • It's recommended to run the connector on a separate server than the main Helix server. Why?
  • If it has to be a separate server, what are the sizing requirements for it?
  • We have multiple offices that use p4proxies. Do I need to set up a git connector server at each of these locations?
  • The Git users will be a small subset of the total Perforce userbase. Since H4G is a separate license, will those be separate user accounts or can the same user work with both Classic & H4G?
Thanks,

#2 Matt Janulewicz

Matt Janulewicz

    Advanced Member

  • Members
  • PipPipPip
  • 172 posts
  • LocationSan Francisco, CA

Posted 08 January 2019 - 10:44 PM

Someone from Perforce can hopefully chime in on some of this in case I'm wrong, but we've been exploring/testing H4G for quite a while now and I might have some insight.

I think the reasoning behind a separate server is likely just general IT/data center practice. If you have an overly-active p4 environment like we do, and a potentially overly-active H4G environment, you'd hammer the heck out of the server. Plus, if there's a hardware failure, you lose two things at once.

Sizing requirements are going to depend on the graph depot sizes you think you're going to end up with and how many users you need to support. I think of a Connector as essentially a git server, which needs some CPU for compressing things and some network pipes for sending data through. The polling/update process for a Connector is pretty low, so most of your resources will be spent on actual git functionality. Don't quote me on it, but if you knew you were only going to have, say, a dozen users on it, you could probably get away with a modest VM (4 CPU, 16 G memory.) It really does depend on the nature of the git repos themselves, in my estimation, though.

For the question of how many and where to put the Connectors, I'm wrestling with that, too. The answer generally is no, you can put a Connector anywhere and point it at your master/commit server. It functions similarly as a p4proxy but for git repos. However, you can point them at an edge server. The theoretical advantage might be that you have your graph depot(s) syncing to the edge servers through pull threads in near real-time, so when the Connector gets around to updating it's getting that data locally instead of your commit server halfway around the world. However, your submits/pushes go through the edge server, also, which is an extra hop, and the push/submit won't complete until it's through both the edge and the commit. Might be extra overhead. I haven't experimented enough with it to see if pointing a Connector at an edge server is useful or just brings in to many points of potential failure.

Anyway, Connectors are independent of any other replicas/proxies you have out there, probably, if you point them all to your master/commit. You'd just need/want to put one wherever your git users are then run polling at a reasonable interval so they could mostly work with local packfiles.

I believe that the license covers all current p4 users. I don't know that there's a way to separate them out, at least a year ago when I last talked to anyone about it that was the case. The license is physically encoded in your regular p4 license. It's a separate purchase/cost, but p4 support will issue you a new, single license that covers both p4d and unlimited graph repos. (unless something's changed recently.)
-Matt Janulewicz
Staff SCM Engineer, Perforce Administrator
Dolby Laboratories, Inc.
1275 Market St.
San Francisco, CA 94103, USA
majanu@dolby.com





Also tagged with one or more of these keywords: helix4git, installation

0 user(s) are reading this topic

0 members, 0 guests, 0 anonymous users