apiVersion is ignored by resource and apply goals about jkube HOT 25 CLOSED

@tipame : Are you using OpenShift templates in your project?

Sorry, I got confused with your CustomResourceDefinition naming.

Could you please share directory contents of fragment folder? I don't think you need to provide any additional configuration for CustomResources. Our E2E test with CRD seems to be passing.

from jkube.

@rohanKanojia you mean to attach generated resources?
jkube.zip

from jkube.

@tipame : No, I didn't mean that. Is it possible to share a simple reproducer project?

from jkube.

@tipame : I tried reproducing your issue but could not reproduce it. I copied the CustomResourceDefinition and CustomResource fragments into src/main/jkube folder unchanged. For me, CustomResourceDefinition and CustomResource seem to get applied okay. Could you please check my reproducer project to see if I missed something here jkube-customresource-fragments?

from jkube.

@rohanKanojia

1. You have no file mapping for custom Template. Actualy there is no way to set mapping in this case - cause thre is no tag for apiVersion (only kind and filenameTypes).
2. I have no errors applying config, but resource with "kind: Template" simply ignored. In maven log there is no entry like:
   Created Custom Resource: my.unique.group/v1alpha1#Template my-namespace/my-example
   As a result no object is created in kubernetes

Also should mention: work fine with other CRD (with kind: Trigger for example)

from jkube.

I'm not able to understand why you need to add a mapping. I tried running k8s:resource k8s:apply and I was able to see an entry like this:

[INFO] --- kubernetes-maven-plugin:1.13.1:apply (default-cli) @ jkube-customresource-fragments ---
[INFO] k8s: Using Kubernetes at https://192.168.39.103:8443/ in namespace null with manifest /home/rokumar/work/repos/jkube-testing/jkube-customresource-fragments/target/classes/META-INF/jkube/kubernetes.yml 
[INFO] k8s: Creating a Service from kubernetes.yml namespace default name jkube-customresource-fragments
[INFO] k8s: Created Service: target/jkube/applyJson/default/service-jkube-customresource-fragments-2.json
[INFO] k8s: Creating a Custom Resource Definition from kubernetes.yml name templates.my.unique.group
[INFO] k8s: Created Custom Resource Definition result: templates.my.unique.group
[INFO] k8s: Creating a Deployment from kubernetes.yml namespace default name jkube-customresource-fragments
[INFO] k8s: Created Deployment: target/jkube/applyJson/default/deployment-jkube-customresource-fragments-2.json
[WARNING] The client is using resource type 'templates' with unstable version 'v1alpha1'
[INFO] k8s: Created Custom Resource: my.unique.group/v1alpha1#Template my-namespace/my-example
[INFO] k8s: HINT: Use the command `kubectl get pods -w` to watch your pods start up
[INFO] ------------------------------------------------------------------------
[INFO] BUILD SUCCESS
[INFO] ------------------------------------------------------------------------
[INFO] Total time:  7.229 s
[INFO] Finished at: 2023-06-20T13:18:40+05:30
[INFO] ------------------------------------------------------------------------
jkube-customresource-fragments : $ kubectl get template -n my-namespace
NAME         AGE
my-example   56s
jkube-customresource-fragments : $ 

from jkube.

Could your issue be due to your mapping colliding with default mapping for OpenShift Template? See kind-filename-type-mapping-default.adoc

from jkube.

Main bug (apply goal) seams to be fixed in 1.13.1 (my plugin version was 1.6.0). Now resource is aplied.
About maping:
Imagine we have two CRD:

apiVersion: my.unique1.crd/v1alfa1
kind: Template
apiVersion: my.unique2.crd/v1alfa1
kind: Template

There is no way to set two differend mapings for this resources.
In my case it colliding with default mapping (as you mention).

from jkube.

Maybe you don't need a mapping at all. Just provide the name without the -$mapping.yaml suffix.

from jkube.

Maybe you don't need a mapping at all. Just provide the name without the -$mapping.yaml suffix.

all files in my project have names like: xxx-yyy-$mapping.yaml
renaming it to xxx-yyy.yaml result to error:
Unknown type 'yyy' for file xxx-yyy.yaml. Must be one of : pr, lr, pv, project, replicaset, cronjob

