| 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:02 |
|---|---|---|
| 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:03 |
| 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:04 |
| 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 | 00:39 |
| veebers | wallyworld_: to be clear there is currently 0 caas support in jaas, right? | 01:30 |
| wallyworld_ | not until they upgrade the controllers to 2.4 or 2.5 | 01:31 |
| rick_h_ | wallyworld_: currently if you add a user with add-model they get house your creds on their models. | 01:32 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:37 |
| * 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:38 | |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| wallyworld_ | vino: strings.Split(unitMachine.Parent().String(), "-") can be replaced with Parent() I think | 01:46 |
| thumper | babbageclunk: when did you want to chat? | 01:59 |
| babbageclunk | thumper: oh, now's good! | 01:59 |
| thumper | ok, | 01:59 |
| 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:04 |
| 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:05 |
| 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:06 |
| wallyworld_ | veebers: adding a machine does use creds to ask the cloud to spin up that vm | 02:07 |
| 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:08 |
| 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:09 |
| 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:10 |
| 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:11 |
| 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:12 |
| veebers | anastasiamac: aye, thanks. | 02:13 |
| 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:15 |
| 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:17 | |
| 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:18 |
| veebers | wallyworld_: right, and there is no option to use different creds when deploying something | 02:19 |
| wallyworld_ | nope | 02:19 |
| vino | wallyworld: sorry. I quickly went outside to have brunch. | 02:28 |
| vino | the parentId is machine-1 | 02:29 |
| vino | thats why i did that split. | 02:29 |
| vino | the func Parent returns this way machine-'x'. | 02:31 |
| anastasiamac | vino: there r build failures on 8991. m ahppy to review once they r resolved :) | 02:35 |
| 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:36 |
| 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:43 |
| wallyworld_ | rick_h_: ye, agreed, any local creds will work, but you must provide your own | 02:44 |
| anastasiamac | vino: no rush. m happy not to review :) just ping whenever it'll b ready | 02:45 |
| vino | wallyworld: i didnt chk the Parent().Id(). I am chking it now. | 02:55 |
| 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:05 |
| vino | hi thumper: I was looking at other window. | 03:11 |
| vino | thumper & wallyworld: agree. I have verified with Parent().Id() as well. I missed to look at it. | 03:12 |
| 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:24 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:30 |
| 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:31 |
| 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:33 |
| 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:34 |
| 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:35 |
| 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:36 |
| 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:41 |
| 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:43 |
| wallyworld_ | if we need to | 03:44 |
| anastasiamac | m in today's one | 03:44 |
| veebers | omw | 03:44 |
| 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. | 03:48 |
| wallyworld_ | vino: sorry, been tied up, looking now | 04:05 |
| vino | sure wallyworld_ nws. | 04:05 |
| wallyworld_ | lgtm ty | 04:05 |
| 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:23 |
| vino | thx wallyworld_ | 04:31 |
| wallyworld_ | np | 04:31 |
| babbageclunk | ugh, of course the uniter API facades are still using the old registration signature. | 05:55 |
| 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:18 |
| anastasiamac | vino: k. thnx | 06:24 |
| kelvin_ | wallyworld_, got a few minutes to discuss CRD? | 06:26 |
| wallyworld_ | ok | 06:26 |
| anastasiamac | vino: will look later on tonight - got hungry mouths to feed for now | 06:32 |
| vino | ya ya sure :) | 06:32 |
| === frankban|afk is now known as frankban | ||
| 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:53 |
| manadart | zeestrat: Ack. Thanks. | 07:55 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| === alephnull_ is now known as alephnull | ||
| zeestrat | Good to know | 08:30 |
| jamespage | morning folks | 08:45 |
| 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:46 |
| jamespage | hmm neither to the proposed streams | 08:47 |
| manadart | Review if anyone is inclined: https://github.com/juju/juju/pull/8992 | 10:15 |
| manadart | Ends up being a simple fix. | 10:15 |
| manadart | jamespage: You need to use the daily image stream. | 10:20 |
| jamespage | manadart: I thought juju only published proposed and stable streams? | 10:21 |
| manadart | jamespage: Ah, I mean when bootstrapping/adding machines. It worked for me when I used config image-stream=daily and --series=cosmic. | 10:24 |
| === frankban is now known as frankban|afk | ||
| 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:48 |
| rick_h_ | hml: eating lunch at the computer atm. Give me 10 or 15? | 18:49 |
| hml | rick_h_: sure | 18:49 |
| 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:02 |
| hml | rick_h_: manadart approved pr 8987, the cinder thing, did you want it manually tested by someone else before landing? | 19:31 |
| rick_h_ | hml: is that the one that needs a manual test? Did he test it then or just review it? | 19:43 |
| 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 | 19:44 |
| 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:00 |
| 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:01 |
| 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:02 |
| veebers | hml: nice! | 21:03 |
| 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:04 |
| hml | veebers: and pmatulis beat me to it | 21:05 |
| veebers | heh :-) | 21:06 |
| hml | wallyworld: ping. | 21:07 |
| wallyworld | hml: hey, otp in k8s call, give me 30 | 21:08 |
| hml | wallyworld: sounds good | 21:08 |
| wallyworld | hml:just finished, but release call starting. so maybe pop in there? | 21:29 |
| hml | wallyworld: omw | 21:29 |
| 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 | 21:34 |
| babbageclunk | Weirdly, it seems like things are mostly working with raft leases. | 22:19 |
| veebers | babbageclunk: yay \o/ | 22:19 |
| babbageclunk | no, spoke too soon... | 22:25 |
| veebers | /o\ | 22:26 |
| 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:32 |
| 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:35 |
| 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:36 |
| thumper | babbageclunk: ping | 22:44 |
| thumper | babbageclunk: ping | 22:44 |
| 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 | 22:45 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!