text:
kamelet binding : camel controller fail reconcile the kafka sink resource.

What is observed:
Strimzi Kafka cluster and Camel controller are installed and healthy.
KafkaTopic: my-topic is created an healthy.
The KameletBinding minio-resource is submitted to the cluster.
The minio-source-binding is created but stay in pending state.

Kubernetes ressource satus

  Type     Reason        Age                   From                                Message
  ----     ------        ----                  ----                                -------
  Warning  KameletError  6m50s (x20 over 45m)  camel-k-kamelet-binding-controller  Cannot reconcile KameletBinding minio-source-binding: could not determine sink URI: the server could not find the requested resource (get kafkas.kafka.strimzi.io my-cluster)

camel-controler pod log:
{"level":"error","ts":1627235132.8817902,"logger":"controller-runtime.manager.controller.kamelet-binding-controller","msg":"Reconciler error","name":"minio-source-binding","namespace":"kafka","error":"could not determine sink URI: the server could not find the requested resource (get kafkas.kafka.strimzi.io my-cluster)","errorVerbose":"the server could not find the requested resource (get kafkas.kafka.strimzi.io my-cluster)\ncould not determine sink URI ....

To reproduce :
Software & releases

Minikube Kubernetes 1.20.2
Private docker  local registry.
Kafka 2.8.0 kafka:my-cluster installed with strimzi operator in namespace kafka (plain text and no authentication)
Camel-k operator 1.5.0 installed with helm in namespace kafka.

What is expected:
Have the minio-source-binding resource created and in healthy state.
As I was suspecting some authorizations issueI, I  modified the camel controler RBAC  to a cluster role without any improvments.

Additional set-up infoamtions.
Camel-k installation configuration
helm install \
  --namespace kafka \
  --set platform.build.registry.address=192.168.1.40:45000 \
  --set platform.build.registry.insecure=true \
  --set platform.profile=kubernetes \
  --set plateform.cluster=kubernetes \
  --generate-name \
  camel-k/camel-k

KameletBinding  spec.
apiVersion: camel.apache.org/v1alpha1
kind: KameletBinding
metadata:
  name: minio-source-binding
  namespace: kafka
spec:
  source:
    ref:
      kind: Kamelet
      apiVersion: camel.apache.org/v1alpha1
      name: minio-source
    properties:
      accessKey: -----------
      bucketName: test
      endpoint: "http://minio2.kafka:9000"
      secretKey: ----------
  sink:
    ref:
      kind: KafkaTopic
      apiVersion: kafka.strimzi.io/v1beta1
      name: my-topic

KafkaTopic spec.
apiVersion: kafka.strimzi.io/v1beta2
kind: KafkaTopic
metadata:
  name: my-topic
  namespace: kafka
  labels:
    strimzi.io/cluster: my-cluster
spec:
  partitions: 1
  replicas: 1
  config:
    retention.ms: 7200000
    segment.bytes: 1073741824

I tested also topics created with v1beta1 api : same behavior of camel-k operator which is not able to query kafka cluster resources. In fact since stimzi operator 0.23 even if it accept the creation of resources (topics and users) with v1beta1 api they are managed  as v1beta2.
Re-tested on a new strimzi cluster version 0.22 : it works as expected.
Latest version of kafka that are managed by strimizi 0.23+ should require an update of camel-k strimzi api.

This recent commit I just discovered  should address it https://github.com/apache/camel-k/commit/ec840637294200f593ca3e8fcf9c9dae5ac20109

repo: apache/camel-k


text:
Remove KEP cryptic message when installing

Warning: the operator won't be able to detect a local image registry via KEP-1755 message can be ignored most of the time but it can create a false sense of alarm to the user. We should either remove the message or provide a more meaningful message.

Agreed. Maybe on TRACE level and remove the "warning"

Can I work on this? I don't know which file to change though

Can I work on this? I don't know which file to change though

Sure. I guess you can look for the resource containing that trace and do the change.

I can't find any such message in the resources folder files

https://github.com/apache/camel-k/blob/1bb415b01a6e1b01f31ec04194b81be19f33fbd5/pkg/install/operator.go#L302

source: gharchive/issue

authors: Kaushik-Iyer johnpoth squakez

license_type: permissive

license_source: github-api


text:
Error when setting knative-service trait annotations

What happened?
Create an integration that uses annotations on the knative-service trait, as in this example:

apiVersion: camel.apache.org/v1
kind: Integration
metadata:
  name: annotations-test
spec:
  sources:
  - name: main.groovy
    content: |-

     from('rest:get:/test')
       .log("It Worked!")

  traits:
    knative-service:
      enabled: true
      annotations:
        autoscaling.knative.dev/class: "hpa.autoscaling.knative.dev"
        autoscaling.knative.dev/metric: "cpu"
        autoscaling.knative.dev/target: "75"
        autoscaling.knative.dev/minScale: "1"
        autoscaling.knative.dev/maxScale: "10"

Apply this content to your kubernetes cluster and monitor the operator logs.
It will display an error when creating the Knative Service object:
{"level":"error","ts":"2024-04-22T20:27:22Z","msg":"Reconciler error","controller":"integration-controller","controllerGroup":"camel.apache.org","controllerKind":"Integration","Integration":{"name":"annotations-test","namespace":"a1b2c3d4e5"},"namespace":"a1b2c3d4e5","name":"annotations-test","reconcileID":"63b0dd87-66be-4641-80b4-697349eeacf0","error":"error executing post actions: error during apply resource: a1b2c3d4e5/annotations-test: admission webhook \"validation.webhook.serving.knative.dev\" denied the request: validation failed: invalid key name \"autoscaling.knative.dev/class\": metadata.annotations\nautoscaling annotations must be put under \"spec.template.metadata.annotations\" to work\ninvalid key name \"autoscaling.knative.dev/maxScale\": metadata.annotations\nautoscaling annotations must be put under \"spec.template.metadata.annotations\" to work\ninvalid key name \"autoscaling.knative.dev/metric\": metadata.annotations\nautoscaling annotations must be put under \"spec.template.metadata.annotations\" to work\ninvalid key name \"autoscaling.knative.dev/minScale\": metadata.annotations\nautoscaling annotations must be put under \"spec.template.metadata.annotations\" to work\ninvalid key name \"autoscaling.knative.dev/target\": metadata.annotations\nautoscaling annotations must be put under \"spec.template.metadata.annotations\" to work","stacktrace":"sigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).reconcileHandler\n\tsigs.k8s.io/controller-runtime@v0.15.2/pkg/internal/controller/controller.go:324\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).processNextWorkItem\n\tsigs.k8s.io/controller-runtime@v0.15.2/pkg/internal/controller/controller.go:265\nsigs.k8s.io/controller-runtime/pkg/internal/controller.(*Controller).Start.func2.2\n\tsigs.k8s.io/controller-runtime@v0.15.2/pkg/internal/controller/controller.go:226"}

Steps to reproduce
No response
Relevant log output
No response
Camel K version
v2.2.0

@squakez We're using Knative Serving 1.12.3
kubectl get namespace knative-serving -o 'go-template={{index .metadata.labels "app.kubernetes.io/version"}}'
1.12.3

Per https://camel.apache.org/camel-k/2.2.x/index.html, Camel K 2.2 is compatible with Knative API 0.27.7, but I could not find any documentation on Knative website that mapped the API Version to the Knative version. So we used the latest available version when 2.2 was released. Maybe I have just found out that the API version is not the expected one.

Thanks! Using generic annotations under knative-service.annotations worked as expected

    knative-service:
      annotations:
        autoscaling.knative.dev/class: "kpa.autoscaling.knative.dev"
        autoscaling.knative.dev/container-concurrency-target-default: "100"
        autoscaling.knative.dev/container-concurrency-target-percentage: "0.7"
        autoscaling.knative.dev/enable-scale-to-zero: "false"
        autoscaling.knative.dev/max-scale-up-rate: "5"
        autoscaling.knative.dev/max-scale-down-rate: "2"
        autoscaling.knative.dev/panic-window-percentage: "40"
        autoscaling.knative.dev/panic-threshold-percentage: "150"
        autoscaling.knative.dev/scale-to-zero-grace-period: "10s"
        autoscaling.knative.dev/scale-to-zero-pod-retention-period: "0s"
        autoscaling.knative.dev/target-burst-capacity: "-1"
        autoscaling.knative.dev/requests-per-second-target-default: "100"

If these are "Revision" annotations, then, we probably need to rework the trait to make the configuration more generic and add any annotation accordingly. Ideally we can have both knative.service-annotations and knative.revision-annotations which would populate the specific annotation object. If this is what you need, feel free to log an issue with these details and we'll schedule the work accordingly.

authors: lsergio squakez


text:
VSCode URI not being formed correctly for JT400 component

Trying to create a new route from the VSCode plugin. As I type the object path, it seems to repeat the whole string in from the "object path" field with every keystroke. For instance, the following is from selecting MSGQ type then typing /qsys.lib/qusrsys.lib/jgorzins.msgq

jt400:://MSGQ//q/qs/qsy/qsys/qsys./qsys.l/qsys.li/qsys.lib/qsys.lib//qsys.lib/q/qsys.lib/qu/qsys.lib/qus/qsys.lib/qusr/qsys.lib/qusrs/qsys.lib/qusrsy/qsys.lib/qusrsys/qsys.lib/qusrsys./qsys.lib/qusrsys.l/qsys.lib/qusrsys.li/qsys.lib/qusrsys.lib/qsys.lib/qusrsys.lib//qsys.lib/qusrsys.lib/j/qsys.lib/qusrsys.lib/jg/qsys.lib/qusrsys.lib/jgo/qsys.lib/qusrsys.lib/jgor/qsys.lib/qusrsys.lib/jgorz/qsys.lib/qusrsys.lib/jgorzi/qsys.lib/qusrsys.lib/jgorzin/qsys.lib/qusrsys.lib/jgorzins/qsys.lib/qusrsys.lib/jgorzins./qsys.lib/qusrsys.lib/jgorzins.m/qsys.lib/qusrsys.lib/jgorzins.ms/qsys.lib/qusrsys.lib/jgorzins.msq/qsys.lib/qusrsys.lib/jgorzins.ms/qsys.lib/qusrsys.lib/jgorzins.msg/qsys.lib/qusrsys.lib/jgorzins.msgq

Any advice on how I can gather useful data?

To fix after https://issues.apache.org/jira/browse/CAMEL-18015

authors: ThePrez mgubaidullin

repo: apache/camel-karavan


text:
Ref #4416: Make the csimple extension agnostic to build systems

fixes #4416
Motivation
The csimple extension has hard-coded references to the directory target which makes only sense in the case of maven. It should be reviewed to be agnostic to build systems.
Modifications:

Replace target with the output directory of the BuildSystemTargetBuildItem

Nice catch, thanks @essobedo !

source: gharchive/pull-request

authors: essobedo ppalaga

repo: apache/camel-quarkus


text:
Create a core module and a spring boot module

Create a parent (pom) module.
Create camel-upgrade-recipes module, this is exactly like before, nothing should change from a Maven usage point of view.
Create camel-spring-boot-upgrade-recipes, this module has a dependency on camel-upgrade-recipes and spring-rewrite.
Create an upgrade recipe for Spring Boot, 49.yaml follow the naming convention and ideas from camel-upgrade-recipes. latest.yaml can be used to update to the same version as the project.version, for example, when using the latest.yaml recipe (org.apache.camel.upgrade.CamelSpringBootMigrationRecipe) the update will be done to the camel-spring-boot-upgrade-recipes:XXX version, this way, the users will have to change only the version in the plugin dependency section.

Usage:
Add the following profile to the pom.xml
<profile>
      <id>upgrade</id>
      <activation>
          <property>
              <name>upgrade</name>
          </property>
      </activation>
      <build>
        <plugins>
          <plugin>
            <groupId>org.openrewrite.maven</groupId>
            <artifactId>rewrite-maven-plugin</artifactId>
            <version>5.46.1</version>
            <configuration>
                <exportDatatables>true</exportDatatables>
                <activeRecipes>
                    <recipe>org.apache.camel.upgrade.CamelSpringBootMigrationRecipe</recipe>
                </activeRecipes>
            </configuration>
            <dependencies>
                <dependency>
                    <groupId>org.apache.camel.upgrade</groupId>
                    <artifactId>camel-spring-boot-upgrade-recipes</artifactId>
                    <version>4.9.0-SNAPSHOT</version>
                </dependency>
            </dependencies>
          </plugin>
        </plugins>
      </build>
    </profile>

execute
mvn rewrite:run package -Pupgrade
I just tried the following, create a Camel Spring Boot application using the archetype version 3.20.0, run the upgrade to 4.9.0-SNAPSHOT, this is the git diff:
diff --git a/pom.xml b/pom.xml
index 2674c02..2328489 100644
--- a/pom.xml
+++ b/pom.xml
@@ -14,8 +14,8 @@
   <properties>
     <project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
     <project.reporting.outputEncoding>UTF-8</project.reporting.outputEncoding>
-    <spring.boot-version>2.7.6</spring.boot-version>
-    <surefire.plugin.version>3.0.0-M4</surefire.plugin.version>
+    <spring.boot-version>3.3.6</spring.boot-version>
+    <surefire.plugin.version>3.1.2</surefire.plugin.version>
   </properties>

   <dependencyManagement>
@@ -32,7 +32,7 @@
       <dependency>
         <groupId>org.apache.camel.springboot</groupId>
         <artifactId>camel-spring-boot-bom</artifactId>
-        <version>3.20.0</version>
+        <version>4.9.0-SNAPSHOT</version>
         <type>pom</type>
         <scope>import</scope>
       </dependency>
@@ -89,9 +89,9 @@
       <plugin>
         <groupId>org.apache.maven.plugins</groupId>
         <artifactId>maven-compiler-plugin</artifactId>
-        <version>3.10.1</version>
+        <version>3.13.0</version>
         <configuration>
-          <release>11</release>
+          <release>17</release>
         </configuration>
       </plugin>
       <plugin>

and the archetype tests are successful

I applied the migration to camel-spring-boot-examples-4.0.0, this is the diff https://pastebin.com/k7xQtYuL , I just updated the parent version manually, one example does not compile after the migration, I think we can improve the camel upgrade recipe, but all the others compile (though I didn't test them)

Thanks @Croway and @JiriOndrusek - lets get this ready before we do the 4.10 release

authors: Croway davsclaus

repo: apache/camel-upgrade-recipes


text:
Add option to use Java 1.8 Optional<?> for POJO fields

Also upgrades to Jackson 2.x to allow injecting a custom ObjectMapper into SalesforceEndpointConfig, which in turn allows registering the Jdk8Module when using Java 1.8, which handles (de)serializing of Optional<?> in a reasonable manner. Jackson 1.x does not have the Jdk8Module.
Note that this requires that the project using the plugin is itself using Java 1.8+.
To use Jdk8Module, add this dependency:
		<dependency>
			<groupId>com.fasterxml.jackson.datatype</groupId>
			<artifactId>jackson-datatype-jdk8</artifactId>
		</dependency>

Then configure a custom ObjectMapper like the following snippet:
import org.apache.camel.component.salesforce.SalesforceEndpointConfig;
...
import com.fasterxml.jackson.databind.ObjectMapper;
import com.fasterxml.jackson.databind.SerializationFeature;
import com.fasterxml.jackson.datatype.jdk8.Jdk8Module;
...
	@Bean
	public SalesforceEndpointConfig salesforceEndpointConfig() {
		SalesforceEndpointConfig salesforceEndpointConfig = new SalesforceEndpointConfig();
		...
		ObjectMapper objectMapper = new ObjectMapper();
		objectMapper.registerModule(new Jdk8Module());
		objectMapper.configure(SerializationFeature.WRITE_DATES_AS_TIMESTAMPS, false);
		salesforceEndpointConfig.setObjectMapper(objectMapper);
		return salesforceEndpointConfig;
	}

Signed-off-by: Sune Keller absukl@almbrand.dk

@davsclaus This is a bigger one, mainly due to upgrading to Jackson 2.x.

This upgrade will also require upgrading camel-salesforce in the karaf features xml file
https://github.com/apache/camel/blob/master/platforms/karaf/features/src/main/resources/features.xml#L1386
And can you log a JIRA ticket so we have that to track this change. And it can only be done on master, eg for 2.18.

JIRA issue: https://issues.apache.org/jira/browse/CAMEL-10059

Can you fix the checkstyle errors by running
/components/camel-salesforce (master)/$ mvn compile -Psourcecheck

@davsclaus Checkstyle errors should be fixed now.

Thanks for the PR it has been merged. Do you mind closing this?

authors: davsclaus sirlatrom

repo: apache/camel


text:
CAMEL-10966 Salesforce Maven Plugin Escape Strings

Salesforce Maven Plugin doesn't escape strings when doing the camel-salesforce:generate phase.
This PR uses the velocity escape tool in order to escape strings.

Thanks
@zregvart do you mind taking a look at this PR ?

@NickCis thank you for this and good catch! Can you please log a JIRA issue for this at https://issues.apache.org/jira/browse/CAMEL/ (just mark it as a bug in 2.19 and against camel-salesforce component), and then squash these commits and amend the git commit message with the JIRA number?
Something along the lines of:
$ git rebase -i HEAD~2

set squash to the second commit, change the commit message to CAMEL-XXXX Salesforce Maven Plugin Escape Strings and force push the branch to your fork (git push -f).
Thank you :+1:

@zregvart Done.
You're welcomed, i'm happy to contribute to the project! :)

