[02:12] <timClicks_> babbageclunk: hey sorry to bother you again, would you mind helping me out with an interface/type coercion issue I've encountered
[02:12] <babbageclunk> timClicks_: sure sure!
[02:12] <timClicks_> I'm 90% sure that I've identified the cause of the import issues
[02:12] <babbageclunk> oh awesome
[02:14] <thumper> timClicks_, babbageclunk: what's the tl;dr on vsan?
[02:14] <timClicks_> thumper: tell you in a few minutes
[02:15] <thumper> ack
[02:37] <timClicks_> thumper: we've identified what's causing the cloud-init the issue; specifying user-data is available into a VirtualApp (container for 1 or more VMs) rather than a VM
[02:38] <timClicks_> annoyingly, the call to ImportVApp (which we
[02:38] <timClicks_> we have been using) returns a VM if the OVF only defines a VM
[02:39] <timClicks_> it looks like we need to customise the OVF XML file that we embed
[02:47] <timClicks_> babbageclunk: it looks like we need to wrap the <VirtualSystem> tag within a <VirtualSystemCollection>
[02:47] <babbageclunk> timClicks_: yeah that makes sense
[03:07] <timClicks_> babbageclunk: tweaking the ovf is creating a vapp
[03:07] <timClicks_> *babbageclunk: tweaking the ovf is working, currently creating a vapp
[03:30] <babbageclunk> timClicks_: I got distracted by the following rabbit-hole: VirtualMachineConfigSpec.VAppConfig.Property (which looks like it would let you edit the fields on that form in the clone VM wizard)
[03:30] <timClicks_> babbageclunk: that looks promising
[03:31] <timClicks_> using a vapp directly doesn't seem like a good option
[03:31] <babbageclunk> Having dug around a bit I think extraConfig is still actually what we want though - trying that now
[03:31] <babbageclunk> timClicks_: bums - yeah, I was worried about that
[03:32] <timClicks_> babbageclunk: we have a method to modify extra config in our vsphereclient code
[03:32] <babbageclunk> bugger, looks like I'm still uploading a vmdk
[03:32] <babbageclunk> looking for that
[03:49] <timClicks_> babbageclunk: it looks like you've been able to power on a machine?
[03:50] <babbageclunk> yeah, but no dice - it still lists the same values in its vapp options
[03:55] <babbageclunk> ok, I'm going to have a go at changing the VAppConfig stuff. It's all a bit black magic though
[04:08] <babbageclunk> timClicks_: trying using govc to extract info about the vm so I can feed that back in
[05:17] <wallyworld> kelvinliu_: there's a k8s bug :-( https://github.com/juju/juju/pull/10515
[05:18] <kelvinliu_> wallyworld: looking
[05:25] <kelvinliu_> wallyworld: lgtm, thanks!
[05:25] <wallyworld> ty
[05:25] <wallyworld> stupid typo
[05:28] <kelvinliu_> [Facepalm]
[14:03] <stickupkid> rick_h, achilleasa here is the output of a bash cmr bundle example https://paste.ubuntu.com/p/k2S8gTbBJk/
[14:03] <stickupkid> achilleasa, it works really nicely
[14:08] <stickupkid> the great thing is, that test from e2e ran in 2m28s which beats the hell out of the python one
[14:20] <gizmo693> Hi Guys. Newbie question. I am working the the docs on https://jaas.ai/docs/getting-started-with-charm-development and when I get to the charm build command it is failing
[14:20] <gizmo693> According to magicaltrout there is a missing series in the metadata.yml ?
[14:20] <gizmo693> Any pointers/advice?
[14:21] <rick_h> gizmo693:  the metadata.yaml needs a series key to say what ubuntu series the charm works on.
[14:22] <gizmo693> I have a trout that is magical in my office so will be able to ask what that means
[14:22] <stickupkid> gizmo693, example https://api.jujucharms.com/charmstore/v5/~jameinel/ubuntu-lite-7/archive/metadata.yaml
[14:23] <gizmo693> From a newbies perspective how would I (anyone) know that
[14:23] <stickupkid> gizmo693, good shout tbh
[14:23] <rick_h> gizmo693:  if you're using a starting template I think it defaults to the latest stable series for you
[14:23] <rick_h> gizmo693:  but the question is what os/version does the software your charm works against work on?
[14:25] <gizmo693> I'm just trying to work through the getting started guide as opposed to actually building a charm of my own
[14:25] <stickupkid> achilleasa, export bundle test https://github.com/SimonRichardson/juju/blob/tests-suite/tests/suites/cmr_bundles/export_overlay.sh#L1-L36
[14:26] <gizmo693> magicaltrout said is it charm build or charm create I should be using?
[14:27] <achilleasa> stickupkid: looks nice! One neat trick that I like to use is to pipe the output to something like "sed -e 's/^/ |/g'" so you can get it indented
[14:27] <rick_h> gizmo693:  ok, if you've got comments/feedback/edits please note the link at the bottom which goes to the discourse post for the page you're on. https://discourse.jujucharms.com/t/getting-started-with-charm-development/1118
[14:27] <rick_h> gizmo693:  charm create will let you start with a known template
[14:27] <rick_h> gizmo693:  charm build is the command to build your charm (compile it really)
[14:28] <stickupkid> achilleasa, i was thinking about that, but then i'm wondering if we should do it everywhere?
[14:29] <achilleasa> stickupkid: possibly; or create library functions that you include in your script (ala init.d's functions)
[14:30] <stickupkid> achilleasa, yeah, that's easy to do, anything in side this folder gets included across all tests https://github.com/SimonRichardson/juju/tree/tests-suite/tests/includes
[14:34] <achilleasa> stickupkid: any plans for handling timeouts? (for juju deploy)
[14:35] <stickupkid> achilleasa, we could easily use timeout
[14:35] <achilleasa> stickupkid: +1
[14:35] <stickupkid> achilleasa, i.e. `timeout -k 10m juju bootstrap lxd test`
[14:36] <rick_h> achilleasa:  time to catch up?
[14:36] <achilleasa> rick_h: sure
[14:37] <rick_h> achilleasa:  k, meet you in daily
[15:05] <rick_h> stickupkid:  "no description provided" boooooo :P
[15:05] <stickupkid> rick_h, for?
[15:05] <rick_h> stickupkid:  your PR
[15:05] <stickupkid> rick_h, ah, i'll fill that in now
[15:12] <stickupkid> rick_h, done
[15:13] <rick_h> stickupkid:  k, review done
[15:13] <rick_h> stickupkid:  anything else you needed in particular for today?
[15:14] <stickupkid> rick_h, sometime to quickly have a look at the bash stuff
[15:15] <rick_h> stickupkid:  k, that's going to go up as a PR of sort right?
[15:15] <stickupkid> rick_h, yeah
[15:15] <rick_h> stickupkid:  ok, let me know when that's up and will peek at it
[15:15] <stickupkid> rick_h, i'll make that PR then, let me close out the pylib juju
[15:15] <stickupkid> rick_h, sure
[15:19] <stickupkid> rick_h, looks like https://github.com/juju/python-libjuju/pull/336 is good to me
[15:21] <rick_h> stickupkid:  cool, aisrael going to hit merge on that then
[15:22] <aisrael> rick_h: stickupkid: ta, thanks!
[15:58] <achilleasa> rick_h: the async charm stuff works with macaroons as well :-)
[16:20] <stickupkid> this annoys me https://paste.ubuntu.com/p/Yxq6sjpg93/ - juju returns something on stderr in none json format when I ask it to do so
[16:21] <stickupkid> doing this makes me sad "juju status --format=json 2> /dev/null"
[16:31] <rick_h> achilleasa:  woot
[16:31] <rick_h> stickupkid:  seems less than ideal
[16:32] <stickupkid> rick_h, esp. considering we're now hiding error messages :(
[16:35] <stickupkid> rick_h, at some point in the future it would be nice to add better ux/design to the CLI - it's a bit rough and showing it's age esp. when comparing snap, kubectl etc
[16:35] <rick_h> stickupkid:  yea, I think that's goals for the 3.x flow
[16:35] <stickupkid> rick_h, let's go mental and add graphs https://github.com/gizak/termui
[16:35] <stickupkid> :wink:
[16:35] <rick_h> lmao
[20:31] <thumper> morning
[20:31] <rick_h> morning thumper
[21:27] <wallyworld> babbageclunk: timClicks: what's the goss on vsan?
[21:36] <babbageclunk> wallyworld: some progress - but have hit another snag, not sure what the issue is
[21:37] <wallyworld> ok, i'll try and organise access to a vsphere technical person whom we can enage with
[21:37] <babbageclunk> wallyworld: that would be awesome
[21:57] <babbageclunk> wallyworld: things are looking pretty good
[22:06] <babbageclunk> wallyworld: charmed-k8s seems to be deploying happily
[22:06] <babbageclunk> (all machine agents are up, waiting for charm installs)
[22:32] <timClicks> wallyworld, thumper: looks like babbageclunk's nailed it
[22:32] <wallyworld> oh, goody. i'll catch up  and get the details soon
[22:32] <babbageclunk> wallyworld: it looks like our vsphere machines can't install snaps though
[22:33] <babbageclunk> might need a network change
[22:33] <wallyworld> can you create an RT?
[22:33] <timClicks> on it
[22:33] <wallyworld> ty
[22:33] <timClicks> just confirming that we haven't somehow introduced it via the patch by reproducing on 2.6.7
[22:34] <thumper> what snaps are we installing?
[22:35] <wallyworld> cdk uses snaps
[22:35] <thumper> ah, right
[23:18] <timClicks> as a side issue, using juju 2.6.7 to deploy multiple new units feels comically slow compared to the new patch
[23:36] <timClicks> babbageclunk: the cdk install issue isn't due to us
[23:37] <babbageclunk> timClicks: woot