[pve-devel] [PATCH v2 guest-common 02/18] refactor method used by config GET calls into AbstractConfig

[Oguz Bektas]

hi,

On Wed, Oct 02, 2019 at 01:49:23PM +0200, Fabian Grünbichler wrote:
> On September 30, 2019 2:44 pm, Oguz Bektas wrote:
> > since this method will be both used by qemu and lxc config GET calls, it
> > makes sense to move it into AbstractConfig. only difference is that qemu
> > also hides the cipassword when it's set. this can be handled by having
> > qemu overwrite the method and add the cipassword code.
> > 
> > Signed-off-by: Oguz Bektas <o.bektas at proxmox.com>
> > ---
> >  PVE/AbstractConfig.pm | 35 +++++++++++++++++++++++++++++++++++
> >  1 file changed, 35 insertions(+)
> > 
> > diff --git a/PVE/AbstractConfig.pm b/PVE/AbstractConfig.pm
> > index 910ca86..6d3f169 100644
> > --- a/PVE/AbstractConfig.pm
> > +++ b/PVE/AbstractConfig.pm
> > @@ -136,6 +136,41 @@ sub cleanup_pending {
> >      return $changes;
> >  }
> >  
> > +sub load_current_config {
> 
> like I said when we discussed this offline, that name is at most a 
> working title :-P the method either returns

i still can't find a reasonable name for it, so just kept load_current_config
it kind of makes sense if we split it

> 
> A the top level config, ignoring any pending changes (called 'current' 
>   in the API schema)
> B the top level config, with any pending changes pseudo-applied (the 
>   opposite of 'current')
> C the config of a specific snapshot + digest of whole file (also not very 'current').
> 
> we can either split this up into
> 
> sub load_config_snapshot => returns C
> sub load_.... ? => returns A or B, depending on parameter
> 
> or make a
> 
> sub load_config_filtered {
>     my ($class, $vmid, $filter) = @_;
> 
> where $filter is a hash, currently with
> { 'snapshot' => $snapname }
> 
> or
> 
> { 'current' => 1 }
> 
> both at once don't make sense, and should probably lead to death.
> 
> I'd prefer the split, since the first half for case C, and the second 
> half for cases A and B don't have much in common anyway. if we have some 
> other filters in mind that we might add in the future, then the $filter 
> variant might be more attractive.

for now we have no use case for the method with $filter, so i think it's unnecessary atm.

i think i'll go for the split. something like:

---------------------------------------
sub load_snapshot_config {
    my ($class, $vmid, $snapname) = @_;

    my $conf = $class->load_config($vmid);

    my $snapshot = $conf->{snapshots}->{$snapname};
    die "snapshot '$snapname' does not exist\n" if !defined($snapshot);

    # we need the digest of the file
    $snapshot->{digest} = $conf->{digest};

    return $snapshot;
}

sub load_config_current {
    # the rest
...
}

---------------------------------------

> 
> > +    my ($class, $vmid, $snapname, $current) = @_;
> > +
> > +    my $conf = $class->load_config($vmid);
> > +
> > +    if ($snapname) {
> > +	my $snapshot = $conf->{snapshots}->{$snapname};
> > +	die "snapshot '$snapname' does not exist\n" if !defined($snapshot);
> > +
> > +	# we need the digest of the file
> > +	$snapshot->{digest} = $conf->{digest};
> > +	$conf = $snapshot;
> > +    }
> > +
> > +    # take pending changes in
> > +    if (!$current) {
> > +	foreach my $opt (keys %{$conf->{pending}}) {
> > +	    next if $opt eq 'delete';
> > +	    my $value = $conf->{pending}->{$opt};
> > +	    next if ref($value); # just to be sure
> > +	    $conf->{$opt} = $value;
> > +	}
> > +	my $pending_delete_hash = $class->parse_pending_delete($conf->{pending}->{delete});
> > +	foreach my $opt (keys %$pending_delete_hash) {
> > +	    delete $conf->{$opt} if $conf->{$opt};
> > +	}
> > +    }
> > +
> > +    delete $conf->{snapshots};
> > +    delete $conf->{pending};
> > +
> > +    return $conf;
> > +}
> > +
> > +
> >  # Lock config file using flock, run $code with @param, unlock config file.
> >  # $timeout is the maximum time to aquire the flock
> >  sub lock_config_full {
> > -- 
> > 2.20.1
> > 
> > _______________________________________________
> > pve-devel mailing list
> > pve-devel at pve.proxmox.com
> > https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
> > 
> > 
> 
> _______________________________________________
> pve-devel mailing list
> pve-devel at pve.proxmox.com
> https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>