apache
Add Cloudian HyperStore Object Storage
Description
This PR Adds A New Object Storage Provider Plugin for Cloudian HyperStore
- Allow the CloudStack administrator to connect to Cloudian HyperStore object storage.
- Once connected, CloudStack Accounts can create buckets that are managed by and belong to their own Account.
- IAM Credentials are available for each bucket such that Accounts can use the buckets either from 3rd party S3 applications or from the CloudStack Bucket Browser UI Feature.
- The plugin supports all the current CloudStack bucket operations such as Object Lock, Versioning, Encryption and policy settings.
- The plugin currently does not support setting a bucket quota as HyperStore does not currently support that functionality.
- Bucket usage is supported.
More Details:
- See plugins/storage/object/cloudian/README.md for details
UI Changes - Add Object Storage for Cloudian HyperStore:
- Cloudian HyperStore Object Storage requires more fields than Minio, Ceph and Simulator so when the Cloudian HyperStore provider is selected, the GUI adjusts and offers the extra fields that the provider requires.
Other Bug fixes and improvements as part of this fix I kept in separate commits.
- Use a password input field type for object store secret key entry
- Fix to avoid pre-pending a second '/' to the object name in the Bucket Browser Feature.
- Fix issue where usage may not be collected if another object store is down.
- Various fixes and enhancements to CloudianClient
Types of changes
- [ ] Breaking change (fix or feature that would cause existing functionality to change)
- [x] New feature (non-breaking change which adds functionality)
- [ ] Bug fix (non-breaking change which fixes an issue)
- [ ] Enhancement (improves an existing feature and functionality)
- [ ] Cleanup (Code refactoring and cleanup, that may add test cases)
- [ ] build/CI
- [ ] test (unit or integration test code)
Feature/Enhancement Scale or Bug Severity
Feature/Enhancement Scale
- [ ] Major
- [x] Minor
Bug Severity
- [ ] BLOCKER
- [ ] Critical
- [ ] Major
- [ ] Minor
- [ ] Trivial
Screenshots (if appropriate):
How Has This Been Tested?
- Unit Testing
- Testing against the Cloudian HyperStore system. Tested bad configurations and credentials, system down.
- Monitored log entries and sniffed network connections.
- Tested the various UI compontents such as Add Object Storage, Edit and Delete Object Storage. Adding buckets with various Accounts and Projects, editing bucket configurations, verifying configurations were set using different S3 exploration tools.
- Tested the bucket browser UI component against HyperStore.
How did you try to break this feature and the system with this change?
- As this change altered CloudianClient which is shared code with the other cloudian infrastructure plugin, I also re-tested that plugin after these changes.
- I also lightly tested with Minio.
- This plugin feature shouldn't break other areas of the system.
Codecov Report
Attention: Patch coverage is 74.38867% with 199 lines in your changes missing coverage. Please review.
Project coverage is 16.24%. Comparing base (
24b7c66) to head (01be768). Report is 250 commits behind head on main.
Additional details and impacted files
@@ Coverage Diff @@
## main #9748 +/- ##
============================================
+ Coverage 4.00% 16.24% +12.24%
- Complexity 0 13368 +13368
============================================
Files 396 5672 +5276
Lines 32530 498985 +466455
Branches 5766 60341 +54575
============================================
+ Hits 1302 81059 +79757
- Misses 31078 408891 +377813
- Partials 150 9035 +8885
| Flag | Coverage Δ | |
|---|---|---|
| uitests | 4.04% <ø> (+0.04%) |
:arrow_up: |
| unittests | 17.09% <74.38%> (?) |
Flags with carried forward coverage won't be shown. Click here to find out more.
:umbrella: View full report in Codecov by Sentry.
:loudspeaker: Have feedback on the report? Share it here.
:rocket: New features to boost your workflow:
- :snowflake: Test Analytics: Detect flaky tests, report on failures, and find test suite problems.
- :package: JS Bundle Analysis: Save yourself from yourself by tracking and limiting bundle sizes in JS merges.
![codecov[bot] avatar](https://avatars.githubusercontent.com/in/254?v=4 "Published by a pub.dev verified publisher"){kind=small}
Thanks for the PR @tpodowd since we don't have the cloudian system to test against, we'll help with regression testing.
@blueorangutan test
Hi @rohityadavcloud - I updated the PR to fix the README.md lint issue and also added a bit more unit test coverage in the main driver code.
You mentioned the following:
since we don't have the cloudian system to test against, we'll help with regression testing.
Thanks, let me know what information you need and I'll do my best to get back to you.
Hi @DaanHoogland - I think I have got the pre-commit stuff nailed now. I ran pre-commit locally and it fixed the end of files for me. Then I reviewed that and pushed commit 40c0366
Sorry. I was reviewing the beautiful code coverage report and reviewing code I had not tested when I noticed a bad typo that means CloudianClient won't timeout. I have a fix locally and have added unit tests. I am doing a full build and a bit more testing and then I'll push another commit.
Ok. Hopefully that is it. I have pre-commit hooked in now also so I know that is clean. Code coverage should be a little better again also.
Hi @DaanHoogland / @rohityadavcloud - There seems to be an error in one of the checks. I'm not sure that it is related to my changes though. Let me know if I need to do anything about it. Thanks!
Hi @DaanHoogland / @rohityadavcloud - There seems to be an error in one of the checks. I'm not sure that it is related to my changes though. Let me know if I need to do anything about it. Thanks!
rerunning, let's see. It doesn't seem related to me either.
I realised that I should not change the key names that the Object Store Details use as they may be read/updated outside of the plugin. Thanks!
Hi @JoaoJandre - I have pushed another commit to address your review comments. Thanks for your time and let me know if you have any other concerns or questions.
Hi @JoaoJandre - I have pushed another commit to address your review comments. Thanks for your time and let me know if you have any other concerns or questions.
@tpodowd I did my best with no knowledge of Cloudian :smile: . In any case, overall it looks good to me. There is only one thing (https://github.com/apache/cloudstack/pull/9748#discussion_r1806353907) left that I think should be addressed.
@tpodowd I did my best with no knowledge of Cloudian 😄 . In any case, overall it looks good to me. There is only one thing (#9748 (comment)) left that I think should be addressed.
Hi @JoaoJandre - No worries. Thank you so much again for your time on this. I have addressed your last comment and have pushed an update.
Hi @tpodowd, I understand Cloudian doesn't support per bucket Quota. Does it support per user quota? Is there a way to configure it from within CloudStack?
cc @rohityadavcloud @sureshanaparti
Hi @abh1sar - Thanks for your comment/question.
I understand Cloudian doesn't support per bucket Quota.
Yes, Cloudian HyperStore does not currently support a bucket storage quota.
Does it support per user quota?
Yes, Cloudian HyperStore does support per user quota. We have a warning level and a hard limit for storage bytes and we also have some other related settings.
Is there a way to configure it from within CloudStack?
Unfortunately not. There are some issues here:
- Although the CloudStack APIs for Object Storage allow setting a quota on a bucket, there is no API framework provided to the plugins to set something on the CloudStack Account level.
- On HyperStore, setting a quota on an Account/User is usually something that an administrator would do as it is related to QoS settings (ie protecting the system, rather than protecting the user). I guess a user concerned about potential storage costs might also want to impose a limit on themselves. But, if the administrator for example set the QoS limit to one thing, then the user should not be able to raise it higher or disable it for themselves.
Currently, the administrator would have to login to the HyperStore system and either:
- Select the HyperStore group (representing the CloudStack Domain) and set a QoS limit that applies to all users in that group.
- Select the HyperStore user (representing the CloudStack Account) and set a QoS limit that only applies to that particular user.
Thanks @tpodowd for your response. If we had to implement the functionality to set Account level Quota in cloudstack, how do you think that could be done? Does the HyperStore plugin has API to do something like that? I am asking because I am working on a PR which adds resource limits to Object Storage space usage.
Hi @abh1sar. The current plugin does not have any API support itself for setting Account level QoS (as it only implements the provided plugin APIs). The HyperStore Admin API itself does support setting QoS for a user though so that could be made available to CloudStack if it was implemented in CloudianClient (which is easy enough). If I know more about what you are doing, I guess I can also chip in.
FYI. I have another PR pending this one also which adds the ability to edit the Object Store details. https://github.com/tpodowd/cloudstack/tree/edit_object_storage
Hi @DaanHoogland @rohityadavcloud - Any update on when this PR is likely to be merged?
Hi @tpodowd , Please sync with the latest code and test bucket creation. The quota field in create bucket api has been made mandatory since https://github.com/apache/cloudstack/pull/10017 to support Object Storage Limits per Account/Project and Domain. Happy to discuss further if needed.
Hi @abh1sar, ok. I will allocate some time to look at this in the coming days. As I mentioned before, we don't have a bucket level quota setting. We do have a User level QoS setting. I think the only thing that I can do currently is to set the User (that owns the bucket) QoS settings to the limit specified in the create bucket request. An example might be as below:
- Bucket B1 created for User A with a quota of 5GB.
-
Plugin adjusts the HyperStore user A's quota to 5GB
- Bucket B2 created for User A with a quota of 5GB.
-
Plugin keeps HyperStore user A's quota at 5GB (updates CS DB quotas for B1,B2 to 5GB to match)
- Bucket B3 created for User A with a quota of 3GB.
-
Plugin reduces HyperStore user A's quota to 3GB (updates CS DB quotas for B1,B2,B3 to 3GB to match)
- Bucket B2's quota is adjusted to 10GB
-
Plugin expands HyperStore user A's quota to 10GB (updates CS DB quotas for B1,B2,B3 to 10GB to match)
When any adjustment happens to the user's quota, all of the HyperStore buckets owned by that account need to get their quota settings updated in the DB to correctly represent the latest user's quota setting.
This is currently all we can do I think. If we document it, it should not be too hard to understand for the admin.
Does this sounds ok? I think plugin wise, the plugin currently does not update information about different bucket(s) when processing a request for a certain bucket, so I will need to figure out how best to do that. I do think it is easier for the administrator to understand the implementation and understand what the quota is set to though if it is done this way.
@DaanHoogland a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress.
Packaging result [SF]: ✖️ el8 ✖️ el9 ✖️ debian ✖️ suse15. SL-JID 12496
@tpodowd , it seems there is some dependency error on debian:
09:14:14 [ERROR] [ERROR] Some problems were encountered while processing the POMs:
09:14:14 [FATAL] Non-resolvable parent POM for org.apache.cloudstack:cloud-plugin-storage-object-cloudian:4.20.0.0-SNAPSHOT: Could not find artifact org.apache.cloudstack:cloudstack-plugins:pom:4.20.0.0-SNAPSHOT and 'parent.relativePath' points at wrong local POM @ line 24, column 13
and in the github action:
Error: ] Some problems were encountered while processing the POMs:
[FATAL] Non-resolvable parent POM for org.apache.cloudstack:cloud-plugin-storage-object-cloudian:4.20.0.0-SNAPSHOT: The following artifacts could not be resolved: org.apache.cloudstack:cloudstack-plugins:pom:4.20.0.0-SNAPSHOT (absent): Could not find artifact org.apache.cloudstack:cloudstack-plugins:pom:4.20.0.0-SNAPSHOT and 'parent.relativePath' points at wrong local POM @ line 24, column 13
I must say I can not find it (yet)
Hi @DaanHoogland - please ignore this PR for the moment. I'm going to look at the plugin again with the new information that @abh1sar has provided regarding the quota being required. I'll fix the build issue before I push anything to the branch.
@abh1sar - can you check my reply above also regarding how I think we might handle this? Thanks @shwstppr for pointing out the issue with the pom versions.
I got my local build working again and confirmed that indeed we cannot add buckets currently as quota is now a requirement and create bucket fails with:
Failed to create bucket with name: testbucket com.cloud.utils.exception.CloudRuntimeException: This bucket does not support quotas.
This is because the Cloudian plugin as written does not implement bucket quota and fails the request. I need to figure out an approach for this. I guess there are two approaches:
- The plugin ignores the quota and creates the bucket regardless.
- We implement the user quota that I mentioned in an earlier comment.
I am guessing that option 1 is not really an option and I need to implement option 2? Let me know if I am wrong about that.
Hi @abh1sar, ok. I will allocate some time to look at this in the coming days. As I mentioned before, we don't have a bucket level quota setting. We do have a User level QoS setting. I think the only thing that I can do currently is to set the User (that owns the bucket) QoS settings to the limit specified in the create bucket request. An example might be as below:
- Bucket B1 created for User A with a quota of 5GB.
Plugin adjusts the HyperStore user A's quota to 5GB
- Bucket B2 created for User A with a quota of 5GB.
Plugin keeps HyperStore user A's quota at 5GB (updates CS DB quotas for B1,B2 to 5GB to match)
- Bucket B3 created for User A with a quota of 3GB.
Plugin reduces HyperStore user A's quota to 3GB (updates CS DB quotas for B1,B2,B3 to 3GB to match)
- Bucket B2's quota is adjusted to 10GB
Plugin expands HyperStore user A's quota to 10GB (updates CS DB quotas for B1,B2,B3 to 10GB to match)
When any adjustment happens to the user's quota, all of the HyperStore buckets owned by that account need to get their quota settings updated in the DB to correctly represent the latest user's quota setting.
This is currently all we can do I think. If we document it, it should not be too hard to understand for the admin.
Does this sounds ok? I think plugin wise, the plugin currently does not update information about different bucket(s) when processing a request for a certain bucket, so I will need to figure out how best to do that. I do think it is easier for the administrator to understand the implementation and understand what the quota is set to though if it is done this way.
Hi @tpodowd There could be another approach : if the user has 3 buckets of size 5GB, 10GB and 3GB, we keep the quota in CS DB as 5, 10 and 3 respectively. On the plugin side we can set the total user quota to be the sum of all quotas i.e. 18GB. So, the plugin needs to increase, decrease user quota whenever a bucket is created/ destroyed or quota is changed. This will also need to be documented, that a bucket from the same user can feed space from another bucket of the same user (Although we defined bucket quota as 5, 10 and 3, the actually usage could be 6, 6 and 6.)
Another thing could be, if you are ok with Cloudian not supporting Object Storage Limits, you can document that and make the quota field non-mandatory for Cloudian.
We discussed this internally. HyperStore does not currently support Bucket Quota limits. We have added an internal feature request for this which we may implement in a future HyperStore release. At such time, we will re-address and update the CloudStack HyperStore plugin bucket quota functionality. As the CloudStack UI and API currently both require a quota setting, we decided to allow the user to specify a value of 0 as the quota. The 0 quota will indicate no quota restriction for the bucket.
I rebased this branch on top of the latest main branch. I fixed 2 issues in commit 01be768a6955313f6e5962b6939124a97e54481c:
- The pom.xml was updated for the correct version number.
- Quota of 0 is now accepted and I added an extra test for the 0 case.
I built everything cleanly and tested adding a bucket successfully using a quota of 0. I also confirmed the error case worked with any other quota value and that UI shows the user the exception message to help them choose the 0 value.
Please let me know if you have any questions or comments.
@DaanHoogland a [SL] Jenkins job has been kicked to build packages. It will be bundled with KVM, XenServer and VMware SystemVM templates. I'll keep you posted as I make progress.
Packaging result [SF]: ✔️ el8 ✔️ el9 ✖️ debian ✔️ suse15. SL-JID 12577