From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <s.hanreich@proxmox.com>
Received: from firstgate.proxmox.com (firstgate.proxmox.com [212.224.123.68])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits))
 (No client certificate requested)
 by lists.proxmox.com (Postfix) with ESMTPS id D4E1E91355
 for <pve-devel@lists.proxmox.com>; Tue, 27 Sep 2022 09:41:03 +0200 (CEST)
Received: from firstgate.proxmox.com (localhost [127.0.0.1])
 by firstgate.proxmox.com (Proxmox) with ESMTP id B7AED1BCDE
 for <pve-devel@lists.proxmox.com>; Tue, 27 Sep 2022 09:40:33 +0200 (CEST)
Received: from proxmox-new.maurer-it.com (proxmox-new.maurer-it.com
 [94.136.29.106])
 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)
 key-exchange X25519 server-signature RSA-PSS (2048 bits))
 (No client certificate requested)
 by firstgate.proxmox.com (Proxmox) with ESMTPS
 for <pve-devel@lists.proxmox.com>; Tue, 27 Sep 2022 09:40:32 +0200 (CEST)
Received: from proxmox-new.maurer-it.com (localhost.localdomain [127.0.0.1])
 by proxmox-new.maurer-it.com (Proxmox) with ESMTP id 43E17445A9
 for <pve-devel@lists.proxmox.com>; Tue, 27 Sep 2022 09:40:32 +0200 (CEST)
Message-ID: <33c05af8-058d-6056-7d9d-9b731b4de58b@proxmox.com>
Date: Tue, 27 Sep 2022 09:40:31 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
 Thunderbird/91.13.0
Content-Language: en-US
To: Thomas Lamprecht <t.lamprecht@proxmox.com>,
 Proxmox VE development discussion <pve-devel@lists.proxmox.com>
References: <20220922141321.1510795-1-s.hanreich@proxmox.com>
 <20220922141321.1510795-2-s.hanreich@proxmox.com>
 <953a9847-4560-495f-6c2f-62f2b1696793@proxmox.com>
From: Stefan Hanreich <s.hanreich@proxmox.com>
In-Reply-To: <953a9847-4560-495f-6c2f-62f2b1696793@proxmox.com>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 7bit
X-SPAM-LEVEL: Spam detection results:  0
 AWL 1.757 Adjusted score from AWL reputation of From: address
 BAYES_00                 -1.9 Bayes spam probability is 0 to 1%
 KAM_DMARC_STATUS 0.01 Test Rule for DKIM or SPF Failure with Strict Alignment
 NICE_REPLY_A           -2.319 Looks like a legit reply (A)
 SPF_HELO_NONE           0.001 SPF: HELO does not publish an SPF Record
 SPF_PASS               -0.001 SPF: sender matches SPF record
 URIBL_BLOCKED 0.001 ADMINISTRATOR NOTICE: The query to URIBL was blocked. See
 http://wiki.apache.org/spamassassin/DnsBlocklists#dnsbl-block for more
 information. [abstractmigrate.pm]
Subject: Re: [pve-devel] [PATCH pve-guest-common 1/1] Add abstract methods
 for pre/post-migrate hooks
X-BeenThere: pve-devel@lists.proxmox.com
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Proxmox VE development discussion <pve-devel.lists.proxmox.com>
List-Unsubscribe: <https://lists.proxmox.com/cgi-bin/mailman/options/pve-devel>, 
 <mailto:pve-devel-request@lists.proxmox.com?subject=unsubscribe>
List-Archive: <http://lists.proxmox.com/pipermail/pve-devel/>
List-Post: <mailto:pve-devel@lists.proxmox.com>
List-Help: <mailto:pve-devel-request@lists.proxmox.com?subject=help>
List-Subscribe: <https://lists.proxmox.com/cgi-bin/mailman/listinfo/pve-devel>, 
 <mailto:pve-devel-request@lists.proxmox.com?subject=subscribe>
X-List-Received-Date: Tue, 27 Sep 2022 07:41:03 -0000



On 9/26/22 17:27, Thomas Lamprecht wrote:
> Am 22/09/2022 um 16:13 schrieb Stefan Hanreich:
>> Signed-off-by: Stefan Hanreich <s.hanreich@proxmox.com>
>> ---
>>   src/PVE/AbstractMigrate.pm | 14 ++++++++++++++
>>   1 file changed, 14 insertions(+)
>>
> 
> for the record, if we do it like this (not much rationale given in the commit message)
> this breaks containers and qemu-server without such an implementation and needs the
> respective Breaks/Depends entries in d/control (which you cannot add as you cannot
> predict the exact version this would get actually added).
>

I figured this might pose some problems when releasing. Is there any way 
I can work around this (also for future patches)? Or do we have to bump 
all 3 packages at once? Anything I should change in particular in this 
case (if we stick to having the hooks in the common package..)

Do you think it might be smarter to move the hooks into the respective 
backend? It shouldn't be too much of a hassle. Maybe it is a smarter 
idea after all, since it allows for more fine-grained control of when 
the hooks should be run exactly.

>> diff --git a/src/PVE/AbstractMigrate.pm b/src/PVE/AbstractMigrate.pm
>> index d90e5b7..5e03488 100644
>> --- a/src/PVE/AbstractMigrate.pm
>> +++ b/src/PVE/AbstractMigrate.pm
>> @@ -178,6 +178,8 @@ sub migrate {
>>   	        "public key authentication\n" if $@;
>>   	}
>>   
>> +	$self->pre_migration_hooks($self->{vmid});
>> +
>>   	&$eval_int($self, sub { $self->phase1($self->{vmid}); });
>>   	my $err = $@;
>>   	if ($err) {
>> @@ -228,6 +230,8 @@ sub migrate {
>>   	    $self->log('err', $err);
>>   	    $self->{errors} = 1;
>>   	}
>> +
>> +	$self->post_migration_hooks($self->{vmid});
>>       })};
>>   
>>       my $err = $@;
>> @@ -368,4 +372,14 @@ sub get_bwlimit {
>>       return $bwlimit;
>>   }
>>   
>> +sub pre_migration_hooks {
>> +    my ($self, $vmid) = @_;
>> +    die "abstract method - implement me";
>> +}
>> +
>> +sub post_migration_hooks {
>> +    my ($self, $vmid) = @_;
>> +    die "abstract method - implement me";
>> +}
>> +
>>   1;
>