kconfig: Added kconfig includes for service provider layer

[James-Kruczek]

kconfig includes which allow for service provider menu and managers
are missing from current master. kconfig/Kconfig was modified to
allow for a service provider menu similar to platform with the
exception of no default service provider. And
kconfig/Kconfig.managers was modified to include manager kconfig
defined by the service provider.

Since service provider is a many to many or none relationship with
platform it is best to have the includes in the core opensync portion.

[dejan-pojbic-plume]

Hi @James-Kruczek,

Best that we get on the call and discuss this change.
There are also other options already available and we would like to see, if some of those would be acceptable for you, like:

• using 3rdparty structure
• using multiple vendors

service-provider intention is more about just connecting to that cloud based on profile (development, qa, staging, production).
Of instance, we use 3rdparty/plume which we have additional tools, managers, plugins, which aren't part of OpenSync and can be also easily add/removed in case someone is doing gateway/extender/stb/...
All those device roles must use service-provider for cloud connectivity .

Thanks,
Dejan

[damjan-we]

I agree with Dejan, the purpose of the service-provider repo is to contain basic connectivity credentials. For additional code and managers I would recommend to use vendor/X. You can also combine multiple vendor/X,Y,Z by using INCLUDE_LAYERS build variable.

[James-Kruczek]

You all know that you wrapped the vendor Kconfig in a choice selection so you CANNOT have more than one vendor for Kconfig right? yeah you can include multiple vendors (which frankly is a much bigger paradigm break than what I am asking because the vendor alines with the model right?) But you can't configure KConfig for more than one vendor. Which is the thing I am trying to solve for. Funny enough You didn't wrap the platform in a choice so I can pick out Kconfig for multiple platforms but not multiple vendors. Also what is funny is I can without ANY patches service provider a layer and I can put managers etc in it. I just can't add Kconfig. At best, I could put my managers in 3rd party as you said. But they are my Service Provider managers, so keeping them there makes more sense. And it works, other than Kconfig. Also, there are many other things you should be pushing off to the service provider. Service providers have customizations that need to make to DHCP options and many other things. You should even have target layer functions for service providers but we haven't even gotten that far. I can't even get Kconfig so why would I start suggesting easy ways for service providers to extend your product?

[dejan-pojbic-plume]

Thanks @James-Kruczek for your comment and input.
Seems we have different views about service-provider usage and philosophy.
Currently OpenSync sees service-provider is more cloud-provider which include only essential cloud variables information, like:

• firmware profiles (development FW, production FW, testing FW, ...)
• cloud URL (developement cloud, staging cloud, production cloud, ...)

When we are switching clouds (aka service-provider aka cloud-provider), we would have same managers / feature scope since managers and other code lives in other repo's/folders. Seems we picked the wrong naming convention for these folders that would be more understandable and the meaning behind them.
Current solution is then to use 3rdparty infrastructure, where your managers/tools/overwrite would live and each vendor would get them and could edit the 3rdparty kconfig to the vendor HW specific values. Same as we have for other 3rdparty software like Ookla, Cognitive, SamKnows, ...
Example for Ookla - is 3rdparty package, vendor will include this 3rdparty package and can edit the default Ookla kconfig. Like change the number of threads used in SpeedTest run to get the best performance results, specific to vendor HW.
Lets discuss more and we hope that we can come to common solution.