I noticed that in version 1.4.3 the app/tasks task JSON contains the state field. However, in version 1.1.1 I don't see it.
Is there some config param I need to set so that the state field is retrieved for each task?
Thanks
--John
The latest (and final) 1.1.x release is 1.1.7, and, unfortunately, does not include a parameter to expose this information. You will need to upgrade to a later release of Marathon (1.3.x) to access it.
Perhaps this is helpful: you can specify the query string parameter "?status=running" to cause only running tasks to be returned.
Related
We have a Spring boot application that has been in production for a while. We use Flyway to manage database migrations. I just upgraded to Spring boot 2.5.4 from 2.4.5 which brings with it an upgrade to Flyway 7.7.3.
When executing all the migrations in a fresh local environment, the migration now fails due to a syntax issue with this comment:
---*********************---
-- ** AUDITING TABLES ** --
---*********************---
I imagine this won't be an issue in environments which have already executed this migration but what is the best way to fix this for new environments with a fresh database given that the original file cannot be edited due to checksum comparison on migration?
My current versioning just includes a major version i.e. V2, V3 etc. My thinking is to get rid of V2 (the script with the issue) and introduce V2.1 which would be an exact copy of V2 with the erroneous comment section removed. I would then set both ignoreMissingMigrations and ignoreIgnoredMigrations to true
Does this sound like the right way to solve this?
Thanks in advance.
Changing the script and then executing flyway repair would be the ideal solution - this would rectify the checksums.
Assuming this option is not available for some reason (it would be helpful to know what that is in case we can fix it!), the above sounds correct. ignoreMissingMigrations means your old deployments won't object to V2 not being there, and ignoreIgnoredMigrations means they won't object to V2.1 being present. The downside is that these ignores may not be valid in the longer term - so they won't, for example, catch a later script that goes missing unintentionally.
I ran into some issues recently configuring the proxy settings for a Gradle project... specifically with the systemProp.https.nonProxyHosts.
Going through the Gradle documentation this setting: systemProp.https.nonProxyHosts = *.nonproxyrepos.com|localhost is valid, but the Networking Properties section from the Java SDK states that systemProp.https.nonProxyHosts does not exist and the non-https sibling will be used instead.
Bottom line: systemProp.https.nonProxyHosts didn't work for me. As soon as I deleted that line the script worked (I tested several times toggling it on/off).
So can anyone confirm if that's outdated on the Gradle documentation, or if Gradle does indeed uses it and maps them internally, but the version I was using (Gradle 6.1.1) had a bug in that regard? Is there a task (or something similar by default) to test/visualize if Gradle is indeed connecting via HTTP or HTTPS so I can corroborate that's working as intended?
It's really hard to tell in retrospect what the issue was in your case.
but the Networking Properties section from the Java SDK states that systemProp.https.nonProxyHosts does not exist and the non-https sibling will be used instead.
First and foremost, this is true. For reference, the DefaultProxySelector in JDK 8 reads
static class NonProxyInfo {
static final String defStringVal = "localhost|127.*|[::1]|0.0.0.0|[::0]";
static NonProxyInfo httpNonProxyInfo = new NonProxyInfo("http.nonProxyHosts", null, null, defStringVal);
}
public java.util.List<Proxy> select(URI uri) {
//....
} else if ("https".equalsIgnoreCase(protocol)) {
// HTTPS uses the same property as HTTP, for backward
// compatibility
pinfo = NonProxyInfo.httpNonProxyInfo;
}
//....
}
So can anyone confirm if that's outdated on the Gradle documentation, or if Gradle does indeed uses it and maps them internally, but the version I was using (Gradle 6.1.1) had a bug in that regard?
Gradle indeed reads https.nonProxyHosts and maps it internally. See JavaSystemPropertiesSecureHttpProxySettings for more details. I'm not aware of any bugs. The commit log's last relevant change was from 2014. The property is used for example when resolving dependencies from remote Maven repositories.
Is there a task (or something similar by default) to test/visualize if Gradle is indeed connecting via HTTP or HTTPS so I can corroborate that's working as intended?
I'm not aware of any task, be it built-in or contributed by 3rd party plugins. You may get more details on what's going on by inspecting --info and --debug output.
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
I've just upgraded SonarQube from 6.0 to 6.7 LTS running in a CentOS 6 box, and noticed that ElasticSearch (ES) failed to start because the kernel (2.6.32-696.3.1.el6.x86_64) doesn't have seccomp available.
This is officially documented at System call filter check and a correct workaround for systems without this feature is to configure bootstrap.system_call_filter to false in elasticsearch.yml.
The issue here is because Sonar creates the ES configuration at startup, writing in $SONAR_HOME/temp/conf/es/elasticsearch.yml and I haven't found a way to set bootstrap.system_call_filter property.
I tried a natural (undocumented) way introducing sonar.search.bootstrap.system_call_filter and bootstrap.system_call_filter properties in sonar.properties but it doesn't work.
We had the same problem. At first we used the above solution but after searching in the sonar code on github found the place where this setting should be placed:
Edit the sonar.properties file and change the line:
#sonar.search.javaAdditionalOpts=
to
sonar.search.javaAdditionalOpts=-Dbootstrap.system_call_filter=false
For sonarqube docker image, setup additional environment to disable this feature when "docker run":
-e SONAR_SEARCH_JAVAADDITIONALOPTS="-Dbootstrap.system_call_filter=false"
Hi I tried to echo bootstrap.system_call_filter: 'false' to temp/conf/es/elasticsearch.yml, I see the line in that file, but got same error during start of sonarqube 6.7 on centos6.
Has someone tested that with success?
First of all: don't even try to update elasticsearch.yml . SonarQube self-manages its ElasticSearch component config, so any attempt of manual intervention will be harmful. (reminder: the only config file that should ever be modified to operate SonarQube is sonar.properties)
More interestingly regarding that seccomp component:
the seccomp requirement does come from underlying ElasticSearch requirement, and transitively applies to operating SonarQube
if you run SonarQube locally with default config (specifically: default sonar.search.host), then the seccomp check may not be fatal (i.e. just a warning)
if you did override sonar.search.host , then the first thing you should wonder is: does the ElasticSearch JVM really needs to listen on other interfaces than loopback ? (knowing that SonarQube uses ES locally, except with the Data Center Edition). If no good answer to that, then keep sonar.search.host at its default value.
Last but not least, the golden path here is obviously to follow the requirement (i.e. have seccomp available on your OS), even if that involves upgrading to a more recent Linux kernel. And to wrap it all up: we've edited SonarQube Requirements to transparently share this situation.
You could really cheat and edit /${SONAR_HOME}/elasticsearch/bin/elasticsearch.
Add
echo "bootstrap.system_call_filter = 'false'" >>
/${SONAR_HOME}/temp/conf/es/elasticsearch.yml
before the "demonized" variable is set.
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