I look at this as the modern way that you'd write a CLI. You'd put in a RESTful API and then your CLI would just make internal REST calls. The AWS CLI is a great example of this.
The problem is things like FreeNAS have been using the old API for almost a decade now and aren't going to rewrite their code just because there's new hotness. Not to mention you'd have to make the new API bug for bug compatible with the old API, which is probably harder than it sounds. (There's a lot of business logic tied up in that zpool command) There's also channel programs to consider. I assume since that came out of Delphix it has at least one consumer. I think the "if we build it they will come" ship has sailed on this one. (Even though from a technical perspective it makes a lot of sense to me) On Mon, Mar 2, 2020, at 5:53 PM, Kjeld Schouten-Lebbing wrote: > Without an actual example use-case... It seems a bit like the usual "xkcd > meme"-proposal... > Ofcoarse there are area's where the User Interface could be significantly > improved, but what I'm interested in what warrants a complete new API in your > opinion. > aka: Why isn't iterative development enough? > > This is a bit harsher, but none the less something to think about: > This is (primarily) a (unrequested!) convenience features for (commercial) > downstream. > If in all those time all those big sponsors never put any significant force > behind this, why is is needed this much? > > Simply put: > You should try and sell us your idea. > At the moment i'm not sold. > > Yours sincerely, > Kjeld Schouten-Lebbing > aka > Ornias1993 > "Matthew Ahrens" mahr...@delphix.com – March 2, 2020 7:52 PM > >> Couple of questions about this: >> What are the expected benefits over fork/exec'ing the zpool/zfs commands? >> There are a lot of things happening in zfs_main.c and zpool_main.c. How much >> of that are you suggesting move to the new library? E.g. we could be talking >> about an API like `int run_zfs_command(char *argv[])` that essentially >> invokes main(). But having that library print to stdout, etc might not be >> what you're looking for. How would you want errors to be expressed in the >> new API? >> Maybe you could give some examples of subcommands that do not have good >> equivalents in libzfs. Here are a few that I looked at: >> zfs_do_set(): it seems to me that zfs_prop_set_list() is a good libzfs >> interface to use in its place. But maybe you have something different in >> mind? >> zfs_do_send(): its CLI parsing is much more complicated but it looks like it >> boils down to one call to zfs_send_*(). Are you thinking that we should make >> a single API entry point that would cover all the zfs_send_*() variants? >> zfs_do_list(): the logic in print_dataset() is a little involved, but unless >> you want the library to be generating the same string output that we have >> from the CLI, it seems like the existing libzfs functions for examining the >> zfs_handle_t seem decent. Again, maybe an example of what you would like to >> see for a "true" API that's equivalent to zfs_do_list() would be helpful. >> --matt >> >> On Mon, Mar 2, 2020 at 8:53 AM Mike Carlin via openzfs-developer >> <developer@lists.open-zfs.org> wrote: >> >>> Dear OpenZFS, >>> >>> Within various applications that make use of ZFS, the means of integration >>> is largely done by calling the zfs/zpool/etc. executables and parsing the >>> output (e.g. moby, lumina). I'd like to see an additional path for >>> integration in the form of an API that provides equivalent functionality to >>> the CLI. While it's true that libzfs and libzfs_core expose all the >>> building blocks necessary to achieve the same result as the aforementioned >>> executables, there's a fair amount of logic in the executables that would >>> need to be duplicated to provide equivalent functionality. >>> >>> I propose that a separate library (or possibly header/source in libzfs) be >>> created, using the logic present in zpool and zfs to provide the same >>> functionality exposed as an API. A few benefits from this: >>> >>> - Allow for an alternate and potentially better integration path for third >>> party applications >>> >>> - Simplify zpool and zfs to really just focus on CLI related concerns >>> >>> In my view, the "true" API to OpenZFS is the functionality provided in the >>> CLI commands of the executables. >>> >>> An example to illustrate what this might look like can be seen here: >>> https://github.com/mcarlin/zfs/commit/660cc435543596284a218bf773cf1087829ebde8 >>> >>> <https://cloud.schouten-lebbing.nl/apps/mail/redirect?src=https%3A%2F%2Fgithub.com%2Fmcarlin%2Fzfs%2Fcommit%2F660cc435543596284a218bf773cf1087829ebde8> >>> I'd greatly appreciate everyone's thoughts on this and to see if this is >>> something the community would be on board with. >>> >>> Thanks, >>> >>> Mike Carlin >>> >> >> >> *openzfs* >> <https://cloud.schouten-lebbing.nl/apps/mail/redirect?src=https%3A%2F%2Fopenzfs.topicbox.com%2Flatest> >> / openzfs-developer / see >> discussions >> <https://cloud.schouten-lebbing.nl/apps/mail/redirect?src=https%3A%2F%2Fopenzfs.topicbox.com%2Fgroups%2Fdeveloper> >> + >> participants >> <https://cloud.schouten-lebbing.nl/apps/mail/redirect?src=https%3A%2F%2Fopenzfs.topicbox.com%2Fgroups%2Fdeveloper%2Fmembers> >> + >> delivery options >> <https://cloud.schouten-lebbing.nl/apps/mail/redirect?src=https%3A%2F%2Fopenzfs.topicbox.com%2Fgroups%2Fdeveloper%2Fsubscription> >> Permalink >> <https://cloud.schouten-lebbing.nl/apps/mail/redirect?src=https%3A%2F%2Fopenzfs.topicbox.com%2Fgroups%2Fdeveloper%2FTdde1f0006baa1227-Md33c32ea5a5db44f2fbcf1a3> >> >> >> >> > *openzfs <https://openzfs.topicbox.com/latest>* / openzfs-developer / see > discussions <https://openzfs.topicbox.com/groups/developer> + participants > <https://openzfs.topicbox.com/groups/developer/members> + delivery options > <https://openzfs.topicbox.com/groups/developer/subscription> Permalink > <https://openzfs.topicbox.com/groups/developer/Td51d2db7befa05bf-M44eef456b5930ead682d368f> -- Thanks, Josh Paetzel ------------------------------------------ openzfs: openzfs-developer Permalink: https://openzfs.topicbox.com/groups/developer/Td51d2db7befa05bf-Mfe758b045971b7d53f5437c8 Delivery options: https://openzfs.topicbox.com/groups/developer/subscription
