Sharing Dependencies

[Ka0o0]

Hi,

I'm currently working with a team on an IoT application where we deploy Kubernetes on >100 edge devices. We've created a service landscape where we group certain services into deployable bundles using Porter. Those bundles roughly represent some functionality that we would like to be plug-and-playable. Between some of those bundles, we have dependencies, e.g. some basic functionality (lets call that bundle c) that is shared between certain bundles (bundle a and b):

a --|
    | --> c
b --|

If I understood the dependency management of Porter correctly, this would mean, if we deployed bundle a and b, bundle c would be installed twice. Once as a dependency to a and once for b. In our use case we have a reduced computational power, so it would rather be of favor to have bundle c only installed once.

So this raises a couple of questions for me:
a) is Porter capable of doing this? Did I overlook something?
b) if no, then is there another solution to this problem?
c) if no, then is it in the interest of Porter to provide such a dependency strategy? I would be happy to contribute.

Thanks in advance for your support.

[carolynvs]

You are correct that is how Porter works today, dependencies cannot be shared.

We have an open proposal to change Porter so that other scenarios are supported:

• exclusive dependencies
• shared dependencies
• user-provided dependencies (use a dependency not installed by porter originally, like an existing dev database)
• dependencies that satisfy an interface (e.g. I need a mysql database, it could be a managed database from a cloud provider, installed by helm, or could be one running on my local machine)

Sounds like the shared dependencies feature would work for your use case?

I am working with the upstream CNAB specification to support these advanced scenarios, if you have feedback or would just like to 👍 the proposal so that I can say it's important, that would be helpful!

[Ka0o0]

Hi @carolynvs,
thanks!
I've had a quick look on the PEP and it seems that it would cover our use case. I'll try to look over it in more detail next week to think about some feedback.