Merge lp://staging/~joetalbott/ubuntu-ci-services-itself/data-store-config into lp://staging/ubuntu-ci-services-itself

Consider me a soft +1. I'm not sure how this will play out when we start to integrate this with a service, but at a minimum - having an example template is nice.

Why does this need to be hardcoded under /etc? Webops put the code and configuration of Prodstack services under /srv:

https://wiki.canonical.com/InformationInfrastructure/WebOps/Juju/Prodstack#Deployment_Environment
https://wiki.canonical.com/InformationInfrastructure/WebOps/Juju#Charm_Writing_Guidelines

"Your application should create a /srv/${external-service-name}/${instance-type}/${service-name} directory for the code itself, and /srv/${external-service-name}/{${instance-type}-logs,scripts,etc,var} as needed."

Could we made this location configurable, built and set by the charm:
http://bazaar.launchpad.net/~daisy-pluckers/charms/precise/daisy/trunk/view/head:/config.yaml#L1
http://bazaar.launchpad.net/~daisy-pluckers/charms/precise/daisy/trunk/view/head:/hooks/common#L3

On Sat, Dec 14, 2013 at 03:20:33PM -0000, Evan Dandrea wrote:
> Review: Needs Fixing
>
> Why does this need to be hardcoded under /etc? Webops put the code and configuration of Prodstack services under /srv:
>
> https://wiki.canonical.com/InformationInfrastructure/WebOps/Juju/Prodstack#Deployment_Environment
> https://wiki.canonical.com/InformationInfrastructure/WebOps/Juju#Charm_Writing_Guidelines

It doesn't have to be in /etc.

>
> "Your application should create a /srv/${external-service-name}/${instance-type}/${service-name} directory for the code itself, and /srv/${external-service-name}/{${instance-type}-logs,scripts,etc,var} as needed."

I'm not certain what the library should use under /srv.

>
> Could we made this location configurable, built and set by the charm:
> http://bazaar.launchpad.net/~daisy-pluckers/charms/precise/daisy/trunk/view/head:/config.yaml#L1
> http://bazaar.launchpad.net/~daisy-pluckers/charms/precise/daisy/trunk/view/head:/hooks/common#L3

I'm not sure we can make it configurable since the code needs to know where to look
for the config file.

i'm wondering if we should ditch the config file notion and do it this way:

the data_store API adds a new method like "initialize(param1, param2, etc)". It then becomes the responsibilty of the service using this API to provide the information. For example, code using my django-charm can take advantage of a configuration option that lets you set key-value pairs in django settings. So maybe we are trying to solve the problem in the wrong place here?

Evan,

Can this be done a single time so that every charm that uses the data store library doesn't have to repeat the same configuration? Eventually, I expect this to be replaced later by a 1st class data store service, in which case that charm is the only one that would need to know the configuration. Until then, is there a pattern for sharing identical, private config values between charms.

On 15 December 2013 20:38, Francis Ginther
<email address hidden> wrote:
> Can this be done a single time so that every charm that uses the data store library doesn't have to repeat the same configuration? Eventually, I expect this to be replaced later by a 1st class data store service, in which case that charm is the only one that would need to know the configuration. Until then, is there a pattern for sharing identical, private config values between charms.

I'm not sure what the best practice is here. Off the top of my head,
one approach might be to include the configuration as a base64-encoded
file in juju-deployer, that gets set for each charm that needs it in
juju-deployer:

vhost_http_template: include-base64://configs/jenkins_http_vhost

Of course that's a copy and paste exercise, at which point you might
as well copy and paste a block of config.yaml settings from one charm
to the next.

For what it's worth, I contemplated whether we could use
juju-deployer's inherits stanza, but that's geared towards inheriting
a set of charms rather than a set of configuration options, I think.

Was able to run tests after creating a /tmp/auth_config.yaml file with my nova credentials. In the future can this be mocked out for unit testing?

For now, this works and I think it's sufficient for other components to start using.

You'll also want to drop ci-utils/ci_utils/data_store/data_store_config.yaml.example now that the credentials are passed in. +1 otherwise.