Closed smn closed 6 years ago
@obmarg as you'll see I've made some changes to .travis.yml, it was complaining about mix format errors which only apply for 1.6.0. I stuck it on 1.6.4 is simply because that's the version I'm on. Not sure what a recommended route would be to go about fixing this, perhaps a build matrix which allows 1.6.0 to fail for formatting errors?
Thanks a lot for the PR Simon. I’ve worked with GKE before and wondered when I’d have to add support for it to Kazan. Really glad you’ve taken care of that.
Just to let you know, I’m away on holiday right now and may not get to reviewing this till I’m back at the end of the month. On Thu, 21 Jun 2018 at 15:11, Simon de Haan notifications@github.com wrote:
@obmarg https://github.com/obmarg as you'll see I've made some changes to .travis.yml, it was complaining about mix format errors which only apply for 1.6.0. I stuck it on 1.6.4 is simply because that's the version I'm on. Not sure what a recommended route would be to go about fixing this, perhaps a build matrix which allows 1.6.0 to fail for formatting errors?
— You are receiving this because you were mentioned.
Reply to this email directly, view it on GitHub https://github.com/obmarg/kazan/pull/48#issuecomment-399081958, or mute the thread https://github.com/notifications/unsubscribe-auth/AAh9yheY83RHqHXcBa4hr8vklnbZkP3Lks5t-41WgaJpZM4Ux3bD .
@obmarg cool, no worries. I'll be installing things from my fork in the mean time.
@obmarg I think your option 2 is most reasonable.
Perhaps making the fact that some arbitrary code is being called explicit is enough? Instead of shipping something that works out of the box perhaps forcing a setup step in config/*.exs
is enough to make the user aware of it happening? Then you could ship a GCP specific resolve_token
function but require that the user configure things themselves, assuming that that would make them aware of what's happening in the background?
Yeah, I think so long as we make users take an explicit extra step I'd be happy. We could even name the GCP specific function so as to make it obvious we're running an external program: execute_auth_provider
or something?
How does kubectl address this security concern? Maybe kazan should follow what kubectl does?
How does kubectl address this security concern? Maybe kazan should follow what kubectl does?
I believe kubectl just executes whatever is in the config file (at least I don't remember having to take any explicit steps when running kubectl on GCP clusters, beyond the initial setup).
I've not forgotten about this PR, just not been able to prioritise it yet.
Oops, hit the wrong button there. Did not mean to close.
@smn no rush at all, just whenever you have time. Also, if you'd like me to handle any of it just let me know.
@obmarg more than happy for you to take a stab if you have a gap
Thanks again for the PR @smn - I've ended up pushing a modified version of this up in 3c3e5cbb3, so I'm closing this.
If you get a chance to test anytime that'd be great - I don't have access to a GKE cluster to do it myself right now.
👌👍
On Saturday, August 25, 2018, Graeme Coupar notifications@github.com wrote:
Thanks again for the PR @smn https://github.com/smn - I've ended up pushing a modified version of this up in 3c3e5cb https://github.com/obmarg/kazan/commit/3c3e5cbb3dd7e02aae83637b98e17232d4a69422, so I'm closing this.
If you get a chance to test anytime that'd be great - I don't have access to a GKE cluster to do it myself right now.
— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/obmarg/kazan/pull/48#issuecomment-415971694, or mute the thread https://github.com/notifications/unsubscribe-auth/AAAEKYqdCOPANp23PbPk7xK9TTxCaPi0ks5uUVolgaJpZM4Ux3bD .
-- Simon de Haan | Praekelt.org
Praekelt.org M: +31 (0) 6 227 85389 | http://twitter.com/smn
GCP uses a gcloud for auth an dynamically generates a token in order to access hosted K8s clusters. This PR adds support for that.
Please let me know if there's anything you'd suggest I change.