[03:57] <thumper> https://github.com/juju/juju/pull/11893 adds ability to introspect the leases on the controllers
[03:57] <thumper> wallyworld: ^^
[03:57] <thumper> or anyone really
[05:31] <wallyworld> thumper: sorry, ffs, missed ping, done
[05:57] <jam> morning all
[05:57] <hpidcock> @jam morning
[05:58] <jam> I like how mattermost characters leak into IRC :)
[06:19] <hpidcock> jam: haha yeah. I have blended everything into one client.
[06:20] <jam> I'm guilty of it as well. I start typing names in mattermost and wonder why they aren't completing
[09:39] <manadart_> stickupkid: This is the fix for AWS constraints/bindings: https://github.com/juju/juju/pull/11886
[09:40] <stickupkid> manadart_, nice, will jump on that soon
[10:19] <achilleasa> manadart_: stickupkid quick poll. I am moving the IngressRule type to core/network and tweaking the code (e.g. use set.Strings for src CIDRS). When you get (or print) the src CIDRs do you think that I should list the _effective_ source CIDRs or the actual CIDRs?
[10:20] <stickupkid> actual
[10:20] <manadart_> achilleasa: Actual.
[10:20] <achilleasa> in other words: if I have 192.168.0.0/24 and then add 192.168.0.0/16 does this yield the latter (as it is a superset)
[10:20] <achilleasa> or both?
[10:21] <stickupkid> achilleasa, for print, get, it should return actual
[10:21] <stickupkid> achilleasa, also you could make a new type that allow you to get both
[10:22] <stickupkid> achilleasa, also I wonder if we should specialise the CIDR, so the type isn't a string in core/network?
[10:22] <achilleasa> cool. I am too lazy to implement it for printing only. There is some code that merges CIDRs to reduce the number of ingress rules so I might add this functionality via a method once I get there
[10:23] <stickupkid> achilleasa, manadart_ I worry about the overuse of strings and set.Strings
[10:23] <achilleasa> Ideally that should be a *net.IPNet but ... mongo
[10:24] <achilleasa> subnets, spaces... all those bits work with string CIDRs
[10:24] <stickupkid> achilleasa, fair, although `type CIDR *net.IPNet` and hang everything off CIDR
[10:25] <stickupkid> achilleasa, you can then implement SetBSON (*sick* inside!)
[10:25] <achilleasa> yeah... but then you have to parse CIDRs early on (could be problematic for tests)
[10:26] <stickupkid> achilleasa, sure, sure, agree with you
[10:26] <achilleasa> ha! can't override SetBSON for type aliases I think
[10:26] <achilleasa> (or other methods)
[10:26] <stickupkid> not sure, maybe
[10:26] <achilleasa> or is that only for existing methods?
[10:26] <stickupkid> existing ones I'm sure of it
[10:27] <achilleasa> yeah... not sure if the restriction extends to other methods
[10:27] <achilleasa> I will check later :D
[10:32] <stickupkid> manadart_, tick
[10:32] <manadart_> stickupkid: Cheers.
[10:46] <manadart_> stickupkid: Quick HO?
[10:46] <stickupkid> sure
[10:59] <b1juj> Hi, I'm having problems setting up gnocchi and ceilometer with juju. Gnocchi has been in waiting state for >12hrs with messages "'shared-db' incomplete" and "'db-router' incomplete, Waiting for proxied DB creation from cluster". Ceilometer is in blocked state with message "Incomplete relations: database, Run the ceilometer-upgrade action on the leader to initialize ceilometer and gnocchi". I have tried running the
[10:59] <b1juj> ceilometer-upgrade action but it fails with message "The identity-credentials and or metric-service relations are not complete.
[10:59] <b1juj>   ceilometer-upgrade cannot be run until they are ready."
[11:03] <stickupkid> achilleasa, HO?
[11:03] <achilleasa> stickupkid: omw
[13:41] <achilleasa> manadart_: https://github.com/juju/juju/pull/11896
[15:30] <stickupkid> hml, also you left this as a comment and not approved :) https://github.com/juju/juju/pull/11888
[15:30] <hml> stickupkid: i did… need to qa
[15:31] <hml> i’ll merge if qa is good
[15:37] <stickupkid> hml, ta
[15:52] <hml> achilleasa:  the hook context read the charm state data, no the unit state data.  is that the context you were refering too?
[15:54] <achilleasa> hml: the uniter has its own state plus a state for each relation (there is a thing in the relation package that reads that from disk). I thought the latter was read at context creation time but I could very possibly be wrong and it could get cached at start time
[15:54] <hml> achilleasa:  I couldn’t find it
[15:54] <achilleasa> it was that weird map struct
[15:54] <achilleasa> one sec
[15:55] <achilleasa> hml: https://github.com/juju/juju/blob/2.7/worker/uniter/relation/relationer.go#L92
[15:55] <achilleasa> it's the one from 2.7 which gets replaced in 2.8 with the stuff we added
[15:56] <achilleasa> I think L96 reads from disk
[15:56] <achilleasa> also the CommitHook method just after that writes to disk
[15:56] <hml> achilleasa:  i was thinking context, as in running hook contexts
[15:57] <hml> yes, data is read at preparehook
[15:57] <achilleasa> hml: ah... I meant the hook contest (runner/context/context.go)
[15:57] <achilleasa> so if we upgrade (+migrate), then a hook fires before the agent restarts... boom?
[16:01] <hml> achilleasa:  okay, so same context then.  i guess i was thinking literally, not in prehook
[16:01] <hml> achilleasa:  that could be it
[16:01] <hml> achilleasa:  moving the upgrade step to the unit will take care of that
[16:16] <hml> achilleasa:  PrepareHook  calls State() which makes a copy of what’s there already then Validate() is called.  Data is read when NewRelations is called.  And when NextHook is called, part of update().  so just different location.