Put the openshift directory in the code repository

[serverhorror]

Is your feature request related to a problem? Please describe.

Every project we are working has had to make modifications to openshift/*.yaml

Modify the priviosing app to put the templates from the openshift/* directory directly in the code that is being provided as boilerplate.

Describe the solution you'd like

We had t repeatedly explain the same situation to users:

• How do you export the currently deployed OpenShift templates
• How to revert the modifications so that, instead of the fixed strings, the template strings are used again
• How/Where to get the "original" templates for a given quickstarter

Our perception is that abstracting/hiding the OpenShift templates to the point where they are now is a tad too much. People would like to see most of the code that is being used to deploy their applications.

Describe alternatives you've considered

none -- that's our only idea

Additional context

none

[michaelsauter]

@serverhorror Thanks for the suggestion!

I really really would like to enforce that everyone has to define their infrastructure as code. Relying on a magic export (release manager) is not a good way to develop your software. So yes, I totally agree. BUT putting the templates into the repo has the effect that suddenly everyone is forced to modify their resources in the repo, instead of clicking around in OpenShift. While technically this is fine, we need to ensure everyone who has a say in this is happy to force all users to do that. Maybe we can survey existing projects to see if many of them define the OpenShift templates?

A middle ground would be to add an option to the prov app to allow people to "opt out" of templates maybe?

Further, we could potentially wait a little longer, and once we have full support for Helm (if that turns out to be a good way going forward), to start with shipping Helm charts with new components.

FYI @metmajer @clemensutschig @henrjk

[henrjk]

A provisioning app option would be nice especially if the default would be to use infrastructure as code.

Without such an option, provisioning could enable infrastructure as code by generating the openshift folder. In cases where this is not wanted follow up changes would be needed to delete the openshift folder with the templates or move them in a different place so they are no longer automatically found. I suppose there would be some other follow up changes needed such as defining triggers for example. These changes would leave a commit trail which I find quite nice.

I would not find this too burdensome, but others may have a different opinion.

[serverhorror]

BUT putting the templates into the repo has the effect that suddenly everyone is forced to modify their resources in the repo, instead of clicking around in OpenShift

Minor note: So far, we've only run into trouble because people were able to click around in the first place. As a goal I'd even like to see that everyone is restricted to read-only access rather than being able to modify via the UI.

Of courses that poses a catch-22, how would one manually clean up after a fat-fingered deployment so I guess that the OpenShift UI will stay as RW for users.

[serverhorror]

Further, we could potentially wait a little longer, and once we have full support for Helm (if that turns out to be a good way going forward), to start with shipping Helm charts with new components.

Excellent point! But since ODS w. helm still needs to support the "old ways" I'm not sure that waiting will provide huge benefit (that is if it means that the "org internal" rollouts will have to wait for ODS5 or even longer to get that feature)

[michaelsauter]

So far, we've only run into trouble because people were able to click around in the first place. As a goal I'd even like to see that everyone is restricted to read-only access rather than being able to modify via the UI.

You're preaching to the choir :)