We Keep Coding

how to ues kubernetes api for java to create mysql cluster

First, the yaml file is right,because I can use them directley create a mysql cluster in kubernetes.
but when I try to create a mysql cluster by kubernetes api for java, an error occured
The commond in yaml file cannot be recognized by the process.
The key component of the yaml file is as follows
initContainers:
- name: init-mysql
image: mysql:5.7.33
env:
- name: MYSQL_ROOT_PASSWORD
valueFrom:
secretKeyRef:
name: mysql-secret
key: password
command:
- bash
- "-c"
- |
set -ex
[[ $(hostname) =~ -([0-9]+)$ ]] || exit 1
ordinal=${BASH_REMATCH[1]}
echo [mysqld] > /mnt/conf.d/server-id.cnf
echo server-id=$((100 + $ordinal)) >> /mnt/conf.d/server-id.cnf
if [[ ${ordinal} -eq 0 ]]; then
cp /mnt/config-map/master.cnf /mnt/conf.d
else
cp /mnt/config-map/slave.cnf /mnt/conf.d
fi
volumeMounts:
- name: conf
mountPath: /mnt/conf.d
- name: config-map
mountPath: /mnt/config-map
and the java code is as follows
........
........
.withInitContainers(new V1ContainerBuilder()
.withName("init-mysql")
.withImage("mysql:5.7.33")
.withEnv(env)
.withCommand("bash",
"\"-c\"",
"|",
"set -ex",
"[[ $(hostname) =~ -([0-9]+)$ ]] || exit 1",
"ordinal=${BASH_REMATCH[1]}",
"echo [mysqld] > /mnt/conf.d/server-id.cnf",
"echo server-id=$((100 + $ordinal)) >> /mnt/conf.d/server-id.cnf",
"if [[ ${ordinal} -eq 0 ]]; then",
" cp /mnt/config-map/master.cnf /mnt/conf.d",
"else",
" cp /mnt/config-map/slave.cnf /mnt/conf.d",
"fi"
)
.withVolumeMounts(new V1VolumeMountBuilder()
.withName("conf")
.withMountPath("/mnt/conf.d")
.build(),
new V1VolumeMountBuilder()
.withName("config-map")
.withMountPath("/mnt/config-map")
.build()
)
.build(),
......
......
The java code and the yaml file look the same, but when I execute it, an error occured. The result for kubectl logs is as follows
bash: "-c": No such file or directory
so I think it may be caused by the uncorrect params of withCommand function.
How can I fix it.Thank you.

In your Java code, you are explicitly including double quotes in the string, withCommand("bash", "\"-c\"", ...). That's causing the container command to execute something similar to bash '"-c"' ... where the quotes are part of the argument. In turn, that doesn't start with a hyphen, so bash interprets it as a script to run, but when there isn't a local file named exactly "-c" including the quotes as part of the filename, you get that error.
The answer to your immediate question is just to remove those extra quotes
.withCommand("bash",
"-c", // no extra quotes here
...)
There's a second half of your question about the YAML syntax: why does what you show work? I believe it would also work to remove the double quotes here
command:
- bash
- -c
- ...
The trick here is that YAML has three different kinds of inline strings ("flow scalars"). Plain strings have no quotes but allow no escaping either; single-quoted strings have 'single quotes' but very limited escaping options; and double-quoted strings have "double quotes" and also can represent any string through escaping. Block scalars provide a further kind of string for multi-line text.
These are all the same:
- the same
- 'the same'
- "the same"
- "the\u0020same"
- >-
the same
In some cases you need a particular quoting style to work around YAML syntax issues. In your case, the -c option looks somewhat similar to the YAML - item list syntax (though the list syntax requires a space after the hyphen) so perhaps the original YAML author chose to quote it to make it unambiguous. It shouldn't be required here though.
The YAML parser will remove the quotes before the application sees them. In the Kubernetes case, this means the quotes around "-c" are removed at the YAML layer and the actual command list contains [bash, -c, ...] with no quotes.

java.io.tmpdir when running java_test with bazel

motivation:
I have a test that needs to write a short temp file (must be < 107 characters).
Currently the test is using
Files.createTempFile(null,".sock");
issue
which when running
I'm trying to figure out the java.io.tmp value when running java test using bazel. The different options I have is:
Setting $TEST_TMPDIR (or without)
Using "local"=True (or without)
Here is the result:
# local=True + TEST_TMPDIR=/btmp:
/btmp/_bazel_ors/719f891d5db9fd5e73ade25b0c847fd1/execroot/__main__/_tmp/8be6e61521c57d3cfc8585efa880e1ac/1638063256753562848.sock
# local=False + TEST_TMPDIR=/btmp:
/btmp/_bazel_ors/719f891d5db9fd5e73ade25b0c847fd1/bazel-sandbox/5561433121200492142/execroot/__main__/_tmp/8be6e61521c57d3cfc8585efa880e1ac/4867903879018296623.sock
# local=True , no TEST_TMPDIR:
/private/var/tmp/_bazel_ors/719f891d5db9fd5e73ade25b0c847fd1/execroot/__main__/_tmp/8be6e61521c57d3cfc8585efa880e1ac/984443110479498941.sock
# local=False , no TEST_TMPDIR:
/private/var/tmp/_bazel_ors/719f891d5db9fd5e73ade25b0c847fd1/bazel-sandbox/6199384508952843116/execroot/__main__/_tmp/8be6e61521c57d3cfc8585efa880e1ac/4588114364301475150.sock
Seems like the shortest temp prefix I can get is:
/private/var/tmp/_bazel_ors/719f891d5db9fd5e73ade25b0c847fd1/execroot/__main__/_tmp/
which is 85 char long (way too long for my needs).
How can I safely play with this configuration and make it a lot shorter?
note:
My env is mac osx sierra and I'm running bazel 0.5.1

Solvable by adding this to the jvm_flags of the test target:
"jvm_flags" = ["-Djava.io.tmpdir=/tmp"],
But note that it would make the test less hermetic

You can also tell bazel where it should store its outputs --output_base=/tmp/foo.

Launching Java With Java_OPTS

This should be a pretty simple question, I can't believe I wasn't able to find anything from googling.
I'm using powershell and I'm trying to run a java app from command line:
$memory = "-Xms128m -Xmx1028m -XX:MaxPermSize=512m"
$ssl = "-Djavax.rmi.ssl.client.enabledProtocols=`"TLSv1`" -Djavax.rmi.ssl.client.enabledCipherSuites=`"_removed_`" -Djavax.net.ssl.trustStorePassword=`"_removed_`" -Djavax.net.ssl.trustStore=`"_removed_`" -Djavax.net.ssl.keyStorePassword=`"_removed_`" -Djavax.net.ssl.keyStore=`"_removed_`" -Djava.endorsed.dirs=`"$($ddmsLoc)tomcat6\endorsed`""
$classpath = getClasspath "manager" $null
$java_opts = "$($memory) $($ssl) -Djavax.net.debug=all"
$cmd = "$($java) $($java_opts) -cp `"$($classpath)`" dss.vector.solutions.manager.server.ServerStatus -g"
Invoke-Expression $cmd
But for some reason it thinks my JAVA_OPTS parameters are the name of the java class I'm running:
Caused by: java.lang.ClassNotFoundException: .rmi.ssl.client.enabledProtocols=TLSv1
I have tried:
The ssl options with/without quotes around the value
Actually setting the JAVA_OPTS environment variable, until I read somewhere else that the JVM doesn't ever read that variable.
wrapping them in more quotes
I'm kind of at a loss here.

Etan Reisner posted a comment that helped me to solve it:
Why does PowerShell split arguments containing hyphens and periods?
Windows is (for some reason) splitting the parameters in half.
echo -Dmy.param=value
returns:
-Dmy
.param=value
If the parameter is wrapped in quotes, like:
echo "-Dmy.param=value"
Then it works just fine.

Trimmomatic not acknowleding commands over Linux cluster

I am trying to use the program Trimmomatic to removed adapter sequences from an Illumina paired-end read over a computer cluster. While I can get the program to open, it will either not acknowledge the commands I enter or will return an error message. I have tried all kinds of permutations of the input commands without success. Examples of input code and error messages are below
Code:
java -classpath /*filepath*/Trimmomatic-0.32/trimmomatic-0.32.jar org.usadellab.trimmomatic.TrimmomaticPE \
-phred33 -trimlog /Results/log.txt \
~/*filepath*/data_R1.fq ~/*filepath*/data_R2.fq \
ILLUMINACLIP:/*filepath*/Trimmomatic-0.32/adapters/TruSeq3-PE-2.fa:2:30:10:3:"true"
Results: (the o/s seems to find and execute the software, but is not feeding in the command; I get the same result if I use the java -jar option for executing Trimmomatic)
TrimmomaticPE [-threads <threads>] [-phred33|-phred64] [-trimlog <trimLogFile>] [-basein <inputBase> | <inputFile1> <inputFile2>] [-baseout <outputBase> | <outputFile1P> <outputFile1U> <outputFile2P> <outputFile2U>] <trimmer1>...
Code: (If I add in the command PE immediately before all other commands, the program executes and can find the fasta file containing the adapter sequences, but then searches for and cannot fund a file called 'PE')
java -classpath /*filepath*/trimmomatic-0.32.jar org.usadellab.trimmomatic.TrimmomaticPE \
PE -phred33 -trimlog /Results/log.txt \
~/*filepath*/data_R1.fq ~/*filepath*/data_R2.fq \
ILLUMINACLIP:/*filepath*/Trimmomatic-0.32/adapters/TruSeq3-PE-2.fa:2:30:10:3:"true"
Results: (Programs rus and finds the fasta file of adapter sequences, but then fails to execute. Why is it looking for a PE file?)
TrimmomaticPE: Started with arguments: PE -phred33 -trimlog /Results/log.txt /*filepath*/data_R1.fq /*filepath*/data_R2.fq ILLUMINACLIP:/*filepath*/Trimmomatic-0.32/adapters/TruSeq3-PE-2.fa:2:30:10:3:true
Multiple cores found: Using 12 threads
Using PrefixPair: 'TACACTCTTTCCCTACACGACGCTCTTCCGATCT' and 'GTGACTGGAGTTCAGACGTGTGCTCTTCCGATCT'
Using Long Clipping Sequence: 'AGATCGGAAGAGCACACGTCTGAACTCCAGTCAC'
Using Long Clipping Sequence: 'TACACTCTTTCCCTACACGACGCTCTTCCGATCT'
Using Long Clipping Sequence: 'GTGACTGGAGTTCAGACGTGTGCTCTTCCGATCT'
Using Long Clipping Sequence: 'AGATCGGAAGAGCGTCGTGTAGGGAAAGAGTGTA'
ILLUMINACLIP: Using 1 prefix pairs, 4 forward/reverse sequences, 0 forward only sequences, 0 reverse only sequences
Exception in thread "main" java.io.FileNotFoundException: PE (No such file or directory)
at java.io.FileInputStream.open(Native Method)
at java.io.FileInputStream.<init>(FileInputStream.java:146)
at org.usadellab.trimmomatic.fastq.FastqParser.parse(FastqParser.java:127)
at org.usadellab.trimmomatic.TrimmomaticPE.process(TrimmomaticPE.java:251)
at org.usadellab.trimmomatic.TrimmomaticPE.run(TrimmomaticPE.java:498)
at org.usadellab.trimmomatic.TrimmomaticPE.main(TrimmomaticPE.java:506)

I've never used trimmomatic but it looks like you are passing in the incorrect parameters.
the trimmomatic webpage lists the usage from version 0.27+ as:
java -jar <path to trimmomatic.jar> PE [-threads <threads] [-phred33 | -phred64] [-trimlog <logFile>] <input 1> <input 2> <paired output 1> <unpaired output 1> <paired output 2> <unpaired output 2> <step 1> ...
or using the "old way"
java -classpath <path to trimmomatic jar> org.usadellab.trimmomatic.TrimmomaticPE [-threads <threads>] [-phred33 | -phred64] [-trimlog <logFile>] <input 1> <input 2> <paired output 1> <unpaired output 1> <paired output 2> <unpaired output 2> <step 1> ...
Where the only difference is the new way is specifying "PE" as the main class instead of a fully qualified path.
First, addressing your 2nd problem:
You look like you are doing both: specifying a fully qualified class name as well as the PE part. This makes trimmomatic think you have a fastq file named "PE" which doesn't exist.
If you get rid of the "PE" OR the qualfited class name; it will call the correct class. Which is what you do first in your first problem.
1st problem
I don't think you have the correct number of arguments listed in your first invocation so trimmomatic displays the usage to tell you what parameters are required. It would be nice if it told you what was wrong but it doesn't.
Solution
It looks like you are only providing 2 fastq files but trimmmoatic needs 6 file paths. You are missing the output paired and unpaired files paths for the read 1 and read 2 data which I assume get created by the program when it runs.
I guess your 2nd attempt got further along in the program since it saw enough parameters that you potentially had enough file paths specified (however, it turns out you had optional step parameters)

Following the advice of dkatzel below and user blakeoft on SeqAnswers (http://seqanswers.com/forums/showthread.php?t=45094), I dropped the PE flag and added individual file names for each output file and the program executed properly.
java -classpath /*filepath*/Trimmomatic-0.32/trimmomatic-0.32.jar org.usadellab.trimmomatic.TrimmomaticPE \
-phred33 \
~/refs/lec12/data_R1.fq ~/refs/lec12/data_R2.fq \
lane1_forward_paired.fq lane1_forward_unpaired.fq lane1_reverse_paired.fq lane1_reverse_unpaired.fq \
ILLUMINACLIP:/*filepath*/Trimmomatic-0.32/adapters/TruSeq3-PE-2.fa:2:30:10:3:true
NB: I also tried using the -baseout flag rather than a list of four files, and the program would open but not execute any commands
NB: The a log file could be generated using the flag -trimlog filename, but only if I first made a blank text file with the same name as the intended log file.

Space in Java command-line arguments

In my Java command-line arguments, any characters after space get ignored. For example,
java test.AskGetCampaignByName "Dummy books"
I get the first argument (args[0]) as "Dummy" only. Single quotes also do not help.
Is there a workaround/fix for this? Could it be because of my terminal settings?
My $TERM is xterm, and $LANG is "en_IN".

The arguments are handled by the shell (I assume you are using Bash under Linux?), so any terminal settings should not affect this.
Since you already have quoted the argument, it ought to work. The only possible explanation I can think of is if your java command is a wrapper script and messes up the escaping of the arguments when passing on to the real program. This is easy to do, or perhaps a bit hard to do correctly.
A correct wrapper script should pass all its arguments on as ${1+"$#"}, and any other version is most likely a bug with regards to being able to handle embedded spaces properly. This is not uncommon to do properly, however also any occurrences of $2 or similar are troublesome and must be written as "$2" (or possibly ${2+"$2"}) in order to handle embedded spaces properly, and this is sinned against a lot.
The reason for the not-so-intuitive syntax ${1+"$#"} is that the original $* joined all arguments as "$1 $2 $3 ..." which did not work for embedded spaces. Then "$#" was introduced that (correctly) expanded to "$1" "$2" "$3" ... for all parameters and if no parameters are given it should expand to nothing. Unfortunately some Unix vendor messed up and made "$#" expand to "" even in case of no arguments, and to work around this the clever (but not so readable) hack of writing ${1+"$#"} was invented, making "$#" only expand if parameter $1 is set (i.e. avoiding expansion in case of no arguments).
If my wrapper assumption is wrong you could try to debug with strace:
strace -o outfile -f -ff -F java test.AskGetCampaignByName "Dummy books"
and find out what arguments are passed to execve. Example from running "strace /bin/echo '1 2' 3":
execve("/bin/echo", ["/bin/echo", "1 2", "3"], [/* 93 vars */]) = 0
brk(0) = 0x2400000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f420075b000
mmap(NULL, 4096, PROT_READ|PROT_WRITE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7f420075a000
access("/etc/ld.so.preload", R_OK) = -1 ENOENT (No such file or directory)
open("/usr/lib64/alliance/lib/tls/x86_64/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/usr/lib64/alliance/lib/tls/x86_64", 0x7fff08757cd0) = -1 ENOENT (No such file or directory)
open("/usr/lib64/alliance/lib/tls/libc.so.6", O_RDONLY) = -1 ENOENT (No such file or directory)
...

In case your program needs more than positional arguments (= when the command line usage is important), you should consider options and switches. Apache Commons has a great library for this.

You just have to escape the spaces like this:
normal String: "Hello World!"
escaped String: "Hello" "World!"
That worked for me.
My environment:
23:39:19 Zarathustra#thora:/Users/Zarathustra~$bash -version
GNU bash, version 3.2.48(1)-release (x86_64-apple-darwin11)
Copyright (C) 2007 Free Software Foundation, Inc.

It sounds like you are using a operating system distribution where the java command available to the user is a wrapper which finds the right JVM "somewhere" and invokes it accordingly.
If so, it most likely does not escape the arguments properly when invoking the actual java executable.
What distribution do you use?

Just reassemble the arguments in your Java program:
StringBuilder allArgs = new StringBuilder();
for (int i=0; i < args.length; i++)
{
//System.out.println("arg"+i+": "+args[i]);
allArgs.append(args[i]+" ");
}
// Parse out the args the way you wish using allArgs