[03:25] <thumper> stub: hey there
[03:25] <stub> thumper: yo
[03:25] <thumper> stub: had an issue with the postgresql charm the other day
[03:25] <thumper> I have an old one in use cs:trusty/postgresql-10
[03:25] <stub> You using the rewrite or the cs: one?
[03:25] <stub> k
[03:25] <thumper> and I tried to upgrade to -28
[03:25] <thumper> only one unit
[03:26] <thumper> but it said "can't as it would break replication relation"
[03:26] <thumper> seems to have a peer relation with itself
[03:26] <thumper> or something
[03:26] <thumper> how do I upgrade it?
[03:26] <stub> I do not recall such an error message :-/
[03:26] <thumper> --force only mentions units in error state
[03:27] <thumper> that error message probably came from juju itself
[03:27] <thumper> I think the charm upgrade expects endpoints to be the same ...
[03:27] <thumper> FSVO the same
[03:27] <stub> oh... that is a juju error message? Right. So probably because some relations got renamed and I didn't realize it would be a problem?
[03:27] <thumper> yeah...
[03:27] <thumper> that makes sense
[03:28] <thumper> what does the replication relation do if there is only one unit?
[03:28] <thumper> anything?
[03:28] <stub> or the name of the interface changed
[03:28] <stub> nothing
[03:28]  * thumper guesses interface changed name
[03:29] <thumper> hmm...
[03:29] <thumper> I wonder what the nice way is to say "just upgrade, ..."
[03:29] <thumper> I should try it locally first I guess :)
[03:29] <stub> So lp:~stub/charms/trusty/postgresql/rewrite is what I recommend and actually has a test to upgrade from r127 (no idea of the cs: revno). But you are earlier than that.
[03:30] <stub> thumper: Is this modern juju, or haven't you updated that bit?
[03:30] <thumper> I deployed this last year around July
[03:30] <thumper> and that charm hasn't been upgraded since:)
[03:30] <stub> thumper: upgrade-charm --force will push the new charm everywhere without running hooks.
[03:31] <thumper> really? --force won't run hooks?
[03:31] <thumper> that seems fcuked
[03:31] <stub> I'd test upgrading to 1.24 then upgrading to the rewrite branch (again, recommended but not landed for review/beurocratic reasons)
[03:32] <stub> thumper: It is the only way to fix a charm that errored in its upgrade-charm hook.
[03:32] <thumper> I have my env running 1.24.5
[03:32] <thumper> right, but it hasn't errored
[03:32] <thumper> it just said "won't upgrade"
[03:32] <thumper> still on -10
[03:32] <thumper> marcoceppi: I see you are around
[03:32] <stub> Yeah, but that is why we love upgrade-charm --force.
[03:32] <thumper> marcoceppi: quick charm upgrade question
[03:32] <marcoceppi> thumper: yes, I am in your timezone
[03:33] <thumper> I have cs:trusty/postgresql-10 and I want to upgrade to cs:trusty/postgresql-28
[03:33] <thumper> but an interface got renamed (or something)
[03:33] <thumper> and juju says "nah"
[03:33] <thumper> what will --force do?
[03:34] <marcoceppi> thumper: so force will, at the next idle point in the agent, unpack the charm files without queuing an upgrade-charm hook
[03:34] <marcoceppi> thumper: not sure if thta fixes your missing interface/relation problem or not, but it's how I develop
[03:35] <thumper> so I should manually run the hooks?
[03:35] <thumper> this seems flakey to me...
[03:36] <thumper> marcoceppi: also, stub has upgrade tests from r127 of the charm, any idea how we can work out what charm version that is?
[03:37] <stub> thumper: Not so much flaky, but a necessary back door to get you out of this snafu. The real problem is way back then I changed a name and nobody at that time realized it was a problem.
[03:38] <marcoceppi> thumper: like right now, I've got a broken hook. So I patch the charm layer, charm build, then upgrade-charm --force, exit 1 in the debug hooks so I can keep that hook, then do a juju resolved --retry on the unit to recaputre that hook
[03:38] <marcoceppi> thumper: no, you should avoid using --force
[03:38] <marcoceppi> thumper: the way to fix this is to break the relation, upgrade-charm, attach the new relation
[03:38] <marcoceppi> whoa, I'm really lagged
[03:39] <stub> thumper: just doing a 'juju set' on it after the upgrade-charm --force will kick off a hook, and one hook is all that is needed with the rewrite charm. Not sure about cs:28.
[03:39] <thumper> marcoceppi: the relation is a peer relation
[03:39] <marcoceppi> thumper: oh bother
[03:40] <stub> marcoceppi: a single unit with a peer relation to boot ;)
[03:40] <marcoceppi> thumper: well then you're fun
[03:40]  * thumper taps...
[03:40] <marcoceppi> thumper: well --force upgrade will get you the new payload
[03:40] <marcoceppi> thumper: not sure if it'll queue the upgrade-charm hook or not tbh
[03:41] <thumper> stub: why is your new rewrite not promulgated (or however you spell that damn word)
[03:41] <marcoceppi> i just know it'll drop the new charm payload
[03:41]  * thumper goes to look at the code...
[03:42] <marcoceppi> syn
[03:42] <stub> thumper: its in the review queue. It got looked at about a month ago, when it was pointed out some tests were failing on the ci system. I got that down to one failing test, which is still better than the existing charm with its tests disabled.
[03:43] <thumper> so... disable the failing test like a real developer :-)
[03:43] <thumper> heh
[03:45] <stub> I've been poking at it to get it fixed, but the ci system gets rather constipated recently and there is still a good chance of failures due to cloud timeouts and such.
[03:47] <stub> Ohh... someone gave it an enema. I got a fresh run coming up in an hour or three.
[03:48] <stub> lxc green already, just need to wait for the real clouds
[03:48] <stub> thumper: where is my lxd provider?
[03:48] <thumper> stub: coming
[03:49] <stub> thumper: will an environment be able to span multiple lxd servers?
[03:49] <thumper> not initially
[03:50] <stub> thumper: will that be a juju task, or an lxd task do you know?
[03:51] <stub> My evil plan needs juju talking to multiple lxds, or a virtual lxd server that abstracts a collection of lxds.
[03:52] <stub> (maybe the latter is better, providing a ha end point to a cluster of lxds and automatic failover of containers etc.)
[03:53] <thumper> the aim is to be able to have the lxd provider be able to point to a remote lxd endpoint
[03:53] <thumper> as well as the default of "localhost"
[03:56] <stub> I guess the manual provider is quite happy deploying a unit to an lxd container somewhere, so it wouldn't be a blocker to anyone. Just trickier to wire up.
[03:58] <stub> marcoceppi: would stopping people making incompatible metadata.yaml changes be a job for charm proof or the charm store? It would need to be able to discover the previous revision of the charm.
[03:58] <marcoceppi> stub: so, juju does this already with relations
[03:58] <marcoceppi> it just makes you remove relation
[03:59] <marcoceppi> but I don't think anyone considered the peer corner case
[03:59] <stub> oh, so this is just an edge case with the peer relation
[03:59] <stub> right
[03:59] <marcoceppi> juju should just allow you to upgrade regardless of the peer interface change
[03:59] <marcoceppi> a bug would be in order
[04:00] <stub> Maybe for juju 2.0 peer relations are considered more special. Currently I think you can have multiple peer relations with all sorts of names and interfaces defined, which isn't really useful afaict.
[04:13] <stub> thumper: are you filing a bug?
[04:14] <thumper> sorry, wasn't following, on a call
[04:14] <thumper> I can file a bug
[04:47] <thumper> stub: bug 1510787
[04:47] <mup> Bug #1510787: juju upgrade-charm errors when it shouldn't <juju-core:Triaged> <https://launchpad.net/bugs/1510787>
[09:55] <stub> So I now need to have two branches for my charm, one containing my work and layers.yaml and another one containing the built charm?
[09:57] <stub> My first attempt was 'charm build -o .' to keep everything together in an easy to develop with place, but that just builds to ./trusty/charmname
[10:00] <stub> If two branches, do we have a official location for the 'source' branch, which is the target branch for reviews, with the current trunk remaining for the generated output to be ingested into the charmstore?
[11:51] <Icey> stub what I've been working on is having them be 2 separate repos, one with the layers.yaml and such, one that is the deployable charm
[11:54] <stub> Icey: Yeah, that seems to be the way it needs to work. And I see I can specify a LAYER_PATH environment variable, so I can split out things into multiple layers when developing.
[11:54] <stub> The review process is going to be more interesting
[11:55] <Icey> yeah, almost like the layers repo isn't going to be reviewed, just the final output?
[11:59] <stub> One of the reasons composer exists is to avoid all the boilerplate that ends up in reviews from things like charmhelpers. I think the layers will need to be reviewed, not the final output.
[11:59] <Icey> hopefully :)
[11:59] <Icey> ideally we get to the point where each layer is independently reviewed, and we can just review the stuff that the charm author is writing
[12:00] <stub> tarmac or something should be able to to the build, commit and push automatically for the CI system to ingest.
[12:24] <gennadiy> hi i still have question about expose services in bundle. i use expose: true in my bundle but after deploring services are not exported
[13:03] <cory_fu> gennadiy: And the services in question have open ports listed in `juju status`?  The `expose: true` should work, if that's the case.  :/
[13:04] <cory_fu> Are you deploying the bundle with `juju quickstart` or `juju deployer`?
[13:05] <gennadiy> i deployed bundle from juju-gui
[13:06] <cory_fu> Oh yes, that, too.  And the services have open ports listed?
[13:06] <gennadiy> but i think i have found problem i use bundles.yaml but in juju store i see bundle.yaml which doesn't contain expose
[13:06] <gennadiy> my bundle name is - tads2015-demo
[13:07] <rick_h__> urulama_: ^ does the expose stuff not get translated perhaps?
[13:08] <urulama_> rick_h__, gennadiy: it might be a bug, yes. we'll investigate.
[13:08] <gennadiy> constraints field is absent too
[13:09] <gennadiy> sorry. constraints presents in result bundle
[13:10] <gennadiy> do i have possibility to create bundle.yaml directly now?
[13:10] <gennadiy> as i understood my original bundles.yaml was converted to bundle.yaml. am i right?
[13:11] <urulama_> gennadiy: yes, you can. use the same format as you see the results.
[13:11] <rick_h__> gennadiy: yes, though be careful. The old system looks for a bundles.yaml so you need both to ingest properly
[13:11] <gennadiy> can i add expose field?
[13:12] <gennadiy> * can i use expose field in bundle.yaml?
[13:12] <rick_h__> gennadiy: yes definitely
[13:12] <urulama_> gennadiy: you should.
[13:12] <gennadiy> ok. i will try
[13:12] <rick_h__> gennadiy: download the bundle and leave both files when you update it.
[13:44] <gennadiy> can i setup name of bundle in bundle.yaml?
[13:44] <gennadiy> because when i try to use bundle and config w/o name config is not applied
[13:45] <gennadiy> i use the following script
[13:45] <gennadiy> juju-deployer -e $JUJU_CUR_ENV -c tads2015-demo/bundle.yaml -c config-demo.yaml tads2015-demo/bundle.yaml
[13:49] <urulama_> gennadiy: unfortunately, we currently don't handle expose.
[13:49] <urulama_> (in new bundle format)
[13:49] <gennadiy> now i use bundle instead of bundles and expose works
[13:52] <gennadiy> but now i have question about juju-deployer it has ability to merge yaml files.
[13:53] <gennadiy> so if i don't use bundle name for inside bundle file it doens't work correctly
[13:53] <frankban> gennadiy: in new bundle format there is no top level namespace with the bundle name
[13:53] <gennadiy> i see, but how to use juju-deployer now?
[13:54] <gennadiy> seem it doesn't work correctly w/o bundle name
[13:54] <frankban> gennadiy: how to use a config yaml file?
[13:54] <gennadiy> am i right?
[13:54] <frankban> gennadiy: don't know, checking sources, could be a juju-deployer bug
[13:58] <frankban> gennadiy: what's the problem with new bundle format? overriding values with multiple yaml files? if so, have you tried passing yaml overrides not including the top level bundle name?
[14:13] <rick_h__> gennadiy: what version of the deployer. You need a fairly recent one to support the newer format where the bundle name is not at the root of the file.
[14:57] <Icey> is there a way to specify machine arguments when deploying?
[14:58] <Icey> in essence, I want to use `juju deploy ceph` but specify a machine add constraint to restrict the service to us-east-1a
[14:58] <Icey> or am I just going to have to use a bundle to get that kind of effect?
[15:30] <vila> mgz_: ping
[15:37] <Icey> is 1.25 out yet :'(
[15:45] <mgz_> vila: hey
[15:46] <vila> mgz_: hey ! See PM ?
[15:51] <lazypower> Icey its in -proposed
[15:51] <lazypower> Icey add-apt-repository ppa:juju/proposed
[15:52] <lazypower> install juju-core and profit from having 1.25
[15:52] <lazypower> you get payload management, update-status hooks, and a whole slew of other nice things
[15:52] <lazypower> but its /proposed, ymmv :)
[16:18] <mgz_> vila: with 1.24.7 you may benefit from bug 1435283 fix
[16:18] <mup> Bug #1435283: juju occasionally switches a units public-address if an additional interface is added post-deployment <addressability> <bug-squad> <network> <openstack-provider>
[16:18] <mup> <juju-core:Fix Released by mfoord> <juju-core 1.24:Fix Released by mfoord> <juju-core 1.25:Fix Released by mfoord> <https://launchpad.net/bugs/1435283>
[16:18] <vila> ack
[16:48] <Icey> lazypower I'm riding proposed now ;-)
[16:51] <aisrael_> lazypower: Layers question for you. I renamed my composer.yaml to layers.yaml by mistake, and charm build complained so I renamed it to layer.yaml. I'm getting this error trying to build now, though: http://pastebin.ubuntu.com/12991002/
[16:51] <aisrael_> lazypower: I suspect something's cached, but not sure where. deps/ looks like it just has the interface I pulled in.
[16:51] <lazypower> ouch
[16:51] <lazypower> that stack trace not really clear with what it duped on
[16:51] <lazypower> but i think i know whatshappening here
[16:52] <aisrael_> lazypower: I can dig deeper if needed.
[16:52] <lazypower> if you ls $JUJU_REPOSITORY/trusty/mything
[16:52] <lazypower> does mything have a compose.yaml?
[16:52] <lazypower> if so, charm build is notifying you that files exist out of band, and you should only continue building if its OK to have this file present. (Eg: local modifications to the charm not the layer)
[16:52] <aisrael_> oh, it has a layers.yaml
[16:52] <lazypower> --force will allow you to override that and get past it, but its erring on the side of caution for you
[16:53] <lazypower> i'm referring to the constructed charm
[16:53] <lazypower> the artifact
[16:53] <aisrael_> lazypower: removing that fixed it. Should I open a bug?
[16:53]  * lazypower is doing a terrible job of explaining htis
[16:53] <lazypower> nah its intended behavior
[16:53] <lazypower> if you run with -l DEBUG
[16:53] <lazypower> it tells you what its matching on i think
[16:54] <aisrael_> lazypower: Right, the previous build left the layers.yaml in $JUJU_REPOSITORY/trusty/mycharm. Bad artifact.
[16:55] <lazypower> :)
[16:55] <aisrael_> lazypower: so a build copies over the charm, rather than replacing or rsyncing, right?
[16:55] <lazypower> the one thing build doesn't do, is take care of removal
[16:55] <lazypower> say you remove an interface from layer.yaml, then re-run build - you need to implicitly rm -rf the built charm and then build, otherwise that interface will linger
[16:56] <lazypower> aisrael_ correct, there are different strategies at play
[16:56] <aisrael_> lazypower: ack. I can see an argument for doing that cleanup automatically, even if it's an extra flag
[16:56] <lazypower> like config.yaml, metadata.yaml get merged
[16:56] <lazypower> other files have a default policy of highest layer that has this file wins.
[16:56] <aisrael_> i.e, if I'm writing a charm in layers/, I'd expect that to be authoritative
[16:57] <lazypower> so whatever your top layer is, will override files below it, save for a handfull of special files. and your local layer takes precedence over the interfaces.juju.solutions api yes but only if you have LAYER_PATH set
[16:57] <lazypower> same with INTERFACE_PATH
[16:57] <aisrael_> like the charm equivalent to make clean
[16:57] <lazypower> yeah
[16:58] <aisrael_> Caffeinated ramblings. Thanks for the help unblocking me!
[16:58] <lazypower> seems like charm build --clean should just nuke the compiled dir if exists then build.
[16:58] <lazypower> NP thanks for the questions :)
[17:03] <Icey> how hard would it be to change the AMIs used by Juju to be something that's EBS optimized?
[17:22] <aisrael_> lazypower: I am now a layer convert (not that I wasn't a fan before).
[17:22] <lazypower> :)
[17:22] <aisrael_> well, layer + reactive
[17:22] <lazypower> Layer + reactive is a powerful tool
[17:23] <lazypower> aisrael_ : https://github.com/mbruzek/layer-k8s/pull/5
[17:23] <aisrael_> Niiiiice
[17:23] <lazypower> working on a feature branch with matt for the last 2 days, working independently there have been zero merge conflicts - putting complexity in its place :)
[17:23] <lazypower> and the change sets are getting smaller
[17:53] <aisrael_> lazypower: lxc now builds for os x, so if we can run lxd in a container... we might be closer to having a working local provider.
[17:55] <lazypower> nice!
[17:56] <aisrael_> I'll poke around at it tonight when I'm back home.
[18:13] <marcoceppi> lazypower: +1 to a --clean flag where it removes the previous build
[18:13] <marcoceppi> helpful when heavily devving
[18:13] <lazypower> I'll feature rq it
[18:15] <lazypower> https://github.com/juju/charm-tools/issues/33
[20:41] <cholcombe> can you combine all your juju actions code into one file and symlink it just like the hooks?
[20:48] <marcoceppi> cholcombe: yes
[20:48] <cholcombe> marcoceppi, nice :)
[20:48] <cholcombe> so i do the usual @hooks.hook business
[20:49] <marcoceppi> cholcombe: welllll
[20:49] <marcoceppi> cholcombe: no one has tried that, they're not hooks, they're actions, so it's hard to say if that code will respect that
[20:50] <marcoceppi> cholcombe: for now it's probably better to just make a python module and then stub the import/execute of that module/methods in each file
[20:50] <cholcombe> marcoceppi, if i remember right at the code i looked at it just calls the hook with the matching filename that it was called with
[20:50] <marcoceppi> cholcombe: sure, but actions are not in the hooks directory
[20:50] <cholcombe> oh i know
[20:50] <marcoceppi> so if there's any attempt to parse out hook related file paths
[20:50] <marcoceppi> it'll fail
[20:51] <cholcombe> hmm yeah
[20:51]  * cholcombe goes back to splitting them up