Offline transfer - remove export tool from architecture
While discussing the offline transfer, it was decided that an export tool is no longer necessary as a part of the core offline transfer design. The architecture doc should be updated to no longer reference it, and to make it clear that customers' source instances will must have the earliest version where offline exports are supported.
Additionally, it should be clear that the export and import destinations will need access to an object storage provider, and we don't intend to support exporting and importing from local drives. See gitlab-com/content-sites/handbook!12056 (comment 2442778051)
Unresolved related comments on the architecture design
-
Suggestion to mention that older source versions could be supported by an export tool, but we aren't planning to build one yet: gitlab-com/content-sites/handbook!12056 (comment 2455709233) -
A comment for clarification on where exports should be uploaded to gitlab-com/content-sites/handbook!12056 (comment 2396691593) -
Feedback that the version table is inaccessible. This should be made more clear gitlab-com/content-sites/handbook!12056 (comment 2453445751) -
A comment suggesting we allow customers to stay within congregate when moving to the import step. Congregate won't be involved at all anymore gitlab-com/content-sites/handbook!12056 (comment 2396691537) -
Some feedback from professional services about the possibility of using Congregate: gitlab-com/content-sites/handbook!12056 (comment 2418767769). This is effectively resolved by removing the export tool, but more discussion on how the team could work with PS is welcome
Edited by 🤖 GitLab Bot 🤖