Edge-home-orchestration-go: [WIP] 边缘设备和服务的集中管理

@suresh-lc @Karthikeyan-Samsung PTAL。 目前的评分机制对我来说有点低效，因为相关的边缘候选者自己计算他们的能力作为分数，然后将结果发送给主人。 另一方面，master 可以根据它们传输的容量因子而不是每个边缘候选来计算这些分数。 这似乎更适合主人。 你怎么看？

我们目前的方法不是小学和中学的那种。 设备详细信息（内存/cpu/带宽）在初始发现期间与其他设备交换。 因此，当设备“A”想要卸载服务时，会在设备“A”本身中计算所有其他设备（已存储）的评分并进行卸载。 因此，只是为了澄清当任何应用程序向边缘编排提出服务卸载请求时，不会从其他设备获得评分。 因此，根据当前的内存/CPU/带宽使这个评分更加动态（实时）将是一个很好的改进点。

正如@t25kim所指出的：想要一种集中的方法（大师）。
以下是在这种情况下的一些考虑：

1. 选择主节点
2. 在主节点出现故障时管理场景，如果我们愿意，可以说是辅助主节点类型的场景。
3. 从 Device A 到 B 的任何请求，最初都需要通过 primary 来识别 Device B。

@suresh-lc 重点不是主次拓扑，目前的评分机制如下（至少从源码层面来说：又名scoringmgr ：

1. 每个候选人计算其分数并自行完成所有必需的处理。
2. 实际上，当边缘编排器决定这样做时，需要卸载，因此应该在该编排器而不是候选者本身中完成分数计算。
3. 这里的建议开始寻找这种情况。

如果您看到真正的分解拓扑，“主节点宕机”之类的场景应该由另一个代表来处理，它只负责状态数据库和 Home Edge 场景中的某些内容。 我不确定当前的评分机制是否是最佳选择。

顺便说一句，让我们用其他术语来称呼master-slave 。 小学/中学呢？

参考：
https://www.zdnet.com/article/linux-team-approves-new-terminology-bans-terms-like-blacklist-and-slave/
https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now
https://tools.ietf.org/id/draft-knodel-terminology-00.html#rfc.section.1.1.1

我喜欢将术语 master/slave 更改为 primary/secondary 的想法。
此外，我想建议使用术语阻止名单/白名单而不是黑名单/白名单。

顺便说一句，让我们用其他术语来称呼master-slave 。 小学/中学呢？

参考：
https://www.zdnet.com/article/linux-team-approves-new-terminology-bans-terms-like-blacklist-and-slave/
https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now
https://tools.ietf.org/id/draft-knodel-terminology-00.html#rfc.section.1.1.1

在其中一个 TSC 中，其中一名成员建议使用上级/下级术语而不是主/从。 为了我们的理解，我把它作为主/从。

我喜欢将术语 master/slave 更改为 primary/secondary 的想法。
此外，我想建议使用术语阻止名单/白名单而不是黑名单/白名单。

对于黑名单：在 TSC 调用中，建议使用“已批准”一词，如“已批准的容器”等。

顺便说一句，让我们用其他术语来称呼master-slave 。 小学/中学呢？
参考：
https://www.zdnet.com/article/linux-team-approves-new-terminology-bans-terms-like-blacklist-and-slave/
https://www.theserverside.com/opinion/Master-slave-terminology-alternatives-you-can-use-right-now
https://tools.ietf.org/id/draft-knodel-terminology-00.html#rfc.section.1.1.1

在其中一个 TSC 中，其中一名成员建议使用上级/下级术语而不是主/从。 为了我们的理解，我把它作为主/从。

我喜欢将术语 master/slave 更改为 primary/secondary 的想法。
此外，我想建议使用术语阻止名单/白名单而不是黑名单/白名单。

对于黑名单：在 TSC 调用中，建议使用“已批准”一词，如“已批准的容器”等。

@suresh-lc 它必须是来自 LF Edge 的 TSC。 有什么指导方针吗？

@suresh-lc 重点不是主/从拓扑，目前的评分机制如下（至少从源代码层面：又名scoringmgr ：

1. 每个候选人计算其分数并自行完成所有必需的处理。
2. 实际上，当边缘编排器决定这样做时，需要卸载，因此应该在该编排器而不是候选者本身中完成分数计算。
3. 这里的建议开始寻找这种情况。

