[00:02] wpk: Uh, I don't think you'll be needing your data after a gamma ray burst. https://www.youtube.com/watch?v=RLykC1VN7NY [00:58] anastasiamac, babbageclunk are there any other clouds that need special treatment on 'add-cloud', specifically details stored on the controller? [00:59] veebers: when u say 'other clouds', which ones u've catered for?.. [00:59] currently add-k8s updates the controller with details, and is listed in 'juju clouds', but if you bootstrap another controller that controller does not have those details (yet 'juju clouds' lists the add-k8s added cloud) [01:00] anastasiamac: I'm looking at the add-k8s command and it seems to do some 'special' things [01:00] veebers: it is the only special one that i know of... :) [01:00] veebers: not that I know of. [01:00] ack, I had assumed so :-) [01:47] anastasiamac, babbageclunk: A controller should be able to have different models in different clouds right? Or are there restrictions? I've bootstrapped in lxd and add-cloud a new lxd cloud (just with a different name) but add-model chokes on it, it's not a clouds supported by that controller [01:48] ah, it doesn't like any other cloud other than the localhost (and k8s if added) [01:48] veebers: no, generally a controller is one cloud only (although I guess caas relaxes that slightly). [01:49] babbageclunk: ack ok that makes sense. [01:49] babbageclunk: so, add-k8s adds details to the (currently selected) controller which means that if you bootstrap a different controller you'll need to add-k8s again, but that would fail as it's locally stored too. That seems odd, right? [01:50] I was wondering if perhaps the controller needs some sort of JIT cloud up details update (like when you add a model for that cloud) or perhaps this is expected behaviour that needs fleshed out a bit [02:00] veebers: yeah, that seems odd. [02:01] (sorry for slow response.) [02:01] I'm not sure about the last point [02:02] babbageclunk: no worries I know you're busy :-) I'll update the bug and email to try get clarity on it [02:04] veebers: i think that will fail because at the moment u can only locally add a controller once.. in this case, it's still the same controller [02:05] anastasiamac: I don't understand that, adding a controller? [02:05] veebers: the fix is no simple... bthe same happens with controller registration, for e.g. u cannot run 'juju register' on the same client more than once [02:07] veebers: to rephrase (without typos...): at this stage, any given client can only b 'aware' of any given controller once [02:13] anastasiamac: I think that's a slightly different issue to what I'm looking at. add-k8s updates the controller with cloud details (stored in the db), but it only does that with the active controller, any others (and any newly boostrapped ones) will not contain that detail. [02:14] anastasiamac: which means that if you "bootstrap test1, add-k8s blah, bootstrap test2, add-model -c test2 blah" it'll fail because test2 controller doesn't have the k8s details, except "juju clouds" will list it among available clouds [02:14] *but* maybe that's somewhat expected? that a k8s cloud is added to a controller and not a juju config? (if that is the case it needs more work to clarify and harden that) [02:16] veebers: oh yes, of course :) my understanding is that 'add-k8s' is equivalent to enabling a controller to be k8-compatible... u need to be explicit... so only controllers that u have explicitly 'switched on to b k8 compatible' will have the ability [02:16] veebers: bu tbh, dunno if in ur scenario u can assume that test2 has the ability... [02:17] maybe if u boootstrap both first, then add-k8s they may both be k8-compatible... but that makes no sense either... [02:17] anastasiamac: ack, that's not completely outrageous, but there is some cleanup work needed around that area [02:18] veebers: i think if we could specify what controller we r making k8 compatible explictly, that might clear up the mud ;D [02:18] anastasiamac: it almost feels like it should be a 2 stage process, add the k8s-cloud and enable a controller [02:18] veebers: yes ^^ [02:18] veebers: altho, does it make sense to enable 2 controllers to use the same k8s? dunno... [02:18] anastasiamac: but even then you couldn't have 2 controllers looking at the same k8s cluster. Perhaps that's expected though [02:19] anastasiamac: hah, jinx, asking the same question at the same time [02:19] veebers: :) there must b a delay btw our thinking but we r on the same page, which is a + [02:19] :D [02:19] :D :D [02:19] ^_^ [02:28] anastasiamac: huh, I lied (well, only just now tried). add-k8s won't fail if you run it for a different controller (new controller is updated) [02:29] veebers: \o/ someone must have travelled the same road we r :D [03:53] anastasiamac: so I have a single character change I might put up for PR, or should I wait and put it in a different (unrelated) PR to make it "worthwhile"? [03:53] I think a single char PR woudl be fine [03:53] better than fine! [03:54] "It's better than bad, it's good!" [03:54] All kids love log! [03:55] veebers: :) we do prefer isolated changes :D but single char PRs are kind of like a treat :0 [04:05] kelvinliu_: I think your PR looks great - I don't have any more to add over what anastasiamac said. Having a warning so we don't just silently ignore what the user's tried to set is good too. [04:06] gah, I think I'm going crazy here - does anyone have a moment to talk something through? [04:06] babbageclunk: i do [04:07] anastasiamac: awesome - in standup? [04:07] k [04:13] Can I get a +1 please? https://github.com/juju/juju/pull/8676 [04:19] thx babbageclunk . [04:23] anastasiamac: thanks you're a genius! [04:23] anastasiamac, babbageclunk updated the PR, appreciate if you could take a look. thx https://github.com/juju/juju/pull/8675 [04:23] veebers: looking, then I'll look at yours kelvinliu_ [04:24] veebers: i've commented too... are you sure?... [04:25] anastasiamac: ah shit, I changed the wrong command 0_0 [04:25] veebers: \o/ [04:26] hahaha, how can one of the simplest PRs be wrong [04:26] :) [04:27] anastasiamac: thanks for the catch, I've push -forced so no one will ever know it took 2 commits to get that right >_> [04:27] while testing my PR, I found bug on caas, https://bugs.launchpad.net/juju/+bug/1769806 [04:27] Bug #1769806: infinitely scale up k8s managed units after upgraded controller [04:29] kelvinliu_: in that bug the first command is "kubectl get all -n testcaas" and the 2nd "kubectl get all -n testcaas1" is that extra '1' on purpose? [04:30] veebers: nws, checking now :) [04:30] anastasiamac: ah great, your comment on the PR is visible for all to see now, I can't get away with it :-) [04:31] veebers: ah babbageclunk beat me to it :) [04:31] veebers: but the important thing is the content, surely :D [04:32] veebers: FWIW, it was not an easy to pick up, thank you for seeing it with ur eagle eye (and fixing it!!) [04:32] anastasiamac: surely pride first, then correctness ;-) [04:34] veebers, good finding! updating [04:37] kelvinliu_: approved, a couple of minor wording tweaks. [04:37] haha, veebers, that might explain how proud ppl can be wrong :) [04:37] (not that it applies to this case, of course!!) :-) [04:37] ^_^ [04:41] babbageclunk much better msg. updated, thx [05:01] babbageclunk: PTAL when u get a chance - https://github.com/juju/juju/pull/8677 [05:02] (the actual interesting bits with call back) [05:02] anastasiamac: ok, looking [05:03] \o/ [05:13] kelvinliu_: you may be intersted in my comments on bugs https://bugs.launchpad.net/juju/+bug/1768847 and https://bugs.launchpad.net/juju/+bug/1768845 [05:13] Bug #1768847: add-k8s requires a model [05:13] Bug #1768845: add-k8s incorrectly reports "cloud already exists"

