| === ec0 is now known as redhat | ||
| === redhat is now known as jhebden | ||
| 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:27 |
|---|---|---|
| babbageclunk | veebers: the latter | 01:28 |
| veebers | babbageclunk: sweet thanks | 01:28 |
| babbageclunk | no worries | 01:29 |
| 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:57 |
| babbageclunk | veebers: yup, that's exactly right | 01:58 |
| veebers | sweet, I'll make it so :-) | 01:58 |
| anastasiamac | babbageclunk: sorry to put it on ur desk, but here it is - https://github.com/juju/juju/pull/8668 | 03:18 |
| babbageclunk | anastasiamac: oof. Ok, I'll have a look this afternoon. | 03:19 |
| 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... | 03:20 |
| 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:41 |
| 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:49 |
| anastasiamac | babbageclunk: and like i mentioned, there r other things that we'd want to inject- status updates the most obvious one... | 04:50 |
| 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 | 04:54 |
| 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:10 |
| kelvinliu | veebers, understand ur concern, | 05:12 |
| 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:17 |
| 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:18 |
| veebers | kelvinliu: lets have a quick HO, higher bandwidth discussion that way :-) Use the standup HO? | 05:19 |
| 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:20 |
| veebers | there is some setup needed though right? to do with kubectl and paths etc. | 05:21 |
| kelvinliu | currently inside the caasClient, it wraps deploying cdk bundle, validing cluster healthy and could add more cmds wraps `kubectl` | 05:22 |
| 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 | 05:23 |
| jam | manadart: given that you just replied to the PR, what is the current state of your changes? | 10:16 |
| manadart | jam: In progress. I will address the remaining small things - DRY up the tests, Etag passthrough. ETA this afternoon. | 10:17 |
| jam | manadart: k. think it is possible to land it before you leave for the rest of the week? | 10:18 |
| manadart | I hope so. If not today, I will still check in and turn around review items. Should only be tid-bits. | 10:19 |
| jam | manadart: quick feedback on the bit of patch I saw. Heading off to lunch now. | 10:29 |
| 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:36 |
| balloons | Good morning | 11:52 |
| 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:48 |
| srihas | rick_h_: juju deploy --constraints tags=compute --config compute.yaml nova-compute | 12:49 |
| 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:50 |
| 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:51 |
| 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:52 |
| 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:53 |
| 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:54 |
| 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:55 |
| 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! :) | 12:56 |
| 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:06 |
| 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:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:23 |
| 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:27 |
| parlos | rick_h thanks, will give it a go. | 13:31 |
| 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 | 13:57 |
| 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:29 |
| srihas | I have read 4 times, not getting hold of it really | 14:31 |
| rick_h_ | srihas: k, let me see if I can get something more hands on to try | 14:32 |
| 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:33 |
| 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 | 14:37 |
| veebers | Morning o/ | 20:35 |
| veebers | babbageclunk: go-guru-describe is great, thanks for putting me onto it | 21:13 |
| babbageclunk | veebers: yeah, it's really handy, especially for a big type that's got methods in multiple files | 21:18 |
| babbageclunk | veebers: I like go-guru-implements as well - it's slower but invaluable | 21:19 |
| veebers | babbageclunk: sounds great, I'll have to give it a spin too! | 21:20 |
| ice9 | how to deploy a charm on local lxc container? | 21:45 |
| 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:16 |
| babbageclunk | veebers: approved | 22:52 |
| 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:53 |
| babbageclunk | oh sure - forgot about that sorry | 22:54 |
| 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 ^_^ | 22:55 |
| 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:05 |
| kelvinliu | veebers, looks good, will let u know when it's changed | 23:47 |
| kelvinliu | veebers, thx | 23:48 |
| veebers | kelvinliu: I can't guarantee it'll run out of the box ;-) may need some minor changes | 23:48 |
| kelvinliu | veebers, yeah, i saw there are some places will need to change a little bit | 23:49 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!