s remove能力的支持

[anycodes]

现在s remove的行为有些鸡肋，这里需要增加一种模式可能会更好，就是：

s remove service -f

可以强行删掉service下所有的东西

[SquatsTonight]

s remove service -y 试一下

[anycodes]

加-f的行为是说如果当前资源下有子资源时，可以直接删除子资源。

[SquatsTonight]

子资源 的范围涵盖哪些？

[SquatsTonight]

@wss-git fc-base-sdk 删除服务是不会删除其下面的函数以及触发器是吗

[anycodes]

1: s remove service

• 如果当前function资源和本yaml一致，直接删除function和service
• 如果当前function资源和本yaml不一致，提示service下的函数资源，或者通过-y,-f来强行删除

2: s remove function

• 如果当前trigger资源和本yaml一致，直接删除trigger和function
• 如果当前trigger资源和本yaml不一致，提示function下的触发器资源，或者通过-y,-f来强行删除

3: s remove domain

• 如果当前route资源和本yaml一致，直接删除route和domain
• 如果当前route资源和本yaml不一致，提示domain下的route资源，或者通过-y,-f来强行删除

4: s remove
s remove进行Yaml中已有的资源删除
相当于分别执行

s remove domain
s remove function
s remove service

即先执行s remove domain，进行提醒和选择
再执行s remove function，进行提醒和选择
最后执行s remove service，进行提醒和选择

如果是执行s remove -y
相当于分别执行

s remove domain -y
s remove function -y 
s remove service -y

[SquatsTonight]

1: s remove service

• 如果当前function资源和本yaml一致，直接删除function和service
• 如果当前function资源和本yaml不一致，提示service下的函数资源，或者通过-y,-f来强行删除

2: s remove function

• 如果当前trigger资源和本yaml一致，直接删除trigger和function
• 如果当前trigger资源和本yaml不一致，提示function下的触发器资源，或者通过-y,-f来强行删除

3: s remove domain

• 如果当前route资源和本yaml一致，直接删除route和domain
• 如果当前route资源和本yaml不一致，提示domain下的route资源，或者通过-y,-f来强行删除

4: s remove
s remove进行Yaml中已有的资源删除
相当于分别执行

s remove domain
s remove function
s remove service

即先执行s remove domain，进行提醒和选择
再执行s remove function，进行提醒和选择
最后执行s remove service，进行提醒和选择

如果是执行s remove -y
相当于分别执行

s remove domain -y
s remove function -y 
s remove service -y

1. 当前 function 资源是指？
2. s remove 逻辑中漏掉了 s remove triggers

[anycodes]

• 当前 function 资源是指？

仅仅是function的个数和名字。不需要更细致的资源层级。

例如我yaml上面声明了functionA

我只需要判断线上的service下是否包括了functionA，如果包括了functionA，是否还有其他的function即可。

• s remove 逻辑中漏掉了 s remove triggers

Trigger的表现和现在一致即可，因为trigger已经是最小资源了

[SquatsTonight]

1: s remove service

• 如果当前function资源和本yaml一致，直接删除function和service
• 如果当前function资源和本yaml不一致，提示service下的函数资源，或者通过-y,-f来强行删除

2: s remove function

• 如果当前trigger资源和本yaml一致，直接删除trigger和function
• 如果当前trigger资源和本yaml不一致，提示function下的触发器资源，或者通过-y,-f来强行删除

3: s remove domain

• 如果当前route资源和本yaml一致，直接删除route和domain
• 如果当前route资源和本yaml不一致，提示domain下的route资源，或者通过-y,-f来强行删除

4: s remove
s remove进行Yaml中已有的资源删除
相当于分别执行

s remove domain
s remove function
s remove service

即先执行s remove domain，进行提醒和选择
再执行s remove function，进行提醒和选择
最后执行s remove service，进行提醒和选择

如果是执行s remove -y
相当于分别执行

s remove domain -y
s remove function -y 
s remove service -y

3. remove service 时是否也要判断 trigger 是否一致
4. 再执行s remove function，进行提醒和选择，选择和提示指的是？

[anycodes]

