Releases: coreos/fleet
v0.5.0
v0.3.3
v0.4.0
Features
- #235: Add support for mount, auto mount, device unit types
- #337: Allow user to choose fields displayed by
fleetctl list-units
- #179: Make available unit SHA1 field to
fleetctl list-units
- #428: Warn user when using fleetctl binary older than cluster
- #455: Block forever in fleetctl load/unload/start/stop commands
- #473: Sort output of
fleetctl list-machines
by ID
Bugs
v0.3.2
v0.3.1
Bugs Fixed
- #373: check for jobs that have actionable work during engine startup
- #407: agent destroys units it should not be running on startup
- #410: fleetctl uses correct format for known_hosts file
- #411: refactor event code to use a single etcd watcher
- #414: units are no longer enabled when loading on a fleet agent
- #420: refuse to start fleet daemon if /etc/machine-id unreadable or empty
- #427: track necessary job state during agent initialization
- #438: fleet no longer panics due to botched etcd lookup
v0.3.0
New Features
- Improved job state machine - see
fleetctl load/unload
and thefleetctl list-units
STATE column - Support timer and path unit types
- Add an
X-ConditionMachineMetadata
unit option (replaces--require
flag) - Add an
X-ConditionMachineID
unit option (replacesX-ConditionMachineBootID
option) - Add debug output to fleetctl
- Assume
.service
extension if not provided in fleetctl commands
Major Bugs Fixed
- #377: Cluster should not destroy itself during etcd leader election
Other Changes
- Use machine ID instead of boot ID to identify Agents
- Stop generating default peers of socket units
- Stop publishing socket information with unit state
- Stop calling 'enable' when starting unit under Agent
Upgrade Notes
While fleet is still under heavy development it is not reasonable to expect a seamless rolling upgrade of a fleet cluster. Do not expect a cluster to be usable with mixed versions of fleet, and do not expect old versions of fleetctl to work after the cluster has been upgraded.
An upgrade from v0.2 to v0.3 will not result in the loss of existing units, but any units that were active pre-upgrade may need to be be restarted post-upgrade. Using the new fleetctl binary, you can run fleetctl start --no-block
on your units before beginning the upgrade to automatically transition them to a launched
state once the upgrade is complete.
v0.2.0
Along with several bug-fixes, this release contains several new features:
Security
- signed payloads
- host key verification
Usability
fleetctl ssh
attempts to autodetect argument as machine vs unitfleetctl journal --follow
will stream logs from systemd-journal back to the userfleetctl start
will block until unit is scheduled or timeout is reached - disable with --no-blockfleetctl ssh --forward-agent
will forward the local ssh-agent through the established connection- fleetctl ssh, journal, and status commands will only establish SSH connections if necessary
Debuggability
- fleet agents publish version information to etcd
- fleet agents dump state when SIGUSR1 received
v0.1.4
v0.1.3
In addition to numerous bug fixes, this release contains the following features:
- Environment-variable configuration of
fleet
andfleetctl
- Better error-handling and documentation of SSH authentication in
fleetctl
- Documentation of how scheduling decisions are made and may be influenced
- Unit descriptions now exposed in
fleetctl list-units
command