[00:49] <wallyworld> kelvinliu: hpidcock: free now
[00:49] <kelvinliu> yep
[01:38] <thumper> wallyworld: https://github.com/juju/juju/pull/10738
[01:40] <wallyworld> looking
[01:41] <wallyworld> another one down, many to go
[01:44] <thumper> at least the number is finite
[02:32] <babbageclunk> quick, everyone start adding more workers
[03:06] <kelvinliu> wallyworld: got this pr to enable `cluster` scope rbac, +1 plz thx https://github.com/juju/juju/pull/10739
[03:06] <wallyworld> ok, looking in 5
[03:06] <timClicks> Feature Highlight: Cross-model relations https://discourse.jujucharms.com/t/feature-highlight-cross-model-relations/2228
[03:59] <jam> rick_h: nammn_de: I would actually say "../relative/path/not/under/cwd"
[03:59] <wallyworld> thumper: https://github.com/juju/juju/pull/10740
[04:00] <jam> I could go either way, but the goal is to make sure we are looking up "what .git is containing the charm" and *not* "what .git contains CWD"
[04:05] <wallyworld> kelvinliu: sorry for delay, lgtm
[04:06] <kelvinliu> wallyworld: np thx
[04:15] <thumper> babbageclunk: thanks for fixing my typo in PR
[04:15] <thumper> wallyworld: I'm assuming you tested against IAAS models ?
[04:16] <babbageclunk> :) I figured it was simpler to fix it than point it out
[04:16] <thumper> wallyworld: code changes look good
[04:16] <wallyworld> thumper: yeah, sorry, i did but forgot to mention, will update PR
[04:16] <thumper> I'm sure this will be helpful in tracking issues with k8s controllers
[04:16] <wallyworld> yup, just had to get shit working in the first place
[05:53] <kelvinliu> wallyworld: still there?
[05:54] <wallyworld> depends who's asking
[05:55] <kelvinliu> wallyworld: aha, can i get some idea from u  about the addrs of binding stuff 😆
[05:55] <wallyworld> sure, standup
[05:55] <kelvinliu> thx
[07:35] <timClicks> jam: thanks for responding to that bug report (I didn't mean to imply that I didn't know what juju trust does!)
[08:31] <anastasiamac> wallyworld: PTAL https://github.com/juju/juju/pull/10742 - 'juju credentials' changes
[08:43] <nammn_de> manadart achilleasa mornin guys, let's say I have a file in packages (core, apiserver, worker) which uses a common function to create a logfile, where would you guys put the function? Afaict currently those things are in the juju utils. Not sure about adding one additionally there though
[09:12] <manadart> nammn_de: Jump on HO?
[09:12] <nammn_de> manadart: sure
[11:53] <nammn_de> jam rick_h stickupkid does this test make sense? https://github.com/juju/juju/pull/10744/files Wanted to open that one quick to discuss whether i understood correctly what was wanted
[12:43] <rick_h> nammn_de:  close, I think the test_deploy_local_charm_revision is missing the sha/version check though
[12:49] <nammn_de> rick_h: great added. Let's wait for stickupkid pr first makes testing easiert 👍
[12:49] <rick_h> nammn_de:  rgr
[12:49] <stickupkid> just need someone to OK it :D
[12:49] <rick_h> stickupkid:  done
[12:49] <nammn_de> stickupkid: rick did
[12:49] <nammn_de> :D
[12:49] <rick_h> stickupkid:  sorry, started but didn't finish it last night :(
[12:49] <rick_h> stickupkid:  looking at the refactor out deb one now
[12:50] <rick_h> stickupkid:  but have questions on what a property.file is
[12:51] <stickupkid> rick_h, it's like a env var file that we can pass around
[12:51] <stickupkid> rick_h, it allows them to be passed around between jobs
[12:51] <rick_h> stickupkid:  ok
[13:50] <achilleasa> manadart: if I juju add-machine, I do hit the provider address change path in the instance poller (going from 0->1 addr); no need to tweak lxd profiles ;-)
[13:50] <manadart> achilleasa: Great.
[13:54] <hml> achilleasa:  I won’t be able to get rid of NewBindings completely without ripping apart the bundle export code which uses EndpointBindings() from the description package.  Also, not convient in the upgrade step.  I will enhance the constructor to handle the cases you’ve brought to light
[14:20] <stickupkid> nammn_de, when you get back, my PR is landed :D
[14:26] <manadart> hml: Can you mark any of achilleasa's comments as resolved if they are addressed?
[14:27] <hml> manadart: I did that yesterday… there was one i couldn’t for some reason, regarding the file name change
[14:27] <manadart> hml: OK. Ta.
[14:29] <hml> manadart: updating a few more with current status, though they are not resolved
[14:44] <achilleasa> hml: sure thing. We can create a followup card to patch description at a later stage
[15:13] <manadart> hml: Made a first pass over the space ID patch. Got some thoughts on the new Bindings type which I'll elucidate tomorrow.
[15:14] <hml> manadart:  i’m in the middle of changes now… that’s a bit late from my point of view.  any chance of a conversation quickly?
[15:14] <hml> manadart: i know it’s late for you
[15:16] <manadart> hml: I have a ride waiting downstairs. There can always be a follow up if you think you'll see to landing it in your day. It's just re-org stuff.
[15:17] <hml> manadart:  I have more Bindings changes almost done.  EndpoingBindings() is becoming a constructor based on conversations with achilleasa
[15:17] <hml> manadart:  so if there’s a big change on top of that… i might be wasting my time today
[15:18] <hml> manadart: understand the ride part.  we’ll see how it goes tomorrow
[15:18] <manadart> hml: That'll be fine. Got to run.
[16:29] <nammn_de> stickupkid: great thanks :D
[17:10] <nammn_de> stickupkid: still around? Got a minute?
[17:48] <nammn_de> rick_h: coming back to the acceptancetest https://github.com/juju/juju/pull/10744 , it shows that we expect charm version to be empty if no git was found. Right now it is working as expected. Given the bug report from manadart, we can tell it is not. Should we change the debug message to be of warning/error?
[17:56] <rick_h> nammn_de:  no, I don't think we want to stop the user on that
[17:57] <nammn_de> rick_h: if thats the case we could elevate the message to be a warning (?)
[17:57] <nammn_de> right now its showing on debug level "no version system found, charm version is empty"
[17:58] <rick_h> nammn_de:  right, but do we know for sure if it's that way because we don't see a .git?
[17:59] <rick_h> nammn_de:  I mean do we know it's an error vs we got it wrong somehow?
[18:05] <nammn_de> rick_h: i cannot say 100% but from the acceptancetests and debugging i found this to be the case of the cases i tested.  AFAICT we use this function to generate the archive https://github.com/juju/charm/blob/v6/charmdir.go#L249 and then in there we create the version string https://github.com/juju/charm/blob/v6/charmdir.go#L419
[18:05] <nammn_de> if one could add a test where we would be outside of the expected boundaries we can be more sure
[18:06] <nammn_de> I could be wrong though, if we use another lib/method instead of ArchiveTo, but could not find so. At least not for the use-case of deploy local charm "juju deploy ~/charms/ntp-nogit --debug"
[18:07] <rick_h> nammn_de:  no, I think you're on track. I just wanted to make sure that we're not erroring when we "don't know" vs we're sure it's a real error
[18:09] <nammn_de> rick_h: Yea makes sense, I would say elevating the log level in this case is in any case a win
[18:09] <rick_h> nammn_de:  sounds good
[18:09] <nammn_de> If a version could not be generated, it is a warning, not error, right?
[18:10] <nammn_de> rick_h: ^
[18:10] <rick_h> nammn_de:  not if there's no .git though is what I was wanting to double check.
[18:10] <rick_h> nammn_de:  not every charm will have to have it
[18:18] <rick_h> nammn_de:  let me know if you're free to chat and we can walk through it
[18:18] <nammn_de> rick_h: yeah, HO?
[18:18] <rick_h> nammn_de:  k, meet you in daily
[18:39] <nammn_de> rick_h: yeah just  tested the deploy. Debug message is: "20:35:11 DEBUG juju.charm charmdir.go:429 charm is not in revision control directory" and "charm-version" does not even exist. Could it be that we never parsed those local "version" files? :D
[18:39] <rick_h> nammn_de:  I would hope not, keep going though and see if we load it in a different path perhaps
[18:47] <nammn_de> rick_h: tested : relative path (deploy . | deploy ./designate), absolute path (deploy ~/workspace/charms/designate) https://pastebin.canonical.com/p/qVjYqK2dVd/
[18:47] <nammn_de> rick_h: no charm_version
[18:50] <rick_h> nammn_de:  ok, so there's our bug then I guess
[18:50] <rick_h> I thought that worked...
[18:51] <nammn_de> rick_h: Good, now I learned that charms are using that. I thought vcs was the only way I can work on this next (?)
[18:58] <nammn_de> rick_h: added additional information to the related launchpad bug
[19:45] <rick_h> nammn_de:  k, ty
[19:55] <thumper> morning
[19:55] <rick_h> morning thumper
[21:09] <thumper> https://github.com/juju/juju/pull/10745
[21:44] <babbageclunk> thumper: approved
[22:23] <timClicks_> babbageclunk, thumper: we need a rubber stamp
[22:24] <timClicks_> wallyworld, kelvinliu, hpidcock: is there a spec/reference for k8s bundles?
[22:26] <babbageclunk> timClicks_: that's thumper's job! ;)
=== timClicks_ is now known as timClicks
[22:26] <kelvinliu> timClicks_: found this https://discourse.jujucharms.com/t/bundles-now-supported/365
[22:26] <babbageclunk> I mean, any indication of what needs stamping would be good too.
[22:27] <timClicks> kelvinliu: thanks - I'll update the jaas.ai/docs bundle page
[22:28] <kelvinliu> and here https://discourse.jujucharms.com/t/charm-bundles/1058
[22:28] <kelvinliu> np
[22:30] <wallyworld> timClicks: sorry was on a call, what we have in discourse is the best source of info
[22:30] <timClicks> wallyworld: all good
[22:30] <wallyworld> babbageclunk: i don't quite get your question on the PR? what do you mean by job?
[22:33] <wallyworld> when you call a charm function, the default is sync (blocking). the progress messages for the resulting task are printed as they occur
[22:33] <wallyworld> when the task ends, showing the task also has all the log messages in the result yaml
[22:58] <babbageclunk> I mean, will the logging be both in the stdout of the task and the list of log messages? It looks like no, from reading the code more.
[22:59] <babbageclunk> wallyworld: sorry - I didn't see your question until now.
[23:01] <wallyworld> babbageclunk: no, stdout is what the actual action/function code itself writes to stdout
[23:01] <babbageclunk> cool
[23:01] <wallyworld> juju tracks the log progress messages separately
[23:02] <babbageclunk> wallyworld: I'm confused by the log message handling - shouldn't Run wait for processLogMessages to finish?
[23:05] <babbageclunk> Maybe I've missed it.
[23:27] <dmitri-s> Hello fellow Jujuers. :) I am new to the tool, interested in trying it on LXD. Running into the `ERROR Get https://10.208.133.1:8443/1.0: Unable to connect to: 10.208.133.1:8443`. However, when I connect to the IP in my browser, it outputs JSON status. Only thing I am thinking is that I don't have a certificate, as browser shows a cert warning. Is there way to pass parameter to JUJU to ignore cert warning or is this issue related to
[23:27] <dmitri-s> something else. I will be very thankful for any advice.
[23:29] <timClicks> dmitri-s: out of interest, what does `curl https://10.208.133.1:8443/1.0`do?
[23:32] <dmitri-s> curl: (60) SSL certificate problem: unable to get local issuer certificate
[23:38] <dmitri-s> Browser returns: {"type":"sync","status":"Success","status_code":200,.... But I had to click ignore cert warning. My understanding (or lack there of) is that 10.208.133.1 is not the Juju controller, but LXD network bridge.
[23:41] <babbageclunk> dmitri-s: can you pastebin the full output you're seeing?
[23:43] <babbageclunk> I think I've seen it when the juju code can't get to the port from inside the container (which it needs to be able to launch new ones).
[23:43] <babbageclunk> If you launch a container yourself, can you curl that address?
[23:43] <dmitri-s> Full output of the bootstrap process or the JSON from LXD?
[23:44] <babbageclunk> dmitri-s: from bootstrap (ideally with --debug)
[23:46] <dmitri-s> Bootstrapping again with debug will post in a minute.
[23:46] <babbageclunk> thanks
[23:47] <babbageclunk> how about launching a container with `lxc launch ubuntu:`, then going into it with `lxc exec <name> bash` and running `curl --insecure https://10.208.133.1:8443/1.0`?
[23:55] <dmitri-s> Considering how long the output is, especially with debug I put it on github: https://github.com/dmitri-s/juju-learn/blob/master/jujubootstrap.log