如果您看到真正的分解拓扑，“主节点宕机”之类的场景应该由另一个代表来处理，它只负责状态数据库和 Home Edge 场景中的某些内容。 我不确定当前的评分机制是否是最佳选择。

设备 A、B 和 C 是连接在同一网络中的三台设备。 所有设备/服务详细信息及其计算/内存能力都在所有设备之间进行交换。

设备 A：App X 请求将服务卸载到同一设备中的 Edge-Orchestrator。
设备 A ：设备 A 中的 Edge-Orchestrator，发现 B 和 C 都有服务。
设备 A : A 向 B 和 C 请求分数
设备 A：根据得分，A 将服务卸载到得分更高的设备 C。
设备 C：执行请求的服务。

以这种方式进行评分的原因使得评分更加实时。 相反，如果我们在请求的设备上进行评分，则无法考虑实时值。 在发现过程中，内存可能是 1Gb，而在计算评分时可能是 512，因为其他进程正在运行。 因此，这种类型的评分计算使其接近实时。 无论如何，候选者的评分计算都是由这些设备中的边缘编排计算的。

我们应该考虑通过基于更多实时参数并考虑更多参数来增强评分机制。 甚至可以进行基于时间的分析，例如如果服务被卸载，但在我们知道设备会因为用户模式而变得忙碌之前，可以合并此类事情。

@suresh-lc 我不同意你的想法，即当前场景更实时，因为在每个边缘接收请求时资源没有不同。
假设请求到达 B 或 C 的时间是 T。在当前场景中，每个设备根据 T 时刻的资源计算并发送分数。在提议的场景中，每个设备在 T 时刻发送相同的资源信息和 primary( master) edge 根据信息计算分数。

您的关注很重要，但我认为当前的问题是设备 A 不知道 B 和 C 有什么优势。
如果 C 显着内存不足，那么即使 C 得分比 B 好，A 也应该选择 B。

@t25kim ：无论您提到什么，例如共享所有设备信息而不是分数，都会将所有设备资源详细信息共享给其他设备。

假设请求到达 B 或 C 的时间是 T。在当前场景中，每个设备根据 T 时刻的资源计算并发送分数。在提议的场景中，每个设备在 T 时刻发送相同的资源信息和 primary( master) edge 根据信息计算分数。

即使在这种方法中，T 处的资源也可能不同。 但是 T+1 时的资源，当分数计算发生在 Edge 时，可能会有所不同。 所以这也不会导致实际的分值。 设备将资源详细信息发送到 Edge 后，资源值可以更改（对于 B 和 C），这就是我的意思。

如果 C 显着内存不足，那么即使 C 得分比 B 好，A 也应该选择 B。

在这种情况下，由于 score 还考虑了内存，因此计算的分数自然会更少。 因此，A自然而然地选择了B而不是C。

因此，没有单一的万无一失的方法。 但是为了加强系统我们可以考虑其他的分数计算方法。 我们可以考虑时间类的经验方式而不是 Apriori 方式

@suresh-lc 嗯..这很有趣，因为正如您指出的“经验方式”而不是“先验方式”，它有一个上下文，即边缘编排器应该做出最佳主节点的最终决定，以卸载基于给定的服务关于收集的数据（具有历史模式等，最终使用 AI/ML）。 所以对我来说，邻居设备完成自己的计算的当前机制有点开销。

@suresh-lc @t25kim我认为@t25kim有一些基本的想法来提出他的建议。 为了结束对这个问题的反复讨论，创建一个单独的分支来检查这个提案的可行性怎么样？ 有什么意见吗？

@suresh-lc @t25kim我认为@t25kim有一些基本的想法来提出他的建议。 为了结束对这个问题的反复讨论，创建一个单独的分支来检查这个提案的可行性怎么样？ 有什么意见吗？

雅其好点做一个可行性。 执行明智，应该可以做到。 但是为了比较现有方法和新方法，我们需要计算指标以查看哪种方法比较好。

1. 设备 B 和 C 向 A 发送分数，然后任何一个设备资源出现故障。
2. 设备 B 和 C 向 A 发送资源详细信息，其中一个设备资源出现故障。

@suresh-lc @MoonkiHong这是一个重要的问题，我现在想不出如何解决这个问题。 当 B 或 C 向 A 发送高分突然下降时，home edge 上是否有任何代码可以解决问题？

我们可能需要找出任何地面实现/算法来重新配置给定本地网络中的主要/次要设备。

通过#26 接受现有报告的考虑