I got a problem on Azure that the Nexus didn't had enough disk space. Nexus failed to start due to this problem so I extended the default PVC jenkins-x-nexus from 8GB to 20GB. This extension was successful and everything is just running file.
But if I now want to upgrade my jx platform (jx upgrade platform) I'm getting the following error:
The PersistentVolumeClaim "jenkins-x-nexus" is invalid: spec.resources.requests.storage: Forbidden: field can not be less than previous value'
How can this be resolved?
The PersistentVolumeClaim "jenkins-x-nexus" is invalid: spec.resources.requests.storage: Forbidden: field can not be less than previous value'
When you're doing a jx upgrade platform, Helm values for Nexus chart are populated from default Nexus chart Helm values - https://github.com/jenkins-x-charts/nexus/blob/master/nexus/values.yaml
If you want to override them, and I guess you do, since you need to specify the correct size of the PVC (>8Gb), you need to specify your custom values in myvalues.yaml file and place it in the same directory, where you're executing a jx upgrade platform and then run a jx upgrade platform
Please use https://jenkins-x.io/docs/managing-jx/old/config/#nexus as reference
Related
As of a few weeks ago we added filebeat, metricbeat and apm to our dotnet core application ran on our kubernetes cluster.
It works all nice and recently we discovered filebeat and metricbeat are able to write a different index upon several rules.
We wanted to do the same for APM, however searching the documentation we can't find any option to set the name of the index to write to.
Is this even possible, and if yes how is it configured?
I also tried finding the current name apm-* within the codebase but couldn't find any matches upon configuring it.
The problem which we'd like to fix is that every space in kibana gets to see the apm metrics of every application. Certain applications shouldn't be within this space so therefore i thought a new apm-application-* index would do the trick...
Edit
Since it shouldn't be configured on the agent but instead in the cloud service console. I'm having troubles to 'user-override' the settings to my likings.
The rules i want to have:
When an application does not live inside the kubernetes namespace default OR kube-system write to an index called apm-7.8.0-application-type-2020-07
All other applications in other namespaces should remain in the default indices
I see you can add output.elasticsearch.indices to make this happen: Array of index selector rules supporting conditionals and formatted string.
I tried this by copying the same i had for metricbeat and updated it to use the apm syntax and came to the following 'user-override'
output.elasticsearch.indices:
- index: 'apm-%{[observer.version]}-%{[kubernetes.labels.app]}-%{[processor.event]}-%{+yyyy.MM}'
when:
not:
or:
- equals:
kubernetes.namespace: default
- equals:
kubernetes.namespace: kube-system
but when i use this setup it tells me:
Your changes cannot be applied
'output.elasticsearch.indices.when': is not allowed
Set output.elasticsearch.indices.0.index to apm-%{[observer.version]}-%{[kubernetes.labels.app]}-%{[processor.event]}-%{+yyyy.MM}
Set output.elasticsearch.indices.0.when.not.or.0.equals.kubernetes.namespace to default
Set output.elasticsearch.indices.0.when.not.or.1.equals.kubernetes.namespace to kube-system
Then i updated the example but came to the same conclusion as it was not valid either..
In your ES Cloud console, you need to Edit the cluster configuration, scroll to the APM section and then click "User override settings". In there you can override the target index by adding the following property:
output.elasticsearch.index: "apm-application-%{[observer.version]}-{type}-%{+yyyy.MM.dd}"
Note that if you change this setting, you also need to modify the corresponding index template to match the new index name.
I'm trying to debug a problem I don't know enough about. It involves an integration of Ansible, Helm, and Kubectl, all running in a container on a CI server.
We have a Docker image that runs Ansible. I don't know if it's a custom image or not. It's called "ansible:2.2", so it seems like it's referring to version 2.2 of Ansible.
We recently made some build changes that integrate Helm. Instead of storing k8s templates in git, we use Helm to generate the templates, and fill in some additional properties with Ansible.
In two of the services I've upgraded to use the new build system, I see an Ansible error message that starts like this:
failed: [] (item=/home/aft/ansible/roles/_configrole/tasks/../templates/k8s/deployment_bg.yaml) => {"changed:" true, "cmd": ["/usr/bin/kubectl", ...], ..., "stderr: "error: error when applying patch:\n\nto:...
This is followed by large blocks of json, and finally ending with:
unable to find api field in struct Container for the json field \"$setElementOrder/env\"
In the overall large error message, seemingly as part of the "kubectl patch" error message, I see three large blocks labeled with "original", "modified", and "current", all of which are slightly different variations of a k8s Deployment object.
I can't figure out the relationship of these three "original", "modified", and "current" blocks to the text of this error message.
In the first service that we saw this error message in, one of the build admins said that he tried deleting the existing Deployment object instead of letting the process try to modify it, and that appeared to work, but I believe that is not ideal.
Just to sum up the discussion in comments.
The issue has been fixed according to: .../issues/50040 and
.../pull/49834.
Additionally, documentation [ 1 ] [ 2 ] states that:
You must use a kubectl version that is within one minor version difference of your cluster. For example, a v1.2 client should work with v1.1, v1.2, and v1.3 master. Using the latest version of kubectl helps avoid unforeseen issues.
In highly-available (HA) clusters, the newest and oldest kube-apiserver instances must be within one minor version.
kubelet must not be newer than kube-apiserver, and may be up to two minor versions older.
kube-controller-manager, kube-scheduler, and cloud-controller-manager must not be newer than the kube-apiserver instances they communicate with. They are expected to match the kube-apiserver minor version, but may be up to one minor version older (to allow live upgrades).
kubectl is supported within one minor version (older or newer) of kube-apiserver
SDK: Apache Beam SDK for Go 0.5.0
We are running Apache Beam Go SDK jobs in Google Cloud Data Flow. They had been working fine until recently when they intermittently stopped working (no changes made to code or config). The error that occurs is:
Failed to retrieve staged files: failed to retrieve worker in 3 attempts: bad MD5 for /var/opt/google/staged/worker: ..., want ; bad MD5 for /var/opt/google/staged/worker: ..., want ;
(Note: It seems as if it's missing a second hash value in the error message message.)
As best I can guess there's something wrong with the worker - It seems to be trying to compare md5 hashes of the worker and missing one of the values? I don't know exactly what it's comparing to though.
Does anybody know what could be causing this issue?
The fix to this issue seems to have been to rebuild the worker_harness_container_image with the latest changes. I had tried this but I didn't have the latest release when I built it locally. After I pulled the latest from the Beam repo, and rebuilt the image (As per the notes here https://github.com/apache/beam/blob/master/sdks/CONTAINERS.md) and reran it seemed to work again.
I'm seeing the same thing. If I look into the Stackdriver logging I see this:
Handler for GET /v1.27/images/apache-docker-beam-snapshots-docker.bintray.io/beam/go:20180515/json returned error: No such image: apache-docker-beam-snapshots-docker.bintray.io/beam/go:20180515
However, I can pull the image just fine locally. Any ideas why Dataflow cannot pull.
I am using the SQL Deploy DACPAC community contributed step to deploy my dacpac to the server within Octopus.
It has been setup correctly and has been working fine until the below situation occurs.
I have a situation where I am dropping columns but the deploy keeps failing due to rows being detected. I am attempting to use /p:BlockOnPossibleDataLoss=false as an "Additional deployment contributor arguments" but it seems to be ignored.
Can anyone guide me to what is wrong?
The publish properties should have DropObjectsNotInSource, try to set it to True.
You might want to fine tune it, to avoid dropping users, permissions, etc.
After multiple updates by the original author, this issue was still not resolved. The parameter has actually since been completely removed since version 11.
Initially, I added a pre-deployment script that copied all the data from the tables that were expected to fail, delete all the data, allow the table schema to update as normal, and in a post-deployment script re-insert all the data into the new structure. The problem with this was that for data that could be lost, a pre-deployment and post-deployment script was required when it wasn't really needed.
Finally, I got around this by duplicating the community step "SQL - Deploy DACPAC" (https://library.octopus.com/step-templates/58399364-4367-41d5-ad35-c2c6a8258536/actiontemplate-sql-deploy-dacpac) by saving it as a copy from within Octopus. I then went into the code, into the function Invoke-DacPacUtility, and added the following code:
[bool]$BlockOnPossibleDataLoss into the parameter list
Write-Debug (" Block on possible data loss: {0}" -f $BlockOnPossibleDataLoss) into the list of debugging
if (!$BlockOnPossibleDataLoss) { $dacProfile.DeployOptions.BlockOnPossibleDataLoss = $BlockOnPossibleDataLoss; } into the list of deployment options
Then, I went into the list of parameters and added as follows:
Variable name: BlockOnPossibleDataLoss
Label: Block on possible data loss
Help test: True to stop deployment if possible data loss if detected; otherwise, false. Default is true.
Control type: Checkbox
Default value: true
With this, I am able to change the value of this parameter with the checkbox when using the step in the process of the project.
Upgraded 1.599->1.605
Matrix job is used
In order to chooseparticular configuration or run All of them the following groovy expression is used in Combination filter:
targetHost=="All" || targetHost.contains(hostUnderTest)
where
hostUnderTest is matrix axis that contains the list of available hosts
targetHost is build parameter and usually contains comma separated list of hosts against which tests are executed
It was working on 1.599 but fails with the following error after update to 1.605
FATAL: Scripts not permitted to use method java.lang.String contains java.lang.CharSequence
I suppose these are due to some security restriction - could someone please advise how to disable them or propose another workaround?
That is truly a pain. What version of the matrix-project do you have? You can see this through Manage Jenkins -> manage plugins
If its 1.4.1 then it is a bad release and you need to downgrade to 1.4 https://issues.jenkins-ci.org/browse/INFRA-250
I think you should be able to apply 1.4 over the top if you download it and used the advanced tab on the manage plugin page
According to this comment - appears to be expected behaviour.
Script works correctly after being approved by jenkins admin in
Manage Jenkins ยป In-Process Script Approval
menu