from jkube.

I think CustomResource fragments need to have -cr.yaml suffix

from jkube.

I think CustomResource fragments need to have -cr.yaml suffix

Forgot about that one :(. This is definitely something to improve.

Then having xxx-yyy-cr.yaml should work without the need for a mapping 🤞 .

from jkube.

I think CustomResource fragments need to have -cr.yaml suffix

Forgot about that one :(. This is definitely something to improve.

Then having xxx-yyy-cr.yaml should work without the need for a mapping 🤞 .

Yep "cr" suffix works! Thank you. Have no more question.

from jkube.

@tipame : Do you have some feedback on how we can improve this in documentation?

from jkube.

Back agan: "cr" = ClusterRole )))
If i use "cr" suffix without setting kind property in XML it's generated to ClusterRole...

In my opinion - there was a future to auto complete XML configuration base on filenaming:
I can ommit "apiVestion", "kind" and "name" properties and they should be generated based on mapings.
Since i can't set apiVersion in custom maping -> it always generated to "v1" (not what i want).

from jkube.

This is definitely a bug we need to tackle ASAP.

from jkube.

Hi @tipame
The current 1.14-SNAPSHOT should contain the fixes to allow for all of your expected behaviors.

Could you please try out the snapshot and confirm that everything is working for you as expected?

from jkube.

Hello @manusa, how can i specify apiVersion in a fixed branch?

from jkube.

@tipame : Marc is asking you to do this:

1. Enable pulling jkube snapshot repositories in pom:

  <pluginRepositories>
    <pluginRepository>
      <id>oss.sonatype.org</id>
      <url>https://oss.sonatype.org/content/repositories/snapshots</url>
      <snapshots>
        <enabled>true</enabled>
        <updatePolicy>always</updatePolicy>
      </snapshots>
    </pluginRepository>
  </pluginRepositories>

2. Update OpenShift Maven Plugin to use 1.14-SNAPSHOT:

            <plugin>
                <groupId>org.eclipse.jkube</groupId>
                <artifactId>openshift-maven-plugin</artifactId>
                <version>1.14-SNAPSHOT</version>
            </plugin>

3. Test whether you get desired behavior by updating version

from jkube.

Question about apiVersion (see isue description), not about maven.
Expect something like:

<mapping>
  <apiVersion>my.unique.crd/v1alfa1</apiVersion>
  <kind>Template</kind>
  <filenameTypes>my_template</filenameTypes>
</mapping>

from jkube.

Question about apiVersion (see isue description), not about maven. Expect something like:

<mapping>
  <apiVersion>my.unique.crd/v1alfa1</apiVersion>
  <kind>Template</kind>
  <filenameTypes>my_template</filenameTypes>
</mapping>

This is not possible at the moment. I did see it as something that would be useful when implementing the IT tests (https://github.com/eclipse/jkube/tree/e116ca23a6526a5498e38b20c55f4c755339c055/gradle-plugin/it/src/it/fragments-custom-mapping).

I think we can definitely add this since it makes much sense when working with CRs and other APIs.

from jkube.

So i do not undestand what should i test? If there is still no way to specify apiVersion - conflict is still here. You just change overriding order (my custom mapping will have bigger priority then deffault)?

from jkube.

So i do not undestand what should i test? If there is still no way to specify apiVersion - conflict is still here. You just change overriding order (my custom mapping will have bigger priority then deffault)?

From the issue description it was unclear you were actually requesting to include apiVersion as part of the custom mappings configuration. It is much clearer now (currently working on that, will probably be available on tomorrow's SNAPSHOTs -I'll keep this issue posted-).

What's fixed right now is the possibility to use your Mappings to override the default ones (yes priority override). And the overall way resources are applied. The previous -cr.yml suffix was a hack and not an actual feature.

from jkube.

Hi @tipame
With the latest PR everything you mentioned should be covered. You should be able to test this once the nightly build SNAPSHOTs are published.

from jkube.

Closing this issue as it should be already fixed. Please re-open or create a new one in case there are problems remaining.

from jkube.