[pve-devel] [PATCH v3 qemu-server 3/8] refactor: split check_running into _exists_ and _running_

Stefan Reiter s.reiter at proxmox.com
Tue Nov 19 11:54:44 CET 2019


On 11/19/19 10:59 AM, Thomas Lamprecht wrote:
> On 11/19/19 10:30 AM, Fabian Grünbichler wrote:
>>> +
>>>   # BEGIN implemented abstract methods from PVE::AbstractConfig
>> IMHO, vm_exists_on_node is a prime candidate for being put into
>> AbstractConfig - it's not qemu-specific at all, we probably want to do a
>> similar split for pve-container as well, and we want to use it when
>> appropriate in AbstractConfig.
>>
>> any objections to moving it there? maybe adapt the name?
>> s/vm/guest_config/ ? actual moving could also be done at a latter point
>> to avoid the bump in + depends on pve-guest-common
>>
> 
> sounds OK, I'd maybe go for "config_exists_on_node", the guest is
> somewhat implicit for methods coming out of that module..

+1

> 
> Else, as "AbstractConfig->config_file" already can be passed a node,
> it could also be ommitted, just using, for example:
> 
> if ! -f AbstractConfig->config_file(...)
> 
> over
> 
> if ! AbstractConfig->config_exists_on_node(...)
> 
> seems not like the biggest win anyway, but no hard feelings...

I like it because it abstracts the whole 'die' and error message code, a 
bit more readable on the call site IMO. Although it might be better 
named "check_config_exists_on_node", since without the $noerr (where 
Fabian was right, it is unnecessary) the function will always die if 
there's an error?

In general I'd like to leave it in, but should I do so in AbstractConfig 
or leave it here for now?

> 
> 
> _______________________________________________
> pve-devel mailing list
> pve-devel at pve.proxmox.com
> https://pve.proxmox.com/cgi-bin/mailman/listinfo/pve-devel
> 




More information about the pve-devel mailing list