add configurable option and defaults for git 'transfer-unpacklimit' to omnibus

This is to change the default transmit behavior of git to set the unpackLimit to 1

/cc: @pcarranza @jacobvosmaer-gitlab

closes gitlab-com/infrastructure#313

mentioned in issue gitlab-com/infrastructure#313

@northrup Did we test this?

You can specify omnibus_gitconfig['system'] = { "receive" => ["fsckObjects = true"], "transfer" => ["unpackLimit = 1"] } in gitlab.rb and reconfigure before we go in and make this a default for packages.

Could you also update the gitlab.rb.template with that line, you specified this setting in a separate line and that won't work (it will override the settings in the line above).

Added 1 commit:

• fb184455 - correct syntax for template file

Test this in staging and dev, it introduced issues with the web based automerge function where it just hangs for some reason. Will investigate further.

@northrup cool, I will reassign to you and when you are confident that it is safe to merge assign it back to me :)

Reassigned to @northrup

@jacobvosmaer-gitlab are you aware of anything 'different' that we do with the web automerge that would lead to this behavior? Git SSH commands worked perfectly on checkout, checkin, branch, etc - just not on the internal application function.

@northrup well web merges are very different from git push because it is libgit2 (rugged) making commits and other objects in the Git repository, instead of the standard Git suite. But I don't see how that would bite / be bitten by transfer.unpackLimit.

@northrup @jacobvosmaer-gitlab what's the status on this? do we need to do anything?

I would really like to enable this in prod.

This can always be enabled in production, it is not necessary to wait for this MR.

Is there anything we should worry about @jacobvosmaer-gitlab @northrup ?

@pcarranza see https://gitlab.com/gitlab-org/omnibus-gitlab/merge_requests/921#note_13765509 . I am not sure if this is even working. @northrup ?

It isn't. It fails when interacting with rugged. SSH interaction is fine, but programmatic interaction through our gem not so much.

What can we do with this then?

@pcarranza investigate how to fix the broken behavior or close the MR.

@jacobvosmaer-gitlab I'm not sure we need to do this given that we are moving everything to cephfs and it doesn't seem to be so affected by small writes as NFS is.

@northrup could you open an issue for further investigation so we can just close this one to not let it linger?

Status changed to closed