search

datopian / ckanext-blob-storage

CKAN extension to offload blob storage to cloud storage providers (S3, GCS, Azure etc).
http://tech.datopian.com/blob-storage/
MIT License
14 stars 6 forks source link

Rename extension and Python module to ckanext-blob-storage #23

Closed rufuspollock closed 3 years ago

rufuspollock commented 4 years ago

external is really unclear - storage is always external ...

Really this is cloud storage so ckanext-cloud-storage would be best but i get there is already taken. In which case I recommend the simple:

ckanext-storage

Or, if we want to be pedantic:

ckanext-blob-storage

/cc @shevron - any thoughts?

shevron commented 4 years ago

I do not agree that "cloud storage" or "blob storage" capture it. Really what this extension does is offload storage to a service outside of CKAN which can be cloud or not. "Blob" is very generic - even CKAN internal's storage uses blobs (and not all clour provides use the term "blob" - actually only Azure does).

That's why I named it "external". I agree it's not a very clear name, but I don't think any of these suggestion does a better job.

The most specific thing I can think of is that this uses a Git LFS server to get access to storage. But I don't think naming it "ckanext-git-lfs" or "ckanext-git-filestorage" is amazing either.

Open for more suggestions.

rufuspollock commented 4 years ago

The point is that it is just storage: storage is always "external" to ckan - it's always on some disk or "cloud" disk that is separate from CKAN. So if we dropped external we get simple ckanext-storage which seems too generic. I'm using blob because that is the term we use here http://tech.datopian.com/storage (not because of cloud providers terminology). Alternative would be "raw" or bitstore e.g. ckanext-raw-storage or ckanext-bitstore.

shevron commented 4 years ago

Got it, and I'm OK with ckanext-blob-storage.

This kind of gets me thinking that maybe we should have a sort of convension for every CKAN extension we build that "chops off" a part of CKAN and moves it to a microservice, including this one, authz-service and versioning (I know technically some of them do it in a slightly different way but the end goal is to off-load some tasks away from CKAN and into a separate, more modular architecture).

So maybe we should call them all something like ckanext-modular-versioning, ckanext-modular-blob-storage, ckanext-modular-authorization etc. I know it's a bit cumbersome, I'm just throwing this in as a half-baked thought.

rufuspollock commented 4 years ago

OK, i've renamed repo on github but not the module itself.

@shevron can you do the renaming here in code and publish a new version to pypi. (I would suggest publishing to pypi old version before we do this if we haven't already so we don't break docker stuff that is depending on old name).

shevron commented 4 years ago

@rufuspollock sure, but this is not in pypi and never has been so I don't see compatibility issues with pypi. If anything, renaming the GitHub repo can break things, but I guess we can quickly fix them if that will happen (the builds I know of are using the Github repo as source).

In general, not many CKAN extensions are published to pypi, I am not entirely sure why. I would just fix the module name and any builds that are failing, and open a separate ticket for publishing to pypi if we want that.