This repository has been archived by the owner on Nov 1, 2022. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 1.1k
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
In reference to #1504
Mainly to account for using "release series" branches, as we've started to do. And to be a bit more generous with explanation.
Now that Kubernetes 1.12 is GA, we are running into problems where YAMLs that are valid for 1.12 are rejected by kubectl. For example, it doesn't like validation of custom resources -- something we use ourselves in the HelmRelease CRD. kubectl versions are officially compatible with one version behind and one version ahead; this effectively drops support for Kubernetes 1.9, though I would expect it to still work. (For reference, Kubernetes 1.10 was released in March 2018.)
Bump baked-in kubectl to 1.11.3
Housekeeping: merge release branch 1.8.x back into master
Update doc on release process
Sample yaml with annotations.
- Flux 1.8.1 - Helm Operator 0.5.0
Helm chart release 0.5.0
Fix chart version in upgrade guide
- remove helm-op git flags - fix typos - set example repo to weaveworks/flux-get-started - use the same git URL format everywhere
- remove GKE node constraint since it doesn't apply anymore
- remove GKE node constraint since it doesn't apply anymore
Prevent Helm release deletion of installed charts
- fix typos - add back the git timeout and poll interval
Co-Authored-By: stefanprodan <stefan.prodan@gmail.com>
Use weaveworks/flux-get-started repo in docs
- fix upgrade from helm-op 0.4 to 0.5
Signed-off-by: David J. M. Karlsen <david@davidkarlsen.com>
Helm chart: parameterize memcached image
Signed-off-by: Hidde Beydals <hello@hidde.co>
Document correct Helm op flags
Add CHANGELOG to Helm chart
Try to make private registry FAQ less confusing
Unless the newly committed change has been synced, rollout status will usually return "ready" trivially. Therefore, always wait for job completion _and_ sync (using `await`) whether `--watch` was passed or not. Secondarily, - it doesn't make sense for someone to fluxctl release --dry-run --watch so make that a usage error. - print the updated pods vs desired, which gives a slightly better indication of progress; ready pods counts those that are outdated, so tends to be almost the same as desired. It's still not perfect -- I don't think there is a perfect -- since updated is different to updated-and-ready (I think).
Here I am trying to walk the line between giving accurate advice, and recognising that the notifications are particular to Weave Cloud (albeit fluxcloud can also do something with them). Fixes #1587.
Add helm install timeout option
Make it clear Slack integration uses a service
`sha256sum` is not available (by default?) on MacOS. Use `shasum -a 256` instead -- even though `shasum` is installed via the perl package on Linux dists, it is more reliably present there and in MacOS. A minor tweak is needed to the checksum file format (and extra space) to make shasum happy.
Use shasum -a 256 rather than sha256sum
Some tests may depend on the helm binary, so make it a dependency. And, since we want to test with the binary that's being baked into the image, put it first on the $PATH.
Running locally, it's likely that you'll already have helm set up; but this isn't the case in CI, and only a coincidence. Therefore, create a temp directory and use that as Helm's home dir when testing.
Upstream git hosts (e.g., GitHub) can treat each tag push as a fresh event for the purpose of their own notifications; and since fluxd pushes the sync tag, every sync, unconditionally, this means there are many many events. To avoid most of these spurious events, we can push the tag only when it looks like it's changed. That is, when the HEAD of the branch points at a different revision to the sync tag. This was already the condition used to guard _logging_ the sync event. You might question whether it's safe to push the tag conditionally -- could it result in an invalid state? - in a correct configuration, the sync loop in a single fluxd will be the only process moving the tag -- so the view in that process is the only one that matters; - in an _incorrect_ configuration (e.g., more than one fluxd using the same sync tag), we might fail to push the tag if some other process has already shifted it to the revision we're looking at. In that case, we wouldn't want to move it anyway. (And if someone has shifted the tag to a different revision, well we would have pushed it before ..)
…nged Move sync tag only when changed
…tl-release Add `--watch` option to release command
Add tests for updateDependencies
We don't want to fail at updating chart dependencies when a chart doesn't have a requirements.yaml file (which is optional, for a chart). However, we _do_ want to fail if the chart doesn't exist in the filesystem at all.
…xist Check that chart exists when updating its deps
hiddeco
suggested changes
Dec 19, 2018
CHANGELOG.md
Outdated
- The experimental flag `fluxctl release --watch` shows the rollout | ||
progress of workloads in the release | ||
[weaveworks/flux#1525][#1525] | ||
- The example manifests now include resource requests, to hepl |
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.
'hepl' -> 'help'
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.
Always gotta have a typo, it's basically a law of nature :-S
squaremo
force-pushed
the
release/1.8.2
branch
from
December 19, 2018 12:18
b405544
to
5724cc0
Compare
hiddeco
approved these changes
Dec 19, 2018
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
This pulls master into the release branch (a fast-forward), and adds a changelog entry for v1.8.2.
I'm trying a new format for the changelog entry, using condensed links. It makes the markup for individual line items a bit more readable, and getting the links right is a bit more methodical.