[01:18] <kelvinliu_> hi veebers mind to take a look these 3 PRs when u got some time? thx https://github.com/juju/juju/pull/8777  https://github.com/CanonicalLtd/juju-qa-jenkins/pull/38/files https://github.com/CanonicalLtd/juju-qa-jenkins/pull/43/files
[01:29] <veebers> kelvinliu_: can do :-)
[01:30] <kelvinliu_> veebers, thx :)
[01:36] <veebers> kelvinliu_: for nw-bootstrap-caas-lxd did you land your fixes for it?
[01:37] <kelvinliu_> veebers, yes, it's in dev branch now
[01:37] <veebers> sweet
[01:38] <kelvinliu_> i set all the two test running on goodra only for now.
[01:38] <veebers> kelvinliu_: for https://github.com/juju/juju/pull/8777 am I right in thinking that other than assess_caas_bootstrap.py and assess_caas_deploy_charms.py the rest i the charm inclusion?
[01:39] <veebers> kelvinliu_: cool, once we've done the full move to lxd 3.0 we can change that to include all the lxd-slave machines
[01:47] <kelvinliu_> veebers, yes, u r right, we only need to look on the first two changed files, the rest are all charm files
[01:48] <veebers> kelvinliu_: ack, reviewed. I'm not reviewing the charm code ^_^
[01:51] <kelvinliu_> veebers, i also didnot read the files, but just checked all the changes files are at `charms` dir
[01:54] <babbageclunk> wallyworld: can we chat? I'm a bit lost and confused
[01:58] <kelvinliu_> veebers, i was planning to do(assert) http health-check after gitlab stabilised, but that needs expose the app which is a little bit difficult to achieve here for now, so instead, I use `wait_for_workloads` to ensure all the app are `active` or it will fail at timeout.
[01:59] <kelvinliu_> veebers, do u think it's reasonable ?
[01:59] <veebers> kelvinliu_: what's the complexity in exposing the app?
[01:59] <kelvinliu_> veebers, we need to expose the k8s node ip
[02:00] <veebers> kelvinliu_: I don't think that just deploying the app is quite sufficient, it's possible the deploy 'works' and status states it happy but then nothing actually works for whatever reason
[02:02] <kelvinliu_> wallyworld, any thoughts about how to solve this?
[02:02] <veebers> kelvinliu_: how is this normally done (by a person) it seems getting access to the deployed app should already be an achievable thing, unless I misunderstand
[02:05] <wallyworld> kelvinliu_: tail the log and wait for "gitlab ready". kubectl logs -f ....
[02:06] <kelvinliu_> wallyworld, currently, the test could ensure all the apps are in ready status now
[02:06] <veebers> wallyworld: is that sufficient enough to ensure the application is responsive? Could we do something similar to where we're using mediawiki and make a url request to the address and check the response
[02:07] <kelvinliu_> wallyworld, do we need expose gitlab then curl the service to do health check in the test?
[02:07] <wallyworld> veebers: gitlab will only print that final message once it has properly initialised itself, created alll the db tables, set things up etc. for now i think that's ok
[02:07] <wallyworld> we could expose and check the url though
[02:08] <wallyworld> kelvinliu_: any reason why we can't get the worker ip address and expose via xip.io?
[02:08] <veebers> even a check for a 200 response would be good, but as soon as you're that far it's just a little more to check the output in some meaningful way
[02:09] <veebers> wallyworld: I think I'm missing some knowledge, is a caas deployed app different in it's ability to expose access than an IAAS app?
[02:10] <wallyworld> yes, you need to provide a FQDN for ingress
[02:10] <wallyworld> so we fudge that using xip.io and the ip address of a worker node
[02:10] <wallyworld> in production it would be set up properly
[02:11] <wallyworld> it's explained a bit more in the getting started doc
[02:11] <kelvinliu_> wallyworld, we might be able to get the node ip from juju status -m base-model
[02:11] <veebers> ack I see. we would need to check with IS to see if we could get the right firewall holes poked for access to xip.io. I'll run an initial question past them now
[02:12] <wallyworld> kelvinliu_: that's right, that's what we need to do
[02:14] <babbageclunk> wallyworld: have a moment to chat about these benchmarks? I'm v confused.
[02:18]  * babbageclunk taps his mic. This thing on?
[02:23] <babbageclunk> hey, axw_, I'm having some trouble with some raft stuff... ;)
[02:23] <axw_> babbageclunk: o/
[02:24] <babbageclunk> how's it going?
[02:24] <axw_> what's the issue?
[02:24] <axw_> babbageclunk: pretty good thanks, and yourself?
[02:25] <babbageclunk> yeah, mostly good, other than bashing my head on some benchmarking stuff.
[02:27] <axw_> babbageclunk: so my raft code is all falling apart right on schedule?
[02:27] <babbageclunk> heh
[02:30] <veebers> wallyworld, kelvinliu_ I think we should be ok with xip.io in the lab (assuming I understood properly :-)).
[02:30] <wallyworld> sgtm
[02:31] <kelvinliu_> veebers, awesome! i am adding features on CaasClient to do http health check on apps
[02:31] <veebers> kelvinliu_: awesome!
[02:36] <kelvinliu_> wallyworld, i am thinking we might be able to let `juju expose` do the `juju-external-hostname` config by itself (before creating ingress resource, juju describes facts from k8s api server)
[02:37] <wallyworld> kelvinliu_: that's essentially what happens. for k8s models, juju expose will read the app config to get the external hostname as configured and willuse that
[02:40] <kelvinliu_> wallyworld, i mean we can let juju figure out(describefrom k8s api) what the node ip that this app is running on is
[02:41] <wallyworld> kelvinliu_: that's hard coding behaviour to one specific deployment scenario
[02:49] <wallyworld> kelvin: not sure if you saw my last message as there was a netsplit. we can't assume any particular deployment scenario. for our simple test case, there's only 1 worker and so yes the ip and xip.io work. but in general no, so juju can't guess. it needs to be told the external host name
[02:53] <kelvin> wallyworld, yes, u r right. And when we have more than one ingress backend available in the cluster, we will need to specify the ingress class to use for example, not sure yet if we are able to fetch the host name from there as we can find the related ingress by the ingress class annotation now.
[02:55] <wallyworld> kelvin: for the CI test, we simply need to get the IP address of the single worker node, set the juju-external-hostname application config accordingly, and then we can expose and connect
[02:55] <kelvin> wallyworld, this potentially could be a very later feature. we can discuss in the future
[02:55] <wallyworld> the ingress class to use defaults correctly to xginex
[02:55] <wallyworld> there's no extra config needed
[02:56] <wallyworld> for the CI test
[02:56] <kelvin> wallyworld, yes, for ci test, i will just fetch the node ip from status output which will be suffucient for us
[02:56] <wallyworld> yup
[04:13] <veebers> How can I run all the tests in apiserver/facades/controller/? ./... doesn't work it complains about no go files (which is fair enough there are none, but I want it to recurse from there down
[04:39] <wallyworld> veebers: go test ./...
[04:40] <wallyworld> jam: babbageclunk need to get your input on some benchmarking if you are free at some point
[04:42] <babbageclunk> wallyworld: I added that recording - the times are consistent between the two request methods, so it's the way apache bench is calculating things that is different
[04:42] <wallyworld> interesting ok
[04:42] <wallyworld> so raft is worse at lower volumes
[04:43] <babbageclunk> The other possibility is that the lease claimer is doing less than I thought it was - I'm looking into that at the moment.
[04:44] <babbageclunk> wallyworld: but otherwise, seems like it
[04:44] <wallyworld> ok
[05:16] <jam> hey babbageclunk are you around now?
[05:17] <jam> veebers: go test -check.v github.com/juju/juju/apiserver/facades/controller/... ?
[05:17] <jam> veebers: ah sorry, -check.v must come *after* the '...'
[05:17] <veebers> jam, wallyworld cheers will try that
[05:17] <jam> because there are 2 processes, one is the 'go test' and the other is the compiled binary. once 'go test' reads an arg it doesn't understand (like -check.v) it stops parsing the rest
[05:18] <wallyworld> jam: i'm here, i wanted to talk about the raft stuff as well. babbageclunk will hopefully be back soon
[05:18] <wallyworld> if not maybe you and i can talk
[05:19] <jam> wallyworld: yeah, but I don't like talking to you... :)
[05:19] <wallyworld> :-(
[05:21] <jam> just a sec and I'll jump on a HO
[05:23] <wallyworld> jam: which HO?
[05:25] <jam> wallyworld: https://hangouts.google.com/hangouts/_/canonical.com/juju?authuser=1
[05:26] <babbageclunk> oops got distracted, coming too!
[05:26] <babbageclunk> I didn't word that well, I mean I'm joining the hangout as well.
[05:26] <jam> babbageclunk: ^^
[05:30] <veebers> jam, wallyworld sweet thanks I had the ./... in the wrong place it seems. Cheers!
[05:31] <wallyworld> great
[06:16] <jam> wallyworld: your PR is bundled with other code that is bumping the Version ?
[06:34] <wallyworld> jam: there's a separate juju pr under develipment by vino which will
[06:35] <jam> wallyworld: ok. cause you're changing the format of App v3,but that will be covered elsewhere?
[06:35] <wallyworld> jam: app v3 was done to cater for caas stuff which hasn't shipped yet, ie for juju 2.4
[06:36] <wallyworld> juju 2.3 doesn't export any caas stuff
[06:38] <wallyworld> thanks jam
[15:36] <thedac> Can I get a review of https://github.com/juju/layer-index/pull/30 ?
[15:36] <thedac> cory_fu perhaps?
[15:36] <thedac> kwmonroe:
[17:00] <kwmonroe> thedac: would you please run ./update-readme.py from your thedac:keystone-admin-github repo, and then push?
[17:03] <thedac> kwmonroe: will do
[17:03] <kwmonroe> gracias thedac!
[17:04] <thedac> kwmonroe: done
[17:09] <kwmonroe> merged thedac.  thanks!
[17:09] <thedac> thank you, kwmonroe
[19:01] <erik_lonroth> @rick_h https://github.com/juju/docs/pull/2726
[19:03] <erik_lonroth> The pull request above contains a series 1,2,3 of beginner level charming. I hope you can test it and eventually add something like this to the tutorial.canonical.com (?) perhaps. Regardless, this hopefully can help some people get through the first agonizing phases of development in juju.
[19:14] <pmatulis> erik_lonroth, thanks for that
[19:17] <rick_h_> erik_lonroth:  amazing! I look forward to checking it out
[19:21] <TheAbsentOne> rick_h_: could you relink what erik_lonroth said? Seems interesting. I'm finishing a getting started guide as well ^^
[19:21] <TheAbsentOne> inbefore it's completely the same
[19:21] <rick_h_> TheAbsentOne: https://github.com/juju/docs/pull/2726
[19:22] <TheAbsentOne> holy it really is x) fml
[19:22] <TheAbsentOne> haha
[19:24] <TheAbsentOne> it's good stuff though, would have saved me a lot of time if I had that to start out with a couple of months ago
[19:24] <TheAbsentOne> nicely done erik_lonroth
[19:28] <pmatulis> TheAbsentOne, perhaps you can comment on his PR. i'm sure you must have some stuff to add
[19:29] <TheAbsentOne> pmatulis: I'll take a look!
[19:44] <TheAbsentOne> pmatulis: erik_lonroth: I made a comment with some suggestions. I'll try to finish my roadmap as well and part of it could function as a part 4 if you guys are up for that
[21:03] <erik_lonroth> TheAbsentOne: I'll update taking your comments and suggestions into it. Thanx for the feedback! Also, I think more beginner level tutorials would be needed. Consider if "Part 4 - interfaces"  would be a beginner level, or, perhaps a intermediate level tutorial. Splitting tutorials into "Beginner" - "Intermediate" - "Experienced" would help the community to add more tutorials on more topics around juju. Also, having all tutorials follow a "
[21:03] <erik_lonroth> format-template" to make them feel easy to follow would be great. Have a look at how Android tutorials are built. Those are really awesome example on how to growe a community with tutorials.
[21:18] <TheAbsentOne> I completely agree erik_lonroth, I'll share a markdown page (and github url) once I'm finished and you guys can decide later ^^
[21:19] <erik_lonroth> go for it!
[21:23] <pmatulis> erik_lonroth, also https://tutorials.ubuntu.com/
[21:24] <pmatulis> but the official docs could use a lot of attention re charm writing
[21:26] <TheAbsentOne> besides something that I don't know: if I deploy a charm how much freedom do I have in terms of cpu, ram, storage actually? At design time and at controller time?
[21:30] <pmatulis> TheAbsentOne, you can use "constraints". what do you mean by 'design' and 'controller' time?
[21:35] <TheAbsentOne> Well I haven't actually worked with a juju controller directly. All I got were models to work with. But pmatulis I assume you can't say "I want to deploy a mysql charm on a centos that has X RAM and 64 bits and Y Gb worth of storage" right? Or how does that actually work? Sorry if it's a stupid question
[21:40] <TheAbsentOne_> Damnit internet broke x(
[21:42] <TheAbsentOne_> kinda found my answer pmatulis with the constraints
[21:44] <TheAbsentOne_> Im off to bed now, I hope to finish the "small" tutorial in the next 24 hours depending on some other stuff