Skip to content
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

kubeadm: Implement support for using images from CI builds #49119

Merged
merged 2 commits into from
Aug 21, 2017

Conversation

kad
Copy link
Member

@kad kad commented Jul 18, 2017

What this PR does / why we need it: Implements support for CI images in kubeadm

Which issue this PR fixes (optional, in fixes #<issue number>(, fixes #<issue_number>, ...) format, will close that issue when PR gets merged): fixes kubernetes/kubeadm#337

Special notes for your reviewer:

Release note:

- kubeadm now supports "ci/latest-1.8" or "ci-cross/latest-1.8" and similar labels.

@k8s-ci-robot
Copy link
Contributor

Hi @kad. Thanks for your PR.

I'm waiting for a kubernetes member to verify that this patch is reasonable to test. If it is, they should reply with /ok-to-test on its own line. Until that is done, I will not automatically test new commits in this PR, but the usual testing commands by org members will still work. Regular contributors should join the org to skip this step.

I understand the commands that are listed here.

Instructions for interacting with me using PR comments are available here. If you have questions or suggestions related to my behavior, please file an issue against the kubernetes/test-infra repository. I understand the commands that are listed here.

@k8s-ci-robot k8s-ci-robot added needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. labels Jul 18, 2017
@k8s-github-robot k8s-github-robot added size/M Denotes a PR that changes 30-99 lines, ignoring generated files. release-note Denotes a PR that will be considered when it comes time to generate release notes. labels Jul 18, 2017
@kad
Copy link
Member Author

kad commented Jul 18, 2017

@luxas if you can add "ok-to-test" please

@k8s-github-robot k8s-github-robot added size/L Denotes a PR that changes 100-499 lines, ignoring generated files. and removed size/M Denotes a PR that changes 30-99 lines, ignoring generated files. labels Jul 18, 2017
@luxas
Copy link
Member

luxas commented Jul 19, 2017

/ok-to-test

@k8s-ci-robot k8s-ci-robot removed the needs-ok-to-test Indicates a PR that requires an org member to verify it is safe to test. label Jul 19, 2017
@kad kad force-pushed the n-addons-repo branch 2 times, most recently from 2152734 to 40b7fe6 Compare July 19, 2017 15:50
@kad
Copy link
Member Author

kad commented Jul 19, 2017

those failures seems to be now on infra side (gcs push failures)

Copy link
Member

@luxas luxas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think this can be done in way less code, without touching the API struct. In the special case of a ci/* version, we'll just use (the constant) gcr.io/kubernetes-ci-images repo in GetCoreImage()

@kad
Copy link
Member Author

kad commented Jul 19, 2017

We can't. gcr.io/kubernetes-ci-images contains only subset of images (the core ones).

@luxas
Copy link
Member

luxas commented Jul 19, 2017

@kad I didn't propose to touch cfg.ImageRepository. Instead, just pass useCIRepository or the like to GetCoreImage(). You can add a new field (e.g. cfg.UseCIRepository) on the internal version of the API for this purpose

@kad
Copy link
Member Author

kad commented Jul 19, 2017

Can you a bit elaborate about "internal version of the API" ? I'll look at this possibilities.
Second thing, that way location of images would be spread across whole source code and strictly hardcoded to gcr.io, which might be not the best in long run if people are interested to use images from local registries in isolated networks.
This current state of the code, it is possible to easily redefine via config file location of core/non-core images separately and have a custom registry for CI images as well.
Actually it can even enable use case of automatic testing via kubeadm support images like etcd or kube-dns, where tests can be deploying latest stable k8s core + via custom NonCoreImageRepository rest of images.

@luxas
Copy link
Member

luxas commented Jul 20, 2017

I'm not planning to expand the ImageRepository functionality more than we do now, instead it will eventually be possible to set all images separately via the config file. We should not over-engineer this, but keep it as simple as we can.

Hardcoding the ci/ helper to gcr.io/kubernetes-ci-images is very fine, since it's a helper. You can indeed prepull these images if you want. If you want to use a local registry, just point ImageRepository to that and set the KubernetesVersion yourself and voila!

There are two sub-API groups for the kubeadm API group, an internal version and an external
Internal: https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/apis/kubeadm/types.go
External: https://github.com/kubernetes/kubernetes/blob/master/cmd/kubeadm/app/apis/kubeadm/v1alpha1/types.go

The external one follows a more strict, versioned scheme, but the internal version may change and have more parameters used internally if applicable. I think having an UseCIImages bool or something in the internal version would make sense for this task. Then GetCoreImage would know whether to use the special CI images repo or not.

@kad
Copy link
Member Author

kad commented Jul 20, 2017

thing is, that this hardcoding in case of bool will be at least in two places (maybe more). e.g. accroding to your request kube-dns images are handled not via GetCoreImage().
Regarding internal APIs, thx, I'll check what can be done better.

@kad
Copy link
Member Author

kad commented Jul 20, 2017

@luxas updated to use only internal APIs and removed ability to configure additional image repositories.

Copy link
Member

@luxas luxas left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks much better 👍, but still needs to be modified a little to work properly. The biggest point here is that if the user specifies the ci/ prefix on the CLI, we should lookup the tag from dl.k8s.io/ci-cross.

if err != nil {
return err
}
cfg.KubernetesVersion = ver

// Requested version is automatic CI build, thus use KubernetesCI Image Repository for core images
if useCI {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Why not just move this up to check strings.HasPrefix(cfg.KubernetesVersion, "ci/") and set the CI repo on that condition? KubernetesValidateVersion will be much simpler then...

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ping

if err != nil {
return err
}
cfg.KubernetesVersion = ver

// Requested version is automatic CI build, thus use KubernetesCI Image Repository for core images
if useCI {
cfg.CIImageRepository = "gcr.io/kubernetes-ci-images"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

probably want a constant for this

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ping

kubeReleaseRegex = regexp.MustCompile(`^v?(0|[1-9][0-9]*)\.(0|[1-9][0-9]*)\.(0|[1-9][0-9]*)([-0-9a-zA-Z_\.+]*)?$`)
kubeReleaseLabelRegex = regexp.MustCompile(`^[[:lower:]]+(-[-\w_\.]+)?$`)
kubeBucketPrefixes = regexp.MustCompile(`^((release|ci|ci-cross)/)?([-\w_\.+]+)$`)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

We will only allow release and ci. What is indeed a little bit confusing is that we're gonna use artifacts from ci-cross under the hood (kubeadm user uses ci/latest => will actually fetch ci-cross/latest.txt for the version to use)

This is due to that the normal ci job does not push images

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ping

if url == "" {
url = kubeReleaseBucketURL + "/release"
}
vurl := fmt.Sprintf("%s/%s.txt", url, version)
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

vurl doesn't say much to me

// release/v1.7.1 -- same as above.
// stable-1.7 or release/stable-1.7 -- labeled official releases
// ci/v1.8.0-alpha.1.123+012345678 -- CI explicit build version
// ci/latest-1.8 or ci-cross/latest-1.8 -- CI labeled builds
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I don't think we should confuse the user with ci-cross although we fetch the images from there under the hood.
Let's not support for ci-cross/ at the moment.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ping

// ci/latest-1.8 or ci-cross/latest-1.8 -- CI labeled builds
//
// Returns: version, build is release (false) or CI (true), error.
func KubernetesValidateVersion(version string) (string, bool, error) {
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I find the relationship between KubernetesValidateVersion and KubernetesReleaseVersion kind of strange.
What I think we want is this:

  • Have a function that takes cfg.KubernetesVersion (may be a label) and just return the resulting "real" version we can use. Basically what KubernetesReleaseVersion is today.

This would do the following:
If it already is a valid version, return
If it matches (release/)?(stable|latest)(-1.[0-9]{1})?, unconditionally trim the release/ prefix and fetch real version from dl.k8s.io/release/%s.txt and return
If it matches ci/latest(-1.[0-9]{1})?, unconditionally trim the ci/ prefix and fetch the real version from dl.k8s.io/ci-cross/%s.txt and return

That will do what we want. Feel free to create private helper functions for that main function.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

ping

@kad
Copy link
Member Author

kad commented Jul 20, 2017

Regarding ci vs ci-cross prefix: there are two different latest.txt files in those buckets. It supports both. Having those tricks to substitute one with another invisible for user sounds like over
engineering to me. Check get-kube.sh, based on what user asked, it will fetch corresponding version file.

@kad
Copy link
Member Author

kad commented Jul 20, 2017

@luxas any hint on how to fix those unit test failures ? they are both related to declare only internally used variable in MasterConfiguration that supposed to be not exposed to versioned external API and not to config ?

@luxas
Copy link
Member

luxas commented Jul 20, 2017

Regarding ci vs ci-cross prefix: there are two different latest.txt files in those buckets. It supports both. Having those tricks to substitute one with another invisible for user sounds like over
engineering to me. Check get-kube.sh, based on what user asked, it will fetch corresponding version file.

That's not how this works. No images are pushed from the job that uploads to ci/latest.txt. Only from the ci-cross job that uploads to ci-cross/latest.txt.

@luxas luxas self-assigned this Aug 2, 2017
@kad
Copy link
Member Author

kad commented Aug 18, 2017

Updated.

@luxas
Copy link
Member

luxas commented Aug 18, 2017

/lgtm
/retest

Thanks!

@k8s-ci-robot k8s-ci-robot added the lgtm "Looks good to me", indicates that a PR is ready to be merged. label Aug 18, 2017
@k8s-github-robot
Copy link

[APPROVALNOTIFIER] This PR is APPROVED

This pull-request has been approved by: kad, luxas

Associated issue: 337

The full list of commands accepted by this bot can be found here.

Needs approval from an approver in each of these OWNERS Files:

You can indicate your approval by writing /approve in a comment
You can cancel your approval by writing /approve cancel in a comment

@k8s-github-robot k8s-github-robot added the approved Indicates a PR has been approved by an approver from all required OWNERS files. label Aug 18, 2017
@luxas
Copy link
Member

luxas commented Aug 18, 2017 via email

@luxas
Copy link
Member

luxas commented Aug 18, 2017 via email

@fejta-bot
Copy link

/retest
This bot automatically retries jobs that failed/flaked on approved PRs (send feedback to @fejta).

Review the full test history for this PR.

@luxas
Copy link
Member

luxas commented Aug 19, 2017 via email

@fejta-bot
Copy link

/retest
This bot automatically retries jobs that failed/flaked on approved PRs (send feedback to @fejta).

Review the full test history for this PR.

3 similar comments
@fejta-bot
Copy link

/retest
This bot automatically retries jobs that failed/flaked on approved PRs (send feedback to @fejta).

Review the full test history for this PR.

@fejta-bot
Copy link

/retest
This bot automatically retries jobs that failed/flaked on approved PRs (send feedback to @fejta).

Review the full test history for this PR.

@fejta-bot
Copy link

/retest
This bot automatically retries jobs that failed/flaked on approved PRs (send feedback to @fejta).

Review the full test history for this PR.

@luxas
Copy link
Member

luxas commented Aug 19, 2017

/retest

@fejta-bot
Copy link

/retest
This bot automatically retries jobs that failed/flaked on approved PRs (send feedback to @fejta).

Review the full test history for this PR.

9 similar comments
@fejta-bot
Copy link

/retest
This bot automatically retries jobs that failed/flaked on approved PRs (send feedback to @fejta).

Review the full test history for this PR.

@fejta-bot
Copy link

/retest
This bot automatically retries jobs that failed/flaked on approved PRs (send feedback to @fejta).

Review the full test history for this PR.

@fejta-bot
Copy link

/retest
This bot automatically retries jobs that failed/flaked on approved PRs (send feedback to @fejta).

Review the full test history for this PR.

@fejta-bot
Copy link

/retest
This bot automatically retries jobs that failed/flaked on approved PRs (send feedback to @fejta).

Review the full test history for this PR.

@fejta-bot
Copy link

/retest
This bot automatically retries jobs that failed/flaked on approved PRs (send feedback to @fejta).

Review the full test history for this PR.

@fejta-bot
Copy link

/retest
This bot automatically retries jobs that failed/flaked on approved PRs (send feedback to @fejta).

Review the full test history for this PR.

@fejta-bot
Copy link

/retest
This bot automatically retries jobs that failed/flaked on approved PRs (send feedback to @fejta).

Review the full test history for this PR.

@fejta-bot
Copy link

/retest
This bot automatically retries jobs that failed/flaked on approved PRs (send feedback to @fejta).

Review the full test history for this PR.

@fejta-bot
Copy link

/retest
This bot automatically retries jobs that failed/flaked on approved PRs (send feedback to @fejta).

Review the full test history for this PR.

@luxas
Copy link
Member

luxas commented Aug 21, 2017

/retest

@k8s-github-robot
Copy link

Automatic merge from submit-queue (batch tested with PRs 50693, 50831, 47506, 49119, 50871)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
approved Indicates a PR has been approved by an approver from all required OWNERS files. cncf-cla: yes Indicates the PR's author has signed the CNCF CLA. lgtm "Looks good to me", indicates that a PR is ready to be merged. release-note Denotes a PR that will be considered when it comes time to generate release notes. size/L Denotes a PR that changes 100-499 lines, ignoring generated files.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Make kubeadm able to consume CI images
7 participants