Merge lp://staging/~doanac/ubuntu-ci-services-itself/restish-charm-local into lp://staging/ubuntu-ci-services-itself

On 16 January 2014 19:21, Andy Doan <email address hidden> wrote:
> + # we have local charms that juju-deployer will expect in a fixed place
> + charms = os.path.join(root_dir, 'charms')
> + for sub in os.listdir(charms):
> + src = os.path.join(charms, sub)
> + dst = os.path.join(self.deployment.deployer_dir, sub)
> + shutil.copytree(src, dst)
> +

As mentioned on IRC, you'll want to just set JUJU_REPOSITORY. juju and
juju-deployer will then look in $JUJU_REPOSITORY/precise/$charm_name
for each charm.

On 01/17/2014 12:45 PM, Evan Dandrea wrote:
> On 16 January 2014 19:21, Andy Doan<email address hidden> wrote:
>> >+ # we have local charms that juju-deployer will expect in a fixed place
>> >+ charms = os.path.join(root_dir, 'charms')
>> >+ for sub in os.listdir(charms):
>> >+ src = os.path.join(charms, sub)
>> >+ dst = os.path.join(self.deployment.deployer_dir, sub)
>> >+ shutil.copytree(src, dst)
>> >+
> As mentioned on IRC, you'll want to just set JUJU_REPOSITORY. juju and
> juju-deployer will then look in $JUJU_REPOSITORY/precise/$charm_name
> for each charm.

I tried that and it doesn't seem to work. It seems like juju-deployer
doesn't honour the JUJU_REPOSITORY environment variable. As far as I can
tell, we'll have to carry this hack around. I'm open to other ideas though.

On 22 January 2014 16:42, Andy Doan <email address hidden> wrote:
> I tried that and it doesn't seem to work. It seems like juju-deployer
> doesn't honour the JUJU_REPOSITORY environment variable. As far as I can
> tell, we'll have to carry this hack around. I'm open to other ideas though.

You're right. Just spoke with hazmat. The reason it was working for me
in lp:ci-train is that the local charm is always in the current
working directory:

https://bugs.launchpad.net/juju-deployer/+bug/1229390

Hmmm, this is a bit frustrating. I'd like to be able to do:

# juju-deployer -c lander.yaml

but the only way for that to work is enforce that the CWD is ./juju-deployer when executing the above. Since that is a no-go due to the bug referenced above, maybe we just need to add this to the deploy script and allow

# deploy lander

and it magically relocates the charms as needed and does "juju-deployer -c $1.yaml".

On 01/22/2014 02:29 PM, Francis Ginther wrote:
> Since that is a no-go due to the bug referenced above, maybe we just need to add this to the deploy script and allow
>
> # deploy lander
>
> and it magically relocates the charms as needed and does "juju-deployer -c $1.yaml".

Not a terrible idea. If Evan +1's the idea, I can add the change.

i spoke to evan and he thinks we should use the juju-deployer branch containing the fix we need. It should be getting upstreamed very soon. I'm going to try and get:

 https://code.launchpad.net/~ev/ubuntu-ci-services-itself/pythonise-integration-test-runner/+merge/202153

merged first. Then, if we still need this updated branch, I'll update this new python version of the tests/run script to use the juju-branch referenced in the bug.

okay - revno 115 changes our code to set JUJU_REPOSITORY. I'm still copying our charms to a temp directory as noted by the comment in that revno so that we don't pollute our source tree.

I'm not super keen on copying charms around, but I reckon we fix this later by using config-manager to populate charms/precise with the branches of all of our not-in-tree charms pinned to specific revnos (so we're not always deploying the untested tip of these charms).

+1

Attempt to merge into lp:ubuntu-ci-services-itself failed due to conflicts:

duplicate in charms.moved