cloudstack-issues mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "ASF GitHub Bot (JIRA)" <>
Subject [jira] [Commented] (CLOUDSTACK-9827) Storage tags stored in multiple places
Date Thu, 16 Mar 2017 00:12:41 GMT


ASF GitHub Bot commented on CLOUDSTACK-9827:

Github user rafaelweingartner commented on a diff in the pull request:
    --- Diff: engine/schema/src/com/cloud/storage/dao/ ---
    @@ -77,4 +92,71 @@ public void deleteTags(long poolId) {
    +    @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) {
    --- End diff --
    No problem ;)
    It is awesome the changes you have done here. The code became cleaner, with good documentation
and on top of that, we now have unit tests to guarantee that the methods are workings as expected.
    Great job @nvazquez, well done!
    PS: Sorry if I have been too picky with the code changes.

> Storage tags stored in multiple places
> --------------------------------------
>                 Key: CLOUDSTACK-9827
>                 URL:
>             Project: CloudStack
>          Issue Type: Bug
>      Security Level: Public(Anyone can view this level - this is the default.) 
>          Components: Management Server
>    Affects Versions:
>         Environment: N/A
>            Reporter: Mike Tutkowski
>            Assignee: Nicolas Vazquez
>            Priority: Blocker
>             Fix For:
> 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
> 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
> 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

View raw message