Tarantool development patches archive
 help / color / mirror / Atom feed
From: Alexander Turenko <alexander.turenko@tarantool.org>
To: Sergey Bronnikov <sergeyb@tarantool.org>
Cc: tarantool-patches@dev.tarantool.org
Subject: Re: [Tarantool-patches] [PATCH] Add options for upgrade testing
Date: Fri, 20 Nov 2020 01:58:59 +0300	[thread overview]
Message-ID: <20201119225859.evkmxyki4xbxm7aa@tkn_work_nb> (raw)
In-Reply-To: <8365255bb9eef01293f66d9a7293730fecc49e2b.1605691680.git.sergeyb@tarantool.org>

Not a review.

On Wed, Nov 18, 2020 at 12:30:49PM +0300, sergeyb@tarantool.org wrote:
> From: Sergey Bronnikov <sergeyb@tarantool.org>
> 
> Option '--snapshot' specifies a path to snapshot that will be loaded in
> Tarantool before testing.
> 
> Option '--disable-schema-upgrade' allows to skip execution
> of Tarantool upgrade script using error injection mechanism.
> 
> Closes https://github.com/tarantool/tarantool/issues/4801

This change cannot close the issue in tarantool. We need to look at all
variants of bootstrap snapshot we had over the history of supported
release branches (and maybe a bit deeper, down to some 1.9) and manifest
compatibility matrix between given data layouts and runtimes ([1]). Once
the support matrix will be defined, we should catch all test fails,
analyze and categorize them. File issue for real problems, exclude
irrelevant fails. Setup CI. It is not a small task.

[1]: https://github.com/tarantool/doc/issues/836

I think we should file an issue to test-run, solve it within our
planning iteration and estimate #4801 for the next iteration.

While I thinking around the task, the idea how to solve the problem with
replication tests comes to me. I know, know. I should have to say it
before you start the task, but I don't know everything in advance,
learning together with you and do my best.

Back to the idea. We can implement an option or errinj to pass a path to
bootstrap snapshot to tarantool and feed it instead the built-in
bootstrap.snap. This way we'll go to the right branch here:

 [src/box/box.cc; box_cfg_xc()]

 | if (checkpoint != NULL) {
 |         /* Recover the instance from the local directory */                            
 |         local_recovery(&instance_uuid, &replicaset_uuid,                               
 |                        &checkpoint->vclock);                                           
 | } else {
 |         /* Bootstrap a new instance */
 |         bootstrap(&instance_uuid, &replicaset_uuid,                                    
 |                   &is_bootstrap_leader);                                               
 | }

And so will land here:

 [src/box/memtx_engine.c; memtx_engine_bootstrap()]

 | /* Recover from bootstrap.snap */
 | say_info("initializing an empty data directory");
 | struct xlog_cursor cursor;
 | if (xlog_cursor_openmem(&cursor, (const char *)bootstrap_bin,
 |                         sizeof(bootstrap_bin), "bootstrap") < 0)
 |         return -1;

It is the place, where we should give our custom snapshot instead of
`bootstrap_bin` (which contains src/box/bootstrap.snap content).

I would call the test-run option that feeds a snapshot to tarantool this
way --bootstrap instead of --snapshot to don't confuse the local
recovery process with bootstrapping from an empty directory.

Let's discuss tasks, planning, worthiness of eating a pie step-by-step
voicely.

  reply	other threads:[~2020-11-19 22:58 UTC|newest]

Thread overview: 21+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-30 14:48 [Tarantool-patches] [test-run] " Sergey Bronnikov
2020-05-15 16:17 ` Alexander Turenko
2020-05-28  9:39   ` Sergey Bronnikov
2020-06-02 11:13     ` Alexander Turenko
2020-06-10 11:29       ` Sergey Bronnikov
2020-11-10  9:55         ` Sergey Bronnikov
2020-11-13 12:41           ` Leonid Vasiliev
2020-11-19  9:44             ` Sergey Bronnikov
2020-11-16 16:40           ` Alexander Turenko
2020-11-18  9:18             ` Sergey Bronnikov
2020-11-18  9:33               ` Sergey Bronnikov
2020-11-18  9:30             ` [Tarantool-patches] [PATCH] " sergeyb
2020-11-19 22:58               ` Alexander Turenko [this message]
2020-11-20 19:27                 ` Sergey Bronnikov
2020-11-27  1:45               ` Alexander Turenko
2020-12-01 12:32                 ` Sergey Bronnikov
2020-12-02  3:40                   ` Alexander Turenko
2020-12-02 10:49                     ` Sergey Bronnikov
2020-12-03  2:09                       ` Alexander Turenko
2020-12-04  4:08                         ` Alexander Turenko
2020-11-29  1:54               ` Alexander Turenko

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20201119225859.evkmxyki4xbxm7aa@tkn_work_nb \
    --to=alexander.turenko@tarantool.org \
    --cc=sergeyb@tarantool.org \
    --cc=tarantool-patches@dev.tarantool.org \
    --subject='Re: [Tarantool-patches] [PATCH] Add options for upgrade testing' \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox