1 回答
- 最新
- 投票最多
- 评论最多
0
Hi majh. If you haven't already, please read this document: https://docs.aws.amazon.com/greengrass/v2/developerguide/manage-deployments.html. In particular:
What version of the nucleus are you running?
If you are running 2.5.1 or later, and the greengrass:ListThingGroupsForCoreDevice permission is granted in the policy (and it seems to be in your case), then the component would be removed on "the next deployment" to that device. (So long as another deployment that targets the device doesn't include that component.)
相关内容
AWS 官方已更新 2 年前
Thanks @Greg_B - So what does this boil down to operationally - as it seems like we want to redeploy to that unit, but not actually change anything, just trigger the process which will remove the component. Is there any sort of generally used scheme for this ? Do we just revise a deployment that is targetting that particular 'Thing' and that will be the trigger ? Or do we need some sort of dummy 'Trigger' component that is just sent down to allow cleanup of removed components ?
Hi majh - I'm not sure I understand your statement. Removing a component certainly changes the state of the device. Are you not adding Thing-X to a different group which would trigger a deployment? If not, then you'll need a deployment that targets the Thing.
Hi JoeAtAWS - In this case - I didn't have a specific need to add Thing-X to a different group, what I wanted, was just to remove the component from being run on the thing. So basically what I meant was, it seems to me that in order to actually have the component removed from the Thing-X, I have to first remove the thing from the group targeted by the component deployment, and then create some sort of dummy or trigger deployment to send down to that thing - so that the removal actually happens. And i was asking how this is generally done. It just seems like there should be a dummy trigger component that's only purpose is to be sent down to the unit to force any component removals to occcur.