Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

librbd: initial set of changes to migration API for instant-restore #37714

Merged
merged 13 commits into from
Oct 26, 2020

Conversation

dillaman
Copy link

Start the process of allowing a JSON-encoded migration source-spec string to be provided. This implies that migration should always attempt to first open the destination image for execute/commit/abort actions. This also includes an initial implementation of a raw, file-based image source IO path handler.

The partial result should be based upon buffer-extent positions
not the original image-extent positions.

Signed-off-by: Jason Dillaman <dillaman@redhat.com>
@dillaman dillaman force-pushed the wip-librbd-migration-1 branch 2 times, most recently from b502669 to c5742c8 Compare October 22, 2020 00:52
overlap == ms.overlap && flatten == ms.flatten &&
mirroring == ms.mirroring && mirror_image_mode == ms.mirror_image_mode &&
state == ms.state && state_description == ms.state_description;
image_id == ms.image_id && source_spec == ms.source_spec &&
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

nit: just wondering, wouldn't it be more correct to compare the source spec just after comparing the header type?

It wouldn't make any difference in real life though I suppose...

@trociny
Copy link
Contributor

trociny commented Oct 22, 2020

And just wondering, what was the reason to use json for the migration source spec? It seems that "ceph native encoding" could work here too, similarly how it is used e.g. for encoding different journal event types.

@dillaman
Copy link
Author

And just wondering, what was the reason to use json for the migration source spec? It seems that "ceph native encoding" could work here too, similarly how it is used e.g. for encoding different journal event types.

We want someone to be able to define it on the CLI without using a hexeditor, so once we have a JSON/XML format, we might was well just keep it in the single format instead of creating yet another format (that would also need to be extensible to permit new formats, streams, etc).

@trociny
Copy link
Contributor

trociny commented Oct 22, 2020

We want someone to be able to define it on the CLI without using a hexeditor, so once we have a JSON/XML format, we might was well just keep it in the single format instead of creating yet another format (that would also need to be extensible to permit new formats, streams, etc).

We could make the CLI/API convert the user format to a native ceph encoding (Anyway, I suppose we might want to validate somehow the user input before storing it in the image migration header?) And users can't extent a format until it is supported by librbd, so this extension could be added to the native encoding.

But I don't have a strong opinion here. Just ignore if you like your way.

Jason Dillaman added 3 commits October 22, 2020 09:40
The initial hooks merely abstract the standard RBD parent/child
clone relationship. The basic interface, however, is abstract
enough to allow third party data formats and streams to be eventually
integrated with RBD live-migration.

Signed-off-by: Jason Dillaman <dillaman@redhat.com>
The migration open source image state machine will handle how to
initialize the source ImageCtx depending on the format and
protocol utilized for the source image.

Signed-off-by: Jason Dillaman <dillaman@redhat.com>
… spec

This source-spec will include a JSON-encoded structure describing the source
format and protocol for accessing the source image data.

Signed-off-by: Jason Dillaman <dillaman@redhat.com>
@dillaman
Copy link
Author

