Rebuild latest docker image

[dmetzler]

It seems that epel-testing introduction has been integrated into apb-base:latest

The commit has been reverted but not integrated into the latest image which leads to anomaly on APBs base on it.

For future reference, here are the errors I encountered:

• 'ascii' codec can't decode byte 0xe2 in position 5091: ordinal not in range(128)" when lookup on file that contains non ascii chars
• Statefulset lookup returning incomplete information (Ready information missing)

[djzager]

Interesting. The latest version of Ansible (2.6) has been moved to epel that was the reason for the revert (and why I had avoided the change for all but a workday). Does this scenario go away by simply rebuilding apb-base from Dockerfile-latest (where Ansible is only installed from epel)?

@jmontleon do you have any thoughts on this?

[dmetzler]

I don't build the docker images by myself. I only use the docker.io repository. Aligning on tag sprint-150 solved my problem.

[djzager]

The difference between packages in apb-base:latest and apb-base:sprint150:

- python2-openshift-0.5.0.a1-6.el7.centos.noarch
+ python2-openshift-0.6.1-10.el7.noarch

- perl-Git-1.8.3.1-13.el7.noarch
+ perl-Git-1.8.3.1-14.el7_5.noarch

- ansible-2.5.5-1.el7.noarch
+ ansible-2.6.0-1.el7.noarch

- git-1.8.3.1-13.el7.x86_64
+ git-1.8.3.1-14.el7_5.x86_64

Based on this, I don't believe that your issue will go away when a new apb-base:latest is built. The sprint150 tag is using older Ansible and no dynamic python client for Openshift (coming from 0.6.1 in latest).

[dmetzler]

Ok, the problems certainly come from 0.6.1. Do you want me to provide a sample apb where I have the problem?

It seems linked to the lookup directive. For instance, the query that we have here never returns true:

https://github.com/nuxeo-sandbox/nuxeo-apb-catalog/blob/master/nuxeo-mongodb-apb/vars/main.yml#L18

status.ready_replicas is always evaluated to None.

[djzager]

Short answer, you'll need to update https://github.com/nuxeo-sandbox/nuxeo-apb-catalog/blob/master/nuxeo-mongodb-apb/vars/main.yml#L11 -- and anywhere else where the kind not in the v1 apiVersion -- to look like:

statefulset_lookup: "{{ lookup('k8s', api_version='apps/v1', kind='StatefulSet', namespace=namespace, resource_name=name) }}"

Longer answer:

One of the frustrating parts about Ansible < 2.6 and our generated openshift client was that you couldn't simply do, taken from your stateful set jinja template:

- name: Create a Service object from an inline definition
  k8s:
    state: present
    definition:
      apiVersion: apps/v1
      kind: StatefulSet
      metadata:
        labels:
          app: {{ name }}
          apb_name: '{{ apb_name }}'
          apb_plan_id: '{{ _apb_plan_id }}'
          apb_service_class_id: '{{ _apb_service_class_id }}'
          apb_service_instance_id: '{{ _apb_service_instance_id }}'
          component: {{ component }}
        name: {{ name }}
        namespace: {{ namespace }}
      spec:
        ...

Essentially, just taking the YAML definition of a k8s object + giving it to the Ansible k8s module. This leads to workarounds like this one you have to create a stateful set. You could have been using k8s_raw in Ansible 2.5, the only significant difference would be the apiVersion (would be v1) since it was using the generated clients. In Ansible 2.6, with the dynamic OpenShift client, the apiVersion and kind are essential for the client to know where to send the request to the kubernetes API server. So I would encourage you to make use of the Ansible 2.6 k8s modules, you'll just need to be mindful of the apiVersion and kind.

Hope that helps.

[dmetzler]

Ok, thanks a lot for taking the time to understand our problem. We are in the process of finalizing our APBs. I will schedule a task to migrate to Ansible 2.6 as it seems more usable. Closing the ticket for now