I'm trying to understand when we would ever have to use force=True. Seems like we would write to the database for no reason. Could we drop that feature for simplicity?

I'm trying to understand when we would ever have to use force=True. Seems like we would write to the database for no reason. Could we drop that feature for simplicity?

Agreed. But not sure if there're any other clients depending on this behavior. So leave this as forcc=True, despite the default value is False

If you're talking about clients other than the Koji CLI, I think it's fine to simplify the API and always raise GenericError here. I know of no other clients that unconditionally call or enableHost or disableHost. It seems reasonable to require all clients to call getHost first and check the value of enabled before calling enableHost/disableHost.

In fact, to me it is better for clients to call the get* method first without authenticating, because if we don't need to write to the database at all, then we can avoid inserting another session into the sessions table, which is already a hotspot for Koji performance.

It would be great to slim down Koji's features. It'll make Koji more consistent and easier to test.

I don't agree that #1088 and #1089 are bugs. These calls are idempotent. You ask the hub to enable a host and at the end the host is enabled. If I chmod a+x a file that is already executable, I do not get an error.

In what situation would the client care about this distinction? In what situation would this actually /be/ an error?

It's pretty common for admins to run {enabled,disable}-host on a long list of hostnames that may not actually all be disabled/enabled at the time.

@mikem Ok, it makes sense. We can drop this pull request and related issues with this.
You are right that we want to have enabled or disabled host and it is. OK, not return an error for this :).