+1 to Russell's proposal. I came to similar conclusions when looking at snapshots for the XenAPI NFS driver (seems similar to the qemu NFS option, except uses VHD not qcow2).
I wondered about, but discarded, the idea about a new cinder-compute worker on each compute node for all volume operations (I guess a bit like brick). Seemed like overkill, and the way it scales just didn't seem right. Quiesced snapshots might require more co-ordination with cinder, I don't really know too much about VSS, but looks like there is only a 60 second window to persist a snapshot: http://msdn.microsoft.com/en-us/library/aa384589(v=vs.85).aspx John On 7 August 2013 04:11, John Griffith <[email protected]> wrote: > > > > On Tue, Aug 6, 2013 at 7:25 PM, Russell Bryant <[email protected]> wrote: >> >> On 08/06/2013 06:55 PM, John Griffith wrote: >> > >> > >> > >> > On Tue, Aug 6, 2013 at 4:05 PM, Russell Bryant <[email protected] >> > <mailto:[email protected]>> wrote: >> > >> > Greetings, >> > >> > The following blueprint is targeted at Havana. I was reading over >> > the >> > design notes today. I wanted to check on the status of this as well >> > as >> > discuss some of the design details. >> > >> > https://wiki.openstack.org/wiki/Cinder/GuestAssistedSnapshotting >> > >> > https://blueprints.launchpad.net/nova/+spec/qemu-assisted-snapshots >> > >> > As a quick overview, the purpose of this is to provide the ability >> > to do >> > volume snapshots for certain volume types that do not support it >> > internally, such as the GlusterFS or NFS drivers. >> > >> > Some comments/questions ... >> > >> > On the Nova side, the wiki page lists adding an API to snapshot all >> > attached volumes at once. This seems fine, but I would personally >> > put >> > it at a lower priority than just making basic snapshots work. The >> > Nova >> > patch I've seen come by so far [1] was for this API, but like I >> > said, I >> > would just come back to this once regular snapshots work. >> > >> > >> > +1 from me on this for sure >> > >> > >> > The page also indicates that a snapshot request through the Cinder >> > API >> > will only work through if it's not attached. That seems fairly >> > undesirable. Can we try to address that with the first pass? It >> > seems >> > like we could do something like: >> > >> > on the cinder side: >> > >> > cinder snapshot API >> > if snapshot requires guest assist while in use, and is in >> > use: >> > call nova's guest assisted snapshot API >> > else: >> > do snapshot in cinder >> > >> > on the nova side: >> > >> > nova's new guest assisted snapshot API >> > if volume type is a local file: >> > do local magic to create a snapshot and call >> > the new create-snapshot-metadata API call in cinder >> > else: >> > do cinder API call to do a snapshot, but potentially >> > adding some guest assistance here (to get the filesystem >> > in a consistent state first, for example) >> > >> > >> > Part of this reminds me of my whole debate about shared FS storage mixed >> > in Cinder to begin with. The capabilties are different, and I think >> > mixing around this "if this: do nova-xxxx; else: do cinder-xxx" results >> > in a poor end-user experience to say the least. >> > >> > My proposal would be to change a couple of things here: >> > >> > 1. As Russell suggests leave the API calls in Cinder. I don't see a >> > strong reason why we can't have a "nova" driver to send requests to >> > Compute for things like this. Even if implementation wise we're still >> > looking at things spread between the two (which I still don't find very >> > appealing) at least from an end-users perspective it's not so confusing >> > as to what's going on. >> > >> > 2. Consider rather than using the existing "cinder snapshot" command we >> > introduce something unique for this special case. This would give the >> > ability to do what we want here and would be considered acceptable in >> > terms of the cinder minimum qualifications requirement. I don't care >> > what it's called, "cinder snapshot-share" or whatever, but it seems like >> > it's a different semantic so should be a different call. >> >> I buy keeping a single API for snapshots (Cinder), but why should it be >> a new Cinder API? Is it really different from the end user's >> perspective? It's obviously wildly different on the backend. It >> requires some cooperation from nova, but it's all done with the VM still >> running AFAIK. > > > So maybe that last part isn't all that necessary, but part of the reason I > mention that has to do with some history. I'm pretty adamant about behavior > consistency and expectations regardless of the backend (a somewhat unpopular > stance with vendors). Part of the reason for this suggestion is the fact > that I *believe* some of these back-ends actually require the volume be > attached to an instance in order to perform the snapshot. Most of the block > devices don't care and do snapshots strictly internally on the device > itself. > > I may be wrong about how this shakes out so I'm perfectly happy to be wrong > and not require an extension or new API call here. >> >> >> > >> > Similarly to create, I think having delete work through Nova, but >> > not >> > Cinder isn't ideal. Can we address that as well with a similar >> > smart-redirect approach? >> > >> > >> > Again, agree on this... having the mix between the two seems like it >> > will just create confusion IMO. The same strategy as suggested above >> > could work here as well. >> > >> > >> > My final comment on all of this is that I'm not a huge fan of having >> > snapshot create/delete in both the nova and cinder APIs. I can't >> > think >> > of a better way to accomplish this, though. We don't have a nova >> > API >> > only exposed internally to the deployment, and I don't think this >> > feature is enough to warrant adding one. >> > >> > >> > So the internal nova API direction is more along the lines of what I was >> > suggesting. To be honest I suspect there's the possibility of more >> > things fitting here in the future but I see your point. The problem I >> > have is if these features aren't enough to justify it then are these >> > features worth enough to justify the confusion of using multiple >> > services/api's do do a volume snapshot? >> >> Yeah, you're right on this. Let's do it. >> >> -- >> Russell Bryant >> >> _______________________________________________ >> OpenStack-dev mailing list >> [email protected] >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > Thanks for the feedback on this, > John > > > _______________________________________________ > OpenStack-dev mailing list > [email protected] > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list [email protected] http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
