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:02 |
---|---|---|
kelvinliu__ | wallyworld, yes, will do | 00:03 |
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:33 |
wallyworld | kelvinliu__: yep, looking | 00:36 |
thumper | wallyworld: I thought we were going to try for a move? | 01:20 |
thumper | rather than rm | 01:20 |
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:23 |
* thumper nods | 01:24 | |
thumper | ok | 01:24 |
thumper | wallyworld: https://github.com/juju/juju/pull/9041 | 03:06 |
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:34 |
wallyworld | veebers: right | 03:40 |
wallyworld | that -add will do a complete operation to update toml, lock copy shit to vendor etc IIANM | 03:41 |
veebers | ack cheers | 03:52 |
veebers | wallyworld: FYI https://github.com/juju/juju/pull/9042, only fixes the one error message I saw, couldn't repro what you saw | 03:59 |
wallyworld | veebers: lgtm, i'll see if i can repro the other error | 04:00 |
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:06 |
veebers | ack, I'll hit it now. Hopefully a quick fix | 04:07 |
veebers | charms don't need to be in a series named directory nowadays do they? It's all sorted in the metadata.yaml? | 04:16 |
babbageclunk | I think that right veebers | 04:17 |
babbageclunk | that's | 04:17 |
veebers | cool, cheers babbageclunk | 04:17 |
veebers | wallyworld, thumper we're unlikely to push a 'stable' version number to edge snap right? (i.e. \d.\d.\d) | 04:27 |
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:28 |
veebers | wallyworld, kelvinliu_ operator image for edge snap should be under jujusolutions namespace right (as opposed to our ci namespace) | 04:31 |
wallyworld | yup | 04:32 |
veebers | mean, on it | 04:33 |
kelvinliu_ | `jujusolutions/caas-jujud-operator` veebers | 04:33 |
veebers | kelvinliu_: ack, the awesome person who wrote the image upload job made only the name and version needed ;-) | 04:34 |
kelvinliu_ | veebers, sorry for hiding the details inside the job.... | 04:36 |
veebers | kelvinliu_: no no, it's great, I'm saying you've made it really easy | 04:37 |
kelvinliu_ | veebers, :) | 04:37 |
=== alephnull_ is now known as alephnull | ||
veebers | wallyworld: that's an odd message on the pr job failure | 08:52 |
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:53 |
veebers | yeah, sat there and timed out after 60 minutes | 08:54 |
wallyworld | each fetch of a dep took waaay too long | 08:54 |
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 | 08:55 |
manadart | For review - basic end-to-end worker for upgrade-series: https://github.com/juju/juju/pull/9017 | 11:15 |
manadart | Uses a pattern for testing the worker that I think could be used more widely. | 11:16 |
stickupkid | nice easter egg manadart: | 11:22 |
stickupkid | https://github.com/juju/juju/pull/9017/files#diff-1730051dd986d1473fe1e5ef57af3985R144 | 11:23 |
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:28 |
manadart | stickupkid: Is that just the ordering/grouping? I fixed it and it has proceeded past there now. | 11:46 |
stickupkid | hml: code review done | 13:30 |
hml | stickupkid: ty | 13:30 |
hml | rick_h_: should you be able to bootstrap by cloud type? | 13:32 |
rick_h_ | hml: sorry? I don't understand | 13:34 |
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:35 |
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:36 |
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:37 |
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:38 |
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:39 |
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:40 |
rick_h_ | hml: stickupkid so what if I asked we s/lxd/lxd-remote in this? https://pastebin.canonical.com/p/2WpmnYBvzy/ | 13:42 |
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:43 |
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:44 |
stickupkid | should we HO? | 13:45 |
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:46 |
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:47 |
pmatulis | maybe we should be changing the name, not the type | 13:48 |
pmatulis | "lxd-local"? | 13:48 |
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:49 |
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:50 |
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:51 |
stickupkid | HO? | 13:52 |
rick_h_ | yea, omw to standup | 13:52 |
stickupkid | manadart: CR please https://github.com/juju/juju/pull/9045 | 14:27 |
manadart | stickupkid: K. | 14:30 |
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:39 |
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:40 |
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 | 14:48 |
stickupkid | wow we get a lot of failures in CI :| | 15:36 |
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:46 |
pmatulis | even though those tools are a deb, i'm pretty certain that it can't install a snap either | 15:47 |
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:14 |
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:44 |
pmatulis | hml, lemme know if you want me to test something | 16:45 |
hml | pmatulis: i’m curious if you can reproduce | 16:55 |
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 | 16:59 |
pmatulis | that's definitely new behaviour | 17:00 |
hml | pmatulis: what’s the landscape project to specify for a doc bug? or add juju docs to a bug? | 18:08 |
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:12 |
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:14 |
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:16 |
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:17 |
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:19 |
pmatulis | (can't add the juju docs project within LP i mean) | 18:20 |
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:21 |
hml | pmatulis: ty | 18:22 |
pmatulis | rick_h_, fyi, https://bugs.launchpad.net/juju/+bug/1786324 | 18:34 |
rick_h_ | pmatulis: k, ty | 18:43 |
bdx | hello all, maas storage question | 19:21 |
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:22 |
bdx | oops, duplicate of https://bugs.launchpad.net/juju/+bug/1691694 | 19:23 |
bdx | I'm wondering if its really a duplicate .... | 19:23 |
bdx | my bug, #1765959 has nothing to do with provisioning storage via bundle | 19:24 |
bdx | here is the workflow I'm trying https://paste.ubuntu.com/p/5qfqkDYyhn/ | 19:26 |
bdx | it seems #1765959 (and #1691694) are still a valid bugs | 19:27 |
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:28 |
bdx | is storage for the maas provider just totally borked right now? | 19:29 |
bdx | per ^ bugs | 19:29 |
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:31 |
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 | 19:32 |
=== thumper changed the topic of #juju to: Topic for #juju is "https://jujucharms.com, general chat on https://discourse.jujucharms.com | ||
bdx | copied ^ over to discourse | 20:37 |
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:43 |
veebers | wallyworld: I'm seeing your merge failures, I'm not sure what to make of it yet though | 20:44 |
wallyworld | yeah, there's been a couple of different scenarios | 20:45 |
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:49 |
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:54 |
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:55 |
bitch17 | kaniini has invited you to join #litepub | 20:59 |
* thumper sighs | 20:59 | |
=== 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) | ||
thumper | I thought I could clear the registration requirement | 20:59 |
thumper | but three people in the last 20 minutes is too much | 21:00 |
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:11 |
wallyworld | veebers: in meeting, ty for looking | 21:12 |
veebers | I think the pr jobs need a bit of a revamp, but still haven't solved this specific issue ;-) | 21:31 |
veebers | "make lxd-setup" introduces the ~/.config/lxc dir owned by root, scripts/setup-lxd.sh is run via sudo | 21:48 |
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:50 |
veebers | fg | 21:53 |
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:13 |
wallyworld | ok :-) | 22:14 |
babbageclunk | hey vinodhini | 23:28 |
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:33 |
cory_fu | veebers: And, along those lines, would you mind taking a look at https://github.com/juju/charm-tools/pull/435 | 23:34 |
veebers | cory_fu: oh cool, seems nice and easy then | 23:39 |
veebers | cory_fu: sure can | 23:39 |
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:52 |
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:56 |
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:57 |
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 !! | 23:58 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!