Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Repo info
Activity
  • May 21 20:43
    MMajd commented #1505
  • May 21 20:39
    manusa commented #1511
  • May 21 20:39
    manusa commented #1511
  • May 21 20:38
    manusa commented #1511
  • May 21 20:36
    manusa commented #1511
  • May 21 20:34
    manusa commented #1511
  • May 21 20:33
    manusa commented #1511
  • May 21 20:33
    manusa commented #1511
  • May 21 20:31
    sonarcloud[bot] commented #1511
  • May 21 20:31
    manusa commented #1511
  • May 21 20:31
    manusa commented #1511
  • May 21 20:29
    manusa commented #1511
  • May 21 20:29
    manusa commented #1511
  • May 21 20:28
    manusa commented #1511
  • May 21 20:28
    manusa commented #1511
  • May 21 20:28
    manusa commented #1511
  • May 21 20:28
    manusa commented #1511
  • May 21 20:28
    manusa commented #1511
  • May 21 20:27
    manusa commented #1511
  • May 21 20:25
    manusa commented #1511
Noel O'Connor
@noeloc_twitter
I'm not sure if this is even possible with jkube
Noel O'Connor
@noeloc_twitter
never mind I figure it out...I added the skipResource=true on the parent and false on the modules
Rohan Kumar
@rohanKanojia
:+1:
Marc Nuri
@manusa
Hi Noel, regarding multi-module there are different approaches.
One of them should be to have a final module that collects the resources generated by the rest of the modules in the project.
This module should depend on the rest of the modules. The generated package should contain a YAML artifact with the collection of the rest of resources (jkube-dependency enricher).
One of the fuse examples works this way, I'll try to find a link for you.
Marc Nuri
@manusa
So in your https://github.com/noelo/istio-demo you could have a final module uber-yml;P that would depend on the rest of modules that do generate YAMLs. This module should collect the resources generated by the rest. Here you could add for example the helm goal execution so that a single chart was produced.
Noel O'Connor
@noeloc_twitter
excellent, a single chart was exactly what I was hoping for, I'll try it out but if you find that fuse example I'd appreciate it, it's not in the quickstarts as far as I can see....
Marc Nuri
@manusa
I couldn't find it.
There's an internal issue that has a sample reproducer project
Noel O'Connor
@noeloc_twitter
no worries, you've set me on the right path so I'll try it out anyway...cheers
Marc Nuri
@manusa
:thumbsup:
robinroos
@robinroos
OpenJDK 17 has been released. Once the necessaru UBI is in place do I merely have to set maven.compiler.source and maven.compiler.target to get an OpenJDK 17 image?
Rohan Kumar
@rohanKanojia
I think we need to discuss how we're going to provide jdk17 based images. Maybe what you're suggesting would be our approach. We'll check project's jdk and switch base image based on that. I would appreciate if you could open an issue where we can discuss this.
Marc Nuri
@manusa
The plan is to provide a JDK17 compatible base image once the package is out.
(and we release 1.5)
Rohan Kumar
@rohanKanojia
Someone from Kogito team also pinged me today regarding release of 1.5.0
Marc Nuri
@manusa

If you provide your own, then

maven.compiler.source and maven.compiler.target to get an OpenJDK 17 image?

Yes, that's enough

Rohan Kumar
@rohanKanojia
They were migrating from fabric8-maven-plugin to jkube and bumped into eclipse/jkube#815
Marc Nuri
@manusa
1.5 should be released before the 21st of October
Rohan Kumar
@rohanKanojia
cool, Thanks.
Marc Nuri
@manusa
Our base image can be upgraded before, but won't be part of 1.5. You could use that base image with earlier versions of JKube by overriding: jkube.generator.from
robinroos
@robinroos

I'm having some difficulties getting a docker image pushed to our local Nexus. Despite my configuration, the push is to "docker://myimagename:latest".

I have the following property settings in force (declared as maven property elements, but shown below as name=value):

jkube.build.buildOutput.kind = DockerImage
jkube.docker.registry = my.nexus.com:8443/repository/MyProject-Docker
jkube.build.pushSecret = my-nexus
jkube.build.switchToDeployment = true
jkube.build.strategy = docker

It would appear that the jkube.docker.registry value is being ignored.

32 replies
Christian-dev-ops
@Christian-dev-ops
hello guys, how to can use Jkube the the mechanisms Kubernetes uses to control resources such as CPU and memory?
Example: resources:
requests:
memory: "64Mi"
cpu: "250m"
limits:
memory: "128Mi"
cpu: "500m"
Rohan Kumar
@rohanKanojia
For now, I think we only support adding a deployment.yaml fragment with custom requests/limits in src/main/jkube
I can't see any field in resource configuration related to requests/limits
We do have requests/limits configuration field for S2I builds(applicable to OpenShift only) https://github.com/eclipse/jkube/blob/master/jkube-kit/config/resource/src/main/java/org/eclipse/jkube/kit/config/resource/OpenshiftBuildConfig.java . Maybe we can add similar resources configuration field in ResourceConfig class also?
Marc Nuri
@manusa
Starting release process for Eclipse JKube 1.5.0
Marc Nuri
@manusa
Starting release process for Eclipse JKube 1.5.1
Marino Borra
@mborra
Hi everyone, I have a need, which I thought to solve with profiles and fragments, I would like to generate different kubernetes.yaml for different environments (local-dev, dev, remote-dev, ...) I would like to use the fragments for the common parts and use the profiles with different directories, I also did different Maven execution, but even setting different profiles I get different kubernetes.yaml in different directories but which are in fact the same and are a mix of all the profiles. I may not have understood how multiple profiles associated with directories and with common fragments work.
12 replies
Zoran Regvart
@zregvart

