Haoran Yang

s 在 linux 下普通用户的体验问题

1

Linux 用户一般不会使用 root，通常是使用普通账户，然后为该账户赋予 sudo 权限。普通账户执行命令，以及以 sudo 权限执行命令，行为是有一些差异的。在 s 上，会带来以下一些体验问题： 1. 普通账户执行 `s init` 初始化项目，第一次执行时会让用户配置账户，AK相关信息，生成 access config。 2. 普通账户在 Linux 环境中执行 docker 相关的命令时，必须以 sudo 方式执行。此时 s 会提醒找不到 access config。 执行 `sudo...

在执行 s proxied setup 后，电脑待机较长时间，此时相关的资源（FC 函数和本地的 proxy 实例）已经被删除了。如果通过 ctrl-c 终止，则会出现下面的错误：  这种错误是没有必要的。如果在删除相关资源时遇到明确返回不存在的错误，我们应该不报错。否则用户会困扰甚至担心。

使用 s local start auto -d 5678 调试 custom container，遇到 could not found runtime 错误

6

如下图所示，这个错误比较让人费解。 1. 将错误改成 custom container does not support debug mode 比较好。 2. custom container 不支持 -d 参数，是因为不知道是什么语言？这里可以参考下 AWS SAM 在 custom runtime/container 下 -d 功能是怎么样的。 

在 linux 环境下，使用 docker 等工具需要 sudo 权限。因此对 custom-container 而言，执行 s build，deploy 等命令需要 sudo 权限。但是一旦使用了 sudo 后，后续所有 s 的使用都必须有 sudo 权限，即使别的项目使用了 nodejs 等语言 runtime 也不行。会出现如下错误：  咱们需要优化的点： 1. 错误信息太多了，大部分是重复的。要精简优化。 2. 理想情况是，s...

初学者在使用 s 时，要开启日志，需要首先创建日志只有，授权，在 FC 服务中配置才行。这个步骤的体验当前是割裂的。我们能否在执行 s logs 时，检查到 s.yaml 中没有相关的日志配置，给出提示，引导用户完成： 1. 列出账户下的 logproject/logstore，以及新建资源的选项，让用户选择。 2. 如果没有相关资源，或者用户选择新建，则让用户输入 logproject/logstore（我们提供默认值，用户可直接确认），s 帮用户创建并配置好。 这样用户能平滑的完成日志的创建和配置。