• remove service 时是否也要判断 trigger 是否一致
  不需要，只需要检查下一层资源就好，即只需要检查function资源就好。默认删除这个函数全部trigger

• 再执行s remove function，进行提醒和选择，选择和提示指的是？

func removeTrigger(){}
func removeDomain(){}
func removeFunction(){}
func removeService(){}

func remove(){
  removeDomain()
  removeTrigger()
  removeFunction()
  removeService()
}

@git-qfzhang

[wss-git]

我说说我的理解哈：
按照上面描述，如果是删除fc的资源，那么删除最大粒度应该是 s remove --force，然后就执行删除操作，流程如下：

1. s remove domain 此资源其实是独立于服务函数体系的，是一个最小资源，理解和 trigger 类似，为什么也有一执行判断的问题呢？
2. s remove triggers 删除所有的触发器
3. s remove function 删除所有的函数
4. s onDemand removeAll 【未提供】
5. s provision removeAll【未提供】
6. s alias deleteAll【未提供】
7. s version deleteAll【未提供】
8. s remove service

按照上面的描述：上面这个 1-8 是属于删除资源的原子能力【不传入 --force 的情况下】，那么在执行这些删除指令的时候是需要 get 一下资源的 list，然后再和传入的参数对比，如果一致，则直接删除，如果不一致，那么则提示是否删除所有，选择是删除所有，选择否尝试删除传入的资源

[anycodes]

再完善一个版本：

1: s remove service

• 如果当前function资源和本yaml一致，直接删除function和service
• 如果当前function资源和本yaml不一致，提示service下的函数资源，或者通过-y,-f来强行删除

2: s remove function

• 如果当前trigger资源和本yaml一致，直接删除trigger和function
• 如果当前trigger资源和本yaml不一致，提示function下的触发器资源，或者通过-y,-f来强行删除

3: s remove domain

• 如果当前route资源和本yaml一致，直接删除route和domain
• 如果当前route资源和本yaml不一致，提示domain下的route资源，或者通过-y,-f来强行删除

4: s remove provision

• 如果指定了参数：--target，可以删除指定target（所谓删除就是将预留调整为0）
• 如果没有指定，提醒用户会删除所有的provision，或者通过-y,-f来强行删除

6: s remove version

• 如果指定了参数：--version-id，可以删除指定id
• 如果没有指定，提醒用户会删除所有的version，或者通过-y,-f来强行删除

7: s remove alias

• 如果指定了参数：--alias-name，可以删除指定alias
• 如果没有指定，提醒用户会删除所有的alias，或者通过-y,-f来强行删除

8: s remove onDemand

• 如果指定了参数：--qualifier，可以删除指定qualifier
• 如果没有指定，提醒用户会删除所有的onDemand，或者通过-y,-f来强行删除

9: s remove layer

• s remove layer version
• s remove layer

10: s remove
s remove进行Yaml中已有的资源删除
相当于分别执行

s remove domain
s remove function
s remove provision
s remove onDemand
s remove alias
s remove version
s remove service

即先执行s remove domain，进行提醒和选择
再执行s remove function，进行提醒和选择
........
最后执行s remove service，进行提醒和选择

如果是执行s remove -y，则直接强制执行

[anycodes]

所有的fc的delete能力都尽量收敛到remove中吧

[wss-git]

devsapp/fc-base-sdk#2 删除 服务函数和触发器

[wss-git]

功能已经完成， help 信息还没有完善，help信息关联到 #51 更新

[lowkeyrd]

1. 这个交互太频繁了，我如果是用户执行s remove会被中断崩溃。不应该把live diff实现到具体的删除函数中，应该提供一个通用的plan命令，在plan里去判断yaml跟线上真实资源的差异，并给出预计操作资源的提示。
   回到remove中，s remove、s remove xxx，都先调用plan，根据传递的scope返回live diff结果，也就是：执行remove，提示所有要删除的资源，仅需进行一次用户确认交互。
2. s remove service，如果service下有函数，此时肯定是操作失败的，这种有资源依赖导致资源必然无法删除的情况，程序是完全可以判断的，应该先给予提示。