I'm trying to migrate from Fabric8 Maven Plugin to OpenShift Maven Plugin, what we had working with FMP was a Docker based build with a Dockerfile and an inline assembly to add more files outside of the context. This is our configuration using FMP: https://github.com/syndesisio/syndesis/blob/c5362115c7adb09190059ed7dbb76a347e767d60/app/ui-react/pom.xml#L326-L360.
With JKube an attempt to use docker buildStrategy with a Dockerfile and an inline assembly leads to exception:

Failed to execute the build: Unable to build the image using the OpenShift build service: This image has already been flattened, you can only flatten the image once

It seems that AssemblyConfiguration::getFlattenedClone is called twice in this case: once from OpenshiftBuildService::build and subsequently from AssemblyManager::getAssemblyConfigurationForDockerfileMode.
At this point I'd like to explore if there is a way to achieve a docker based OpenShift build with Dockerfile and additional files outside of the context with OpenShift Maven Plugin.
I've found that including the empty <assembly> in this constelation triggers the issue, for example this will fail:

<plugin>
  <groupId>org.eclipse.jkube</groupId>
  <artifactId>openshift-maven-plugin</artifactId>
  <executions>
    <execution>
      <id>default-cli</id>
      <phase>package</phase>
      <goals>
        <goal>build</goal>
      </goals>
      <configuration>
        <skipBuildPom>false</skipBuildPom>
        <buildStrategy>docker</buildStrategy>
        <images>
          <image>
            <name>test</name>
            <build>
              <dockerFile>${basedir}/docker/Dockerfile</dockerFile>
              <assembly />
            </build>
          </image>
        </images>
      </configuration>
    </execution>
  </executions>
</plugin>
Rohan Kumar
@rohanKanojia
Which version of jkube are you using?
Rohan Kumar
@rohanKanojia
Do you have your branch somewhere where you have with migrated to jkube configuration?
Zoran Regvart
@zregvart
We're migrating to version 1.5.1. This is what I landed on as a workaround: https://github.com/syndesisio/syndesis/blob/c156d086682bd99101d10ba47d0b75b7f2f104e5/app/ui-react/pom.xml#L328-L354 so no inline assembly, but now I have a symlink from the context (where the Dockerfile is) to the directory I wanted to include. The above snippet reproduces the issue, i.e. just adding an empty <assembly /> triggers this case.
Marc Nuri
@manusa
I'm really not following, but it should be possible to port the original config, there's nothing strange in it.
Assemblies can now provide information for multiple layers (<inline> ---> <layers><layer><!-- ... --></layer></layers>). The get Flattened cloned basically combines/merges all of those layers, but shouldn't break anything.
I'll give it a try tomorrow.
Marc Nuri
@manusa
It seems like when we implemented the multi-layer support we didn't account for the OpenShift+Dockerbuild+Dockerfile+AssemblyConfig scenario. I will further investigate and open the corresponding bug.
2 replies
robinroos
@robinroos
I set <maven.compiler.release> to 17 today; jkube seems still to be pushing a Java 11 image (I might have done something wrong on my side). Is the jkube OpenJDK 17 base image available yet?
Rohan Kumar
@rohanKanojia
No, it still needs to be done: eclipse/jkube#1106
If you need it urgently, you can use your own image based on JDK 17 for now. It can easily be configured via jkube.generator.from or via XML configuration
javastl
@javastl
I would like to know how Jkube can be configured to add this statement to the dockerfile "FROM ubuntu:20.04"
Rohan Kumar
@rohanKanojia
It can be done via jkube.generator.from property
Or use your own Dockerfile or XML image configurationhttps://www.eclipse.org/jkube/docs/kubernetes-gradle-plugin#groovy-scenario-image
javastl
@javastl
Right now I am using maven and the from property is used by java with <configuration>
<images>
<image>
<name>${docker.user}/random-generator:${project.version}</name>
<build>
<from>openjdk:11</from>
If I replace with ubuntu:20.04, java is not found
Rohan Kumar
@rohanKanojia
What do you mean by java? Do you mean the java CLI is not found in container?
It could be due to java not being setup on that specific image
javastl
@javastl
This is the current dockerfile that is output that works
This line in the pom assembly has no effect <jkube.generator.from>ubuntu:20.04</jkube.generator.from>