-
Notifications
You must be signed in to change notification settings - Fork 47
Plugins
Greengrass can load components as plugins to the Nucleus JVM. This enables those plugins to access anything that Nucleus or other plugins offer via their Java interfaces. Because of this, plugins are very powerful and are able to do things that no component would otherwise be able to do. Plugins currently come in 3 types; 1) component 2) "trusted" 3) provisioning plugin.
Greengrass components can be plugins when their "ComponentType" is set to aws.greengrass.plugin. If a component is a plugin type, then it will be loaded as an external (not builtin or "trusted") plugin. The plugin component must have an artifact which is a jar file whose name matches the component name. For some additional security, component plugins may not be installed from a local source; they must be downloaded from the AWS account. Using EZPlugins class, Greengrass will read the component jar file and find the class within the jar which implements the component. It has two ways to do this. The newer preferred way is that the jar file has a manifest entry called GG-Plugin-Class which tells Greengrass what class it should try to load. If that manifest entry is missing, then it will fallback to the older behavior which is to scan the full jar file and look for all classes that are annotated with @ImplementsService. This old behavior is slow and can use large amounts of heap memory, so it should be avoided and eventually removed. This slow path is slightly optimized to only scan for classes under com.aws.greengrass package namespace.
"Trusted" plugins are plugins which are not installed as components to Greengrass, rather they are automatically discovered and loaded when Greengrass starts up. They can be used for extending functionality of Greengrass before Greengrass is able to connect to AWS. For example, the PKCS11 provider plugin enables Greengrass to use private keys stored in hardware modules in order to connect to AWS. If Greengrass had to first connect to AWS and then receive a deployment that contained this PKCS11 plugin, that would not work because it is a chicken-egg problem.
Trusted plugins are automatically discovered during startup by providing the EZPlugins class with a "cache directory". The cache directory will be /greengrass/v2/plugins. Under that directory will be two more directories; trusted and untrusted. All jar files within these two directories will be scanned to find any class annotated by @ImplementsService, which will then be loaded into Greengrass and started as a service. Untrusted plugins are not used for anything and are not really tested currently. The difference between trusted and untrusted is that trusted plugins are loaded such that they extend the root Greengrass classloader and any future loaded trusted plugins then extend that classloader which enables one plugin to load classes from another plugin (which was loaded before it).
Greengrass plugin services as either component or trusted ought to extend from PluginService which provides correct default implementations for isBootstrapRequired(), bootstrap(), and isBuiltin().
Provisioning plugins differ from the previously described plugins because they do not implement a Greengrass service using @ImplementsService. Instead, they only provide provisioning capabilities and must implement DeviceIdentityInterface. Same as with component plugins, a provisioning plugin can specify the class to load in the manifest as GG-Plugin-Class which will prevent scanning the jar file.