Cockpit support

[agrover]

https://cockpit-project.org/ is the current graphical administration interface for servers, so Stratis configuration should be supported there.

Related issues:

• The root object, the one that implements the ObjectManager interface, should not appear in the result of a GetManagedObjects call #216
• Script to allow Cockpit to use stratisd to set key in kernel keyring safely #219
• Investigate if dbus-rs emits InterfaceChanged signals properly stratisd#1377
• Expose key descriptions for encrypted, locked pools stratisd#2179
• Consider exposing the physical path for a block device on the D-Bus stratisd#2191
• filesystem.Devnode does not emit PropertiesChanged when calling SetName stratisd#2219

[mvollmer]

I have this now: cockpit-project/cockpit#14109

The main issue I found is that there don't seem to be any D-Bus signals coming out of the org.storage.stratis2 API. Indeed, the introspection data returned by stratisd does not mention any signals at all, not even the signals of the standard ObjectManager and Properties interfaces. Right now, I'd call this is a blocker, but maybe I am misunderstanding things.

Other issues:

• The symlinks in /stratis/ are not managed by udev, and are for example unknown to UDisks2. This complicates processing slightly since Cockpit needs to read them explicitly in order to match Stratis blockdevs to UDisks2 objects. I hear that you are moving away from this, true?

• I don't clearly see the motivation for the FetchProperties interface. It looks like a weaker version of the standard Properties interface with no added value but some drawbacks (like no change notifications, and not allowing per-interface properties). Could I convince you to just use the Properties interface?

• Method calls don't use the standard D-Bus error replies but include codes and messages in their result signature. That also looks unmotivated to me, but we can of course easily work with either style.

[jbaublitz]

The symlinks in /stratis/ are not managed by udev, and are for example unknown to UDisks2. This complicates processing slightly since Cockpit needs to read them explicitly in order to match Stratis blockdevs to UDisks2 objects. I hear that you are moving away from this, true?

I can at least comment on the udev-managed symlinks. There is a PR with proposed changes here stratis-storage/stratisd#2020. This would move management mostly into a udev rule and the symlinks would be under /dev/stratis.

[jbaublitz]

I don't clearly see the motivation for the FetchProperties interface. It looks like a weaker version of the standard Properties interface with no added value but some drawbacks (like no change notifications, and not allowing per-interface properties). Could I convince you to just use the Properties interface?

@mvollmer I have a question for you on this point. The rationale for this is primarily that we need to expose some properties where fetching them can fail. If fetching them fails, the whole call to GetManagedObjects() will also fail and stratisd becomes essentially unusable. Users can no longer list any information about the resources that they have created. I've been curious if there's a better way to handle this using existing D-Bus infrastructure but I have been unable to find any mention of how to handle this case in the D-Bus specification docs or in other articles that I've read on D-Bus. Is there an alternative that you've seen given how much you've worked with D-Bus that protects us from getting into a completely unusable state simply because a property gets into a failure state?

[agrover]

Be easier to just not fail getting property values. Maybe cache prop vals and return cached if fetch fails. Stale is better than nothing. Or, one value missing is better than the whole thing missing.

[mvollmer]

I don't clearly see the motivation for the FetchProperties interface. [...]

@mvollmer I have a question for you on this point. The rationale for this is primarily that we need to expose some properties where fetching them can fail. [...]

With FetchProperties, you encode the failure to compute a value into the value of the property, as (False, "message"). You can just do the same with the standard Properties interface.

[mulkieran]

Since this is an issue that really requires in-depth discussion, I'm considering it blocked by the other significant work that we need to complete in the next couple of weeks.

[mulkieran]

Blocked by #171.

[mulkieran]

We should all take a look at the prototype and video; then it'll be time to meet.

[mulkieran]

Just one left, but definitely won't be working on that until April.

[mulkieran]

Closing this, since there is only one sub-issue left.