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.bek...@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@pve.proxmox.com
> > https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
> >
> >
>
> _______________________________________________
> pve-devel mailing list
> pve-devel@pve.proxmox.com
> https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
>
_______________________________________________
pve-devel mailing list
pve-devel@pve.proxmox.com
https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
