Martin Pitt <martin(a)piware.de> writes:
Marius Vollmer [2017-02-08 14:27 +0200]:
> If someone drops /etc/cockpit/machines.d/10-foo.json, will those
> machines immediatly show up on the dashboard?
Would be nice at some point, with an inotify watch. My gut feeling was that
this was a version 2 thing, as we don't do this right now either.
We do, actually. If you change /var/lib/cockpit/machines.json with vi,
say, this has immediate effect on the dashboard. The magic is provided
by cockpit.file(...).watch():
http://cockpit-project.org/guide/latest/cockpit-file.html
We have equivalent magic for watching directories, but there is no nice
JavaScript API for that yet, I think. (The "fslist1" channel payload,
documented in .../cockpit/doc/protocol.md.)
> Or would those machines only be available for autocompletion when
the
> user explicitly adds a machine to the dashboard?
I think they should appear in full, like an entry from our current
/var/.../machines.json.
The current machines.json has a "visibility" property, and removing a
machine actually just sets that property to false. This way, Cockpit
remembers the address and color of the machine and can offer it for
autocompletion and the machine gets the same color again next time it is
added.
> If the user now adds or removes such a machine or changes the
color for
> it, where does Cockpit store this? In 10-foo.json or in 99-webui.json?
Hmm, good question. My original intent was to change the file that defines the
host entry, i. e. 10-foo.json in this example. This would look less confusing,
but it might cause conflicts if 10-foo.json is being by puppet or similar which
would then stomp over the config again.
However, the same is true for pretty well every other setting that
cockpit (indirectly) can make, such as hostname or time zone.
Yeah, but that's a bug, not a feature. :-) Ideally, we would like to
prevent people from running into conflicts with other management tools,
see
https://trello.com/c/lPweIUlQ/325-spike-markers-for-config-management-tools
> I think this is implicitly addressed in the wiki page, since it
proposes
> to merge all the json files. So changing a color or visibility would go
> to 99-webui.json, which would overwrite what is already in 10-foo.json.
That would technically work too, yes. When reading we must support merging, the
question is just where we write updates to. I don't have a strong opinion about
that, though.
I would write to 99-webui.json only.