-
Choerodon平台版本: 0.10
-
遇到问题的执行步骤:
-
文档地址:
http://choerodon.io/zh/docs/installation-configuration/steps/install/parts/base/gitlab/ -
环境信息(如:节点信息):
-
报错日志:
-
原因分析:
提出您分析问题的过程,以便我们能更准确的找到问题所在
-
疑问:
在分步部署过程中，如何利用企业已有的gitlab服务（10.5）,原有的gitlab是通过官方的 Omnibus方式非容器部署的，数据库默认是postgresql，用户通过ldap身份验证，看了choerodon的gitlab集成文档似乎要改成Oauth认证，有没有不影响现有业务无缝集成原有gitlab的方案
目前是这种已有gitlab的对接是没有的，由于系统对gitlab的集成较高，gitlab相关的配置、设置、权限等等不一致很容易导致系统问题。
但是该需求我们已经在讨论实验中了，会在后续的版本进行方案支持，如果有新的进度我们会及时在这里回复
希望将来能够解耦支持外部gitlab部署，通过helm部署的gitlab性能完全不能够用在生产上，而且基本上要用到PAAS平台的企业内部肯定早有gitlab服务，迁移原来的代码仓库也是伤筋动骨的事情，本来想体验下C7N现在就卡在这了
好的
您好，关于choerodon最新版本0.14，是否可集成已有的gitlab？ 如果当前没有，是否存在排期计划？
当前的情况为：创建应用时，可直接拉取已有git库中的项目，并在choerodon集群中的git-service存在，但问题在于此操作只会拷贝获取master代码，其他原有的提交记录、分支信息、tag记录等所有原数据均无法整体迁移，这个风险是很高的，存在严重的数据丢失问题。
我们也考虑将已有原gitlab全量备份并迁移到choerodon集群中，但这里涉及到原git库的用户与choerodon的用户无法对应，且权限和认证问题也无对应的解决方案。 这个问题导致我们完全无法完整的使用choerodon平台，是否有相应解决方案呢？
这部分我们也在努力的去做方案，目前我们对接企业内部的这种需求是由我们的人进行额外的人工操作进行的，由于gitlab的版本适配、人员同步、权限问题、ops库初始化、仓库的hook设置等等问题很难直接对接到系统进行一站式的迁移，这里涉及到的问题其实不仅仅是人员同步的问题，所以直接通过平台进行原有gitlab的对接我们目前还没有好的办法。
目前提供和建议的方式就是在应用创建的时候进行直接导入，目前已经支持了gitlab和github的仓库地址
嗯，非常感谢你们的付出，当前在创建应用时，确实支持从指定git地址导入应用。
建议评估：
是否可支持直接导入，并使用导入的gitlab库用户作为choerodon的用户？即以gitlab的用户组织架构作为choerodon的组织架构，毕竟只能有一个组织，将所有用户纳入“运营组织”之下即可，以这种逆向的方式是否具备可操作性？
做一下记录，可以作为一个优化的点来进行，但是这块工作涉及的内容蛮多的，可能需要的周期略久一些
因为使用PAAS平台，就是为了一站式包含处理以往处于割裂状态的各种阶段。而有这种需求的全都是已存在较长时间的项目，肯定存在原有git库的。 如果不能解决这个问题，确实无法全方位的发挥Choerodon的威力，哈哈
这个问题也是我一直关注的，不知道现在有没有进展了？