search

appsody / appsody-operator

An Operator for deploying Appsody based applications to Kubernetes. This repo will be archived soon.
Apache License 2.0
18 stars 15 forks source link

When running on OpenShift, add the openshift.io labels and annotations #175

Closed kylegc closed 4 years ago

kylegc commented 5 years ago

Feature Request

Is your feature request related to a problem?

Not currently, but OpenShift views and actions will not properly work with appsody projects without this.

Describe the solution you'd like

When the operator is running on OpenShift, it should add the standard openshift.io labels and annotations to its resources.

Some of the openshift.io labels and annotations can be found here: https://github.com/gorkem/app-labels/blob/master/labels-annotation-for-openshift.adoc https://github.com/openshift/source-to-image/blob/master/pkg/scm/git/types.go

The applied AppsodyApplication yaml should provide most of this information in alternate labels and annotations. It is expected that the openshift.io labels will duplicate some data.

edavidj commented 4 years ago

@kylegc could you elaborate on which labels/annotations from those links are required for Openshift views and actions to function? Is it all of them or just the recommended ones?

The list contains a few recommended labels and annotations that seem strange to infer without the user defining them, such as app.openshift.io/connects-to or apps.openshift.io/vcs-uri which define aspects of the user application rather than the stack itself. That said if they're needed we can set generic defaults and document that in the user guide.

kylegc commented 4 years ago

This request stemmed from an email from Chris Bailey (see below). The Openshift view we are targeting here is the Topology View.

I would focus on the first link (gorkem/app-labels). It classifies each label as required or optional (also pay attention to the tips!). We should strive to get all of the required labels added, and only add the optional ones if we can infer them from other labels.

For example, vcs-uri should be passed by appsody as image.opencontainers.org/source if it came from a github repository. If appsody doesn't add this label, you may have to leave this off or set a default like unknown.

connects-to is listed as optional, so it is okay to leave off for now. When Appsody has better support for service binding multiple microservices, we may need to readdress this one.

Email from Chris Bailey:

We already have some support for the new topology view labels on the roadmap for inclusion via the new labelling approach and the appsody-operator, for example, the new µservice binding approach is lined up to provide the app.openshift.io/connects-to label.

What we've outlined to set the following labels on the deployments:

Our approach is that we'll only set the OpenShift labels if running on OpenShift, and if those duplicate information we have elsewhere, we'll provide the OpenShift labels in addition to the "standard ones". (this does mean having more than one link to the Git source repo).

This means we are "independent", but integrate better with OpenShift if that's where we're running there (and as an open source project, we can happily consider adding cluster specific labels for other vendors if requested).

edavidj commented 4 years ago

Awesome, thanks for the info Kyle 👍 That sounds good to me, I'll take a look at what's currently set or relates to info otherwise available and set defaults where/if needed.