External/libvirt
1
0
Fork 0
mirror of https://gitlab.com/libvirt/libvirt.git synced 2024-12-30 17:45:23 +00:00
Code Issues Packages Projects Releases Wiki Activity
0f61d7b5f2
libvirt/src/libvirt_admin_public.syms

42 lines
1.3 KiB
Plaintext
Raw Normal View History

Add libvirt-admin library Initial scratch of the admin library. It has its own virAdmConnectPtr that inherits from virAbstractConnectPtr and thus trivially supports error reporting. There's pkg-config file added and spec-file adjusted as well. Since the library should be "minimalistic" and not depend on any other library, the list of files is especially crafted for it. Most of them could've been put to it's own sub-libraries that would be LIBADD'd to libvirt_util, libvirt_net_rpc and libvirt_setuid_rpc_client to minimize the number of object files being built, but that's a refactoring that isn't the orginal aim of this commit. Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2015-04-15 14:16:24 +00:00
#
# Officially exported symbols, for which header
# file definitions are installed in /usr/include/libvirt
# from libvirt-admin.h
#
# Versions here are *fixed* to match the libvirt version
# at which the symbol was introduced. This ensures that
# a new client app requiring symbol foo() can't accidentally
# run with old libvirt-admin.so not providing foo() - the global
# soname version info can't enforce this since we never
# change the soname
#
admin: enable both admin API functionality and tarball distribution This patch enables admin socket creation in daemon's code, bumps the library version in libvirt_admin_public.syms, and performs all necessary modifications to our makefiles so that admin API can finally be included in the tarball, and eventually become part of an rpm package (a patch later in this series). Signed-off-by: Erik Skultety <eskultet@redhat.com>
2016-06-24 17:27:09 +00:00
LIBVIRT_ADMIN_2.0.0 {
Add libvirt-admin library Initial scratch of the admin library. It has its own virAdmConnectPtr that inherits from virAbstractConnectPtr and thus trivially supports error reporting. There's pkg-config file added and spec-file adjusted as well. Since the library should be "minimalistic" and not depend on any other library, the list of files is especially crafted for it. Most of them could've been put to it's own sub-libraries that would be LIBADD'd to libvirt_util, libvirt_net_rpc and libvirt_setuid_rpc_client to minimize the number of object files being built, but that's a refactoring that isn't the orginal aim of this commit. Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2015-04-15 14:16:24 +00:00
global:
admin: fix virt-admin startup crash by calling virAdmInitialize Similarly to what virsh virt-login-shell do, call virAdmInitialize prior to initializing an event loop and initializing the error handler. Commit 97973ebb7 described and fixed an identical issue for libvirt_lxc. Since virAdmInitialize becomes a public API after applying this patch, the symbol is also added to public syms and the doc string of the method is slightly enhanced analogically to virInitialize. Signed-off-by: Erik Skultety <eskultet@redhat.com>
2016-06-29 14:12:58 +00:00
virAdmInitialize;
admin: Introduce virAdmClient client-side object Besides ID, the object also stores static data like connection transport and connection timestamp, since once obtained a list of all clients connected to a server, from user's perspective, it would be nice to know whether a given client is remote or local only and when did it connect to the daemon. Along with the object introduction, all necessary client-side methods necessary to work with the object are added as well. Signed-off-by: Erik Skultety <eskultet@redhat.com>
2016-04-13 08:35:26 +00:00
virAdmClientFree;
virAdmClientGetID;
virAdmClientGetTimestamp;
virAdmClientGetTransport;
Revert "admin: Rename virAdmConnect to virAdmDaemon" Commmit df8192aa introduced admin related rename and some minor (caused by automated approach, aka sed) and some more severe isues along with it. First reason to revert is the inconsistency with libvirt library. Although we deal with the daemon directly rather than with a specific hypervisor, we still do have a connection. That being said, contributors might get under the impression that AdmDaemonNew would spawn/start a new daemon (since it's admin API, why not...), or AdmDaemonClose would do the exact opposite or they might expect DaemonIsAlive report overall status of the daemon which definitely isn't the case. The second reason to revert this patch is renaming virt-admin client. The client tool does not necessarily have to reflect the names of the API's it's using in his internals. An example would be 's/vshAdmConnect/vshAdmDaemon' where noone can be certain of what the latter function really does. The former is quite expressive about some connection magic it performs, but the latter does not say anything, especially when vshAdmReconnect and vshAdmDisconnect were left untouched.
2015-12-10 12:46:45 +00:00
virAdmConnectOpen;
virAdmConnectClose;
virAdmConnectRef;
admin: introduce virAdmGetVersion Unfortunately, client side version retrieval API virGetVersion uses one-time initialization (due to the fact we might not have initialized the library by calling connect prior to this) which is not completely compatible with admin initialization. This API is rather simplistic and reimplementing it for admin might be the preferred method of reusing it. Note that even though the method will be reimplemented, the version number is still the same for both the libvirt and libvirt-admin library.
2015-11-26 14:08:36 +00:00
virAdmGetVersion;
Revert "admin: Rename virAdmConnect to virAdmDaemon" Commmit df8192aa introduced admin related rename and some minor (caused by automated approach, aka sed) and some more severe isues along with it. First reason to revert is the inconsistency with libvirt library. Although we deal with the daemon directly rather than with a specific hypervisor, we still do have a connection. That being said, contributors might get under the impression that AdmDaemonNew would spawn/start a new daemon (since it's admin API, why not...), or AdmDaemonClose would do the exact opposite or they might expect DaemonIsAlive report overall status of the daemon which definitely isn't the case. The second reason to revert this patch is renaming virt-admin client. The client tool does not necessarily have to reflect the names of the API's it's using in his internals. An example would be 's/vshAdmConnect/vshAdmDaemon' where noone can be certain of what the latter function really does. The former is quite expressive about some connection magic it performs, but the latter does not say anything, especially when vshAdmReconnect and vshAdmDisconnect were left untouched.
2015-12-10 12:46:45 +00:00
virAdmConnectIsAlive;
virAdmConnectGetURI;
virAdmConnectGetLibVersion;
virAdmConnectRegisterCloseCallback;
virAdmConnectUnregisterCloseCallback;
admin: Introduce adminDaemonConnectListServers API This API is merely a convenience API, i.e. when managing clients connected to daemon's servers, we should know (convenience) which server the specific client is connected to. This implies a client-side representation of a server along with a basic API to let the administrating client know what servers are actually available on the daemon. Signed-off-by: Erik Skultety <eskultet@redhat.com> Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2015-08-14 07:17:01 +00:00
virAdmConnectListServers;
virAdmServerGetName;
admin: Introduce virAdmServerGethreadPoolParameters New API to retrieve current server workerpool specs. Since it uses typed parameters, more specs to retrieve can be further included in the pool of supported ones. Signed-off-by: Erik Skultety <eskultet@redhat.com>
2015-11-23 11:41:32 +00:00
virAdmServerGetThreadPoolParameters;
admin: Introduce adminDaemonConnectListServers API This API is merely a convenience API, i.e. when managing clients connected to daemon's servers, we should know (convenience) which server the specific client is connected to. This implies a client-side representation of a server along with a basic API to let the administrating client know what servers are actually available on the daemon. Signed-off-by: Erik Skultety <eskultet@redhat.com> Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2015-08-14 07:17:01 +00:00
virAdmServerFree;
admin: Introduce virAdmServerLookupClient Just like with server-related APIs, before any of client-based APIs can be called, a reference to a client-side client object needs to be obtained. For this purpose, a lookup method should exist. Apart from the client retrieval logic, a new error code for non-existent client had to be added as well. Signed-off-by: Erik Skultety <eskultet@redhat.com>
2016-04-22 07:47:09 +00:00
virAdmServerLookupClient;
admin: Add virAdmConnectLookupServer It does not have a suffix ByName because there are no other means of looking up the server and since the name is known, this should be the preferred one. Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2016-03-01 16:33:37 +00:00
virAdmConnectLookupServer;
admin: Introduce virAdmServerSetThreadPoolParameters Since threadpool increments the current number of threads according to current load, i.e. how many jobs are waiting in the queue. The count however, is constrained by max and min limits of workers. The logic of this new API works like this: 1) setting the minimum a) When the limit is increased, depending on the current number of threads, new threads are possibly spawned if the current number of threads is less than the new minimum limit b) Decreasing the minimum limit has no possible effect on the current number of threads 2) setting the maximum a) Icreasing the maximum limit has no immediate effect on the current number of threads, it only allows the threadpool to spawn more threads when new jobs, that would otherwise end up queued, arrive. b) Decreasing the maximum limit may affect the current number of threads, if the current number of threads is less than the new maximum limit. Since there may be some ongoing time-consuming jobs that would effectively block this API from killing any threads. Therefore, this API is asynchronous with best-effort execution, i.e. the necessary number of workers will be terminated once they finish their previous job, unless other workers had already terminated, decreasing the limit to the requested value. 3) setting priority workers - both increase and decrease in count of these workers have an immediate impact on the current number of workers, new ones will be spawned or some of them get terminated respectively. Signed-off-by: Erik Skultety <eskultet@redhat.com>
2016-02-22 13:24:04 +00:00
virAdmServerSetThreadPoolParameters;
admin: Introduce listing clients Finally add public method to retrieve the list of currently connected clients to a given server. Signed-off-by: Erik Skultety <eskultet@redhat.com>
2016-04-14 22:20:11 +00:00
virAdmServerListClients;
admin: Introduce virAdmClientGetInfo API Expose a public API to retrieve some identity and connection information about a client connected to the specified server on daemon. The identity info retrieved is mostly connection transport dependent, i.e. there won't be any socket address returned for a local (UNIX socket) connection, while on the other hand, when connected through TLS or unencrypted TCP, obviously no UNIX process identification will be present in the returned data. All supported values that can be returned in typed params are exposed and documented in include/libvirt/libvirt-admin.h Signed-off-by: Erik Skultety <eskultet@redhat.com>
2016-04-22 11:05:42 +00:00
virAdmClientGetInfo;
admin: Introduce virAdmClientClose API Once we're able to list and identify all clients connected to a specific server, we can then support force-closing a connection. This patch introduces a simple API calling virNetServerClientClose on a specific client, which can be later extended easily, e.g. by sending an event once the client is disconnected successfully. Signed-off-by: Erik Skultety <eskultet@redhat.com>
2016-04-28 08:26:25 +00:00
virAdmClientClose;
admin: Introduce virAdmServerGetClientLimits Enable retrieval of the number of maximum clients connected to all sockets combined, as well as the number of maximum clients waiting for authentication, in order to be successfully connected. These are the attributes configurable through libvirtd.conf, however, it could be handy to not only know values for these limits, but also the values for the current number of clients connected and number of clients currently waiting for authentication which are changing dynamically. This API does both, retrieves the limits as well as the current dynamic values. Signed-off-by: Erik Skultety <eskultet@redhat.com>
2016-04-04 08:28:22 +00:00
virAdmServerGetClientLimits;
admin: Introduce virAdmServerSetClientLimits Opposite operation to virAdmServerGetClientLimits. Understandably though, setting values for current number of clients connected or still waiting for authentication does not make sense, since changes to these values are event dependent, i.e. a client connects - counter is increased. Thus only the limits to maximum clients connected and waiting for authentication can be set. Should a request for other controls to be set arrive (provided such a setting will be first introduced to the config), the set of configuration controls can be later expanded (thanks to typed params). This patch also introduces a constraint that the maximum number of clients waiting for authentication has to be less than the overall maximum number of clients connected and any attempt to violate this constraint will be denied. Signed-off-by: Erik Skultety <eskultet@redhat.com>
2016-04-04 12:24:52 +00:00
virAdmServerSetClientLimits;
Add libvirt-admin library Initial scratch of the admin library. It has its own virAdmConnectPtr that inherits from virAbstractConnectPtr and thus trivially supports error reporting. There's pkg-config file added and spec-file adjusted as well. Since the library should be "minimalistic" and not depend on any other library, the list of files is especially crafted for it. Most of them could've been put to it's own sub-libraries that would be LIBADD'd to libvirt_util, libvirt_net_rpc and libvirt_setuid_rpc_client to minimize the number of object files being built, but that's a refactoring that isn't the orginal aim of this commit. Signed-off-by: Martin Kletzander <mkletzan@redhat.com>
2015-04-15 14:16:24 +00:00
};
Reference in New Issue Copy Permalink