[05:35] jam: I have a holiday here today, but I opened https://github.com/juju/juju/pull/8678 for 2.3. [05:35] Will likely drop by for today's stand-up too. [05:39] hi manadart, enjoy your day off [05:39] thanks [05:39] morning all [05:41] morning jam, welcome back! [05:41] hi babbageclunk [05:41] thanks [05:41] babbageclunk: how's it going in Juju land? [05:42] jam: goooood? I'm still bashing my head on raft clustering. [05:43] babbageclunk: would it help to talk through it? I've done at least some of it for Mongo, so I might have enough context to help [05:44] jam: yeah, that would be really great, but I can't tonight - need to rush off soon. Can we do tomorrow? [05:46] jam: yay, I just saw my cluster recovery thing actually work! [05:46] babbageclunk: nice ! Give me a ping tomorrow. I'm happy to chat if I have time. I'm not sure if ian and tim are back around for meeting at 4UTC, and then I have to take my dog to the vet at 6UTC, but if we can find a time, I'm happy to chat. [05:47] jam: ok, awesome, thanks! [05:48] babbageclunk: if you have code you want me to look at, you could push it up as WIP, or something. [05:48] jam: yeah, I'm going to push it up now - I'll send you a link. [05:49] needs some tidying to remove the huge amount of debug logging I just added. [06:44] jam: ran out of time, I'll create a WIP PR when I get back later this evening [09:03] multi monitor support in 18.04 is absolutely abysmal :) [10:43] hey jam, here's the WIP PR: https://github.com/juju/juju/pull/8680 [10:44] * babbageclunk goes to sleep [13:49] externalreality_: for bug #1761706 I know we landed your patch for develop, did you also backport it to 2.3 ? [13:49] Bug #1761706: Bootstrap on Openstack fails if there is an IPv6 subnet [13:50] and/or *can* you backport it? [13:51] jam, checking [13:53] jam, looks like it was already backported: https://github.com/juju/juju/pull/8630 [13:55] externalreality_: thanks, we just didn't update the bug [13:55] jam, my fault. I just saw that, and updated to fix-committed. [13:56] thanks === freyes__ is now known as freyes [14:26] i see 2.3.8 is candidate in the snap store, when would that go to stable? [14:28] admcleod_: not sure. We just put out .7 and the .8 will be tracking the 2.3 trunk as it moves forward [14:28] admcleod_: something in there you're waiting on? [14:29] yep bug.. [14:29] 176317 and ... [14:29] 1765571 [14:29] that doesnt look right does it [14:30] no, not quite [14:30] 1764317 and 1765571 [14:30] admcleod_: ah, there's one more bionic bug that needs to land for that. I'm not sure what timeline it'll be. [14:30] admcleod_: once that's done we can make sure to work to time a release witht he bionic fixes in place [14:48] rick_h_: yeah - would be great to start that before next tuesday [14:48] admcleod_: k, ty for the feedback there. What's next Tues? [14:51] rick_h_: openstack charm freeze [14:51] admcleod_: ah ok [14:52] rick_h_: how would i know if those backports on the bugs, to 2.3.8, are in the snap candidate? any way for me to find out? [14:53] admcleod_: looking [14:53] thanks! [14:54] admcleod_: so the snap info shows the git sha on the end there and that matches up to the latest commit in the 2.3 tree here: https://github.com/juju/juju/commits/2.3 [14:54] ah! [14:54] admcleod_: I see the lxd init one there, looking for the second one [14:55] admcleod_: looks like those two bugs are the last two commits just landed in the last 6hrs so they're fresh [14:56] admcleod_: you're just bleeeeeeding edge heh [14:56] awesome [14:56] thanks rick [14:56] np [15:35] Hi all, I once again (sorry for that) ask for some help when writing a charm and an interface layer. It seems I still fail to grasp everything. I start prototyping the main aspects on this page: https://github.com/Ciberth/Logboek-Thesis/blob/master/prototyping.md Could someone take a quick look to see if this is the right way and if my reasoning is correct? Once i get home I'll try building everything and putting repo's online, [15:59] TheAbsentOne: you are getting warmer for sure [16:00] TheAbsentOne: have you followed the charm authors docs and built the vanilla charm? [16:01] yeah more or less on a smaller project bdx gotta run now though Im back in an hour [16:01] TheAbsentOne: https://jujucharms.com/docs/stable/developer-getting-started [16:02] should solve all your problems if you understand whats going on ^ [16:02] bdx: I'm just having troubles with writing the interface layer properly I think, [16:02] totally [16:02] can you go through ^ example a few times please? [16:02] I think it may serve you well [16:03] TheAbsentOne: this too https://jujucharms.com/docs/stable/developer-layer-example [16:03] Sure I'll reread it first, then create the repo's and go from there. I'll get back to you, [16:03] though I think I know these docs by heart by now xD [16:04] TheAbsentOne: you shouldnt need to create any interfaces [16:04] they already exist [16:04] see how its done in the vanilla charm example^ [16:06] oh but I do sir, I really need the ability to have a generic-database inside a requires/provides from the metafile for my use cases bdx (back in an hour or so) [16:16] what's up bdx? [16:20] rick_h: what's going on??? [16:21] I'm breaking the qtrly budget getting these blades ordered for the openstack, writing company docs like a mad man, snapping and charming everything in sight [16:21] you know [16:21] the usual [16:21] :) [16:21] rick_h: you back in the states? [16:22] thinking about just making these public https://imgur.com/a/lgEkHKn [16:24] talking to the guys doing ceph at GARR about a little collab on some intro -> advanced juju ceph and openstack operations documentation, hoping to fold in my hoard ^ [16:26] currently working on an xpak subordinate for the elastic stuff [16:27] bdx: sorry, made some tea :) [16:27] bdx: yea, back home and working on TZ adjustments [16:27] bdx: nice on public-fying fun stuff [16:36] reminds me, i need to figure out what I'm doing for the show tomorrow. [16:37] cory_fu: you going to be around? want to show off that aws stuff? [17:18] rick_h_, hey, just fyi , juju2.4-beta2 daily appears to have working bionic lxd containers: https://pastebin.ubuntu.com/p/mqbZR4BsNz/ [17:19] :) [17:19] sfeole: yea, that's got the same two fixes in there [17:19] rick_h_, just fyi, i'm using it today, figured i would let you know [17:19] :) [17:19] rick_h_: just confirmation [17:19] sfeole: nice to see, awesome! [17:20] externalreality_: manadart ^ [17:21] admcleod_: sfeole so the one thing known out is an issue with bonds and bionic (in case you tinker with that) [17:21] rick_h_, i don't actively but will keep that in mind [17:46] few random questions [17:47] in 2.4, will juju opt to install lxd from a snap, or will it continue to install lxd from apt? [17:48] also, will it be possible to use custom storage pools with juju deployed lxd instances in 2.4? [17:49] `juju deploy ubuntu --to lxd:0` - I want the lxd to use storage backed X [17:49] backend* [17:50] possibly these things will be taken into consideration as lxd 3.0 sinks in over the next amount of time [17:58] bdx: so, not sure on install from snap. We'll have to look and see. The one thing that makes me nervous is the story behind the firewall off the top of my head, but it's something that's got to be done/figured out at some point [17:58] bdx: as far as custom storage, there's a roadmap item for the next cycle to improve lxd 3 support including constraints/instance types, remote clusters, and some profile customization methods [17:59] bdx: I'll note that as part of the conversation there [18:51] rick_h_: awesome, thx [20:22] moring team [20:22] or morning [20:27] hi, goodnight x) [20:35] Morning all o/ [20:35] hey thumper how's things? [20:40] bdx: still here by any chance? [20:40] When I try to build a charm that uses a local interface, I get the error that build doesn't find the interface, but when I echo $JUJU_REPOSITORY everything is exported correctly, did I miss something? [20:43] TheAbsentOne: did you also export LAYER_PATH and INTERFACE_PATH [20:43] ? [20:47] yep both echo fine bdx [20:48] TheAbsentOne: is your interface under $INTERFACE_PATH? [20:49] TheAbsentOne: can you paste the output of `ls -la $INTERFACE_PATH | pastebinit` [20:50] https://www.dropbox.com/s/arwlx108kjgys51/tempinterfacerror.png?dl=0 bdx [20:51] bdx: paste.ubuntu.com/p/S6Y4gP8wwN [20:52] ow sorry: https://paste.ubuntu.com/p/S6Y4gP8wwN/ * [20:53] It's not like you need to build or anything an interface right? [20:55] TheAbsentOne: `mv $INTERFACE_PATH/generic-database-layer $INTERFACE_PATH/generic-database` [20:56] TheAbsentOne: then try building your layer [20:57] hey thumper, welcome back! [20:57] bdx: oh god ofcourse, I'm retarded, thanks so much [20:57] np [20:57] so stupid >.< [20:58] veebers: things are generally good [20:58] although jet lag has hit me particularly hard this time [20:59] TheAbsentOne: its a common mistake, no worries - I think there is an initiative to infer the interface from the name in the interface.yaml file instead of the name of the directory [20:59] not sure what ever happened to it [20:59] let me see if I can find it [21:00] that would be interesting, to be honest I thought that was the case first bdx [21:01] TheAbsentOne: totally, I feel it should be too [21:01] thumper: "generally good", very ominous :-) hopefully the lag wears off shortly [21:01] thumper: bists du ein berliner? [21:01] bdx: like in my case I have a repo called "generic-database" which is my charm and not my interface but this might become confusing when using the interface "generic-database" [21:02] totally [21:04] TheAbsentOne: I've found prefixing the layer, interface, bundle, snap repo name with what they are, see how I do them here https://github.com/omnivector-solutions [21:05] bdx: I have another remark/question. The output of the build now states: "build: layer.yaml includes generic-database-layer which isn't used in metadata.yaml" where does he get's this from? [21:06] bdx: yeah I might have to rename them idd, good tip [21:06] ahh, look at any of the layers ^^ and look at the metadata.yaml and see how it defines the interface under either the requires or provides stanzas [21:06] the metadata defines it as "interface:generic-database" [21:07] that "generic-database-layer" is never used or typed only in folder name [21:07] TheAbsentOne: link to the repo? [21:09] https://github.com/Ciberth/generic-database-layer is the interface, https://github.com/Ciberth/consumer-app uses it at requires side, https://github.com/Ciberth/generic-database uses it at provides side [21:09] I find it weird that the build procedure even finds that [21:12] bdx: maybe it does take the name from the interface.yaml; I made a mistake there! [21:12] ok [21:12] thats what I thought [21:13] yep that was it! Maybe I should call it a day and sleep haha xD thanks again though bdx [21:14] np [22:34] veebers: hey, did you work out what was happening with the problem you were seeing with CMR and percona-cluster? [22:37] babbageclunk: not yet still working on it, annoying as the test I run to uncover it takes *ages* [22:37] veebers: sucks [22:37] I mean, the slow test meaning it's hard to investigate [22:37] babbageclunk: I'm trying to narrow down the commit range to narrow down where to look for the issue (I'm not familiar enough with the codebase to make a fully educated guess based on symptoms) [22:38] hah ^_^ [22:38] What's the time range/commit range? [22:39] I can have a look at a list of commits to see if there's anything poignant to suggest good starting places. [22:39] babbageclunk: hah so far between the macaroon version bump (works) and the catacomb tomb v1 ->v2 change. Somewhere there :-) Narrowing it down now [23:13] babbageclunk: am I correct in thinking that ControllerCommandBase commands are commands that take "-c " args and act on a controller (as opposed to a hosted model) [23:13] veebers: yup [23:14] sweet, cheers [23:58] babbageclunk: just a quick note - I didnt fix in the way we discussed on Monday(adding one more upgrade step for 2.4). I can explain u what happens around that code part. [23:59] vino: ok, let me have a read through the PR and we can talk about it