[00:02] wallyworld_: If i create an openstack, juju add-cloud and creds for it, how do I currently share access to others to it? Purely through adding a user and granting perms, or can I share some details so they can 'add-cloud' it them selves and then use credentials provided to them too? [00:03] they can access it via your controller, so you need to give them add-model permission on the controller. they need to supply their own creds when they then add-model [00:03] wallyworld_: ack, thanks for clarifying [00:04] add-model takes a --credential arg [00:04] aye, so you would have to provide that user with some creds too, it's not just a case of 'add user', 'grant add-model' [00:39] veebers: no, they need to provide their own creds [00:39] the --credential arg to add-model slurps up the creds from their local yaml file [01:30] wallyworld_: to be clear there is currently 0 caas support in jaas, right? [01:31] not until they upgrade the controllers to 2.4 or 2.5 [01:32] wallyworld_: currently if you add a user with add-model they get house your creds on their models. [01:33] wallyworld_: or intake that back...do we autoupload the new users creds for that cloud on add-model? [01:33] I know I don't specify it when I do multi-user controllers with different nodels [01:33] rick_h_: add-model takes a --credential arg - I think that's required for a user if their creds for that cloud aren't already in the controller [01:34] so if i bootstrap, my creds for the cloud are uploaded [01:34] wallyworld_: it's not required. I never use it but do multi-user controllers all the time [01:34] and if i add-model, that remains the case [01:34] ok, i guess it defaults to the creds of the person who created the model; [01:35] wallyworld_: worth a quick bootstrap, add-user, grant check [01:35] i think that's a bad decision IMO [01:35] wallyworld_: right but a second user running add-model doesn't have to use --credential either [01:35] wallyworld: i have addressed ur review comments. We shd not be taking childID(). We use parentID that refersto MachineTagID which matches with Id in machine constraints. [01:35] right, that's what i think is bad [01:35] Not judging, just biting how multi-year work now [01:35] yeah [01:35] s/biting/noting [01:36] IMO a user shouyld need to specify their credential [01:36] or be branted access to someone else's [01:36] not just use them by magic [01:36] wallyworld: whenever u get time. please take a look at PR. [01:36] maybe there's a reason i'm miaaing [01:37] anastasiamac: i have PR for u to review forward port of exportBundle Client part. [01:37] vino: i updated my comment to ask for Patent() [01:37] wallyworld_: because change in behavior would be something to watch out for. I'd suggest veebers do a quick 2 user test. I *think* the add-model call for the second user auto uploads a local credential for that user tbh [01:37] PArent() even [01:37] vino: sure, i'll look soon. thnx ;) [01:37] rick_h_: yeah, worth checking. last time i tried, i could have sworn i neede dto use --credential [01:37] anastasiamac: it has a failure. [01:38] * rick_h_ swears opposite lol [01:38] as there was no cred for me in the controller [01:38] i am working on CI tests. I will correct PR which is already there for review by EOD. [01:38] rick_h_: i could very well be wrong [01:38] * rick_h_ avoids temptation to move to the computer to test [01:38] rick_h_: veebers is on it :-) [01:38] * vino going to have early lunch. [01:39] rick_h_: heh, leave it with me :-) [01:39] rick_h_: i had bootstrapped my controller, disabled a credential in db and add-model with the same client credential... the command flipped validity on credential which proabbly means that add-model uploads default credential [01:39] from the client... [01:39] veebers: <3 [01:39] (or at least updates, rick_h_) [01:40] rick_h_: i had an idea that seems plausible - the add-model grant should control access to clouds. right now it is assumed that a controller only has one cloud, but that's nmo longer the case with k8s, lxd clusters etc. so add-model should take a cloud arg [01:40] that then controls visibility [01:40] and that's what jaas would use to filter what gets offered [01:41] wallyworld_: seems on the right path [01:41] yeah, we're working the idea into the doc, see how it pans out [01:41] but it fits the model nicely [01:42] wallyworld_: yea basically forcing us to jump into multi-cloud controller stuff a bit faster because we have to. But that's the problem space. [01:42] rick_h_: yeah, luckily most of the modelling woth clouds creds etc already had that in mind [01:42] just tweaking the from end a bit [01:42] wallyworld_: yea [01:42] *front [01:43] Because we modelled it for jaas so it's not too crazy [01:43] rick_h_: veebers is aiming to have a doc out in the next day or so for review [01:44] wallyworld_: cool, I'll be good and patient :) [01:44] veebers: thank you! And don't hesitate to ask if there's any help we can be [01:44] but i want it all *now* [01:44] rick_h_: I can't add-cloud to jaas for myself can I? Currently the clouds accessible with jaas is immutable? [01:45] veebers: correct. [01:45] that may well be the case - i don't think KIMM exposes that [01:45] JIMM [01:45] right, ok that meshes with my understanding good [01:45] No, there's been PoC to add openstack but it's not a feature flag for sure [01:46] vino: strings.Split(unitMachine.Parent().String(), "-") can be replaced with Parent() I think [01:59] babbageclunk: when did you want to chat? [01:59] thumper: oh, now's good! [01:59] ok, [02:04] wallyworld_, rick_h_ what actions do I need creds for? I imagine deploying a charm (if it adds a model) right? [02:04] you mean cloud creds? [02:05] anything that calls the cloud apis [02:05] deploying a charm doesn't add a model [02:05] the model already exists [02:06] wallyworld_: sorry yes I mean cloud creds. Ok so a machine being added for a charm doesn't use cloud apis? [02:06] I'm getting straight in my head when creds are used, and how that relates to users etc. [02:07] veebers: adding a machine does use creds to ask the cloud to spin up that vm [02:08] wallyworld_: ok, so I can add a user with just admin on a model, and that user can deploy a charm without providing creds in any way [02:09] Is there a way to see what creds where used for the deploy? I presume thats something like what anastasiamac mentioned just before [02:09] veebers: that's what me and rick want you yo test - we're not sure if the creds of the model owner are used or if it is mandatory for a user who ohas been granted add-model access to spully their own always [02:09] veebers: u can see what model is using in show-model [02:10] veebers: i think u can also see all creds on the controller using 'show-credential" [02:10] wallyworld_: sorry, I need to confirm what creds have been used. I have created a user and have that user deploy a charm there was no need to add any creds or anything [02:10] Users are split into different JUJU_DATA dirs [02:10] veebers: i think "add-model' uses credentials too [02:10] anastasiamac: awesome, thanks [02:10] nws [02:11] veebers: so that implies we by default use the model owner creds which makes me a bit sad [02:11] yeah, it def uses the credential that the main user added [02:12] at least it tells you who the owner is :-P https://paste.ubuntu.com/p/GdZtfqDtft/ [02:12] vino: what pr did u need a review on? [02:12] veebers: to use a 2nd user cred, u should b able to use 'add-model --credential' [02:13] anastasiamac: aye, thanks. [02:15] wallyworld_: hmm, seems that for add-model you need to define creds, it doesn't use any stored: https://paste.ubuntu.com/p/bxfC75fyrG/ [02:17] that's what i thought was the case but rick thought it may have used the stored owner creds, so good to know [02:17] * wallyworld_ is happy it works that way [02:18] wallyworld_: you're ok with using model owner creds for deploys? [02:18] yes because as per the above the creds are uploaded when the model is created [02:18] so they need to be suplied by the ower when the model is set up [02:19] wallyworld_: right, and there is no option to use different creds when deploying something [02:19] nope [02:28] wallyworld: sorry. I quickly went outside to have brunch. [02:29] the parentId is machine-1 [02:29] thats why i did that split. [02:31] the func Parent returns this way machine-'x'. [02:35] vino: there r build failures on 8991. m ahppy to review once they r resolved :) [02:36] anastasiamac: yes. correct. i mentioned that to u. i want to finish this other 2 PRs. Didnt expect that failure. Will resolve by EOD for sure. [02:43] veebers: wallyworld_ I'm just staying if you have local creds for that cloud they'll auto upload/work [02:43] s/staying/saying [02:43] rick_h_: yeah, looks like juju was looking for aws creds: credentials not found: AWS_SECRET_ACCESS_KEY not found in environment [02:44] rick_h_: ye, agreed, any local creds will work, but you must provide your own [02:45] vino: no rush. m happy not to review :) just ping whenever it'll b ready [02:55] wallyworld: i didnt chk the Parent().Id(). I am chking it now. [03:05] vino: you should never have to do split type things with tags [03:05] if you find yourself wanting to, look to expose the correct method on the type instead [03:11] hi thumper: I was looking at other window. [03:12] thumper & wallyworld: agree. I have verified with Parent().Id() as well. I missed to look at it. [03:24] wallyworld_: If I add a custom cloud (say a k8s cluster) add a user and grant them add-model perms. They won't have a new entry in 'juju clouds', as the controller has been bootstrapped right? and when 'add-credential' the client will hit the controller to query for the auth type details etc.? [03:26] juju clouds only shows the local yaml, yes. add-credential does look at what's in the controller [03:26] ack, thanks [03:27] wallyworld_: sure? add-credential operates on the client only [03:27] sorry, i was thinking of the apd credential api facade endpoint [03:28] what we invoke when uploading a credential as part of add model etc [03:28] veebers: tread carefully ^^ :D [03:28] wallyworld_: yes, that i agree with :D [03:30] wallyworld_, anastasiamac ah ok, so adding a credential for a new cloud would be an issue? (as per example above, someone adds cloud to their config, adds user and grants add-model perms, that user would have to manually add a cloud to allow them to add creds to allow them to add a model [03:30] no [03:31] they specify creds when adding a model [03:31] veebers: add-credenital command wil only add cred to this users client [03:31] using --credential arg [03:31] veebers: when they are add-model with --credential, u'll get the behavior u r after [03:31] juju help add-model [03:33] wallyworld_, anastasiamac but thats for use for credentials that juju knows about [03:33] veebers: no, that's for use of crednentials that are on the client [03:34] no, it uploads the specified ones [03:34] from the local yaml [03:34] juju *knows* about credntials on the client too... [03:35] wallyworld_, anastasiamac I might be confused, but if I'm granted access to a controller in a custom cloud (that someone has added on their end) how, ah wait I see, you can't add a cloud that juju doesn't know the type of any way, so it's always possible to add-credential for it [03:35] right [03:36] when a cloud is added to a controller, the local yaml; becomes irrelevant [03:36] the controller stores all necessary cloud info, regions, auth types etc [03:41] wallyworld_: I may be being dense, this is also on the edge of the multi-cloud controller discussion, but if I add a user with add-model perms to a controller with a k8s cloud, for that user to be able to actually add a model they would have to juju add-k8s with the details too to get creds access, as juju add-credential won't work for them as they wouldn't have the k8s cloud defined to add the creds to [03:41] add-model --credentials with [03:43] someone with add-model perms who wants to make a model doesn't use add-credential [03:43] see above, you use the --credential arg to add-model [03:43] add-credential is purely to update the local yaml [03:43] veebers: wallyworld_ could we ho? like in standup? [03:44] if we need to [03:44] m in today's one [03:44] omw [03:48] wallyworld_ : i was messaging u. I missed '_'. I agree with that Parent().ID().Since u mentioned here in chat Parent() i was disagreeing. I have made changes. [04:05] vino: sorry, been tied up, looking now [04:05] sure wallyworld_ nws. [04:05] lgtm ty [04:23] oh FYI the answer to the k8s cloud, add-models is that (currently) you would have to manually edit the credentials.yaml to add a credential to pass to 'add-model --credential' [04:31] thx wallyworld_ [04:31] np [05:55] ugh, of course the uniter API facades are still using the old registration signature. [06:18] anastasiamac: i have corrected the error in the PR. [06:18] Just moved the files to correct location. [06:18] If u can take a look when u r free. [06:24] vino: k. thnx [06:26] wallyworld_, got a few minutes to discuss CRD? [06:26] ok [06:32] vino: will look later on tonight - got hungry mouths to feed for now [06:32] ya ya sure :) === frankban|afk is now known as frankban [07:53] manadart: thanks for the work on the LXD constraints. I guess you can mark this one as fixed and released: https://bugs.launchpad.net/juju/+bug/1582105 [07:53] Bug #1582105: lxd provider doesn't honour memory constraints

