[00:02] <veebers> 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] <wallyworld_> 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] <veebers> wallyworld_: ack, thanks for clarifying
[00:04] <wallyworld_> add-model takes a --credential arg
[00:04] <veebers> 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] <wallyworld_> veebers: no, they need to provide their own creds
[00:39] <wallyworld_> the --credential arg to add-model slurps up the creds from their local yaml file
[01:30] <veebers> wallyworld_: to be clear there is currently 0 caas support in jaas, right?
[01:31] <wallyworld_> not until they upgrade the controllers to 2.4 or 2.5
[01:32] <rick_h_> wallyworld_: currently if you add a user with add-model they get house your creds on their models.
[01:33] <rick_h_> wallyworld_: or intake that back...do we autoupload the new users creds for that cloud on add-model?
[01:33] <rick_h_> I know I don't specify it when I do multi-user controllers with different nodels
[01:33] <wallyworld_> 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] <wallyworld_> so if i bootstrap, my creds for the cloud are uploaded
[01:34] <rick_h_> wallyworld_: it's not required. I never use it but do multi-user controllers all the time
[01:34] <wallyworld_> and if i add-model, that remains the case
[01:34] <wallyworld_> ok, i guess it defaults to the creds of the person who created the model;
[01:35] <rick_h_> wallyworld_: worth a quick bootstrap, add-user, grant check
[01:35] <wallyworld_> i think that's a bad decision IMO
[01:35] <rick_h_> wallyworld_: right but a second user running add-model doesn't have to use --credential either
[01:35] <vino> 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] <wallyworld_> right, that's what i think is bad
[01:35] <rick_h_> Not judging, just biting how multi-year work now
[01:35] <wallyworld_> yeah
[01:35] <rick_h_> s/biting/noting
[01:36] <wallyworld_> IMO a user shouyld need to specify their credential
[01:36] <wallyworld_> or be branted access to someone else's
[01:36] <wallyworld_> not just use them by magic
[01:36] <vino> wallyworld: whenever u get time. please take a look at PR.
[01:36] <wallyworld_> maybe there's a reason i'm miaaing
[01:37] <vino> anastasiamac: i have PR for u to review forward port of exportBundle Client part.
[01:37] <wallyworld_> vino: i updated my comment to ask for Patent()
[01:37] <rick_h_> 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] <wallyworld_> PArent() even
[01:37] <anastasiamac> vino: sure, i'll look soon. thnx ;)
[01:37] <wallyworld_> rick_h_: yeah, worth checking. last time i tried, i could have sworn i neede dto use --credential
[01:37] <vino> anastasiamac: it has a failure.
[01:38]  * rick_h_ swears opposite lol
[01:38] <wallyworld_> as there was no cred for me in the controller
[01:38] <vino> i am working on CI tests. I will correct PR which is already there for review by EOD.
[01:38] <wallyworld_> rick_h_: i could very well be wrong
[01:38]  * rick_h_ avoids temptation to move to the computer to test
[01:38] <wallyworld_> rick_h_: veebers is on it :-)
[01:38]  * vino going to have early lunch.
[01:39] <veebers> rick_h_: heh, leave it with me :-)
[01:39] <anastasiamac> 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] <anastasiamac> from the client...
[01:39] <rick_h_> veebers: <3
[01:39] <anastasiamac> (or at least updates, rick_h_)
[01:40] <wallyworld_> 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] <wallyworld_> that then controls visibility
[01:40] <wallyworld_> and that's what jaas would use to filter what gets offered
[01:41] <rick_h_> wallyworld_: seems on the right path
[01:41] <wallyworld_> yeah, we're working the idea into the doc, see how it pans out
[01:41] <wallyworld_> but it fits the model nicely
[01:42] <rick_h_> 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] <wallyworld_> rick_h_: yeah, luckily most of the modelling woth clouds creds etc already had that in mind
[01:42] <wallyworld_> just tweaking the from end a bit
[01:42] <rick_h_> wallyworld_: yea
[01:42] <wallyworld_> *front
[01:43] <rick_h_> Because we modelled it for jaas so it's not too crazy
[01:43] <wallyworld_> rick_h_: veebers is aiming to have a doc out in the next day or so for review
[01:44] <rick_h_> wallyworld_: cool, I'll be good and patient :)
[01:44] <rick_h_> veebers: thank you! And don't hesitate to ask if there's any help we can be
[01:44] <wallyworld_> but i want it all *now*
[01:44] <veebers> rick_h_: I can't add-cloud to jaas for myself can I? Currently the clouds accessible with jaas is immutable?
[01:45] <rick_h_> veebers: correct.
[01:45] <wallyworld_> that may well be the case - i don't think KIMM exposes that
[01:45] <wallyworld_> JIMM
[01:45] <veebers> right, ok that meshes with my understanding good
[01:45] <rick_h_> No, there's been PoC to add openstack but it's not a feature flag for sure
[01:46] <wallyworld_> vino: strings.Split(unitMachine.Parent().String(), "-") can be replaced with Parent() I think
[01:59] <thumper> babbageclunk: when did you want to chat?
[01:59] <babbageclunk> thumper: oh, now's good!
[01:59] <thumper> ok,
[02:04] <veebers> wallyworld_, rick_h_ what actions do I need creds for? I imagine deploying a charm (if it adds a model) right?
[02:04] <wallyworld_> you mean cloud creds?
[02:05] <wallyworld_> anything that calls the cloud apis
[02:05] <wallyworld_> deploying a charm doesn't add a model
[02:05] <wallyworld_> the model already exists
[02:06] <veebers> wallyworld_: sorry yes I mean cloud creds. Ok so a machine being added for a charm doesn't use cloud apis?
[02:06] <veebers> I'm getting straight in my head when creds are used, and how that relates to users etc.
[02:07] <wallyworld_> veebers: adding a machine does use creds to ask the cloud to spin up that vm
[02:08] <veebers> 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] <veebers> 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] <wallyworld_> 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] <anastasiamac> veebers: u can see what model is using in show-model
[02:10] <anastasiamac> veebers: i think u can also see all creds on the controller using 'show-credential"
[02:10] <veebers> 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] <veebers> Users are split into different JUJU_DATA dirs
[02:10] <anastasiamac> veebers: i think "add-model' uses credentials too
[02:10] <veebers> anastasiamac: awesome, thanks
[02:10] <anastasiamac> nws
[02:11] <wallyworld_> veebers: so that implies we by default use the model owner creds which makes me a bit sad
[02:11] <veebers> yeah, it def uses the credential that the main user added
[02:12] <veebers> at least it tells you who the owner is :-P https://paste.ubuntu.com/p/GdZtfqDtft/
[02:12] <anastasiamac> vino: what pr did u need a review on?
[02:12] <anastasiamac> veebers: to use a 2nd user cred, u should b able to use 'add-model --credential'
[02:13] <veebers> anastasiamac: aye, thanks.
[02:15] <veebers> 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] <wallyworld_> 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] <veebers> wallyworld_: you're ok with using model owner creds for deploys?
[02:18] <wallyworld_> yes because as per the above the creds are uploaded when the model is created
[02:18] <wallyworld_> so they need to be suplied by the ower when the model is set up
[02:19] <veebers> wallyworld_: right, and there is no option to use different creds when deploying something
[02:19] <wallyworld_> nope
[02:28] <vino> wallyworld: sorry. I quickly went outside to have brunch.
[02:29] <vino> the parentId is machine-1
[02:29] <vino> thats why i did that split.
[02:31] <vino> the func Parent returns this way machine-'x'.
[02:35] <anastasiamac> vino: there r build failures on 8991. m ahppy to review once they r resolved :)
[02:36] <vino> 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] <rick_h_> veebers: wallyworld_ I'm just staying if you have local creds for that cloud they'll auto upload/work
[02:43] <rick_h_> s/staying/saying
[02:43] <veebers> rick_h_: yeah, looks like juju was looking for aws creds: credentials not found: AWS_SECRET_ACCESS_KEY not found in environment
[02:44] <wallyworld_> rick_h_: ye, agreed, any local creds will work, but you must provide your own
[02:45] <anastasiamac> vino: no rush. m happy not to review :) just ping whenever it'll b ready
[02:55] <vino> wallyworld: i didnt chk the Parent().Id(). I am chking it now.
[03:05] <thumper> vino: you should never have to do split type things with tags
[03:05] <thumper> if you find yourself wanting to, look to expose the correct method on the type instead
[03:11] <vino> hi thumper: I was looking at other window.
[03:12] <vino> thumper & wallyworld: agree. I have verified with Parent().Id() as well. I missed to look at it.
[03:24] <veebers> 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] <wallyworld_> juju clouds only shows the local yaml, yes. add-credential does look at what's in the controller
[03:26] <veebers> ack, thanks
[03:27] <anastasiamac> wallyworld_: sure? add-credential operates on the client only
[03:27] <wallyworld_> sorry, i was thinking of the apd credential api facade endpoint
[03:28] <wallyworld_> what we invoke when uploading a credential as part of add model etc
[03:28] <anastasiamac> veebers: tread carefully ^^ :D
[03:28] <anastasiamac> wallyworld_: yes, that i agree with :D
[03:30] <veebers> 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] <wallyworld_> no
[03:31] <wallyworld_> they specify creds when adding a model
[03:31] <anastasiamac> veebers: add-credenital command wil only add cred to this users client
[03:31] <wallyworld_> using --credential arg
[03:31] <anastasiamac> veebers: when they are add-model with --credential, u'll get the behavior u r after
[03:31] <wallyworld_> juju help add-model
[03:33] <veebers> wallyworld_, anastasiamac but thats for use for credentials that juju knows about
[03:33] <anastasiamac> veebers: no, that's for use of crednentials that are on the client
[03:34] <wallyworld_> no, it uploads the specified ones
[03:34] <wallyworld_> from the local yaml
[03:34] <anastasiamac> juju *knows* about credntials on the client too...
[03:35] <veebers> 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] <wallyworld_> right
[03:36] <wallyworld_> when a cloud is added to a controller, the local yaml; becomes irrelevant
[03:36] <wallyworld_> the controller stores all necessary cloud info, regions, auth types etc
[03:41] <veebers> 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] <veebers> add-model --credentials with
[03:43] <wallyworld_> someone with add-model perms who wants to make a model doesn't use add-credential
[03:43] <wallyworld_> see above, you use the --credential arg to add-model
[03:43] <wallyworld_> add-credential is purely to update the local yaml
[03:43] <anastasiamac> veebers: wallyworld_ could we ho? like in standup?
[03:44] <wallyworld_> if we need to
[03:44] <anastasiamac> m in today's one
[03:44] <veebers> omw
[03:48] <vino> 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] <wallyworld_> vino: sorry, been tied up, looking now
[04:05] <vino> sure wallyworld_ nws.
[04:05] <wallyworld_> lgtm ty
[04:23] <veebers> 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] <vino> thx wallyworld_
[04:31] <wallyworld_> np
[05:55] <babbageclunk> ugh, of course the uniter API facades are still using the old registration signature.
[06:18] <vino> anastasiamac: i have corrected the error in the PR.
[06:18] <vino> Just moved the files to correct location.
[06:18] <vino> If u can take a look when u r free.
[06:24] <anastasiamac> vino: k. thnx
[06:26] <kelvin_> wallyworld_, got a few minutes to discuss CRD?
[06:26] <wallyworld_> ok
[06:32] <anastasiamac> vino: will look later on tonight - got hungry mouths to feed for now
[06:32] <vino> ya ya sure :)
[07:53] <zeestrat> 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] <mup> Bug #1582105: lxd provider doesn't honour memory constraints <constraints> <juju-release-support> <lxd-provider> <juju:Triaged> <https://launchpad.net/bugs/1582105>
[07:55] <manadart> zeestrat: Ack. Thanks.
[08:25] <zeestrat> 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] <manadart> zeestrat: Yes, all LXD containers will honour constraints - deployed by provider, or as machines on other substrates.
[08:26] <zeestrat> manadart: Cool stuff. Thanks again.
[08:26] <manadart> zeestrat: There is a current known issue for the provider.
[08:27] <manadart> 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] <manadart> But only the controller.
[08:28] <manadart> https://bugs.launchpad.net/juju/+bug/1784075
[08:28] <mup> Bug #1784075: LXD provider places a limit on memory for the controller but not for a workload machine <docteam> <juju:Triaged> <https://launchpad.net/bugs/1784075>
[08:30] <zeestrat> Good to know
[08:45] <jamespage> morning folks
[08:46] <jamespage> 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] <jamespage> hmm neither to the proposed streams
[10:15] <manadart> Review if anyone is inclined: https://github.com/juju/juju/pull/8992
[10:15] <manadart> Ends up being a simple fix.
[10:20] <manadart> jamespage: You need to use the daily image stream.
[10:21] <jamespage> manadart: I thought juju only published proposed and stable streams?
[10:24] <manadart> jamespage: Ah, I mean when bootstrapping/adding machines. It worked for me when I used config image-stream=daily and --series=cosmic.
[18:48] <rick_h_> hml: how did the review of ian's comments go? Do we have a path forward that's ok?
[18:48] <hml> rick_h_: I’ve grocked Ian’s comments on the PR - when is a good time to chat?
[18:49] <rick_h_> hml: eating lunch at the computer atm. Give me 10 or 15?
[18:49] <hml> rick_h_:  sure
[19:02] <rick_h_> hml: k, free when you are
[19:02] <hml> rick_h_: ready, which HO?
[19:02] <rick_h_> hml: let's use standup please
[19:02] <hml> rick_h_: omw
[19:31] <hml> rick_h_: manadart  approved pr 8987, the cinder thing, did you want it manually tested by someone else before landing?
[19:43] <rick_h_> hml: is that the one that needs a manual test? Did he test it then or just review it?
[19:44] <hml> rick_h_: yes, i believe he just reviewed it, not test
[19:44] <rick_h_> hml: yea then we do need a test by a 3rd party please
[19:44] <hml> rick_h_: ack
[21:00] <hml> veebers: yes, the lxd remote bootstrap stuff in discourse  uses a trust password and interactive
[21:00] <hml> but if you read the credentials.yaml - that gets morfed into a certificate and big values
[21:01] <hml> it’s a validation error in initialization args - changing the type to interactive in credentials.yaml to see what happens
[21:01] <veebers> hml: that's odd that it gets changed, is that happening during bootstrap?
[21:02] <hml> veebers: during add-credentials i believe
[21:02] <hml> veebers: my hack worked
[21:02] <hml> filing a bug.  (most likely to myself  :-D )
[21:03] <veebers> hml: nice!
[21:04] <hml> 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] <hml> veebers: and pmatulis beat me to it
[21:06] <veebers> heh :-)
[21:07] <hml> wallyworld: ping.
[21:08] <wallyworld> hml: hey, otp in k8s call, give me 30
[21:08] <hml> wallyworld:  sounds good
[21:29] <wallyworld> hml:just finished, but release call starting. so maybe pop in there?
[21:29] <hml> wallyworld: omw
[21:34] <veebers> 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] <babbageclunk> Weirdly, it seems like things are mostly working with raft leases.
[22:19] <veebers> babbageclunk: yay \o/
[22:25] <babbageclunk> no, spoke too soon...
[22:26] <veebers>  /o\
[22:32] <babbageclunk> ok, think I've cracked it!
[22:32]  * veebers refuses to celebrate at this early stage
[22:32] <babbageclunk> at least, whacked that more
[22:32] <veebers> ;-)
[22:32] <babbageclunk> *mole
[22:32] <babbageclunk> fair
[22:32] <veebers> my arms get tired otherwise
[22:35] <babbageclunk> 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] <babbageclunk> thumper, wallyworld: ^
[22:36] <wallyworld> the latter
[22:36] <wallyworld> we can't control what happens downstream
[22:36] <wallyworld> and we want to allow annotation etc
[22:36] <babbageclunk> Yeah, I was just thinking that too - otherwise we need to be vigilant about all the layers in between.
[22:36] <babbageclunk> coolthanx
[22:44] <thumper> babbageclunk: ping
[22:44] <thumper> babbageclunk: ping
[22:45] <babbageclunk> thumper: poong
[22:45] <babbageclunk> impatient much?
[22:45] <thumper> babbageclunk: https://hangouts.google.com/hangouts/_/canonical.com/juju-sts
[22:45] <thumper> can you join us please?
[22:45] <babbageclunk> yup