Different set of config data passed from NuleculeBase config to providers.

[cdrage]

atomicapp master:

2015-10-16 10:23:21,606 - atomicapp.nulecule_base - DEBUG - Data given {'general': {'namespace': 'test', 'provider': 'docker'}}
2015-10-16 10:23:21,606 - atomicapp.plugin - DEBUG - Found provider <class 'docker.DockerProvider'>
2015-10-16 10:23:21,607 - atomicapp.plugin - WARNING - Configuration option 'providerconfig' not found
2015-10-16 10:23:21,607 - docker - DEBUG - Given config: {'namespace': 'test', 'provider': 'docker'}

cdk2-beta3-rc1:

- WARNING - Configuration option 'providerconfig' not found
2015-10-16 10:32:10,396 - atomicapp.providers.docker - DEBUG - Given config: {'general': {'namespace': 'test', 'provider': 'docker'}}
2015-10-16 10:32:10,396 - atomicapp.providers.docker - DEBUG - Namespace: default

See Given config: line.

Now... for future integration and more information, I believe we should pass the entire config (including "general"), which is what cdk2-beta3-rc1 is doing right now. If we perhaps happen to include more variables in the future, we wouldn't want to do another PR to fix and perhaps break integration.

This will however change the:
self.namespace = self.config.get("namespace")
to
self.namespace = self.config["general"]["namespace"]

In all providers.

[dustymabe]

@rtnpro - I'm interested in your take on this.

[cdrage]

UPDATE

Seems it was a testing error for configuration. Either way, still want to discuss whether we want to pass the entire configuration to provider.

[rtnpro]

@charliedrage
Can we use get_context() to supply normalized config data to a provider?
Usage: https://github.com/projectatomic/atomicapp/blob/cdk2-beta3-rc1/atomicapp/nulecule/base.py#L276
Code: https://github.com/projectatomic/atomicapp/blob/cdk2-beta3-rc1/atomicapp/nulecule/lib.py#L49

Will the above solve this issue?

[cdrage]

@rtnpro Yup, that will.

We will however have to change the Nulecule spec to conform to this. We should label this issue for after GA / Beta-3.

[rtnpro]

Agreed 👍

[dustymabe]

@cdrage @rtnpro has the goal of this issue changed at all. I know there is #423 which might affect this.

[cdrage]

@dustymabe With the persistent storage implementation we will need a way to pass persistent storage information to the provider (if we go the way of having a def persistent_storage function within the provider and the provider handling it). So yes, this still needs to be implemented.

[cdrage]

Hey @rtnpro you are working on a Config class for this. Seems that this issue would be fixed upon the completion of it, I'm going to assign this to you for now. :)