fleetctl: add list-unit-files command

This is functionally equivalent to `fleetctl list-units --fields
unit,hash,dstate' for now; it will start to make more sense as the registry
API and `fleetctl list-units` receive their own changes.

Not really sure on good descriptions so open to suggestions.
I think it's reasonable for us to do the following:
- when a user submits a unit, whether via api (unitoptions) or command line
(actual unit file), we serialise to a "canonical" unit file (which then
becomes immutable) and store in the back end
- canonical unit file is hashed and that hash is returned to the user at
unit creation time
- client introspection (eg fleetctl cat) will show the canonical unit file,
ie not necessarily identical to what the user submitted, but consistent

The only problem I see here is if you are trying to go in the direction of
units not being immutable eg to support schema migrations or whatever...
But I'm not sure that's a good path.
On Jul 20, 2014 9:31 PM, "Brian Waldon" <notifications@github.com> wrote:

> In fleetctl/list_unit_files.go:
>
> > +	listUnitFilesFieldsFlag string
> > +	cmdListUnitFiles        = &Command{
> > +		Name:        "list-unit-files",
> > +		Summary:     "List the units loaded into the cluster",
> > +		Usage:       "[--fields]",
> > +		Description: `Lists all units loaded into the cluster.`,
> > +		Run:         runListUnitFiles,
> > +	}
> > +	listUnitFilesFields = map[string]jobToField{
> > +		"unit": func(j *job.Job, full bool) string {
> > +			return j.Name
> > +		},
> > +		"dstate": func(j *job.Job, full bool) string {
> > +			return string(j.TargetState)
> > +		},
> > +		"hash": func(j *job.Job, full bool) string {
>
> My original concern was a bit orthogonal to what you bring up. If we are
> no longer storing a unit file in the original format provided by the user,
> the approach to comparing fleet jobs based on unit hashes no longer works.
> fleet will generate a hash from a serialized list of UnitOption objects,
> while the user will have the original unit file on disk. Those will not
> match.
>
> In the scenario you bring up, we will still be able to generate hashes of
> different unit files that a user could compare, they just wouldn't be able
> to generate a hash of a local file and compare that to what fleet reports.
>
> —
> Reply to this email directly or view it on GitHub
> <https://github.com/coreos/fleet/pull/688/files#r15154917>.
>