[07:55] zeestrat: Ack. Thanks. [08:25] manadart: No problemo. Just so I understand correctly, those new LXD constraints work for LXD containers deployed on machines on all the different clouds right? [08:26] zeestrat: Yes, all LXD containers will honour constraints - deployed by provider, or as machines on other substrates. [08:26] manadart: Cool stuff. Thanks again. [08:26] zeestrat: There is a current known issue for the provider. [08:27] Unless you specify one of the applicable constraints (cores/mem/instance-type) there will be a default mem limit of 3.5GB on the controller. [08:27] But only the controller. [08:28] https://bugs.launchpad.net/juju/+bug/1784075 [08:28] Bug #1784075: LXD provider places a limit on memory for the controller but not for a workload machine === alephnull_ is now known as alephnull [08:30] Good to know [08:45] morning folks [08:46] https://discourse.jujucharms.com/t/juju-2-4-1-has-been-released/80 advertised cosmic support, but the release streams for juju tools don't include cosmic references? [08:47] hmm neither to the proposed streams [10:15] Review if anyone is inclined: https://github.com/juju/juju/pull/8992 [10:15] Ends up being a simple fix. [10:20] jamespage: You need to use the daily image stream. [10:21] manadart: I thought juju only published proposed and stable streams? [10:24] jamespage: Ah, I mean when bootstrapping/adding machines. It worked for me when I used config image-stream=daily and --series=cosmic. === frankban is now known as frankban|afk [18:48] hml: how did the review of ian's comments go? Do we have a path forward that's ok? [18:48] rick_h_: I’ve grocked Ian’s comments on the PR - when is a good time to chat? [18:49] hml: eating lunch at the computer atm. Give me 10 or 15? [18:49] rick_h_: sure [19:02] hml: k, free when you are [19:02] rick_h_: ready, which HO? [19:02] hml: let's use standup please [19:02] rick_h_: omw [19:31] rick_h_: manadart approved pr 8987, the cinder thing, did you want it manually tested by someone else before landing? [19:43] hml: is that the one that needs a manual test? Did he test it then or just review it? [19:44] rick_h_: yes, i believe he just reviewed it, not test [19:44] hml: yea then we do need a test by a 3rd party please [19:44] rick_h_: ack [21:00] veebers: yes, the lxd remote bootstrap stuff in discourse uses a trust password and interactive [21:00] but if you read the credentials.yaml - that gets morfed into a certificate and big values [21:01] it’s a validation error in initialization args - changing the type to interactive in credentials.yaml to see what happens [21:01] hml: that's odd that it gets changed, is that happening during bootstrap? [21:02] veebers: during add-credentials i believe [21:02] veebers: my hack worked [21:02] filing a bug. (most likely to myself :-D ) [21:03] hml: nice! [21:04] veebers: i figured it would work because the controller instance does get created and installed… it’s just the validation function that fails [21:05] veebers: and pmatulis beat me to it [21:06] heh :-) [21:07] wallyworld: ping. [21:08] hml: hey, otp in k8s call, give me 30 [21:08] wallyworld: sounds good [21:29] hml:just finished, but release call starting. so maybe pop in there? [21:29] wallyworld: omw [21:34] hml: might be worth posting that bug on the discourse post for LXD Clustering? In case other people get tripped up by it they'll at least see a fix is underway [22:19] Weirdly, it seems like things are mostly working with raft leases. [22:19] babbageclunk: yay \o/ [22:25] no, spoke too soon... [22:26] /o\ [22:32] ok, think I've cracked it! [22:32] * veebers refuses to celebrate at this early stage [22:32] at least, whacked that more [22:32] ;-) [22:32] *mole [22:32] fair [22:32] my arms get tired otherwise [22:35] Do we think it's better to a) be careful not to wrap/trace errors when we're checking for specific singleton errors or b) always make sure to use errors.Cause at the point of the check? [22:35] thumper, wallyworld: ^ [22:36] the latter [22:36] we can't control what happens downstream [22:36] and we want to allow annotation etc [22:36] Yeah, I was just thinking that too - otherwise we need to be vigilant about all the layers in between. [22:36] coolthanx [22:44] babbageclunk: ping [22:44] babbageclunk: ping [22:45] thumper: poong [22:45] impatient much? [22:45] babbageclunk: https://hangouts.google.com/hangouts/_/canonical.com/juju-sts [22:45] can you join us please? [22:45] yup