cloudstack-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Mike Tutkowski <mike.tutkow...@solidfire.com>
Subject Re: storage subsystem 2.0 question
Date Sun, 22 Sep 2013 05:10:21 GMT
Also, we can bring John Burwell into this as he had related comments
several months ago, but we did not want to have the storage plug-ins
calling into the hypervisors. The idea was to get away from having any
hypervisor dependencies in the storage plug-ins.

The default storage plug-in does not follow this practice (it does call
into the hypervisors), but the idea is to get away from that.


On Sat, Sep 21, 2013 at 11:07 PM, Mike Tutkowski <
mike.tutkowski@solidfire.com> wrote:

> Hey Marcus,
>
> As far as I remember, grantAccess and revokeAccess are not invoked at all
> in 4.2. Edison may be able to elaborate more on this, but I don't believe
> the framework ever calls them.
>
> Talk to you later
>
>
> On Sat, Sep 21, 2013 at 11:02 PM, Marcus Sorensen <shadowsor@gmail.com>wrote:
>
>> Oh, one more question. Is grantAccess/revokeAccess called as I'd
>> expect for migration, e.g. when PrepareForMigrationCommand is called
>> on the target host we can grantAccess to the new host, and then when
>> MigrateCommand returns successfully from the old host we revokeAccess
>> from the old host?
>>
>> On Sat, Sep 21, 2013 at 10:57 PM, Marcus Sorensen <shadowsor@gmail.com>
>> wrote:
>> > All,
>> >    We've had our own storage plugins based on the 4.1 branch for
>> > awhile now. Basically everything was done in KVM on the Agent side.
>> > With the new storage framework in place for 4.2, I'm working on
>> > splitting this code between Agent-specific (attach to VM, etc) and the
>> > code that talks to the SAN apis, which should live in the new plugin.
>> > However, I seem to be missing some functionality, namely storage
>> > stats. In 4.1, GetStorageStatsCommand would be sent to the Agent, and
>> > it would call _storagePoolMgr.getStoragePool, which we'd use to update
>> > the used bytes and capacity of the storage pool.
>> >
>> > 1) with the new framework, will storage pools managed by a plugin
>> > still call GetStorageStatsCommand?  This is less than ideal, but
>> > better than nothing. I'd prefer to move all code that talks to the SAN
>> > into the storage plugin and out of the KVM agent.
>> >
>> > 2) Or is there some call I can handle that I'm not noticing will
>> > already do this in the storage plugin? I can fetch the current
>> > size/used in the initialize, or even when hosts attach in the Listener
>> > (which I don't see any documentation on), but I think the plugin
>> > framework needs the equivalent of GetStorageStatsCommand if it doesn't
>> > already have it.
>>
>
>
>
> --
> *Mike Tutkowski*
> *Senior CloudStack Developer, SolidFire Inc.*
> e: mike.tutkowski@solidfire.com
> o: 303.746.7302
> Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play>
> *™*
>



-- 
*Mike Tutkowski*
*Senior CloudStack Developer, SolidFire Inc.*
e: mike.tutkowski@solidfire.com
o: 303.746.7302
Advancing the way the world uses the
cloud<http://solidfire.com/solution/overview/?video=play>
*™*

Mime
  • Unnamed multipart/alternative (inline, None, 0 bytes)
View raw message