[00:02] kelvinliu__: before we land the dep changes we need to update the godeps make target in 2.3 and 2.4 to rm -rf ./vendor [00:03] wallyworld, yes, will do [00:33] wallyworld, https://github.com/juju/juju/pull/9039 https://github.com/juju/juju/pull/9040 mind to take a look these tiny PRs? thx [00:36] kelvinliu__: yep, looking [01:20] wallyworld: I thought we were going to try for a move? [01:20] rather than rm [01:23] thumper: considered it. but more moving parts. by having to run make ensure-dependencies anyway (just like godeps -u ...) it will regenerate it from local cahce and only takes approx 10s [01:24] * thumper nods [01:24] ok [03:06] wallyworld: https://github.com/juju/juju/pull/9041 [03:34] kelvinliu_, wallyworld: query about the dep change, it only ever looks in the vendor/ dir right? So to consider a dep you need to "dep ensure -add ..." [03:34] also, I love that some of our tools use --arg and others use -arg :-| [03:40] veebers: right [03:41] that -add will do a complete operation to update toml, lock copy shit to vendor etc IIANM [03:52] ack cheers [03:59] wallyworld: FYI https://github.com/juju/juju/pull/9042, only fixes the one error message I saw, couldn't repro what you saw [04:00] veebers: lgtm, i'll see if i can repro the other error [04:06] wallyworld: you want to catch up real quick re: working on the cloud container status work, or should I move onto '--resource' taking a file path for oci-image details, oh or actually I could look real quick at the operator-image gen for edge snaps [04:06] let's do the operator image gen so we don't break stuff again [04:07] ack, I'll hit it now. Hopefully a quick fix [04:16] charms don't need to be in a series named directory nowadays do they? It's all sorted in the metadata.yaml? [04:17] I think that right veebers [04:17] that's [04:17] cool, cheers babbageclunk [04:27] wallyworld, thumper we're unlikely to push a 'stable' version number to edge snap right? (i.e. \d.\d.\d) [04:28] wouldn't think so [04:28] correct [04:28] I'm wanting to put an extra check in the operator image step so nothing released gets overwritten [04:28] cool thanks ! [04:28] wallyworld, github.com/juju/juju/dependencies_test.go this test ensures tsv does not include spaces. i am going to delete this test file together with the dependencies.tsv [04:28] sgtm [04:31] wallyworld, kelvinliu_ operator image for edge snap should be under jujusolutions namespace right (as opposed to our ci namespace) [04:32] yup [04:33] mean, on it [04:33] `jujusolutions/caas-jujud-operator` veebers [04:34] kelvinliu_: ack, the awesome person who wrote the image upload job made only the name and version needed ;-) [04:36] veebers, sorry for hiding the details inside the job.... [04:37] kelvinliu_: no no, it's great, I'm saying you've made it really easy [04:37] veebers, :) === alephnull_ is now known as alephnull [08:52] wallyworld: that's an odd message on the pr job failure [08:53] veebers: it really didn't like talking to github. the last one timed out [08:53] wallyworld, kelvinliu_ seems it's having trouble within the lxd container? [08:53] wallyworld: hmm, interesting [08:54] yeah, sat there and timed out after 60 minutes [08:54] each fetch of a dep took waaay too long [08:55] much better now [08:55] seems to be working again [08:55] yeah it's already to dep 96, failed on 20 or so last time [11:15] For review - basic end-to-end worker for upgrade-series: https://github.com/juju/juju/pull/9017 [11:16] Uses a pattern for testing the worker that I think could be used more widely. [11:22] nice easter egg manadart: [11:23] https://github.com/juju/juju/pull/9017/files#diff-1730051dd986d1473fe1e5ef57af3985R144 [11:28] manadart: you've got a gometalinter issue on that PR [11:28] "worker/upgradeseries/worker_test.go:1::warning: file is not goimported (goimports)" [11:46] stickupkid: Is that just the ordering/grouping? I fixed it and it has proceeded past there now. [13:30] hml: code review done [13:30] stickupkid: ty [13:32] rick_h_: should you be able to bootstrap by cloud type? [13:34] hml: sorry? I don't understand [13:35] rick_h_: e.g. juju bootstrap lxd without defining any additional clouds [13:35] just having the default ones [13:35] hml: no, because you have to setup the remote endpoint. [13:35] hml: juju bootstrap localhost should work [13:35] juju bootstrap lxd should work [13:36] lxd and localhost are interchangeable [13:36] \o/ [13:36] stickupkid: that’s what i’m seeing [13:36] it should work though, is it not? [13:36] stickupkid: but it doesn’t make sense. since doesn’ twork with any other cloud, i hope [13:36] stickupkid: i didn’t expect it to work… and confused why a bug thought it should [13:37] erm... i just kept it around, so I didn't break backawards compatibility [13:37] i get the same results with bootstrap locahost and bootstrap lxd [13:37] stickupkid: hml oh....ummm...that doesn't seem right. [13:37] rick_h_: +1 [13:37] turns out some people use `juju bootstrap lxd` aka jam :p [13:38] rick_h_: i’m seeing this in 2.4.1, so for backwards compat? [13:38] orly? hmmm [13:38] yuck [13:38] ugh [13:38] rick_h_: came across it in my bug and thought it was an error [13:38] yea, I mean you can't juju add-cloud with google/aws/etc so I wouldn't expect the add-cloud to be the same as the thing you bootstrap [13:39] as jam says "lxd is 'special'" hmmm [13:39] if there was a differentiator with lxd and localhost, that would make life a bit easier it certain places, but 2.4 you can use lxd [13:40] and thumper told me not to break stuff :D [13:40] yea, not breaking stuff is good... [13:40] so then the question is do we make the add-cloud something not lxd... [13:40] lxd-remote [13:40] what's the bug? [13:42] hml: stickupkid so what if I asked we s/lxd/lxd-remote in this? https://pastebin.canonical.com/p/2WpmnYBvzy/ [13:43] rick_h_: it might be confusing unless with use lxd-remote everywhere. since lxd and lxd-remote are the same yes?… but even then giving that folks bootstrap lxd. [13:43] would we end up with localhost, lxd and lxd-remote? [13:44] hml: so we'd allow lxd but remove it from the docs/help [13:44] i'm fine with lxd there [13:44] hml: and have localhost and lxd-remote [13:45] should we HO? [13:46] one can still add a local 'lxd' type cloud manually so it makes sense to keep it 'lxd' with add-cloud [13:46] then prompt for 'local' or 'remote' [13:46] pmatulis: what is a local lxd type cloud locally that's not localhost? [13:47] a local cluster [13:47] s/cluster/remote/ [13:47] rick_h_, 'localhost' is the *name* of a local 'lxd' type cloud [13:48] maybe we should be changing the name, not the type [13:48] "lxd-local"? [13:49] ugh, I knew that half hearted lxd thing would bite us [13:49] fine, that's a lxd-remote where the IP addr is what you're on, or one of the other nodes in that cluster. [13:50] this was why i was originally saying we should split providers between local and remote [13:50] but i'm still thinking this way is actually good, tbh [13:50] here's the thing. If you add-cloud a lxd what happens to the built in "localhost" [13:50] you can't use both [13:51] so you show-clouds and localhost and something else you named is just the same reference? [13:51] well this is awesome: https://pastebin.canonical.com/p/QGjnqNvG86/ [13:51] bootstap [13:51] you can, if you use `juju set-default-credential` [13:51] stickupkid: not following there [13:52] HO? [13:52] yea, omw to standup [14:27] manadart: CR please https://github.com/juju/juju/pull/9045 [14:30] stickupkid: K. [14:39] rick_h_: stickupkid i forgot to add an lxd group and put ubuntu in it. :-/ [14:39] ah of course, forgot about that [14:40] hml: ah gotcha [14:40] rick_h_: does the juju snap install the lxd snap too? [14:40] is that a thing [14:48] hml: I don't think so as we expect lxd to be on the system [14:48] hml: and if we did that if you had the deb lxd we'd introduce a lxd in a snap the user isn't expecting [15:36] wow we get a lot of failures in CI :| [15:46] hml, snaps cannot add other snap afaiu. if a snap needs something it has to drag in the source code somehow. for instance, you don't install deb 'zfsutils-linux' when you use the lxd snap [15:47] even though those tools are a deb, i'm pretty certain that it can't install a snap either [16:14] rick_h_: pmatulis if lxd is apt installed, a snap install gets juju only. but if the apt of lxd is purged, a snap install of juju, installs lxd it appears: https://pastebin.canonical.com/p/WHbxVqV2Qs/ or am i crazy again today. ;-) [16:44] hml, i've never seen lxd and juju influencing each other ito installing, regardless of how each is installed [16:44] has something changed? [16:44] i sure hope not [16:45] hml, lemme know if you want me to test something [16:55] pmatulis: i’m curious if you can reproduce [16:59] hml, it appears that lxd snap will always be installed when installing juju snap providing that lxd deb is not installed [16:59] (tested on Bionic) [16:59] pmatulis: interesting, i saw the same, yu [16:59] ty [17:00] that's definitely new behaviour [18:08] pmatulis: what’s the landscape project to specify for a doc bug? or add juju docs to a bug? [18:12] hml, docs team hasn't done anything with landscape for a very long time. can you give me details on the issue you see? [18:12] and not sure what you mean by your second question [18:14] pmatulis: we need a doc change related to https://bugs.launchpad.net/juju/+bug/1784018 - where it talks about setting up lxd, there is mention that ipv6 is not supported, [18:14] pmatulis: lxd init configures ipv6 by default [18:16] pmatulis: i mean the lxd setup for juju in the docs, does NOT mention that IPv6 is not supported. :-) [18:16] i don't see landscape in any of that (?) [18:17] pmatulis: i didn’t mean that the bug was a aginst landscape… just want to add juju docs as a project that needs to fix something as part of the bug resolution [18:19] hml, you want to file a juju docs bug you mean? [18:19] you can't do that within LP [18:19] pmatulis: sure, that’s another way to accomplish the same thing [18:20] (can't add the juju docs project within LP i mean) [18:21] the easiest is to simply file a docs bug and then link to it in an LP comment [18:21] anastasia does this fairly often [18:21] https://github.com/juju/docs/issues/new [18:22] pmatulis: ty [18:34] rick_h_, fyi, https://bugs.launchpad.net/juju/+bug/1786324 [18:43] pmatulis: k, ty [19:21] hello all, maas storage question [19:22] I filed this a few months ago https://bugs.launchpad.net/juju/+bug/1765959 [19:22] looks like it was marked a duplicate of https://bugs.launchpad.net/juju/+bug/1765959 [19:23] oops, duplicate of https://bugs.launchpad.net/juju/+bug/1691694 [19:23] I'm wondering if its really a duplicate .... [19:24] my bug, #1765959 has nothing to do with provisioning storage via bundle [19:26] here is the workflow I'm trying https://paste.ubuntu.com/p/5qfqkDYyhn/ [19:27] it seems #1765959 (and #1691694) are still a valid bugs [19:28] from what I can tell, I'm provisioning the storage pool and attaching the storage correctly (my nodes raid disks are tagged with 'raid') [19:29] is storage for the maas provider just totally borked right now? [19:29] per ^ bugs [19:31] I feel like ^bugs would have had more priority on them if its true that maas storage is borked [19:31] thats why I feel it must be me [19:32] but I also feel my workflow checks out [19:32] either way [19:32] any insight here would be appreciated [19:32] thx thx === thumper changed the topic of #juju to: Topic for #juju is "https://jujucharms.com, general chat on https://discourse.jujucharms.com [20:37] copied ^ over to discourse [20:43] kaniini has invited you to join #litepub [20:43] rick_h_: is bionic supported by 2.4 and 2.3? (I ask re: ci-tests) [20:44] wallyworld: I'm seeing your merge failures, I'm not sure what to make of it yet though [20:45] yeah, there's been a couple of different scenarios [20:49] kaniini has invited you to join #litepub [20:49] veebers: should just be 2.4 I think [20:49] veebers: since we needed to get things to work in bionic [20:54] rick_h_: ack, the jenkins change stickupkid suggested will break things for older branches, I'll counter propose something that should work for all branches [20:55] veebers: ah gotcha yea I bet he didn't think of that [20:55] yeah, the ci stuff is a big beast [20:59] kaniini has invited you to join #litepub [20:59] * thumper sighs === thumper changed the topic of #juju to: https://jujucharms.com, general chat on https://discourse.jujucharms.com, this channel is going to require registered users while we deal with spam bot (see https://freenode.net) [20:59] I thought I could clear the registration requirement [21:00] but three people in the last 20 minutes is too much [21:11] wallyworld: so, jumping on the pr lxd machine ~/.config is owned by root, I don't know why yet, but that's why we see the perms denied thing, as git it trying to check it's config. I'm looking into it now [21:12] veebers: in meeting, ty for looking [21:31] I think the pr jobs need a bit of a revamp, but still haven't solved this specific issue ;-) [21:48] "make lxd-setup" introduces the ~/.config/lxc dir owned by root, scripts/setup-lxd.sh is run via sudo [21:50] if the file exists before hand it's fine. is it possible the xenial lxd images changes recently so .config isn't created by default? [21:53] fg [22:13] wallyworld: I'm testing out a fix or two for different things, please don't re-merge your PR as I'm using it as a test bed :-) [22:14] ok :-) [23:28] hey vinodhini [23:33] veebers: Hey, so apparently builds.snapcraft.io already supports triggering builds on updates to parts, so it looks like we won't actually need to do anything other than watch master on charmstore-client. See: https://forum.snapcraft.io/t/further-automation-of-build-snapcraft-io/2926 [23:34] veebers: And, along those lines, would you mind taking a look at https://github.com/juju/charm-tools/pull/435 [23:39] cory_fu: oh cool, seems nice and easy then [23:39] cory_fu: sure can [23:52] kelvinliu_: just to be 100%... when I run 'make dep' and get back only message that says 'skipping dep', it's because i have all i need and dep does not need to do anything? [23:56] anastasiamac, there is a env var flag to turn on/off this target. JUJU_MAKE_DEP [23:56] anastasiamac, kelvinliu_: wallyworld has a change that will invert that (i.e. will always do deps [23:57] kelvinliu_: so i need to set JUJU_MAKE_DEP= true before running 'make dep'? [23:57] once it land [23:57] s [23:57] veebers: yes... but until it lands :) [23:57] anastasiamac, so u can run JUJU_MAKE_DEP=true make dep, [23:57] But I'm holding it up a little bit as it's my testbed for pr changes [23:57] anastasiamac: right, yeah that was more of a PSA than "this will help you" :-) [23:57] anastasiamac: the behaviour here hasn't changed - make never used to run godeps -u dependencies.tsv byu defualt [23:58] kelvinliu_: thnx [23:58] wallyworld: i never used make before :) [23:58] but we are swapping tht around now [23:58] anastasiamac, np [23:58] yeah exactly - so people can use make we are making it work [23:58] by default [23:58] wallyworld: i ran godeps directly... yep, +1 on making ppl trust and use make !!