Adding support for aws-greengrass-pkcs11-provider in meta-aws

[mariam-elshakfy]

Hello,

I was looking into enabling aws-greengrass-pkcs11-provider in a project, but didn't find any support for this here in meta-aws. So, ended up creating one inside our Yocto layer (meta-cassini).

I'm checking if this could be upstreamed here.
If so, which of the following would make more sense to add?

• A new recipe in meta-aws/recipes-iot/aws-iot-greengrass
• A PACKAGECONFIG for greengrass-bin (like fleetprovisioning)
• Any other ideas?

Thanks!

[thomas-roos]

Hi,
very cool - thank you!
I think the greengrass-bin recipe is already too big - so thinking may separating fleetprovisioning and pkcs11 is the next logical step. But not having this as a separate recipe, I like the package config. But might then the devtool upgrade does not work anymore?
May having a greengrass-bin-common.inc for folders etc and separate recipes and then a packageconfig (pkcs11) that enables a RDEPENDS for that pkcs11 component?
What do you think?

[mariam-elshakfy]

Thanks!

I think it makes sense to have a base recipe (+ greengrass-bin-common.inc for common configs).

Let me check if I understand it correctly:

1. The base recipe installs Nucleus runtime core + a default config without any plugins. It has RDEPENDS on plugin recipe depending on PACKAGECONFIG values.
2. Each plugin can have its own recipe (these could inherit a common plugin bbclass. I think it's the same logic: grab plugin from database and install it in a certain path + install a config fragment like this part)

For this to work: do_install of each plugin should be invoked only after do_install of the base.
I think the tricky part is the config, since all of the plugins will need an entry in the same file, so some extra post-processing task might be needed.

[thomas-roos]

Ok, this part I did not think through - even if I did something about this issue here. I mean if we have yq-native could merge in the do_install task, but as you said dependency wise the initial config should be installed first.
As long as we don't have support for config fragments (as we have for gg-lite) I'm about to say add this into greengrass-bin recipe as it is done for fleetprovisioning? Would that work for you? And would this break anything?
Still thinking... cause it would be good to have like a "greengrass" class or so that would handle the config merge easily. Then other, customer components could use this as well instead of having to do aws-greengrass-bin bbappend...

[mariam-elshakfy]

Adding it like fleetprovisioning works for me as well. It will just make the recipe even bigger 😄
Let me see if I can spend some time in doing a prototype for the separation though, it could be easier for discussion when ready.
Thanks.

[mariam-elshakfy]

Hi @thomas-roos,
I have created a PR regarding this discussion:
#13110

This is a prototype, so not tested thoroughly. I just made sure that plugins are in place and configuration is merged as expected.
Would appreciate the feedback.

[thomas-roos]

Based on your PR I was also working on an version that also supports components and greengrass-lite (#13222 still WIP) - also I try to avoid the yq-native, as this adds a layer dependency. Thus implementing the merge in python.
Feel free to comment. BTW in which branch do you need the PKCS11 ?

[mariam-elshakfy]

Hi Thomas,
Thanks. I think just master would be fine (and future stable releases as well - whinlatter, wrynose ..etc).