OpenShift 3.11 support?

[hextrim]

Hi,
Does the latest release 0.8.x support 3.11?

Docs are out dated?

I may contribute to update docs... ?

Thanks,
Wojtek

[willthames]

I'm not an openshift expert, but I doubt there's much that ties us to specific versions (particularly now we have the dynamic client)

Certainly it works fine with kubernetes 1.11 and I'm not aware of a reason it wouldn't work with 1.13 or the upcoming 1.14

[fabianvf]

Yes, that is accurate, the dynamic client should work across the version matrix. It's currently tested from 1.10 to 1.13.

[hextrim]

Hi just tested it today on 3.11/1.11 and looks as this masterpiece works well.
Will try to create a kind: Template as this was my main concern if that would work?
No worries will find out soon.

[fabianvf]

Unfortunately templates are one of the only unsupported resource, as they violated a core assumption of discovery (that group-version-kind maps to one resource). It's on the backlog to fix this but it will take a little rearchitecting.

[hextrim]

@fabianvf
Oooh, does the native kubernetes python lib support kind:template's ?

Considering that creating new-app's from template is a preffered choice, I could argue its even intuitive way for auto-orchestration around OpenShift... Adding kind:template w options for parameters will take this lib to the next level.

Wish I could contribute at least a bit...

Think about it, meanwhile I will get use to it an try out its capabilities.

[fabianvf]

No, the base kubernetes library doesn't support any openshift specific resources as far as I'm aware. I definitely want to get this in in the next version or two, it's just a matter of finding the time.

[lucastheisen]

@fabianvf , I monkey-patched my openshift/dynamic/client.py to handle Template... By any chance, would you accept a PR for this:

624     def get(self, **kwargs):
625         """ Same as search, but will throw an error if there are multiple or no
626             results. If there are multiple results and only one is an exact match
627             on api_version, that resource will be returned.
628         """
629         results = self.search(**kwargs)
630         # If there are multiple matches, prefer exact matches on api_version
631         if len(results) > 1 and kwargs.get('api_version'):
632             results = [
633                 result for result in results if result.group_version == kwargs['api_version']
634             ]
635         # If there are multiple matches, prefer non-List kinds
636         if len(results) > 1 and not all([isinstance(x, ResourceList) for x in results]):
637             results = [result for result in results if not isinstance(result, ResourceList)]
638         if len(results) > 1 and 'kind' in kwargs and kwargs['kind'] == 'Template':
639             results = [result for result in results if result.singular_name == 'template']
640         if len(results) == 1:
641             return results[0]
642         elif not results:
643             raise ResourceNotFoundError('No matches found for {}'.format(kwargs))
644         else:
645             raise ResourceNotUniqueError('Multiple matches found for {}: {}'.format(kwargs, [result.__dict__ for result in results]))

Its clearly not ideal but would allow Template to work until the duplicate issue is resolved...

[lucastheisen]

Well, I just noticed that you release 0.9.0 yesterday... And the release notes say:

Templates and other resources where the Group/Version/Kind maps to multiple resources are now properly discovered

But the unit test still shows search returning multiple records, and get still throws ResourceNotUniqueException for that case, which makes means the ansible k8s module still wont work. Did I miss something?

[fabianvf]

No, it's fixed in the client (ie both template resources are discovered), and you can use client.resources.get as long as you use the resource name rather than (or in addition to) the kind, but the k8s module behavior will be unchanged. There's a nasty workaround where you can use templates or processedtemplates as the kind and the k8s module will find the resource properly. Unfortunately search returning multiple records is the correct behavior from the client's perspective, because there are multiple records for the Template kind, and you need more information than just group/version/kind to narrow it to an individual resource.

[lucastheisen]

@fabianvf , so that means the only correct path forward would be for the k8s ansible module to do a search first (before get) and then allow for differentiation using singular_name as well as kind (like my monkey patch)? Otherwise, get will just throw the exception and its too late for the k8s module...

[fabianvf]

@lucastheisen yes, I think a path forward would be to add a field to the k8s module that allows you to specify additional attributes to use when trying to find a resource. The k8s module would just have to add those attributes to its get call and that should work (get allows you to filter by name, singular name, short_name, etc, in addition to api_version and kind).

[lucastheisen]

I just tried the:

nasty workaround where you can use templates or processedtemplates as the kind and the k8s module will find the resource properly

But it didn't work:

   TASK [Create template] **********************************************************************************************************************************************************************************************************************************************
   Thursday 20 June 2019  16:08:18 +0000 (0:00:00.394)       0:00:02.317 *********
   fatal: [foo-dev]: FAILED! => {"changed": false, "msg": "Failed to find exact match for v1.templates by [kind, name, singularName, shortNames]"}

[willthames]

Not quite sure I understand this one - why aren't we doing exact matches (i.e just return template from a search for template, and need to specify processedtemplate to get processedtemplate)

we could optionally ensure we search for both singular and plural matches

[fabianvf]

The issue is that the Template resource violates the one GVK maps to one resource assumption (and it really shouldn't, most of the other openshift resources that did this have since been fixed). So kind: Template even with the API version is ambiguous

[willthames]

does kind: Namespace have a similar problem in openshift?

[willthames]

I've raised #310 for the bug with kind: namespace (the lower case n was the source of the bug that I hit, but it also surfaces the template confusion)

[lucastheisen]

The Template problem reported in this issue has been resolved by #333 ... Don't know if there is anything else holding this issue open, but for me, i no longer have any problems using with OpenShift 3.11.