[RFC] About the way Kimchi deals with services (libvirt, nfs, etc)

Hello all, I am working in a nfs related bug where kimchi hungs up if the nfs service stops for some reason while creating a NFS pool. I have a very similar situation Power-only with another service. My idea at first was to verify the service status every time we request a specific service. This could work for actions that requires specific services, such as NFS. However, for this approach make sense, we should verify the status of libvirt for all the operations that depend of it. We would flood the code with "if (libvirt.service is active) " conditionals do to pretty much anything. Thus, I am creating this RFC to ask you: how can we handle Kimchi dependencies on external services in a neat, clean way? Mark suggested to use systemd, for example. Thanks!

Hello all,
I am working in a nfs related bug where kimchi hungs up if the nfs service stops for some reason while creating a NFS pool. I have a very similar situation Power-only with a But nother service.
My idea at first was to verify the service status every time we request a specific service. This could work for actions that requires specific services, such as NFS. However, for this approach make sense, we should verify the status of libvirt for all the operations that depend of it. We would flood the code with "if (libvirt.service is active) " conditionals do to pretty much anything. Do you mean to check nfs service indirectly by checking libvirtd service? It is possible that the command hangs when you try to check
2014/2/17 19:17, Daniel H Barboza: the libvirt service with commands like "service status libvirtd". I would suggest to check the service status in another process and set a timeout value for the process to time out.
Thus, I am creating this RFC to ask you: how can we handle Kimchi dependencies on external services in a neat, clean way? Mark suggested to use systemd, for example.
Thanks!
_______________________________________________ Kimchi-devel mailing list Kimchi-devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/kimchi-devel
participants (2)
-
Daniel H Barboza
-
Shu Ming