If we had an intermediate binary format, the OSDs (cls_rbd methods) would still need to treat the source_spec as binary blob and not attempt to decode it or else adding new client-side only features would require OSD upgrades. On the client-side, the next PR adds basic validation (valid JSON, can properly open the source before creating the destination image w/ the embedded JSON). This basic validation could probably be extended to support fail or warn on unknown attributes (i.e. don't let an image be created with attributes that are not used / understood) or warn on unused/unknown arguments on open.

The journal was all binary encoded for performance/space efficiency reasons which I don't think applies here. I think at the end of it all, JSON can provide the exact same set of forward and backward protection as native encoding w/o all the extra boilerplate code. I would think at best you just a few bytes of space savings here and there since you wouldn't have to encode key names and non-text values can be binary encoded. Just my opinion.

Copy link
Contributor

@trociny trociny left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

LGTM

@trociny
Copy link
Contributor

trociny commented Oct 24, 2020

Jason Dillaman added 7 commits October 24, 2020 13:51
The legacy migration source format has explicit pool, namespace, and image
parameters. This helper method will convert it into the JSON format that
will be used for the new-style migration source-spec.

Signed-off-by: Jason Dillaman <dillaman@redhat.com>
When using advanced, non-legacy migration sources like a remote Ceph
cluster or a flat file, this API will return the JSON-encoded description
of the migration source.

Signed-off-by: Jason Dillaman <dillaman@redhat.com>
This will help ensure that the source ImageCtx can be made optional
when migrating from a read-only, non-native image source.

Signed-off-by: Jason Dillaman <dillaman@redhat.com>
With the exception of the 'prepare' command, always attempt to open
the destination image first. This will better align with the
ability for read-only, non-native images to be used as a source
image.

Signed-off-by: Jason Dillaman <dillaman@redhat.com>
Signed-off-by: Jason Dillaman <dillaman@redhat.com>
The file stream helper will translate byte-extent IO read requests
to ASIO file read requests on the specified backing file. This can be
layered with file format helpers to translate image IO extents down
to the backing file.

Signed-off-by: Jason Dillaman <dillaman@redhat.com>
The raw format maps an abstract, fully allocated, raw block device image
to the migration source IO API.

Signed-off-by: Jason Dillaman <dillaman@redhat.com>
@dillaman
Copy link
Author

@trociny Thanks. The first two (cli and python) were due to typos during rebases and have been corrected. I'll fix the memory leak tomorrow as a new appended commit.

Jason Dillaman added 2 commits October 26, 2020 12:01
Tweak the format interface's 'read' call to just let the existing
read request continue passed the migration layer if the native
format is in use. Otherwise, the provided AioCompletion would need to
be wrapped with another AioCompletion to prevent the original
image dispatch spec from getting lost.

Signed-off-by: Jason Dillaman <dillaman@redhat.com>
Prevent re-using the same AioCompletion between multiple
ImageDispatchSpec objects to prevent the possibility of a memory
leak.

Signed-off-by: Jason Dillaman <dillaman@redhat.com>
@trociny
Copy link
Contributor

trociny commented Oct 26, 2020

@dillaman Jenkins failed on assertion inTestLibRBD.FlushEmptyOpsOnExternalSnapshot, but I suspect it is related to my recent changes to the watcher. I am going to investigate this tomorrow (if the cause is not obvious for you).

@dillaman
Copy link
Author

@dillaman Jenkins failed on assertion inTestLibRBD.FlushEmptyOpsOnExternalSnapshot, but I suspect it is related to my recent changes to the watcher. I am going to investigate this tomorrow (if the cause is not obvious for you).

Yeah, it's an issue related to the watcher changes. Looks like the SafeTimer isn't actually configured to be safe (m_safe_timer = new SafeTimer(cct, m_lock, false)) so there is a possibility for the timer to fire but not get invoked w/ m_lock locked and therefore race w/ any of the cancel_event calls.

@dillaman
Copy link
Author

jenkins test make check

@trociny trociny merged commit ec64935 into ceph:master Oct 26, 2020
@dillaman dillaman deleted the wip-librbd-migration-1 branch October 26, 2020 19:26
@trociny
Copy link
Contributor

trociny commented Oct 28, 2020

Yeah, it's an issue related to the watcher changes. Looks like the SafeTimer isn't actually configured to be safe (m_safe_timer = new SafeTimer(cct, m_lock, false)) so there is a possibility for the timer to fire but not get invoked w/ m_lock locked and therefore race w/ any of the cancel_event calls.

pushed #37880 for this.

@trociny
Copy link
Contributor

trociny commented Oct 29, 2020

https://pulpito.ceph.com/jdillaman-2020-10-26_10:08:16-rbd-wip-jd-testing-distro-basic-smithi/
https://pulpito.ceph.com/jdillaman-2020-10-26_10:23:51-rbd-wip-jd-testing-distro-basic-smithi/

@dillaman I missed this before merging (the job was still running when I was looking and later I forgot to check its status before merging), but there was one failure [1], though I have no idea if it is related. If I interpret the logs correctly It seems like the qemu got stuck?

Just wanted to let you know in case you had not seen this and would be interested.

[1] http://qa-proxy.ceph.com/teuthology/jdillaman-2020-10-26_10:23:51-rbd-wip-jd-testing-distro-basic-smithi/5560517/teuthology.log

@dillaman
Copy link
Author

dillaman commented Oct 29, 2020

The dynamic_features_no_cache has been getting randomly stuck for a while. I tried to look into it a couple weeks ago by increasing the log levels but then it failed to repeat. I'll open a ticket against it so that I don't forget about it [1]

[1] https://tracker.ceph.com/issues/48038

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
2 participants