In the reference docs, they say you can print the image of a container like so.
kubectl get pod test-pod -o custom-columns=CONTAINER:.spec.containers[0].name,IMAGE:.spec.containers[0].image
However, when I try any command that has brackets, I get an error message and no output.
no matches found: custom-columns=CONTAINER:.spec.containers[0].name,IMAGE:.spec.containers[0].image
if I just specify something like .spec.containers it will output the entire array similar to this:
[map[image:weaveworksplugins/scope-traffic-control:latest imagePullPolicy:Always name:weavescope-traffic-control-plugin resources:map[requests:map[cpu:100m]] securityContext:map[privileged:true procMount:Default] terminationMessagePath:/dev/termination-log terminationMessagePolicy:File volumeMounts:[map[mountPath:/var/run/docker.sock name:docker-sock] map[mountPath:/var/run/scope/plugins name:scope-plugins]
...
Kubectl version information
Client Version: version.Info{Major:"1", Minor:"15", GitVersion:"v1.15.2", GitCommit:"f6278300bebbb750328ac16ee6dd3aa7d3549568", GitTreeState:"clean", BuildDate:"2019-08-05T16:54:35Z", GoVersion:"go1.12.7", Compiler:"gc", Platform:"darwin/amd64"}
Server Version: version.Info{Major:"1", Minor:"14", GitVersion:"v1.14.2", GitCommit:"66049e3b21efe110454d67df4fa62b08ea79a19b", GitTreeState:"clean", BuildDate:"2019-05-16T16:14:56Z", GoVersion:"go1.12.5", Compiler:"gc", Platform:"linux/amd64"}
That's a shell (probably ZSH?) error message, not related to kubectl. You need to quote the string that contains the [ and ] so they don't get interpreted as shell metachars.
kubectl get pod test-pod \
-o custom-columns='CONTAINER:.spec.containers[0].name,IMAGE:.spec.containers[0].image'
Related
I installed miniconda via choco install miniconda3.
Creating a python3 environment works fine.
conda create --name envA python=3 --verbose
But creating a python2 environment has a problem.
conda create --name envB python=2 --verbose
Collecting package metadata (current_repodata.json): ...working... done
Solving environment: ...working... failed with repodata from current_repodata.json, will retry with next repodata source.
Collecting package metadata (repodata.json): ...working... done
Solving environment: ...working...
Found conflicts! Looking for incompatible packages.
failed
Traceback (most recent call last):
...
File "C:\Users\fred\miniconda3\lib\site-packages\conda\resolve.py", line 352, in find_conflicts
raise UnsatisfiableError(bad_deps, strict=strict_channel_priority)
conda.exceptions.UnsatisfiableError
#cel gets credit for this
Switching to mamba provided better diagnostics.
mamba create -n foo python=2
Looking for: ['python=2']
conda-forge/win-64 Using cache
conda-forge/noarch Using cache
Encountered problems while solving:
- nothing provides vc 9.* needed by python-2.7.12-0
Then use mamba to find vc.
mamba search vc
# Name Version Build Channel
vc 14.1 h21ff451_1 conda-forge
vc 14.1 h6d1b3ff_2 conda-forge
...
The vc v9 can be found in the defaults channel.
mamba search 'vc[channel=defaults]'
# Name Version Build Channel
vc 9 h2eaa2aa_6 pkgs/main
...
Updating the .condarc with the defaults channel, corrected the problem.
channels:
- conda-forge
- defaults
channel_priority: disabled
As a final note, should someone else find themselves in this situation...
The ~/.condarc got changed (dropping the defaults channel) as part of installing mambaforge.
I need your help. I have this error, I managed to convert the .json file from version 1.0.0 to version 2.0.0.0 with the following command at the prompt
C:\Users\AC\Desktop\test>postman-collection-transformer convert -i test.json -o prueba1.json -j 1.0.0 -p 2.0.0 -P
In the following url is the collection that I converted and the one that after making the changes in Visual, it doesn't update. and when I send the request, the file is not updated with the changes that I specify in Visual Studio Code, I don’t know what could be going wrong. Why Postman doesn't allow version 1.0.0?
Capture Visual
Anaconda run
In this image it should return me an id, not that phrase. It's as if after the conversion something is lost.
it won't update the file it will create a new collection file :
postman-collection-transformer convert -i old_collection.json -o new_collection.json -j 1.0.0 -p 2.0.0 -P
the above command converts the v1 "old_collection.json" file and creates a new_collection.json
There is curl v7.19.7 on my cnetos. Since I want to develop c++ program to send email, I got the curl v7.50.3 source code and install it(configure, make, make install). Although my c++ program build successfully, but when I try to execute it, there are errors:
* Protocol smtp not supported or disabled in libcurl
* Unsupported protocol
curl_easy_perform() failed: Unsupported protocol
When I proceed command: curl --version, it shows:
curl 7.50.3 (x86_64-pc-linux-gnu) libcurl/7.19.7 NSS/3.13.6.0 zlib/1.2.3 libidn/1.18 libssh2/1.4.2
It seems libcurl still refer to the older version!
Although I try to
1. rpm -q curl
2. rpm -e --nodeps curl-7.19.7-35.el6.x86_64
but it comes out no difference. I also add "/usr/local/lib" in /etc/ld.so.conf, still not working!
How can I do to remove old version curl library(v7.19.7) clearly, let my c++ program refer to the new version curl(v7.50.3)?
Try using "ldd" on your executable to check what version of curl it is using.
Make sure the libcurl path matches "/usr/local/lib" or whereever you installed the curl you compiled
[user#computer bin]$ ldd myExecutable | grep curl
libcurl.so.4 => /usr/local/lib/libcurl.so.4 (0x00...)
You can use following commands;
rpm -Uvh http://www.city-fan.org/ftp/contrib/yum-repo/city-fan.org-release-2-1.rhel6.noarch.rpm
yum --enablerepo=city-fan.org update curl
Enter this command to see the version;
curl -V
We are upgrading our gsoap version from 2.7.8 to the latest version 2.8.33
When our make file runs soapcpp2.exe and wsdl2h.exe with the exact same flags, I don't get the exact same classes and API, so I figured I'll have to tweak them a little bit.
We used to run soapcpp2.exe with these flags: -C -L -x -I
The first noticeable change was classes inheriting from structs soap rather than pointing to them. I was able to solve this compatibility issue by adding -j.
Now, I am encountering another incompatibility where a function
SOAP_FMAC5 int SOAP_FMAC6 soap_serve_request(struct soap *soap)
is absent.
I searched the gsoap code and found it, so I guess there's some way to make gsoap to generate it. Is there really a way to make gsoap generate this function, or will I have to adjust my code/ write the function myself
The gsoap tools have options to support backward compatibility. Run soapcpp2 -h to see your options:
Usage: soapcpp2 [-0|-1|-2] [-C|-S] [-T] [-Ecdt] [-L] [-a] [-A] [-b] [-c|-c++|-c++11] [-d path] [-e] [-f N] [-h] [-i] [-I path:path:...] [-l] [-m] [-n] [-p name] [-Q name] [-q name] [-r] [-s] [-t] [-u] [-v] [-w] [-x] [-y] [-z#] [infile]
...
...
-z1 compatibility: generate old-style C++ service proxies and objects
-z2 compatibility with 2.7.x: omit XML output for NULL pointers
-z3 compatibility with 2.8.30 and earlier: _param_N is indexed globally
Try -z1.
PS. The old proxy and service classes with option -z1 are more simplistic, the new classes generated with option -j are an improvement. But when you're generating service classes with -j the C-like API with global functions are gone (a good thing IMO).
In Jetty 8 I was passing values like -Djetty.port=8888 -DSTOP.PORT=8887 -DSTOP.KEY=STOP but in Jetty 9 these don't seem to work.
I am able to set the port with --module=http jetty.port=8888 but am not sure how to set the other values?
Also, I used to use the command java -DSTOP.PORT=8887 -DSTOP.KEY=STOP -jar start.jar --stop but am not sure how to run the stop command now?
The docs at http://www.eclipse.org/jetty/documentation/current/start-jar.html#d0e8360 suggest that stopping hasn't changed, but when I try that I get
java.net.ConnectException: Connection refused: connect
at java.net.DualStackPlainSocketImpl.connect0(Native Method)
at java.net.DualStackPlainSocketImpl.socketConnect(Unknown Source)
at java.net.AbstractPlainSocketImpl.doConnect(Unknown Source)
at java.net.AbstractPlainSocketImpl.connectToAddress(Unknown Source)
at java.net.AbstractPlainSocketImpl.connect(Unknown Source)
at java.net.PlainSocketImpl.connect(Unknown Source)
at java.net.SocksSocketImpl.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.connect(Unknown Source)
at java.net.Socket.<init>(Unknown Source)
at java.net.Socket.<init>(Unknown Source)
at org.eclipse.jetty.start.Main.stop(Main.java:761)
at org.eclipse.jetty.start.Main.stop(Main.java:740)
at org.eclipse.jetty.start.Main.start(Main.java:648)
at org.eclipse.jetty.start.Main.main(Main.java:103)
Usage: java -jar start.jar [options] [properties] [configs]
java -jar start.jar --help # for more information
TIA
I have experienced the same problem, but found it has always been an overlooked mistake on my part. With that being said, I think you are actually on the right track.
This should work
With
jetty-distribution-9.2.7.v20150116
the following sequence does work:
# setting up jetty config
java -jar mypath/start.jar --add-to-startd=http,deploy
# check to see if the ports are available
netstat -tapn | grep "808[07]"
# starting server
java -DSTOP.PORT=8087 -DSTOP.KEY=STOP -jar mypath/start.jar
# check to see if the ports are now monitored
netstat -tapn | grep "808[07]"
# starting server
java -DSTOP.PORT=8087 -DSTOP.KEY=STOP -jar mypath/start.jar --stop
# check to see if the ports are now free
netstat -tapn | grep "808[07]"
Preferred syntax
The above -D syntax works, but the following syntax is better supported:
java -jar mypath/start.jar STOP.PORT=8087 STOP.KEY=STOP
java -jar mypath/start.jar STOP.PORT=8087 STOP.KEY=STOP --stop
java -jar mypath/start.jar STOP.PORT=8087 STOP.KEY=STOP --list-config
java -jar mypath/start.jar STOP.PORT=8087 STOP.KEY=STOP --dry-run
You can easily confirm that this syntax does work by trying it.
Additional steps
Those last two commands (--list-config and --dry-run) can be very handy for checking a variety of problems.
The --help command is also very useful to sanity checking odd problems like this. It does reveal nuances like the above preferred syntax that you found difficult to find:
java -jar mypath/start.jar --help
If you've already tried these steps, try upgrading to a newer version of Jetty in case the problem you experienced was an actually bug that was subsequently fixed.
If it still doesn't work, I'll try to help you and update this "answer" appropriately.