"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)."
I said that a little incorrectly. The storage framework shouldn't be sending those messages to the hypervisors (as in StorageManager shouldn't be sending them). I believe it's VolumeApiService. For example, the AttachCommand being sent in VolumeApiService.sendAttachVolumeCommand. On Sat, Sep 21, 2013 at 11:43 PM, Mike Tutkowski < mike.tutkow...@solidfire.com> wrote: > 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> > *™* > -- *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> *™*
