Merge lp://qastaging/~ev/ubuntu-ci-services-itself/restish-swift-deployment into lp://qastaging/ubuntu-ci-services-itself

You might want to take a look at my branch. I made an update based on your comments. Specifically i think you'll want to merge in:

 http://bazaar.launchpad.net/~doanac/ubuntu-ci-services-itself/restish-charm-local/revision/115

I also merged with trunk for revno 114. My notes:

1) The bulk of this is just adding charm-helpers. I think Joe's approach in the webui MP handles this better. He's got a makefile that pulls in a specific revno of charm-helpers. I think this will keep our source tree a lot cleaner - especially when we start to merge in all the other charms.

2) Are you sure code like:
  code_runner = config['user_code_runner']

is safe when no value is provided and default is intended? When I've done this in the past, there is no dictionary item for elements that aren't specified explicitly. so i've always had to do: config.get('user_code_runner', 'restish'). Seems odd/annoying juju wouldn't do that for me, so maybe you know a trick

3) do we really need all the swift_* config options? Now that we have started to say we want "auth config" type stuff to go into a juju-deployer/config file that we pass to the charm, I was thinking this type of data could go there, so we don't have to specify it in every charm?

On 27 January 2014 19:28, Andy Doan <email address hidden> wrote:
> 2) Are you sure code like:
> code_runner = config['user_code_runner']
>
> is safe when no value is provided and default is intended? When I've done this in the past, there is no dictionary item for elements that aren't specified explicitly. so i've always had to do: config.get('user_code_runner', 'restish'). Seems odd/annoying juju wouldn't do that for me, so maybe you know a trick

  user_code_runner:
    default: "restish"
    type: string
    description: The user that runs the code

So it's guaranteed to at least set to 'restish'.

On 27 January 2014 19:28, Andy Doan <email address hidden> wrote:
> You might want to take a look at my branch. I made an update based on your comments. Specifically i think you'll want to merge in:
>
> http://bazaar.launchpad.net/~doanac/ubuntu-ci-services-itself/restish-charm-local/revision/115
 194 # juju needs to know about our local charms.
 195 # we could use the charms directory, but juju will wind up copying
 196 # external charms we use into this directory and making our source
 197 # tree dirty. using the deployer directory just makes it a bit cleaner

I don't understand what you mean by making the tree dirty. Can you elaborate?

We want to have the external charms in tree for the deployment, which
juju-deployer does. It doesn't let you bind to a specific revno, so
we'll want to have a commit or branch that builds these out with
config-manager, as we discussed this morning.

On 01/28/2014 06:24 AM, Evan Dandrea wrote:
>> http://bazaar.launchpad.net/~doanac/ubuntu-ci-services-itself/restish-charm-local/revision/115
> 194 # juju needs to know about our local charms.
> 195 # we could use the charms directory, but juju will wind up copying
> 196 # external charms we use into this directory and making our source
> 197 # tree dirty. using the deployer directory just makes it a bit cleaner
>
> I don't understand what you mean by making the tree dirty. Can you elaborate?

w/o that snippet you wind up having things like the apache2 and postgres
charm get copied to your source's charms/precise directory. It just gets
a little annoying because "bzr stat" shows these things. With my snippet
they get thrown into the venv directory and you just see that one entry
when you run "bzr stat"

On 28 January 2014 12:36, Andy Doan <email address hidden> wrote:
> On 01/28/2014 06:24 AM, Evan Dandrea wrote:
>>> http://bazaar.launchpad.net/~doanac/ubuntu-ci-services-itself/restish-charm-local/revision/115
>> 194 # juju needs to know about our local charms.
>> 195 # we could use the charms directory, but juju will wind up copying
>> 196 # external charms we use into this directory and making our source
>> 197 # tree dirty. using the deployer directory just makes it a bit cleaner
>>
>> I don't understand what you mean by making the tree dirty. Can you elaborate?
>
> w/o that snippet you wind up having things like the apache2 and postgres
> charm get copied to your source's charms/precise directory. It just gets
> a little annoying because "bzr stat" shows these things. With my snippet
> they get thrown into the venv directory and you just see that one entry
> when you run "bzr stat"

.bzrignore? :)

On 01/28/2014 10:48 AM, Evan Dandrea wrote:
> .bzrignore? :)

yeah - i thought about that. its not a terrible idea. i suppose that's
not any worse than my hack to copy the charms to a temp directory

On Tue, Jan 28, 2014 at 04:54:17PM -0000, Andy Doan wrote:
> On 01/28/2014 10:48 AM, Evan Dandrea wrote:
> > .bzrignore? :)
>
> yeah - i thought about that. its not a terrible idea. i suppose that's
> not any worse than my hack to copy the charms to a temp directory

I'm not a huge fan of the .bzrignore approach. I agree with Andy that
having external charms in a working copy of a bzr branch is bad. I like
to be able to easily blow away the juju-deployer set up charms/precise
directory at will and not have to pick and choose what to delete.

I don't have an easy solution either. I think having our charms in a
separate branch might be a better approach especially if we are also
going to need to be able to grab a specific revno of a charm. For that
matter I even think one branch per charm might be the best way to go.

I think the reason we initially went with including the charms in the
ubuntu-ci-services-itself (u-c-s-i) branch was to avoid having to update two
branches in lock-step. If I'm mistaken the rest of this paragraph is
probably moot. What solutions are available for inter-charm
dependencies? i.e. charm-A revno X requires charm-B revno Y. If we're
using revnos for each charm in u-c-s-i's juju-deploy config won't this
mostly mitigate the issue?

Text conflict in juju-deployer/image-builder.yaml.tmpl
Text conflict in juju-deployer/lander.yaml.tmpl
Text conflict in juju-deployer/test-runner.yaml.tmpl
3 conflicts encountered.

FAILED: Continuous integration, rev:118
No commit message was specified in the merge proposal. Click on the following link and set the commit message (if you want a jenkins rebuild you need to trigger it yourself):
https://code.launchpad.net/~ev/ubuntu-ci-services-itself/restish-swift-deployment/+merge/203385/+edit-commit-message

http://s-jenkins.ubuntu-ci:8080/job/uci-engine-ci/11/
Executed test runs:

Click here to trigger a rebuild:
http://s-jenkins.ubuntu-ci:8080/job/uci-engine-ci/11/rebuild

PASSED: Continuous integration, rev:118
http://s-jenkins.ubuntu-ci:8080/job/uci-engine-ci/19/
Executed test runs:

Click here to trigger a rebuild:
http://s-jenkins.ubuntu-ci:8080/job/uci-engine-ci/19/rebuild

I've proposed:

 https://code.launchpad.net/~doanac/ubuntu-ci-services-itself/restish-swift/+merge/207068

which might be an easier branch for people to review and approve.