| pmatulis | apparently when a LXD-backed controller is created there are some LXD profiles that come with it. one is supposedly called 'juju-default'. where can i see these? | 00:17 |
|---|---|---|
| wallyworld | pmatulis: off hand i can't remember but heather wil know for sure | 01:34 |
| wallyworld | tlm: got 5? | 01:34 |
| Chipaca | is 2.7.1 the right cutoff for deciding whether relation-get/relation-set know about --app ? | 02:20 |
| Chipaca | https://discourse.juju.is/t/juju-2-7-1-release-notes/2495 seems to imply that but i'm not positive; 2.7.2 already talks about fixing bugs in relation-get --app :) | 02:20 |
| Chipaca | and i have reports of it not working on 2.7.0 | 02:21 |
| * Chipaca realises there aren't many options left in there :) | 02:21 | |
| tlm | wallyworld: back now | 02:29 |
| wallyworld | tlm: dog ok? | 02:30 |
| tlm | for the moment :) | 02:30 |
| tlm | HO wallyworld ? | 02:30 |
| wallyworld | Chipaca: not sure off hand - but have you considered upgrading to 2.7.6 where any such issues will be mot? | 02:31 |
| wallyworld | tlm: i answered by own question, so no need for HO | 02:31 |
| tlm | ah cool | 02:31 |
| wallyworld | *moot | 02:31 |
| Chipaca | wallyworld: i'm running 2.8 here :) but some heathens dare run older versions and still wnat to run charms | 02:31 |
| wallyworld | they ned to upgrade cause really, anything < 2.7.6 is not so much supported | 02:32 |
| wallyworld | if there's a bug we'd to them to upgrade | 02:32 |
| wallyworld | relation-set app came in in 2.7 | 02:33 |
| wallyworld | but there were early bugs from emmory | 02:33 |
| wallyworld | so if they use < 2.7.6 they may not be happy | 02:33 |
| Chipaca | they're aware it's an issue, but they can't upgrade everywhere at this time | 02:34 |
| Chipaca | wallyworld: but, good to know relation-get and relation-set got it at different times | 02:35 |
| Chipaca | er, or maybe i misunderstood you | 02:35 |
| wallyworld | relation-get/set would have been done at the same time | 02:35 |
| Chipaca | ok :) | 02:36 |
| wallyworld | it was part of an overall feature | 02:36 |
| Chipaca | to be clear i don't think they're using the feature, it's just that we always sent --app=<bool> and it trips up on them | 02:36 |
| Chipaca | ok, back to sleep. đź‘‹ | 02:41 |
| tlm | wallyworld: got 5 min for HO ? | 03:02 |
| wallyworld | ok | 03:02 |
| === ulidtko|k is now known as ulidtko | ||
| wallyworld | manadart: there's been a field critical bug, here's a PR i need your input on; not sure about my new link layer device removal code, i think we need to delete them even if a parent device (furture PR will want to compose as a model op as well but for now...). also, i am unclear why we would have excluded containers in the first place, that code seems like it was done way back in 2013 so who knows https://github.com/juju/juju/ | 06:16 |
| wallyworld | pull/11682 | 06:16 |
| manadart | wallyworld: Hmm. That code path is used now by both the instance-poller and the machiner. So I think this will cause flapping if there is a device seen by the machine, but not the provider. | 06:20 |
| manadart | I am actually working on this at present in the context of another bug. | 06:20 |
| wallyworld | ok, no problem, i can abandon the PR if appropriate | 06:20 |
| wallyworld | the quick fix was to remove the container ceck | 06:22 |
| wallyworld | but then we got orphansed entries | 06:22 |
| wallyworld | i think we need to then separate out provider vs machine devices, like we do for addresses? | 06:23 |
| wallyworld | ot at least tag where they came from | 06:23 |
| wallyworld | so we can then delete macine vs provider devices properly | 06:24 |
| wallyworld | and we aggregate in the getter? | 06:24 |
| manadart | wallyworld: Prior patches have introduced the idea of device address origin. This way the provider can effectively relinquish devices to the machiner, and the machiner can safely remove them if not observed. | 06:40 |
| manadart | That's the bit I'm on at present. | 06:40 |
| wallyworld | sounds good, i was sort of hinting at something similar i think. so this new work is in 2.8 right? we need a quick fix for 2.7 | 06:42 |
| manadart | wallyworld: I will see if I can back-port. | 06:55 |
| wallyworld | ok, ty, i should close my PR then | 06:55 |
| wallyworld | did you want to include the small actual fix in yours? ie remove the container check? or i can slim mine down to just d that bit | 06:56 |
| achilleasa | manadart: can you take a look at https://github.com/juju/juju/pull/11670? | 08:36 |
| manadart | achilleasa: I'm working a field-critical bug ATM. | 08:37 |
| achilleasa | manadart: nw, I will look into another bug for now | 08:37 |
| manadart | achilleasa: Actually, can you hop in Daily? | 08:49 |
| stickupkid | manadart, CR when you get a chance https://github.com/juju/juju/pull/11684 | 10:57 |
| jam | manadart or achilleasa did either of you see: https://bugs.launchpad.net/juju/+bug/1882127 | 12:32 |
| mup | Bug #1882127: nil pointer dereference in 'relation-set' <juju:Triaged> <juju 2.7:New> <https://launchpad.net/bugs/1882127> | 12:32 |
| manadart | jam: Yeah, I'll take a look when I've a moment. | 12:33 |
| achilleasa | jam: that's an odd one. It means that either r.Settings or r.ApplicationSettings returned nil without an error (https://github.com/juju/juju/blob/2.7/worker/uniter/runner/jujuc/relation-set.go#L150-L160). Is it confirmed that we saw this in 2.7.6? | 12:35 |
| jam | achilleasa, that is what was reported, I haven't reproduced it | 12:35 |
| achilleasa | asking because we did some work in 2.7.6 to fix some of the issues accessing application data (inc. fixing some err var shadowing issues) | 12:37 |
| achilleasa | I will take a closer look later today | 12:38 |
| jam | achilleasa, thanks | 12:42 |
| achilleasa | jam: also, we do have integration tests that check access to unit/app data in various scenarios: https://github.com/juju/juju/blob/develop/tests/suites/relations/relation_data_exchange.sh | 12:42 |
| stickupkid | achilleasa, I bet you this is a Settings(nil) issue | 12:50 |
| achilleasa | stickupkid: they should be getting an empty map or an error | 12:50 |
| achilleasa | I suspect based on the bug report that this is a nil returned when fetching the ApplicationData | 12:51 |
| stickupkid | achilleasa, yeah, i don't get it yet, doing more looking | 12:51 |
| stickupkid | achilleasa, I'm just putting my flag in the sand | 12:51 |
| achilleasa | if you got a bit of time, can you run the integration tests against 2.7.6? | 12:51 |
| achilleasa | (the one linked above) | 12:52 |
| jam | achilleasa, stickupkid : yeah given the Python code is grabbing the application data, it would be that ApplicationSettings is returning nil, nil | 12:52 |
| stickupkid | achilleasa, sure, let me sort that out | 12:52 |
| stickupkid | achilleasa, do it after daily | 12:53 |
| stickupkid | there are a lot of places that check that certain things exist in a map, but not actually the value of said item in the map is valid | 12:56 |
| jam | stickupkid, achilleasa for more context, it is a k8s charm where this is happening | 13:00 |
| jam | specifically this charm: https://github.com/davigar15/zookeeper/tree/master/src happening in this code: https://github.com/davigar15/zookeeper/blob/master/mod/zookeeper/zookeeper_provides.py | 13:00 |
| stickupkid | petevg, I think we can mark it as wontfix tbh https://bugs.launchpad.net/juju/+bug/1882571 | 14:03 |
| mup | Bug #1882571: juju schema doesn't contain docs <juju:New> <https://launchpad.net/bugs/1882571> | 14:03 |
| petevg | stickupkid: agreed. Thx for the comment on it :-) | 14:03 |
| pmatulis | hml, i've been told you may help me. apparently when a LXD-backed controller is created there are some LXD profiles that come with it. one is supposedly called 'juju-default'. where can i see these? | 14:27 |
| hml | pmatulis: on the machine the lxd containers are running on | 14:28 |
| hml | pmatulis: there is a profile created per model. so by default “juju-defaul” and “juju-controller” | 14:28 |
| stickupkid | pmatulis, lxc profile list and lxc profile show juju-default | 14:31 |
| pmatulis | hml, stickupkid: ok, so juju effectively creates a lxc profile (lxc profile create) along for every model that it creates and will apply that profile for that model? | 15:00 |
| hml | pmatulis: yes. the profile is applied to all machines in that model | 15:00 |
| hml | pmatulis: the default profile is also use | 15:01 |
| hml | for all lxd machine | 15:01 |
| pmatulis | hml, i don't understand. two profiles are used? | 15:03 |
| hml | pmatulis: the default one is what’ever the user put into the profile. and contains network interfaces by default | 15:03 |
| hml | pmatulis: the juju one is what juju requires | 15:03 |
| hml | pmatulis: yes, 2 profiles minimum | 15:04 |
| pmatulis | hml, wow ok thanks | 15:05 |
| stickupkid | pmatulis, think of them as a stack or profiles to apply. You concat them together to give you the container you want/need | 15:06 |
| pmatulis | stickupkid, so that default profile should normally never be deleted | 15:08 |
| stickupkid | pmatulis, indeed because we use that to find the bridge name | 15:09 |
| pmatulis | would an error occur if a container was created w/o the 'default' profile? i mean, even for pure lxd (not juju) | 15:09 |
| stickupkid | pmatulis, not sure tbh, would need to test that scenario | 15:11 |
| pmatulis | stickupkid, cheers thanks | 15:12 |
| hml | stickupkid: doesn’t juju verify the network info is in the default profile? i can’t remember if it rewrites the default profile if its not | 15:15 |
| stickupkid | hml, it never re-writes the default profile, it just queries it | 15:16 |
| hml | stickupkid: so what happens if there isn’t a nic defined then? | 15:16 |
| stickupkid | hml, there is logic around this, will check | 15:17 |
| stickupkid | hml, pmatulis we expect default profile in a lot of places | 15:18 |
| stickupkid | hml, oh wow, we do update the default, I was wrong sorry | 15:20 |
| stickupkid | https://github.com/juju/juju/blob/develop/container/lxd/network.go#L183 | 15:20 |
| hml | stickupkid: i thought so… remember being in that code a long time ago | 15:21 |
| stickupkid | hml, forgot about that, been a long time | 15:21 |
| pmatulis | stickupkid, ok thanks for that follow up | 15:25 |
| pmatulis | stickupkid, and if a charm itself included a profile the associated container would use a stack of three profiles? | 15:41 |
| stickupkid | pmatulis, correct | 15:47 |
| pmatulis | got it thx | 15:49 |
| stickupkid | achilleasa, I can't reproduce the bug | 15:53 |
| stickupkid | achilleasa, well with the integration tests | 15:54 |
| achilleasa | even on 2.7.5? | 15:54 |
| stickupkid | achilleasa, 2.7.5 returns | | | 16:07 |
| stickupkid | | ERROR invalid value "db:2" for option -r: relation not found | 16:07 |
| stickupkid | | ERROR permission denied | 16:07 |
| stickupkid | | ERROR permission denied | 16:07 |
| achilleasa | stickupkid: yeah... that was one of the things that got fixed in 2.7.6 | 16:15 |
| stickupkid | achilleasa, ho? | 16:23 |
| achilleasa | stickupkid: omw | 16:23 |
| kelvinliu | wallyworld: ho for azure stuff? | 23:28 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!