Capomastro's charm should not have local payloads of jobtypes XMLs

[Caio Begotti]

So basically we first had to upgrade the charm before fiddling with its Juju relations during the last service upgrade. It is because the API relation with Jenkins was not picking up the latest XML files for the jobtypes as Juju only update charm branch (thus all our XML payloads) when it upgrades the charm altogether.

Ideally we should have the jobtypes data out of the charm tree as Deej mentions below but I think using Swift for all cases is not the best solution as only us use Swift, Other People (tm) might simply want to use the charm without Openstack so we'll need to think of another way.

I'm also setting this to low importance as discussed on IRC (chat log below).

<deej> juju-deploy makes sure there's a service running matching all the services defined in your config
<deej> But wont do a charm upgrade
<deej> Doesn't really have a way to determine if one is necessary, honestly
<caio1982> i still wonder if i should file a bug about that, as a user i'd expect juju to be able to update the charm data so relations can be updated without necessarily upgrading the charm
<deej> Er?
<deej> I'm still not sure what you mean by that
<deej> I saw you say it last night but was on my way to dinner
<caio1982> deej: we tried to remove/readd a relation between charms and it wasnt working because they relied on a bzr update of the charm files, but juju only bzr update that when you call a charm upgrade, so we had to upgrade the charm before being able to re-add the relation, then it worked
<caio1982> kind of offtopic anyway, maybe i'm getting juju wrong
<deej> So a relation required a new set of relation data?
<caio1982> yep
<caio1982> (local files that are "imported" into the unit by the relation when it is set)
<deej> That didn't exist in the charm code until you ran an update-charm
<deej> Ah
<deej> So, shipping payloads around like that is kind of sub-optimal
<deej> Ideally the only things you'd be shipping in the charm are templates
<deej> And payloads should be in swift
<caio1982> how do you guys suggest us to do it?
<caio1982> oh, ok
<deej> (There may be other use cases for files shipped with charms, but they're few and far between)
<deej> Yeah, the current best practice is to put your payload in swift
<deej> And have your charm fetch it from there
<deej> Upload it to swift as part of the mojo build phase, ideally
<caio1982> i'll make a note about that and file an internal bug so we can change it then
<deej> Yeah, it's not super urgent
<caio1982> but lesson learned last night anyway, we'll need to upgrade the charm before fixing the relation next times
<deej> But you're going to find shipping the file in the charm is awkward in those kinds of ways
<deej> Yeah