[01:27] <veebers> babbageclunk: For things like "type FindToolsParams struct {" do the "json:<name>" parts match up with something declared elsewhere or does it just define how they are marshalled across the wire?
[01:28] <babbageclunk> veebers: the latter
[01:28] <veebers> babbageclunk: sweet thanks
[01:29] <babbageclunk> no worries
[01:57] <veebers> babbageclunk: to clarify what you where saying earlier, to bump the API you suggest making API be the newest version and add a "previous version" api to cover the diff? (i.e. so ClienAPI is always latest, incrementing to have a v2 means creating a ClientAPIv1 and ClientAPI is what v2 represents)?
[01:58] <babbageclunk> veebers: yup, that's exactly right
[01:58] <veebers> sweet, I'll make it so :-)
[03:18] <anastasiamac> babbageclunk: sorry to put it on ur desk, but here it is - https://github.com/juju/juju/pull/8668
[03:19] <babbageclunk> anastasiamac: oof. Ok, I'll have a look this afternoon.
[03:20] <anastasiamac> \o/
[03:20] <anastasiamac> babbageclunk: m happy to do it over ho once u've browsed as i imagine 144 files PR could b daunting...
[04:41] <babbageclunk> anastasiamac: I know this is a weird thing to ask, but would a worker that checked credentials periodically (say daily or hourly) get us a lot of the way to what we want?
[04:49] <anastasiamac> babbageclunk: there will b  a periodic worker too... however, for credentials specifically, as soon as we *know* that they r invalid we need to stop calls that depend on valid creds... why, for example, keep retrying if we *know* a call will fail?
[04:50] <anastasiamac> babbageclunk: and like i mentioned, there r other things that we'd want to inject- status updates the most obvious one...
[04:54] <babbageclunk> anastasiamac: yeah, that makes sense. Actually, I think I have another idea, want to discuss in a hangout?
[04:54] <anastasiamac> yes
[04:54] <babbageclunk> anastasiamac: anyway, I've been reading through the PR too.
[04:54] <babbageclunk> ok, in standup?
[04:54] <anastasiamac> yes
[05:10] <veebers> kelvinliu: re: my questions on what make a model a caas model, I'm trying to find the right place to have a CaasClient (wrt ModelClient). It should either be contained or auto, passing an arg into a test doesn't make sense (when would you ever pass in a 'normal' client, the test is for caas)
[05:12] <kelvinliu> veebers, understand ur concern,
[05:17] <kelvinliu> veebers, the reason why the assess script parses the client_type was I thought we are mostly using `from_args` to create the client.
[05:17] <veebers> kelvinliu: so, you dont' actually interact differently with a caas model when using the juju cli right?
[05:18] <kelvinliu> veebers, ideally, we could have `create_client` accepts client type to initiate a client.
[05:18] <veebers> kelvinliu: previously we used to versioned ModelClients to account for the different versions of juju (and the CI test code was in a separate repo), since then we now have a ModelClient that is valid for the version of juju that it is in the tree of
[05:19] <veebers> kelvinliu: lets have a quick HO, higher bandwidth discussion that way :-) Use the standup HO?
[05:20] <kelvinliu> veebers, I would say it will be mostly same/similar when u interact with caas model via juju cli
[05:20] <kelvinliu> sounds good
[05:20] <veebers> kelvinliu: is there a need for a CaasModel then? I think all the other checks needed for the test are commands outside of juju?
[05:21] <veebers> there is some setup needed though right? to do with kubectl and paths etc.
[05:22] <kelvinliu> currently inside the caasClient, it wraps deploying cdk bundle, validing cluster healthy and could add more cmds wraps `kubectl`
[05:23] <kelvinliu> yes, to interact with the cluster via kubectl, we needs the kube/config and kubectl bins which are all prepared in `CaasClient`
[05:23] <kelvinliu> veebers, i am in HO
[10:16] <jam> manadart: given that you just replied to the PR, what is the current state of your changes?
[10:17] <manadart> jam: In progress. I will address the remaining small things - DRY up the tests, Etag passthrough. ETA this afternoon.
[10:18] <jam> manadart: k. think it is possible to land it before you leave for the rest of the week?
[10:19] <manadart> I hope so. If not today, I will still check in and turn around review items. Should only be tid-bits.
[10:29] <jam> manadart: quick feedback on the bit of patch I saw. Heading off to lunch now.
[11:36] <srihas> hi guys, have just gotten a juju-controller setup. Do we need to add machines to juju explicitly or we just specify the tags while deploying charms. (OpenStack wiht MAAS+JUJU)
[11:52] <balloons> Good morning
[12:48] <rick_h_> srihas: howdy, once you have the controller bootstrapped you should be able to just deploy workloads using juju deploy and any constraints you need (such as a specific flavor or hardware characteristic)
[12:49] <srihas> rick_h_: juju deploy --constraints tags=compute --config compute.yaml nova-compute
[12:50] <srihas> it took third node; out of my 4 nodes tagged compute in MAAS
[12:50] <rick_h_> srihas: oh I see, you're deploying openstack on maas?
[12:50] <rick_h_> srihas: yea, that looks right
[12:50] <srihas> how can I extend to the other three nodes the nova-compute?
[12:50] <srihas> rick_h_: I am unable to use --to 1,2,4 for example
[12:51] <rick_h_> srihas: so --to means to machines that show up in juju status
[12:51] <rick_h_> srihas: so you have to do "juju add-machine" first and then use those numbers to reference the placement directive
[12:51] <rick_h_> srihas: Juju tries to encourage the cattle vs pets idea so that machines aren't special
[12:52] <srihas> rick_h_: aha, so I need to add machines first?
[12:52] <rick_h_> srihas: well only if you want to specify --to, ideally you shouldn't need to
[12:52] <rick_h_> srihas: you'd just tell Juju to deploy to machines with certain characteristics and Juju will work with maas to find machines that fit the bill and bring up up
[12:53] <srihas> rick_h_: juju deploy --constraints tags=compute --config compute.yaml nova-compute
[12:53] <srihas> found only one machine änd deployed on it
[12:53] <rick_h_> srihas: right, that looks peachy
[12:53] <srihas> I have three other
[12:53] <rick_h_> srihas: ok, so you'd need to use -n 4 for that command to find and bring up 4 machines
[12:53] <rick_h_> srihas: once you have one there you can "juju add-unit -n 3 nova-compute"
[12:54] <rick_h_> srihas: to scale up the existing application, with the same config/constraints, 3 more times
[12:54] <srihas> exactly I want to do it
[12:54] <srihas> rick_h_: I will try
[12:55] <srihas> rick_h_: juju add-unit --constraints tags=compute -n 3 nova-compute ? like this probably
[12:55] <rick_h_> srihas: no, once you specify the constraints Juju remembers them for future units
[12:56] <rick_h_> srihas: so that your units are consistent with each other and you don't have to remember them months later
[12:56] <srihas> juju add-unit -n 3 nova-compute
[12:56] <rick_h_> srihas: +1
[12:56] <srihas> rick_h_: thank you
[12:56] <rick_h_> srihas: np, good luck! :)
[13:06] <srihas> rick_h_: on the deployed node, how does juju figure out public IP for each system? for me its configuring an IP in a different network
[13:06] <srihas> something I mixedup in MAAS it seems
[13:07] <rick_h_> srihas: sooooo this can be a bit more interesting and complex. Juju and MAAS support the idea of network spaces. And when you deploy you can specify how the application should come on, on which networks/spaces/etc.
[13:07] <rick_h_> srihas: check out https://docs.jujucharms.com/2.3/en/network-spaces
[13:08] <rick_h_> and after that https://docs.jujucharms.com/2.3/en/charms-deploying-advanced#deploying-to-network-spaces
[13:08] <srihas> rick_h_: I wonder if I can just change the configuring after assigning networks to spaces or do I need to redeploy
[13:09] <rick_h_> srihas: yea, I think you'll have to redeploy. Changes to underlying MAAS won't auto update things running as there's no promise they're compatible with what was vs what is new
[13:10] <srihas> rick_h_: ok! it's a learning for me, thanks again :)
[13:10] <rick_h_> srihas: no problem, there's a bit to learn for sure
[13:23] <parlos> Good Morning, quick question, whats the 'expected' way to detect when a deployment has completed, any API to call suitable for machine processing?
[13:27] <rick_h_> parlos: so there's a juju plugin called "juju-wait" that I think most folks use for that
[13:27] <rick_h_> parlos: https://pypi.org/project/juju-wait/
[13:31] <parlos> rick_h thanks, will give it a go.
[13:57] <theoneijf> I am running CDK on a bare metal machine and the cluster breaks after reboot.  Total newb and have no clue where to start troubleshooting
[14:29] <srihas> rick_h_: spaces thing is really complex
[14:29] <rick_h_> srihas: yea, the idea though is that if you're deploying software and managing what networks each bit speaks through it's hard to make that modeled well in a reusable way.
[14:31] <srihas> I have read 4 times, not getting hold of it really
[14:32] <rick_h_> srihas: k, let me see if I can get something more hands on to try
[14:33] <rick_h_> srihas: check out https://insights.ubuntu.com/2016/01/21/introduction-deploying-openstack-on-maas-1-9-with-juju
[14:33] <rick_h_> srihas: it's much more verbose and such
[14:37] <srihas> rick_h_: I am on it
[14:37] <srihas> I am changing spaces in MAAS, lets see
[14:37] <rick_h_> srihas: cool, hopefully that's a more thorough walk through that's specific to openstack that'll click more
[20:35] <veebers> Morning o/
[21:13] <veebers> babbageclunk: go-guru-describe is great, thanks for putting me onto it
[21:18] <babbageclunk> veebers: yeah, it's really handy, especially for a big type that's got methods in multiple files
[21:19] <babbageclunk> veebers: I like go-guru-implements as well - it's slower but invaluable
[21:20] <veebers> babbageclunk: sounds great, I'll have to give it a spin too!
[21:45] <ice9> how to deploy a charm on local lxc container?
[22:16] <veebers> babbageclunk, wallyworld: FYI: https://github.com/juju/juju/pull/8669 I'm just updating the upgrade functional test now, I'll add that to this PR too
[22:16] <babbageclunk> veebers: ok, just looking at another PR then I'll check yours out
[22:16] <veebers> babbageclunk: awesome thanks
[22:52] <babbageclunk> veebers: approved
[22:53] <veebers> babbageclunk: sweet cheers, I was hoping to get the functional test in in the same PR, it's taking longer than the 5 minutes I thought it would :-P It ok to add that shortly and have you sanity check that?
[22:54] <babbageclunk> oh sure - forgot about that sorry
[22:55] <veebers> no worries, I should have waited until it was ready and pushed the lot, but I was anxious to get judged and told what I did wrong ^_^
[23:05] <veebers> kelvinliu: for when you're online, thoughts on this for the caas ci test. It gives a way to interact with the k8s bits and keeps the ModelClient 'clean'. This is with the understanding that the only k8s/caas specific bits is the add-k8s, everything after that can just use a ModelClient to interact: https://paste.ubuntu.com/p/wYmmjMF8nw/
[23:47] <kelvinliu> veebers, looks good, will let u know when it's changed
[23:48] <kelvinliu> veebers, thx
[23:48] <veebers> kelvinliu: I can't guarantee it'll run out of the box ;-) may need some minor changes
[23:49] <kelvinliu> veebers, yeah, i saw there are some places will need to change a little bit