ModelArts上自动学习预测分析为啥需要gitee网站上下载工程呢？这个工程不能编译到ModelArts里吗？看了好几个文档都要求去工程。假如是自己整理数据集来训练，那工程也需要网上下载吗？或者是说网站上没有的话？如何处理？

【功能模块】【操作步骤&问题现象】1、agg的时候sum(case when里有to_char和to_date，发现性能很差，优化成immtable的函数后性能从6分钟提升到40秒2、pck的列为columnA和columnB，只过滤columnB的情况下pck会提高性能么？我实际试了试试提高了性能的，但是我之前理解应该是只有按照columnA或者columnA+columnB过滤才会有效，请教下为啥【截图信息】【日志信息】（可选，上传日志内容或者附件）

 请问tf.nn.sparse_softmax_cross_entropy_with_logits是否在Ascend 910支持？将tf迁移到Ascend 910是否有支持算子的清单或约束说明？如果不支持，是否有替代方案？

GitOps通过使用成熟的DevOps优秀实践（包括：版本控制、代码审查、以及CI/CD管道等），提供了一整套自动化的管理方法。本文向您介绍GitOps基本原理、组成与优势。如今，许多团队都在各种项目中争相使用着诸如：版本控制、代码审查、以及CI/CD管道等，与DevOps有关的优秀实践。不过，您是否注意到，这些方法主要针对的是软件开发生命周期中的自动化。而在涉及到基础架构的设置和部署时，项目团队仍然主要依赖的是手动的过程。对此，GitOps提供了一套管理基础架构的自动化方法。项目团队可以借助GitOps，并通过使用各种声明文件，将基础架构编写为代码(infrastructure as code，IaC)，进而自动化配置的过程。也就是说，我们可以像存储应用程序的开发代码那样，将基础架构存储放在Git存储库中，以提高整体的交付能力和产品质量。GitOps的工作原理GitOps的概念最初是由Kubernetes管理公司--Weaveworks(请参见https://www.weave.works/)提出的。众所周知，基于容器的应用往往比较复杂，而且难以进行配置和管理。因此，GitOps主要针对的是：在Kubernetes背景下，如何将编排平台转换到运行在容器中的微服务上，并采用DevOps领域的成熟技术，来协助简化该过程。下面我们将深入讨论GitOps的各个主要组成部分：基础架构即代码(IaC)如前所述，IaC可以通过将各种声明性文件存储为代码，进而实现基础架构的配置和管理。据此，通过利用IaC和版本控制，项目团队可以优化当前的各项操作进程。此处提到的声明式(Declarative)，意味着您的配置将不再是一组命令，而是对某种预期状态的声明。例如，在Kubernetes中，您可以在清单文件(manifest)中定义服务所需的Pod数量。系统将通过自行处理，获取所需的容器编号，而无需工程师额外编写命令脚本。在此，任何符合声明性模型的云原生软件，都可以被视为代码。通常，我们会将各种所需的状态声明为代码，并通过系统应用的更改，以自动化的方式实现目标状态。例如：我们可以使用诸如AWS CloudFormation之类的声明性工具，来编写AWS的基础架构。拉取请求(Pull Requests)GitOps概念背后的主要思想是：版本控制系统是唯一的来源。我们既可以将Git用作应用代码的变更管理系统，通过拉取请求来实现各项操作性的变更，又可以将其用于基础架构的代码上，以便将整个声明文件集中于一处。在应用开发的工作流中，我们需要将某个主分支作为发布分支。在此基础上，开发人员会从主分支处创建各个功能性分支，以便开发出特定的功能或故事线。而在功能性分支上，一旦完成了更改，他们会通过创建拉取请求的方式，重新合并回主分支。这样一来，我们就可以在方便实现协作的同时，透明地获悉到谁在何处进行何种更改。而且，由于所有更改都是在Git处被提交的，因此这对于开发团队从根本原因处进行问题的跟踪，也是非常实用的。可见，创建拉取请求的好处在于，我们可以让代码在被集成到代码库的另一个分支之前，事先经历代码的审查过程。而代码审查恰好能够阻止各种不良的代码，进入测试或生产环境。显然，这对于故障的消除，以及基础架构代码而言，都是非常重要的。Git的组成GitOps并不依赖于任何工具或技术。它可以与诸如：GitHub、BitBucket或GitLab等，任何基于Git的系统协同使用。而在部署过程中，GitOps至少需要两个存储库，即：包含了应用源代码、及其部署清单的应用程序存储库;和使用着每个环境的声明性规范描述的，包含了整个系统目标状态的环境配置存储库。您可以在代码存储库中将目标环境定义并描述为开发环境、测试环境、生产环境、或是包含了运行着特定版本的应用和基础架构服务的环境。CI/CD要实现完整的GitOps，您势必需要一个CI/CD管道，以实现Git存储库在每次发生更改时，开发团队都能将对应的基础架构变更交付到指定的环境中。该自动交付管道能够将Git的拉取请求连接到编排系统中，以便通过请求来触发管道，并让编排系统执行指定的任务。一般而言，GitOps有两种可能的部署策略：推送管道和拉取管道。您可以根据当前架构需要部署的实际环境，在两者间做出选择。下面我们来具体看看两种策略的各种特点：推送管道(Push Pipelines)目前，许多流行的CI/CD工具都在使用这种策略。开发人员通常将应用程序的源代码、及其部署清单存储在一个存储库中。当应用代码发生变更时，管道将触发容器映像的构建，并将变更推送到相应的环境中。由于该策略支持任何类型的基础架构，因此它具有较大的灵活性。不过，其缺点是：它会赋予CI/CD工具对于目标环境的写入权限。基于推送的DevOps部署拉取管道(Pull Pipelines)在开发者社区中，人们普遍认为：对于GitOps的拉取管道方法是一种更安全的策略。这种方法引入了操作符(operator)的概念。它是管道和业务流程工具之间的组件。操作符能够不断将环境存储库中的目标状态，与已部署的基础架构的实际状态，进行比较。如果操作符检测到任何修改，那么它就会更改基础架构，以适应环境存储库。同样地，它也可以监视镜像注册表，以识别出需要部署的镜像新版本。基于拉取的DevOps部署可见，在GitOps中，只有在环境存储库中出现修改时，对应的环境才会更新。相反，如果已实施的基础架构在环境存储库中并未定义任何方式的修改，那么系统将会自动还原。在实际项目中，大多数应用程序都会同时涉及到多个环境。对此，GitOps允许您创建多个管道，以同时更改多个环境存储库。当然，您也可以在环境存储库中使用单独的分支，来管理多个环境。我们既可以通过将操作符部署到生产环境中，来对单个分支的修改及时做出反应，又可以通过部署到测试环境中，来响应另一个分支。GitOps的优势由于GitOps专注于Git工作流、IaC、CI/CD管道，不可变服务器(immutable servers)、跟踪、以及可观测性等优秀实践模型，因此它代表了对于Kubernetes云原生应用管理的高级状态。据此，开发团队可以从如下方面受益：简化持续部署顾名思义，持续部署(https://microtica.com/cracking-the-continuous-deployment-code/)意味着更快、更频繁的部署。通过GitOps，部署操作符提供了必要的结构和自动化，而且这一切都在版本控制系统中发生，因此我们无需各种工具，便可管理系统的状态、停机时间、上游/下游依赖关系、以及其他与组织相关的流程。此外，GitOps不但提高了项目团队的生产率，而且加快了他们的平均部署时间(Mean-time-to-deployment，MTTD)。有证据表明，自动化持续部署能够确保团队每天触发30到100次以上的变更，并将生产环境的性能平均提高2到3倍。缩短平均修复时间(Mean-time-to-repair，MTTR)MTTR是衡量DevOps团队绩效的一项关键指标(https://microtica.com/13-devops-metrics-for-increased-productivity/https://microtica.com/13-devops-metrics-for-increased-productivity/)。由于GitOps保留了版本控制系统中的所有修改，并且能够实现自动化的管理，因此，开发团队能够全面了解目标环境中的变化，轻松发现和修复错误，从而显著降低MTTR。简化Kubernetes管理在无需透彻了解Kubernetes的情况下，开发人员可以使用Git等较为熟悉的工具，更加轻松地管理Kubernetes的升级和各项功能。据此，新加入的成员也能够在几天时间快速上手Kubernetes。全面掌握并标准化工作流由于GitOps提供了一站式的应用程序、软件、以及针对Kubernetes修改的框架，因此开发团队可以清晰地洞悉整个项目的端到端工作流，并能通过Git来完全复现日常的业务运营活动。GitOps的实现建立稳定的代码审查与测试过程。通过仔细地检查代码的更改，我们能够及时发现诸如全局变量的添加等操作，并且可以通过提交拉取请求(而非直接提交更改的方式)，来验证代码。而在拉取请求被检查与合并之后，管道才会被触发。此举在避免发布错误的代码的同时，有效地保持了高标准的代码，以及系统后续的稳定性。持续测试。合并到GitOps中，往往意味需要通过高级的自动化机制，对待发布的应用程序进行彻底的测试。有了GitOps，我们不但能够相对轻松地实现回滚，还能够通过良好的测试用例，保障代码的质量和可靠性。专注监控。GitOps允许开发人员重复各项操作流程，改进、发布并回顾各种可追溯的系统状态。而通过专注于监控，我们可以识别并防止任何意外的漂移(drift)、以及系统配置的变更。因此，在开始使用GitOps之前，开发团队有必要检查自己的监控水平，以及处理变更的能力。拥抱文化。作为目前在开发领域的优秀战略，DevOps文化能够促进团队的共同协作，更有效地管理基础架构的稳定性，更快、更流畅地执行应用程序。而GitOps又能够让我们在此基础上，进一步理解开发和运营的协同价值，提供一整套自动化的管理方法。小结作为一种非常好的工作流模式，GitOps不但可以帮助我们有效地处理云基础架构，还能够为工程团队提供：更好的协调性、透明度、稳定性、以及系统耐用性等方面的诸多好处。原文标题：GitOps – DevOps for Infrastructure Automation，作者：Sara Miteva   来源：51CTO.com  陈峻

【功能模块】【操作步骤&问题现象】发表博客被拦截，审核未通过【截图信息】【日志信息】（可选，上传日志内容或者附件）

如题，ModelArts连接github超时导致无法加载预训练权重，想问一下有什么办法能解决？

【功能模块】导入智慧园区自动化测试工程，无法访问git库【操作步骤&问题现象】【截图信息】【日志信息】（可选，上传日志内容或者附件）

svn是集中式版本控制系统，git是分布式版本控制系统。svn就是所有人修改的都是服务器上的程序，如果有人修改了同样的部分，那就冲突了。所以呢，一般团队会约定，对于公共部分的程序，尽量标注出开发人员特有标识，又或者A从上添加，B从下添加。git就是开发人员创建自己的分支，这个分支就相当于将源码copy一份在本机上，之后修改的都是本地的代码，可随时拉取服务器的代码进行同步，git可创建无数分支，开发人员只需将自己修改的代码提交就可以了，这样冲突的几率会小很多。svn是直接与服务器进行交互，git是将项目缓存在本地再推送到服务器。svn必须在联网的情况下工作，git可不联网开发。svn易冲突，git不易冲突。svn旨在项目管理，git旨在代码管理。svn适用于多项目并行开发，git适用于单项目开发。svn适用于企业内部，由项目经理协调多个项目统筹开发，git适用于通过网络多人开发同一项目。

svn是集中式版本控制系统，git是分布式版本控制系统。svn就是所有人修改的都是服务器上的程序，如果有人修改了同样的部分，那就冲突了。所以呢，一般团队会约定，对于公共部分的程序，尽量标注出开发人员特有标识，又或者A从上添加，B从下添加。git就是开发人员创建自己的分支，这个分支就相当于将源码copy一份在本机上，之后修改的都是本地的代码，可随时拉取服务器的代码进行同步，git可创建无数分支，开发人员只需将自己修改的代码提交就可以了，这样冲突的几率会小很多。svn是直接与服务器进行交互，git是将项目缓存在本地再推送到服务器。svn必须在联网的情况下工作，git可不联网开发。svn易冲突，git不易冲突。svn旨在项目管理，git旨在代码管理。svn适用于多项目并行开发，git适用于单项目开发。svn适用于企业内部，由项目经理协调多个项目统筹开发，git适用于通过网络多人开发同一项目。

打个比方:链接:https://gitee.com/ascend/samples/tree/master/objectdetection/for_atlas200dk_1.7x.0.0_c++/objectdetection里面的src文件夹的作用是啥?我的个人理解:是目标检测在Atlas200DK的部署所需要的的主代码,不知道理解是否有误,还望大佬指点.

实际体验的好处是可以这碰碰，那撞撞，盲人摸象般探测边界在哪儿~昨天看了【操作指南系列】CloudIDE实例中导入Git代码库，今天才try了一下！有了夜读成才的教程，超级顺利~连许久不用的github密码居然一次就蒙对了~23333在github上改了下代码，嗯，没有自动同步到cloudIDE中。再重新import一下，文件夹重名，提示错误。改个文件名，第二次拉取下来。在Cloud IDE修改代码，然后上送git,一直报错鉴权失败，是啊，没有保存github的用户名和密码，这就需要用SSH方式连接github了。密码复制的问题：昨天确实发现代码粘贴不出来，是上面编辑框的代码粘贴不到本地，但是terminal中的文本一直是可以粘贴到剪辑板再到本地的。这里的密码不用使用手册上说的xclip -sel clip < ~/.ssh/id_rsa.pub直接能复制出来就可以了。感觉CloudIDE有点像vmware虚拟机的使用，但VM虚拟机安装了插件后，是可以在虚机和本端自由复制的。

【问题现象】git clone 下载仓库报错，不能创建文件夹cannot create directory at ' XXX    ' : No such file or directory【问题分析】参考https://blog.csdn.net/weixin_37639900/article/details/98495662分析原因是文件夹名称有空格，mkdir 不能创建最后带有空格的文件名，但界面创建文件夹支持文件名最后又空格。【问题解决】删除仓库中文件夹名中的空格，可以正常 git clone。【补充说明】linux文件名称要求：1.文件名名称严格区分字符大小写；2.文件名可以除了使用除斜线（/）以外的任意字符；不建议使用特殊字符、空格；必须多个单词命名的可以使用下划线来连接其多个单词；例如：aaa**B文件名称不易理解 3.文件名不能，不能超过255个字符；4.以点号开头的文件为隐藏文件，windows文件名称要求：1 允许文件或者文件夹名称不得超过255个字符。2 文件名除了开头之外任何地方都可以使用空格。3 文件名中不能有下列符号：“？”、“、”、“/”、“╲”、“*”、“<”、“>”、“|”。4 Windows文件名不区分大小写，但在显示时可以保留大小写格式。5 文件名中可以包含多个间隔符，如“我的文件。我的图片。001”。

【问题现象】 git 提交代码时，报：error: RPC failed; HTTP 413 curl 22 The requested URL returned error: 413 Request Entity Too Large【问题解决】提交的代码太大，删除仓里的编译临时文件，例如： *.om  *.pyc  *.o/build /out 文件夹git可以配置gitignore，告诉Git哪些文件不需要添加到版本管理中

执行git submodule update --init --recurise 出现问题【截图信息】使用的git url格式与原项目下的.gitmodule文件中的url格式不对。进入项目根目录，vi .gitmodules，编辑文件，找到提示问题的模块，将url = 后面的git改为https 然后：wq 保存退出。

在课件中，有GitHub的链接，西北地区有什么办法可以打开GitHub吗？