Combine the fields that will be used for content transformation
(content-type, codec, and group version) into a single struct in client,
and then pass that struct into the rest client and request. Set the
content-type when sending requests to the server, and accept the content
type as primary.
Will form the foundation for content-negotiation via the client.
- wget is not installed by default on fedora 23. Use curl instead
since it is always available on recent Fedora.
- The repo url for cockpit resulted in an http redirect message being
saved as the repo file which broke deployment. Update the url to
url that was redirected to and ensure that future redirects will be
handled correctly.
- The main Fedora 23 repo includes salt packages, and there is no
salt repo for 23. The salt bootstrap still creates a repo file for
a nonexistent repo, though, and this change removes it to avoid
having dnf report an error on every update.
build-runtime-config was being called in verify-prereqs, which didn't
match how GCE called it, and didn't seem to actually work.
Instead call it just before the master configuration is built. Also
call it just before the node configuration is built, even though the
nodes don't _currently_ require the runtime_config.
To fix it, I just add openssl depedency on "generate-cert" state. It
should work on Debian-like and RedHat-Like systems. (and, Archlinux,
Opensuse, etc)
Fixed error :
$ sudo salt 'kubernetes-master' state.apply
----------
ID: kubernetes-cert
Function: cmd.script
Result: False
Comment: Command 'kubernetes-cert' run
Started: 06:57:06.634203
Duration: 208.719 ms
Changes:
----------
pid:
793
retcode:
1
stderr:
/tmpm24T3R.sh: line 22: openssl: command not found
chgrp: cannot access '/srv/kubernetes/server.key': No such file or directory
chgrp: cannot access '/srv/kubernetes/server.cert': No such file or directory
chmod: cannot access '/srv/kubernetes/server.key': No such file or directory
chmod: cannot access '/srv/kubernetes/server.cert': No such file or directory
stdout:
After applying my patch (success) :
----------
ID: kubernetes-cert
Function: cmd.script
Result: True
Comment: Command 'kubernetes-cert' run
Started: 07:17:04.172384
Duration: 1041.092 ms
Changes:
----------
pid:
1045
retcode:
0
stderr:
Generating a 4096 bit RSA private key
......................................................................++
...............................................................................++
writing new private key to '/srv/kubernetes/server.key'
-----
stdout:
----------
If we don't use an elastic IP, the IP address will be lost if we lose
the master for any reason, and a replacement master will not have the
same IP. But the master IP is set both in client kubeconfig files and
the master SSL certificate. Hence the default should be to allocate an
elastic IP for the master.
One complication: AWS doesn't allow tags on elastic IPs, so it is hard
to track the elastic IP so we can delete it as part of kube-down.
Instead, we take the master EBS volume with the elastic IP. This is a
little odd, but works because the master volume & the master elastic IP
really need to be assigned to the same machine, so might be thought of
as a pair.
Also, we now delete the master EBS volume as part of kube-down, as
people expect kube-down to clean-up everything it creates.
