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 | 03:57 |
wallyworld | thumper: sorry, ffs, missed ping, done | 05:31 |
jam | morning all | 05:57 |
hpidcock | @jam morning | 05:57 |
jam | I like how mattermost characters leak into IRC :) | 05:58 |
hpidcock | jam: haha yeah. I have blended everything into one client. | 06:19 |
jam | I'm guilty of it as well. I start typing names in mattermost and wonder why they aren't completing | 06:20 |
manadart_ | stickupkid: This is the fix for AWS constraints/bindings: https://github.com/juju/juju/pull/11886 | 09:39 |
stickupkid | manadart_, nice, will jump on that soon | 09:40 |
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:19 |
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:20 |
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:21 |
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:22 |
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:23 |
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:24 |
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:25 |
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:26 |
achilleasa | yeah... not sure if the restriction extends to other methods | 10:27 |
achilleasa | I will check later :D | 10:27 |
stickupkid | manadart_, tick | 10:32 |
manadart_ | stickupkid: Cheers. | 10:32 |
manadart_ | stickupkid: Quick HO? | 10:46 |
stickupkid | sure | 10:46 |
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." | 10:59 |
stickupkid | achilleasa, HO? | 11:03 |
achilleasa | stickupkid: omw | 11:03 |
achilleasa | manadart_: https://github.com/juju/juju/pull/11896 | 13:41 |
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:30 |
hml | i’ll merge if qa is good | 15:31 |
stickupkid | hml, ta | 15:37 |
hml | achilleasa: the hook context read the charm state data, no the unit state data. is that the context you were refering too? | 15:52 |
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:54 |
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:55 |
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:56 |
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? | 15:57 |
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:01 |
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. | 16:16 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!