Skip to content
This repository has been archived by the owner on Nov 1, 2022. It is now read-only.

Release Flux v1.8.2 #1608

Merged
merged 113 commits into from
Dec 19, 2018
Merged

Release Flux v1.8.2 #1608

merged 113 commits into from
Dec 19, 2018

Conversation

squaremo
Copy link
Member

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.

Monty Zukowski and others added 30 commits November 13, 2018 10:39
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.)
Housekeeping: merge release branch 1.8.x back into master
Sample yaml with annotations.
- Flux 1.8.1
- Helm Operator 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
- purge a Helm release only if there is a single revision and that one failed
- prevent Helm release deletion if Kubernetes API connectivity is flaky
- fix #1524 #1447
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
- purge a Helm release only if there is a single revision and that one failed
- prevent Helm release deletion if Kubernetes API connectivity is flaky
- fix #1524 #1447

(cherry picked from commit 9571c6a)
davidkarlsen and others added 25 commits December 7, 2018 15:14
Signed-off-by: David J. M. Karlsen <david@davidkarlsen.com>
Helm chart: parameterize memcached image
Signed-off-by: Hidde Beydals <hello@hidde.co>
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 ..)
…tl-release

Add `--watch` option to release command
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
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
Copy link
Member

Choose a reason for hiding this comment

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

'hepl' -> 'help'

Copy link
Member Author

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 squaremo merged commit e3baeeb into release/1.8.x Dec 19, 2018
@hiddeco hiddeco deleted the release/1.8.2 branch April 11, 2019 13:08
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

10 participants