@NickCis thank you for your contribution it has been merged, you can close this pull request. And if you find any other issues please don't hesitate to create more pull requests, we :heart:  them :+1:

@zregvart I've found that there was missing the escaping in the sobject-pojo file. I've added it in the last commit.
In addition, i've found a bug in the way the velocity escapes. If there is a slash /, velocity escapes it to \/ which is invalid. I think this is due to a apache lang2 EscapeUtils bug (which is what Velocity Escape tools uses), i've tested using apache lang3 EscapeUtils directly and the escaping works correctly.
Should i create another Jira ticket and send another PR? (I've fixed it in this branch).
Is there a recommended way in order to write some tests for this specific case?

@NickCis thanks for testing this I hadn't had the chance to test it, we can re-open the ticket and you can do another pull request.
Testing Maven plugins is doable, but I wonder if you can do a test with just the velocity templates that might prove to be a bit simpler.
Open a PR with what you have and if you get into pains testing this we collaborate on a test together.

I've opened another pr to address this issues.

authors: NickCis davsclaus zregvart


text:
[CARBONDATA-2753] Fix Compatibility issue with Preaggregate table

Problem: User creates maintable and load data and create preaggregate datamap on maintable using old version and loads data into maintable using new version and dataload fails.

[ ] Any interfaces changed?

[ ] Any backward compatibility impacted?

[ ] Document update required?

[ ] Testing done

[ ] For large changes, please consider breaking it into sub-tasks under an umbrella JIRA.

Retest this please

Build Success with Spark 2.2.1, Please check CI http://88.99.58.216:8080/job/ApacheCarbonPRBuilder/6061/

SDV Build Success , Please check CI http://144.76.159.231:8080/job/ApacheSDVTests/5919/

authors: CarbonDataQA Indhumathi27 ravipesala

repo: apache/carbondata


text:
[FEATURE] Java process names are too simple

Execute jps. Displays celeborn java process name: master or worker, the name is too simple. Inconvenient identification

Hi @melin
It is because the simple class of org.apache.celeborn.service.deploy.master.Master is Master.
You can use jps -l to show the full class name.
BTW, feel free to create ticket in celeborn jira for feature or bug fix requirement, https://issues.apache.org/jira/projects/CELEBORN/issues
Thanks for the question, I am closing it.

authors: melin turboFei

repo: apache/celeborn


text:
vmware: affinity and anti-affinity rules must be followed when VMware cluster DRS is enabled

ISSUE TYPE

Improvement Request

COMPONENT NAME

VMware

CLOUDSTACK VERSION

NA

CONFIGURATION

Advanced zone with vSphere Datacenter, multiple ESXi 6.7 hosts
DRS enabled on the vSphere cluster
OS / ENVIRONMENT

N/A
SUMMARY

When the vSphere cluster has DRS enabled, VMs created from CloudStack with anti-affinity rules get migrated to the same host(s) by the VMware. This makes use of affinity groups useless at CloudStack end when DRS is enabled in VMware.
STEPS TO REPRODUCE

1. Enable DRS at VMware end, have sufficient load that it can kick in
2. Create an affinity group with type anti-affinity
3. Deploy multiple VMs using that group
4. Observe VMs getting started on different hosts
5. When DRS kicks in, VMs may get migrated depending on load-balancing
6. CloudStack updates new host for the VM on power sync

EXPECTED RESULTS

VM remains on different hosts

ACTUAL RESULTS

VMs end up on same host(s)

I'm not sure if we can do anything but make this known by documentation, or at best made mutually exclusive features by configuration.

good point @aleskxyz , thanks. This worth some investigation. @shwstppr had you looked into this as well?
So if the zone is a vphere dc, antiaffinity should be ignored by the deployment planner but instead it should be configured on vcenter.
important:
 Note:

If you use the vSphere HA Specify Failover Hosts admission control policy and designate multiple failover hosts, VM-VM affinity rules are not supported.

I think it must be possible to call that procedure

https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.resmgmt.doc/GUID-7297C302-378F-4AF2-9BD6-6EDB1E0A850A.html

in an automated fashing on rule creation and than add and remove VMs from it at will.

Hi @shwstppr is there any work made on this issue?

None I checked, it may be scheduled to be fixed @nvazquez

@sureshanaparti can you explore and advise about the proposed procedure https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.resmgmt.doc/GUID-7297C302-378F-4AF2-9BD6-6EDB1E0A850A.html ?

@sureshanaparti can you explore and advise about the proposed procedure https://docs.vmware.com/en/VMware-vSphere/6.5/com.vmware.vsphere.resmgmt.doc/GUID-7297C302-378F-4AF2-9BD6-6EDB1E0A850A.html ?

@nvazquez vSphere cluster supports multiple VM Rules to keep VMs together (affinity) and separate VMs (anti-affinity), so each affinity / anti-affinity group from CloudStack can be created / mapped to a VM rule in vSphere cluster (with name as the  affinity / anti-affinity group name in CloudStack). The VM(s) created from CloudStack can be added to /  removed from the VM rule in that vSphere cluster, based on the affinity / anti-affinity group of the VM. For workaround, the operator can now create similar VM rules in vSphere cluster and add / remove VMs to / from these rules.

Thanks @sureshanaparti - not including this one on the 4.16 milestone after your remark

We do not have any work in progress for this at the moment so moving it out of 4.19.0.0 milestone

authors: DaanHoogland nvazquez rhtyd shwstppr sureshanaparti

repo: apache/cloudstack


text:
Cannot save empty value in domain settings tab

ISSUE TYPE

Bug Report

COMPONENT NAME

UI, API

CLOUDSTACK VERSION

4.16

CONFIGURATION

N/A
OS / ENVIRONMENT

N/A
SUMMARY

There is no way to delete a domain setting once there is something set.
STEPS TO REPRODUCE

1. Go to Domains > ROOT (for example) and click on the 'Settings' tab.
2. Set ldap.bind.password (or other setting) to some value, for example 'password'
3. Now edit the same field again, clearing the text and click on the 'OK' icon

or use the cloudmonkey command:
update configuration domainid=<domain_uuid> name=ldap.bind.password value=password
update configuration domainid=<domain_uuid> name=ldap.bind.password value=

EXPECTED RESULTS

The value must be cleared.

ACTUAL RESULTS

When using cloudmonkey, it gives the following error:

🙈 Error: (HTTP 530, error code 4250) DB Exception on: com.mysql.cj.jdbc.ClientPreparedStatement: UPDATE domain_details SET domain_details.value=null WHERE domain_details.id = 1

This is the corresponding SQL exception in the management log:

2021-10-01 14:19:53,439 ERROR [c.c.a.ApiServer] (qtp220309324-18:ctx-b48f70c3 ctx-ec3c314b) (logid:98017a9d) unhandled exception executing api command: [Ljava.lang.String;@489189f7
com.cloud.utils.exception.CloudRuntimeException: DB Exception on: com.mysql.cj.jdbc.ClientPreparedStatement: UPDATE domain_details SET domain_details.value=null WHERE domain_details.id = 1
        at com.cloud.utils.db.GenericDaoBase.update(GenericDaoBase.java:846)
        at com.cloud.utils.db.GenericDaoBase.update(GenericDaoBase.java:801)
        at com.cloud.utils.db.GenericDaoBase.update(GenericDaoBase.java:1361)
        at jdk.internal.reflect.GeneratedMethodAccessor103.invoke(Unknown Source)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:566)
        at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:344)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:198)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163)
        at com.cloud.utils.db.TransactionContextInterceptor.invoke(TransactionContextInterceptor.java:34)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:175)
        at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:97)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
        at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:215)
        at com.sun.proxy.$Proxy165.update(Unknown Source)
        at com.cloud.configuration.ConfigurationManagerImpl.updateConfiguration(ConfigurationManagerImpl.java:691)
        at com.cloud.configuration.ConfigurationManagerImpl.updateConfiguration(ConfigurationManagerImpl.java:869)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
        at java.base/jdk.internal.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
        at java.base/jdk.internal.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
        at java.base/java.lang.reflect.Method.invoke(Method.java:566)
        at org.springframework.aop.support.AopUtils.invokeJoinpointUsingReflection(AopUtils.java:344)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.invokeJoinpoint(ReflectiveMethodInvocation.java:198)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:163)
        at org.apache.cloudstack.network.contrail.management.EventUtils$EventInterceptor.invoke(EventUtils.java:107)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:175)
        at com.cloud.event.ActionEventInterceptor.invoke(ActionEventInterceptor.java:51)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:175)
        at org.springframework.aop.interceptor.ExposeInvocationInterceptor.invoke(ExposeInvocationInterceptor.java:97)
        at org.springframework.aop.framework.ReflectiveMethodInvocation.proceed(ReflectiveMethodInvocation.java:186)
        at org.springframework.aop.framework.JdkDynamicAopProxy.invoke(JdkDynamicAopProxy.java:215)
        at com.sun.proxy.$Proxy130.updateConfiguration(Unknown Source)
        at org.apache.cloudstack.api.command.admin.config.UpdateCfgCmd.execute(UpdateCfgCmd.java:155)
        at com.cloud.api.ApiDispatcher.dispatch(ApiDispatcher.java:156)
        at com.cloud.api.ApiServer.queueCommand(ApiServer.java:772)
        at com.cloud.api.ApiServer.handleRequest(ApiServer.java:596)
        at com.cloud.api.ApiServlet.processRequestInContext(ApiServlet.java:321)
        at com.cloud.api.ApiServlet$1.run(ApiServlet.java:134)
        at org.apache.cloudstack.managed.context.impl.DefaultManagedContext$1.call(DefaultManagedContext.java:55)
        at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.callWithContext(DefaultManagedContext.java:102)
        at org.apache.cloudstack.managed.context.impl.DefaultManagedContext.runWithContext(DefaultManagedContext.java:52)
        at com.cloud.api.ApiServlet.processRequest(ApiServlet.java:131)
        at com.cloud.api.ApiServlet.doGet(ApiServlet.java:93)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:645)
        at javax.servlet.http.HttpServlet.service(HttpServlet.java:750)
        at org.eclipse.jetty.servlet.ServletHolder$NotAsync.service(ServletHolder.java:1443)
        at org.eclipse.jetty.servlet.ServletHolder.handle(ServletHolder.java:791)
        at org.eclipse.jetty.servlet.ServletHandler.doHandle(ServletHandler.java:550)
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:143)
        at org.eclipse.jetty.security.SecurityHandler.handle(SecurityHandler.java:602)
        at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
        at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:235)
        at org.eclipse.jetty.server.session.SessionHandler.doHandle(SessionHandler.java:1624)
        at org.eclipse.jetty.server.handler.ScopedHandler.nextHandle(ScopedHandler.java:233)
        at org.eclipse.jetty.server.handler.ContextHandler.doHandle(ContextHandler.java:1435)
        at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:188)
        at org.eclipse.jetty.servlet.ServletHandler.doScope(ServletHandler.java:501)
        at org.eclipse.jetty.server.session.SessionHandler.doScope(SessionHandler.java:1594)
        at org.eclipse.jetty.server.handler.ScopedHandler.nextScope(ScopedHandler.java:186)
        at org.eclipse.jetty.server.handler.ContextHandler.doScope(ContextHandler.java:1350)
        at org.eclipse.jetty.server.handler.ScopedHandler.handle(ScopedHandler.java:141)
        at org.eclipse.jetty.server.handler.gzip.GzipHandler.handle(GzipHandler.java:766)
        at org.eclipse.jetty.server.handler.HandlerCollection.handle(HandlerCollection.java:146)
        at org.eclipse.jetty.server.handler.HandlerWrapper.handle(HandlerWrapper.java:127)
        at org.eclipse.jetty.server.Server.handle(Server.java:516)
        at org.eclipse.jetty.server.HttpChannel.lambda$handle$1(HttpChannel.java:388)
        at org.eclipse.jetty.server.HttpChannel.dispatch(HttpChannel.java:633)
        at org.eclipse.jetty.server.HttpChannel.handle(HttpChannel.java:380)
        at org.eclipse.jetty.server.HttpConnection.onFillable(HttpConnection.java:273)
        at org.eclipse.jetty.io.AbstractConnection$ReadCallback.succeeded(AbstractConnection.java:311)
        at org.eclipse.jetty.io.FillInterest.fillable(FillInterest.java:105)
        at org.eclipse.jetty.io.ChannelEndPoint$1.run(ChannelEndPoint.java:104)
        at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.runTask(EatWhatYouKill.java:336)
        at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.doProduce(EatWhatYouKill.java:313)
        at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.tryProduce(EatWhatYouKill.java:171)
        at org.eclipse.jetty.util.thread.strategy.EatWhatYouKill.run(EatWhatYouKill.java:129)
        at org.eclipse.jetty.util.thread.ReservedThreadExecutor$ReservedThread.run(ReservedThreadExecutor.java:375)
        at org.eclipse.jetty.util.thread.QueuedThreadPool.runJob(QueuedThreadPool.java:773)
        at org.eclipse.jetty.util.thread.QueuedThreadPool$Runner.run(QueuedThreadPool.java:905)
        at java.base/java.lang.Thread.run(Thread.java:829)
