Is This Project Still Active?

[Queuecumber]

Last commit was over a year ago, last release over two years ago, is this project dead or considered finished

[tasleson]

targetd utilizes lvm2app library which has been deprecated [1] and btrfs which has been deprecated [2].

This project has been placed in maintenance mode and could be revived if those deprecated pieces are replaced with something that is supported and maintained.

I'll update the project read me to reflect this.

[1] https://bugzilla.redhat.com/show_bug.cgi?id=1489590 [2] https://access.redhat.com/documentation/en-US/Red_Hat_Enterprise_Linux/7/html/7.4_Release_Notes/chap-Red_Hat_Enterprise_Linux-7.4_Release_Notes-Deprecated_Functionality.html

[Queuecumber]

I think switching to lvm2 w/ dbus API is actually doable, no promises but I'm going to take a look at it (I remember thinking that your lvm code was quite clean)

As far as the filesystem API goes, I'm curious why you even want that. It seems out of scope for the project, I recommend to strip that out and make the iSCSI part perfect.

In my mind, this project is a perfect fit in kubernetes where there is already a targetd ISCSI provisioner written (https://github.com/kubernetes-incubator/external-storage/tree/master/iscsi/targetd) specifically for targetd, and it can be combined with the NFS provisioner to create a lightweight small scale answer to edgefs (which is overkill for most setups). In that sense, you wouldnt want targetd for it's filesystem API anyway since NFS itself works so well and it creates added headache maintaining the feature.

[tasleson]

Yes, that is a viable option, patches welcomed :+1:

I added blurb to README.md

[Queuecumber]

OK so just to be clear you'd accept a patch that deprecates the filesystem API and removes it in lieu of replacing BTRFS

[tasleson]

I was thinking more of taking the approach of updating the lvm code and leaving FS as is, so that it continues to function for those distros that have it. I think returning an error code when a user tries to utilize FS functionality would suffice.

But to answer your question, yes.

Your thoughts?

[Queuecumber]

I think that is a reasonable option

[tasleson]

You should consider using https://github.com/storaged-project/libblockdev for the lvm interaction. The library provides a plugin architecture so it can either use lvm dbus API or the lvm command line. It has python bindings which should make it quite easy to utilize.

[Queuecumber]

Very nice, this should make life a lot easier

[dwlehman]

FWIW here's an example of libblockdev in python: https://github.com/storaged-project/api-examples/blob/master/demo-1-libblockdev-python

[Queuecumber]

It looks like they even have plugins beyond just lvm which could give us more flexibility in what we use for the underlying block devices

[dwlehman]

Yes, libblockdev is used extensively by a couple of higher-level general-purpose storage management APIs (udisks2, blivet).