Determine which lightweight Git implementation to use for Gitops of BB install

added BB-Air-Gap label

We need to have a Git instance to use for the Gitops style install of BB into a cluster. In an air gap situation we might not have an outside git available for this. We need to determine what is the best light weight solution. Some things to explore are listed below.

Gitea - has a light weight front end and doesn't require a database. Gogs - Light weight, but requires a mysql database. Put a lightweight ssh server on the bastion host. Put a lightweight ssh server in the cluster somewhere.

** There is no real need to have a front end UI for this Git instance. We can always move the GitRepository over into Gitlab as a later installation step.

See the diagram above for the chicken vs egg issue.

added 1 design

added to epic &32 (closed)

added 1 deleted label

It was determined to use just a Linux instance with ssh and the git user.

assigned to @egoode

assigned to @toladipupo and @evan.rush

If customer does not have an existing git server then basic ssh & git user is all that is needed for airgap bootstrapping. Customer can choose to enable the gitlab addon as part of BB install.

closed

reopened

Reopened per discussion with @cmcgrath, will need a http(s) version of git when operating in a ssh restricted environment. For now the accepted solution is simple ssh + git user, but this cannot be only solution as it does not cover all situations. @cmcgrath please add further details if needed.

added 1 deleted label and removed 1 deleted label

changed title from Spike - Determine which lightweight Git implementation to use for Gitops of BB install to Determine which lightweight Git implementation to use for Gitops of BB install

changed the description

Note: There is a use case where

• No pre-existing container registry exists
• No pre-existing git repo exists

based on the demo today:

• registry:2 can be used to create a registry
• it was originally thought to use ssh git repo

There are environments that require use of OS settings that prevent use of ssh based git repo, (restrictions on ssh implementation). Thus a HTTPS git repo implementation would be nice to see.

(Was typing while you were typing, only other detail is prob good idea to support HTTPS git repo with self signed CA)

added priority4 label

here's an implementation that uses a self contained and self installing utility cluster to host:

• http(s) git server
• registry

changed iteration to Big Bang Iterations Apr 6, 2021 - Apr 20, 2021

set weight to 3

added statusdoing label and removed 1 deleted label

There was a DM between customer's engineers and product team members working airgap.

We re-analysed the problem and brain stormed 2 possible solutions:
The problem: Customer is forced to use an AMI & ssh config that prevents the use of normal ssh.
1st possible solution: use HTTPS based git repo
2nd possible solution: use ssh based git repo inside of a container, and expose the container's ssh over a non standard port (and if flux complains about the non standard port use an LB to map 22 to the non standard port.)

Current plan being investigated is the 2nd possible solution since it's significantly less overhead (HTTPS involves Certs and CAs).

changed epic to &69 (closed)

Issue completed, a solution is in place to use a Docker container to serve the git repos on ssh via a non-standard port. All artifacts have been added to the MR 363.

added 1 deleted label and removed statusdoing label

closed

removed 1 deleted label