Skip to content
This repository has been archived by the owner on Mar 11, 2021. It is now read-only.

Use namespaces from tenant for Deployments API #2110

Merged
merged 4 commits into from
Jun 15, 2018

Conversation

ebaron
Copy link
Contributor

@ebaron ebaron commented Jun 7, 2018

Until now, the Deployments API has used the fabric8-environments config map to discover the environments belonging to a user. This config map is generated from a simple template [1], which would miss environments made available to the user via an organization (openshiftio/openshift.io#350).

This PR changes the Deployments API to detect environments using namespace information from the User Services controller, which is already used for our existing multi-cluster/proxy support. As a side-effect, this PR should mitigate intermittent issues stemming from this config map not being available (openshiftio/openshift.io#3556).

Fixes: openshiftio/openshift.io#3111

[1] https://github.com/fabric8-services/fabric8-tenant-team/blob/106ef4cb92dee51e0c7d09a5dbd7f96e2c7435f2/packages/fabric8-tenant-team/src/main/fabric8/fabric8-environments-cm.yml

@codecov-io
Copy link

codecov-io commented Jun 7, 2018

Codecov Report

Merging #2110 into master will increase coverage by 0.05%.
The diff coverage is 100%.

Impacted file tree graph

@@            Coverage Diff             @@
##           master    #2110      +/-   ##
==========================================
+ Coverage      69%   69.06%   +0.05%     
==========================================
  Files         162      162              
  Lines       15126    15113      -13     
==========================================
  Hits        10438    10438              
+ Misses       3739     3729      -10     
+ Partials      949      946       -3
Impacted Files Coverage Δ
kubernetes/deployments_kubeclient.go 72.61% <100%> (-0.66%) ⬇️
controller/deployments_urlprovider.go 47.72% <100%> (+6.47%) ⬆️
controller/workitem.go 79.41% <0%> (+0.62%) ⬆️
remoteworkitem/scheduler.go 60.97% <0%> (+7.31%) ⬆️
remoteworkitem/jira.go 100% <0%> (+25%) ⬆️

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update c1c44e6...0709b13. Read the comment docs.

@michaelkleinhenz
Copy link
Collaborator

We should split the Deployment controller services from the WIT. We're building a monolith here. The WIT is supposed to track Work Items, not act as a generic service implementation for all of OSIO.

@ebaron
Copy link
Contributor Author

ebaron commented Jun 8, 2018

@michaelkleinhenz Agreed. We are planning to move some shared utilities to a common repository under fabric8-services (openshiftio/openshift.io#3553), and creating a starter project to facilitate the creation of new backend services (openshiftio/openshift.io#3720). These efforts should make it easier to split deployment services (and possibly others) out of WIT.

}

func isInternalNamespace(envType string) bool {
internalTypes := []string{"user", "che", "jenkins"}
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

internalTypes could be a constant or a global variable initialized once for all.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Sure, I have now done this.

for envNS, attr := range up.namespaces {
envName := attr.Type
if envName == nil || len(*envName) == 0 {
return nil, errs.Errorf("namespace %s has no type", envNS)
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

should you return an error, or just log the error and keep iterating on the namespaces ?

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I have changed this method to log the error and continue. I have kept the severity as error, let me know if you think this should be lowered.

@joshuawilson
Copy link
Member

@xcoulon is this good now?

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants