I spent more time trying to understand the code today. What I said before was
an incorrect understanding of what was happening. Anyway, I found an API called
`ListResourceDetailsCmd` which I can call with a resourceid of the object store
and a resourcetype of ‘objectstore’. This doesn’t work out of the box but just
a few changes and I was able to get it to return details for the particular
object store.
My question however is if it is ok to do this as looking at the signature of
ListResourceDetailsCmd, it doesn’t seem to have any setting values for
authorized… this implies I think that anyone can call this API and not just
Admins? If this is true, then maybe I should not add support for
ObjectStorageDetails via the ListResourceDetailsCmd as authorization
information is kept there and it would be better to have a custom API that is
only allowed by the admin to retrieve this information. Or should
ListResourceDetailsCmd actually be more restricted? I’m not clear what all the
use cases are for what this API is used for. Actually, I didn’t find any users
of the API in the UI code so maybe it would be no harm to lock it down? Please
advise.
Then again, I also noticed that none of the API commands for objectstorage
pools currently restrict the roles that can call those APIs? I do think the
default is open so perhaps this is wrong and I can also fix that.
Another question. the interface for the driver has a listBuckets() function:
public interface ObjectStoreDriver extends DataStoreDriver {
...
List<Bucket> listBuckets(long storeId);
...
}
I can only find 1 caller to this function and that is from the
UpdateObjectStoragePoolCmd API call which uses that driver function to validate
the new URL (and soon other settings)… I’m not sure what the original purpose
of that command is but there is no real reason to return a list of buckets to
validate if the storage is working. My idea is to add a new “lighter” function
called something like
boolean isConnectionValid(long storeId);
This is more obviously named in its purpose and should provide a better check
of the different parts of the system that the updated settings cover. For
HyperStore for example, I need to validate connectivity to 3 urls (2 of which I
don’t use to listBuckets).
Thanks,
Tom.
> On Oct 11, 2024, at 21:15, Tom O'Dowd <tpod...@cloudian.com> wrote:
>
> Hi Vishesh/all,
>
> I had a go at this but I need a bit of help/guidance I think.
>
> I figured out how to create and hook in a updateObjectStorage.vue file. I
> wanted to get a basic one working first.
>
> The issue I’m having next is I cannot get the “details” map out to the GUI as
> part of UpdateObjectStoragePoolCmd.java as that command is defined like this:
>
> @APICommand(name = UpdateObjectStoragePoolCmd.APINAME, description = "Updates
> object storage pool", responseObject = ObjectStoreResponse.class, entityType
> = {ObjectStore.class},
> requestHasSensitiveInfo = false, responseHasSensitiveInfo = false,
> since = "4.19.0")
> public class UpdateObjectStoragePoolCmd extends BaseCmd {
> public static final String APINAME = "updateObjectStoragePool";
>
>
> The key here seems to be the EntityType which is ObjectStore.class.
>
> If I understand correctly, that is an interface that only has the basic
> properties such as name, providerName, url, id. So even if I add a map
> parameter to the API, I think that will only be for when the api is called to
> update?
>
> If I log the resource in the js console I get:
>
> this.resource: Proxy(Object) {id: 'fcad9cc0-7985-483b-aa31-988a03815db6',
> name: 'Cloudian', url: 'https://s3-admin.name.or.jp:19443', providername:
> 'Cloudian HyperStore', key: 0}
>
> What should I do to get the details map? Perhaps there are 3 ways?
> 1. Add details (yuck?) to ObjectStore?
> 2. Create another type of object just for this?
> 3. Call another API that pulls the details from the vue script on loading -
> involves creating another API for this also?
>
> I’m not really a front end guy so struggling with the js/vue stuff also but
> am making my way through it. Also just looking at the API stuff for the first
> time so new to that also.
>
> Any help appreciated.
>
> Tom.
>
>> On Oct 10, 2024, at 17:47, Vishesh Jindal <vishesh.jin...@shapeblue.com>
>> wrote:
>>
>> Hi Tom,
>>
>> This is the right place for the discussion.
>>
>> I think what you are suggesting makes sense. If the user wants to update the
>> accessKey and secretKey, it should be allowed.
>>
>> We can create a validation function for the Storage Plugins as per the
>> selected provider to validate the details map. And if for some reason, the
>> provider doesn't support the update for a particular key, the request will
>> fail.
>>
>> If you raise a PR for the changes, I can review it.
>>
>> Regards
>> Vishesh
>>
>>
>>
>>
>> ________________________________
>> From: Tom O'Dowd <tpod...@cloudian.com.INVALID>
>> Sent: Thursday, October 10, 2024 11:02 AM
>> To: dev@cloudstack.apache.org <dev@cloudstack.apache.org>
>> Subject: Updating Object Store Configuration
>>
>> I have a question about updating the Object Store Information.
>>
>> The current code only allows updating either the Name or the Object Store
>> URL.
>>
>> https://github.com/apache/cloudstack/blame/d6181d542108d02cca31daa758234bb29e1b317a/server/src/main/java/com/cloud/storage/StorageManagerImpl.java#L4180
>>
>> I think it is necessary to also update the other fields, namely accessKey
>> and secretKey of the admin user of the different object stores. Currently
>> there is no way to update them. I’m sure MinIO and Ceph will need this as
>> well as Cloudian.
>>
>> For our Cloudian implementation I would also like to be able to update other
>> store details which are the S3 URL and the IAM URL and whether or not the
>> SSL Certificate should be validated.
>>
>> When the object store is first created, this information is sent in a
>> “details” map. Therefore, it might make sense to ask the object store that
>> is being updated for its “details" Map, the GUI can be changed to allow
>> editing these and new details then passed back to this method which asks the
>> object store to set and validate them (rather than what it is doing here
>> where the update method itself is actually updating the store with
>> potentially bad data, then checking if it works before reverting it on
>> failure.
>>
>> So something like:
>>
>> User clicks Edit Object Storage
>> GUI requests Object Storage Info (url, name, details map etc)
>> (should ask the Object Storage Implementation for its configuration
>> information new function - details map)
>> displays the fields appropriate to the providerName (similar to create
>> Object Storage) using the details map.
>> When GUI updates, the details map is also posted along with the URL and name.
>> a new Object Storage Implementation update configuration function is called
>> which validates and saves the information if good.
>>
>> Anyway this probably needs some kind of formal discussion to make progress?
>> Is that this thread or does that happen elsewhere?
>>
>> Thanks,
>>
>> Tom.
>>
>>
>
