-
Notifications
You must be signed in to change notification settings - Fork 38.6k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add release support for trusty kube-system manifests #18485
Changes from all commits
File filter
Filter by extension
Conversations
Jump to
Diff view
Diff view
There are no files selected for viewing
Original file line number | Diff line number | Diff line change |
---|---|---|
|
@@ -653,6 +653,7 @@ function kube::release::package_tarballs() { | |
kube::release::package_client_tarballs & | ||
kube::release::package_server_tarballs & | ||
kube::release::package_salt_tarball & | ||
kube::release::package_kube_manifests_tarball & | ||
kube::util::wait-for-jobs || { kube::log::error "previous tarball phase failed"; return 1; } | ||
|
||
kube::release::package_full_tarball & # _full depends on all the previous phases | ||
|
@@ -849,6 +850,36 @@ function kube::release::package_salt_tarball() { | |
kube::release::create_tarball "${package_name}" "${release_stage}/.." | ||
} | ||
|
||
# This will pack kube-system manifests files for distros without using salt | ||
# such as Ubuntu Trusty. | ||
# | ||
# There are two sources of manifests files: (1) some manifests in the directory | ||
# cluster/saltbase/salt can be directly used on instances without salt, so we copy | ||
# them from there; (2) for the ones containing salt config, we cannot directly | ||
# use them. Therefore, we will maintain separate copies in cluster/gce/kube-manifests. | ||
function kube::release::package_kube_manifests_tarball() { | ||
kube::log::status "Building tarball: manifests" | ||
|
||
local release_stage="${RELEASE_STAGE}/manifests/kubernetes" | ||
rm -rf "${release_stage}" | ||
mkdir -p "${release_stage}" | ||
|
||
# Source 1: manifests from cluster/saltbase/salt. | ||
# TODO(andyzheng0831): Add more manifests when supporting master on trusty. | ||
local salt_dir="${KUBE_ROOT}/cluster/saltbase/salt" | ||
cp "${salt_dir}/fluentd-es/fluentd-es.yaml" "${release_stage}/" | ||
cp "${salt_dir}/fluentd-gcp/fluentd-gcp.yaml" "${release_stage}/" | ||
cp "${salt_dir}/kube-registry-proxy/kube-registry-proxy.yaml" "${release_stage}/" | ||
# Source 2: manifests from cluster/gce/kube-manifests. | ||
# TODO(andyzheng0831): Enable the following line after finishing issue #16702. | ||
# cp "${KUBE_ROOT}/cluster/gce/kube-manifests/*" "${release_stage}/" | ||
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. @andyzheng0831 You cc'd the wrong person :) Do you have a branch that has the examples that has the There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. Not yet. I am working on the master side change but still keep it locally. Currently, I am switching to make another change, i.e., move kube-proxy into a static pod, just like #17121. The newly added manifest for kube-proxy (https://github.com/kubernetes/kubernetes/blob/master/cluster/saltbase/salt/kube-proxy/kube-proxy.manifest) contains salt config. So I plan to copy it to cluster/gce/kube-manifests. My idea is that we remove the salt content, replace all variables in {{var}} format. Then, the shell script can replace the variables with real values. What do you think? |
||
|
||
kube::release::clean_cruft | ||
|
||
local package_name="${RELEASE_DIR}/kubernetes-manifests.tar.gz" | ||
kube::release::create_tarball "${package_name}" "${release_stage}/.." | ||
} | ||
|
||
# This is the stuff you need to run tests from the binary distribution. | ||
function kube::release::package_test_tarball() { | ||
kube::log::status "Building tarball: test" | ||
|
@@ -912,6 +943,7 @@ function kube::release::package_full_tarball() { | |
mkdir -p "${release_stage}/server" | ||
cp "${RELEASE_DIR}/kubernetes-salt.tar.gz" "${release_stage}/server/" | ||
cp "${RELEASE_DIR}"/kubernetes-server-*.tar.gz "${release_stage}/server/" | ||
cp "${RELEASE_DIR}/kubernetes-manifests.tar.gz" "${release_stage}/server/" | ||
|
||
mkdir -p "${release_stage}/third_party" | ||
cp -R "${KUBE_ROOT}/third_party/htpasswd" "${release_stage}/third_party/htpasswd" | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
nit: consider folding the manifests in an array and looping on them, as you plan to add more?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yes, will go that way for better readability when we add more files. Currently it has only 3, so should be fine.