Note: This bug is displayed in read-only format because the product is no longer active in Red Hat Bugzilla.

Bug 1357061

Summary: RFE: Openshift Installer (BYO): Make adding different types of identity providers easier to the inventory file
Product: OpenShift Container Platform Reporter: Matt Woodson <mwoodson>
Component: apiserver-authAssignee: Erica von Buelow <evb>
Status: CLOSED WONTFIX QA Contact: Chuan Yu <chuyu>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 3.2.0CC: aos-bugs, jokerman, mmccomas, nraghava, scuppett
Target Milestone: ---Keywords: OpsBlocker
Target Release: 4.1.0   
Hardware: Unspecified   
OS: Unspecified   
Whiteboard:
Fixed In Version: Doc Type: If docs needed, set a value
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2018-12-03 12:50:39 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Embargoed:

Description Matt Woodson 2016-07-15 15:26:46 UTC 
Description of problem:

Let me preface this by saying this isn't an easy issue to solve. But this is one that I would like to get some improvements on. It would help Openshift Ops quite a bit.

The current problem:

We are using the BYO inventory file to configure a lot of clusters with all sorts of authentication schemes. There is one variable to configure all of these:

openshift_master_identity_providers

Then, we need to set this var as a json dict. There are multiple problem with this:

-there is no good examples with all of the different supported auth types (at least I couldn't find them)

- the auth types don't have all of the options documented.
(https://gist.github.com/detiber/da042623b26522fcd5767825eafe97a0 as an example)

- the dictionaries that are needed do NOT line us with official docs of the auth type. What i mean by this, we pass in a dictionary of values that are then put in the right place in the yaml code by the byo. For example, I can't look at https://docs.openshift.com/enterprise/3.2/install_config/configuring_authentication.html and come up with what the json dictionary should be.

- each dictionary takes different options depending on the auth type.

- the dictionaries are hard to read

- not all options in the dict are needed. It's hard to know what is, what isn't. It would help if this was lined up with documents.
Comment 1 Matt Woodson 2016-07-15 15:27:33 UTC 
This originally filed here:

https://github.com/openshift/openshift-ansible/issues/2083

I would like to brainstorm on the possible outcome. I would love to hear other's thoughts.

Here is one of the suggestion that could help solve the issue. Take this for what it's worth.

What if a variable was added like:

openshift_master_identity_type=

This would be one of the types of id that openshift supports. It could be "google", "github", "openid", "htpasswd", etc...

Then, there would be a list of required or variables that go with each provider type. I would envision each type having it's own set of variables that are needed. If the option isn't required, the byo should handle that appropriately. For example, if

openshift_master_oauth_type=google

We would then have other variable that are used:

openshift_master_oauth_google_provider_clientID=
openshift_master_oauth_google_provider_clientSecret=
openshift_master_oauth_google_provider_hostedDommain=

There could be oauth level ones that map accross all types of auth. For example, the higher level ones could be something like:

openshift_master_oauth_mappingMethod=lookup

This could be documented fairly easily. We could add additional variables based on the oauthConfig found in the docs and in the config file.

I think this would be much easier than the existing dictionary. This would also line up with what is in the docs and follow the oauthConfig dictionary found in the master-config.yml.
Comment 2 Matt Woodson 2016-07-15 15:41:44 UTC 
@detiber  If you could have a simple version that worked for a handful of auth providers, I would support that.  But when we start jamming in data structures into a single variable, in my opinion that loses it's simplicity.  I am not against providing  something simple, but I do want the flexibility to put in something.

I'd be ok with being able handing over a "final configuration chunk", something that the final output would like in master-config.yml, and then you put it in place as one of the auth types.  We could store our auth  variables in yaml at that point, hand them to the installer, and just have it do the right thing.  Then you could keep a simple and have this way be the "advanced" config.  

Hmm, the more I think about this, the more I like this.  The advantages are:

- we could use official documentation for the right variables.  We wouldn't have to guess how they will be interpreted and then converted
- we could use this to check against the master config  with config management.
- it should be easy for you, and then not have to write all sorts of different variables for different advanced auth types, and maintain them.  It's just pure yaml.

I like this this idea, thoughts from you guys?