I agree you'd want to get away from going from the agent to the SAN API. My storage plug-in doesn't have any hypervisor dependencies, though. It creates volumes, deletes them, and other SAN-related activities and lets the storage framework coordinate orchestration activities (like ask the storage plug-in for a volume, then send a message to the hypervisor to attach the resultant volume).
On Sat, Sep 21, 2013 at 11:39 PM, Marcus Sorensen <shadow...@gmail.com>wrote: > It's fine, I can leave that code as-is from 4.1 to 4.2 in my plugin, > but if the capability is there to move it I'd prefer to do so. I'm not > sure how we'd get away from calling into any of the hypervisors if we > need to attach disks, or manage default storage types. I can't create > storage on Xen without talking to Xen, or a disk image on KVM without > talking to libvirt or some other thing on KVM. It is after all about > orchestrating the hypervisor, but perhaps I misunderstand the > intention. My point was that I want to get away from Mgmt server -> > Agent -> SAN API wherever possible, it should be unnecessary to go > through the Agent, but in 4.1 that's where everything was done, so > that's what we made talk to the SAN. > > On Sat, Sep 21, 2013 at 11:19 PM, Mike Tutkowski > <mike.tutkow...@solidfire.com> wrote: > > I believe, though, we should look into adding calls to grantAccess and > > revokeAccess for 4.3. > > > > For 4.2 I didn't worry about it because my plug-in didn't work with KVM. > I > > set XenServer and VMware up to use shared SRs/datastores using CHAP > > credentials that I added to all hosts in the cluster (programmatically). > VM > > migrations were handled natively (meaning here coordinated by the > cluster), > > as far as I know. > > > > Since CloudStack handles live migrations for KVM, it would probably be > > better to have support for grantAccess and revokeAccess the way you > > described earlier (since there is no true KVM cluster to handle this). > > > > > > On Sat, Sep 21, 2013 at 11:10 PM, Mike Tutkowski < > > mike.tutkow...@solidfire.com> wrote: > > > >> 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.tutkow...@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 <shadow...@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 < > shadow...@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.tutkow...@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.tutkow...@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.tutkow...@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.tutkow...@solidfire.com o: 303.746.7302 Advancing the way the world uses the cloud<http://solidfire.com/solution/overview/?video=play> *™*
