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