fabric8io / osio-pipeline

DSL and utility functions in groovy for running Jenkins OSIO Pipeline
13 stars 17 forks source link

OSIO Pipeline: imagestream tagging for backing services fails. #68

Open sbose78 opened 5 years ago

sbose78 commented 5 years ago

I was testing a Node + DB CRUD booster https://github.com/sbose78/nodejs-rest-http-crud

The db was defined in .openshiftio/service.yaml

apiVersion: v1
items:
- apiVersion: v1
  kind: ImageStream
  metadata:
    annotations:
      openshift.io/generated-by: OpenShiftNewApp
    creationTimestamp: null
    labels:
      app: my-database
    name: my-database
  spec:
    tags:
    - annotations:
        openshift.io/imported-from: openshift/postgresql-92-centos7
      from:
        kind: DockerImage
        name: openshift/postgresql-92-centos7
      generation: null
      importPolicy: {}
      name: latest
      referencePolicy:
        type: ""
  status:
    dockerImageRepository: ""

While running the cd step which looked like this

cd {

    // override the RELEASE_VERSION template parameter
    def resources = processTemplate(params: [
        RELEASE_VERSION: "1.0.${env.BUILD_NUMBER}"
    ])
    def cm = loadResources(file: ".openshiftio/service.yaml")

    // performs an s2i build
    build resources: resources
    deploy resources: [resources,  cm], env: 'stage'
    deploy resources: [resources,  cm], env: 'run', approval: 'manual'
  }

..at the deploy step, the pipeline library tries to do a

oc tag -n usernamespace --alias=true usernamespace/my-database:1.0.1  my-database:1.0.1

which fails because the imagestream in the usernamespace doesn't exist. Only my node app's image stream exists in the usernamespace. The .openshiftio/service.yaml wasn't processed as part of build which is why the image stream doesn't exist.

Do you think allowing build to do something like build resources: [resources, cm] is a good idea? https://github.com/sbose78/osio-pipeline/blob/master/vars/build.groovy#L4

hrishin commented 5 years ago

@sbose78 yes let us try passing resources to build API as a workaround. However as a user, somehow I'm not convinced about how deploy handles the service resources and as a side effect tagImage still could fail.

We can consider a couple of options to deploy services: 1) Annotation based processing: If deploy finds service: true annotation in ImageStream, DC/Deploy in resources then it can process those in a certain way.

How to manage that annotation? As a user, do I need to care about it?

Yes, it can be added manually by user or processTemplate, loadResources (need investigation) API

2) Add/Create dependent resources (ImageStream for instance) if not present deploy API