Caused by: java.sql.SQLIntegrityConstraintViolationException: Column 'value' cannot be null
        at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:117)
        at com.mysql.cj.jdbc.exceptions.SQLError.createSQLException(SQLError.java:97)
        at com.mysql.cj.jdbc.exceptions.SQLExceptionsMapping.translateException(SQLExceptionsMapping.java:122)
        ... 87 more

@vladimirpetrov this wil be solved by the reset values #4230 !?

Resetting to a default value is different than setting an empty string @DaanHoogland. Currently this empty string is converted to a null value which is rejected by the backend. But I agree, this PR could be a workaround for this particular case with the LDAP settings.

Please triage @nvazquez - if this is a serious regression requiring fixing?

Definitely a regression, we don't have it in 4.15.1 @rhtyd @nvazquez

@vladimirpetrov @nvazquez the 'value' column in the domain_details table is altered, and doesn't accept NULL. so, this needs fix.

Thanks for confirming @sureshanaparti you may want to look at all tables/columns which got altered and preemptively explore/fix potential issues like Vladi has discovered wrt 4.16.0.0.

Thanks for confirming @sureshanaparti you may want to look at all tables/columns which got altered and preemptively explore/fix potential issues like Vladi has discovered wrt 4.16.0.0.

Fixed @rhtyd, PR here: #5551

authors: DaanHoogland rhtyd sureshanaparti vladimirpetrov