some commands require that certain flags be set in order to function.
Annotate those flags so the bash completions will suggest to the user
that they be set.
1. Move fluentd-gcp to be a core cluster addon, rather than a contrib.
2. Get rid of the synthetic logger under contrib, since the exact same
synthetic logger was also included in the logging-demo.
3. Move the logging-demo to examples, since it's effectively an example.
We should also consider adding on a GCP section to the logging-demo
example :)
A user types:
kubectl get $resource
This will cause the bash completions to suggest the possible objects the
user can ask for. The complete list right now is:
endpoints
event
limitrange
namespace
node
persistentvolume
persistentvolumeclaim
pod
replicationcontroller
resourcequota
secret
service
status
But this list should stay up2date as api objects are added or deleted
These functions call out to kubectl to get information about running
resources. They give us completions which are kubernetes aware and thus
obviously better than just cobra subcommands and flags.
Right now, our doc generation scripts notice if you make changes and
don't regen docs, don't include new docs, etc. But they miss it if your
changes should have REMOVED a doc. Both kubectl-apiversion and
kubectl-clusterinfo should have been removed, but weren't.
This patch starts tracking all generated doc files and will cause
problems if files should be removed and aren't.
This is a basic ansible repo that will do a couple of things
1) set up an etcd node
2) set up a master running apiserver, scheduler, controller-manager
3) setup any number of nodes
Hopefully this can be expanded to do things like set up skydns, set up a
private docker repo, set up an overlay network (flannel) etc etc. But
right now all it does is set up etcd and configure a master and nodes.
Instead of endpoints being a flat list, it is now a list of "subsets"
where each is a struct of {Addresses, Ports}. To generate the list of
endpoints you need to take union of the Cartesian products of the
subsets. This is compact in the vast majority of cases, yet still
represents named ports and corner cases (e.g. each pod has a different
port number).
This also stores subsets in a deterministic order (sorted by hash) to
avoid spurious updates and comparison problems.
This is a fully compatible change - old objects and clients will
keepworking as long as they don't need the new functionality.
This is the prep for multi-port Services, which will add API to produce
endpoints in this new structure.
only set the etcd servers in the apiserver config
set the --master= in the global config
still need --api_servers= different in kubelet because, ummmm, we do
comment out the apiserver config in controller and scheduler, not needed
point the proxy to api, not to etcd
It's just easier to package if we keep all the tmpfiles in one place
(even though there is only one)
All of the kube code uses /var/run/ not /run. Even though /var/run is
a link to /run on all systemd systems, it makes sense to me to keep our
codebase consistent.
Works:
--api_servers=127.0.0.1:8080
--api_servers=http://127.0.0.1:8080
--api_servers=http://localhost:8080
Fails:
--api_servers=localhost:8080
Include the http:// in the example, so users aren't likely to hit the
problem
requirement for the parameter. Sans parameter the kubelet will fail
silently trying to obtain service setting that are placed into the
ENV of the PODS.
From the systemd man page:
Use "${FOO}" as part of a word, or as a word of its own, on the command
line, in which case it will be
replaced by the value of the environment variable including
all whitespace it contains, resulting in a single argument.
Use "$FOO" as a separate word on the
command line, in which case it will be replaced
by the value of the environment variable split at
whitespace, resulting in zero or more arguments.
Since we want people to be able to use these for multiple arguments we
need to make sure we don't use {} around the env vars...