[
https://issues.apache.org/jira/browse/CLOUDSTACK-9827?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15924529#comment-15924529
]
ASF GitHub Bot commented on CLOUDSTACK-9827:
--------------------------------------------
Github user rafaelweingartner commented on a diff in the pull request:
https://github.com/apache/cloudstack/pull/1994#discussion_r105959436
--- Diff:
engine/schema/src/com/cloud/storage/dao/StoragePoolTagsDaoImpl.java ---
@@ -77,4 +90,68 @@ public void deleteTags(long poolId) {
txn.commit();
}
+ @Override
+ public List<StoragePoolTagVO> searchByIds(Long... stIds) {
+ final int detailsBatchSize = getDetailsBatchSize();
+
+ // query details by batches
+ List<StoragePoolTagVO> uvList = new ArrayList<StoragePoolTagVO>();
+ int curr_index = 0;
+
+ if (stIds.length > detailsBatchSize) {
+ while ((curr_index + detailsBatchSize) <= stIds.length) {
+ searchForStoragePoolIdsInternal(curr_index,
detailsBatchSize, stIds, uvList);
+ curr_index += detailsBatchSize;
+ }
+ }
+
+ if (curr_index < stIds.length) {
+ int batch_size = (stIds.length - curr_index);
+ searchForStoragePoolIdsInternal(curr_index, batch_size, stIds,
uvList);
+ }
+
+ return uvList;
+ }
+
+ /**
+ * Search storage pools
+ * @param currIndex current index
+ * @param batchSize batch size
+ * @param stIds storage tags array
+ * @param uvList
+ */
+ protected void searchForStoragePoolIdsInternal(int currIndex, int
batchSize, Long[] stIds, List<StoragePoolTagVO> uvList) {
--- End diff --
What about improving this java doc here?
Something like:
> Search for storage pools based on their IDs. The search is executed in
batch, this means that we will load a batch of size #getDetailsBatchSize
@link{StoragePoolTagVO} at each time. The loaded storage pools are added in the
uvList parameter.
The links to classes, methods and parameters in the Java doc would have to
be fixed (I wrote it without using the IDE and I did not know the proper markup)
What do you think about the "@param" notation? I normally prefer not to use
them if the onyl thing I will write is the parameter name such as `@param
uvList`
> Storage tags stored in multiple places
> --------------------------------------
>
> Key: CLOUDSTACK-9827
> URL: https://issues.apache.org/jira/browse/CLOUDSTACK-9827
> Project: CloudStack
> Issue Type: Bug
> Security Level: Public(Anyone can view this level - this is the
> default.)
> Components: Management Server
> Affects Versions: 4.10.0.0
> Environment: N/A
> Reporter: Mike Tutkowski
> Assignee: Nicolas Vazquez
> Priority: Blocker
> Fix For: 4.10.0.0
>
>
> I marked this as a Blocker because it concerns me that we are not handling
> storage tags correctly in 4.10 and, as such, VM storage might get placed in
> locations that users don't want.
> From e-mails I sent to dev@ (most recent to oldest):
> If I add a new primary storage and give it a storage tag, the tag ends up in
> storage_pool_details.
> If I edit an existing storage pool’s storage tags, it places them in
> storage_pool_tags.
> **********
> I believe I have found another bug (one that we should either fix or examine
> in detail before releasing 4.10).
> It looks like we have a new table: cloud.storage_pool_tags.
> The addition of this table seems to have broken the listStorageTags API
> command. When this command runs, it doesn’t pick up any storage tags for me
> (and I know I have one storage tag).
> This data used to be stored in the cloud.storage_pool_details table. It’s
> good to put it in its own table, but will our upgrade process move the
> existing tags from storage_pool_details to storage_pool_tags?
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
