Re: [libvirt] [PATCH 08/20] Secret manipulation step 8: Add virsh commands
On Thu, Aug 20, 2009 at 08:18:06PM +0200, Miloslav Trma?? wrote:
Changes since the third submission:
- Add "flags" parameter to virSecretDefineXML(), virSecretGetXMLDesc(),
virSecretGetValue(), virSecretSetValue(), and all derived interfaces.
- Add documentation to virsh.1
---
docs/virsh.pod | 43 ++++++++
src/virsh.c | 323 ++++++++++++++++++++++++++++++++++++++++++++++++++++++++
virsh.1 | 34 ++++++-
3 files changed, 399 insertions(+), 1 deletions(-)
Functionally this patch looks fine, but having tried it out I'm wondering
about the 'secret-list' command output...
+/*
+ * "secret-list" command
+ */
+static const vshCmdInfo info_secret_list[] = {
+ {"help", gettext_noop("list secrets")},
+ {"desc", gettext_noop("Returns a list of secrets")},
+ {NULL, NULL}
+};
+
+static int
+cmdSecretList(vshControl *ctl, const vshCmd *cmd ATTRIBUTE_UNUSED)
+{
+ int maxuuids = 0, i;
+ char **uuids = NULL;
+ if (!vshConnectionUsability(ctl, ctl->conn, TRUE))
+ return FALSE;
+ maxuuids = virConnectNumOfSecrets(ctl->conn);
+ if (maxuuids < 0) {
+ vshError(ctl, FALSE, "%s", _("Failed to list secrets"));
+ return FALSE;
+ }
+ uuids = vshMalloc(ctl, sizeof(*uuids) * maxuuids);
+ maxuuids = virConnectListSecrets(ctl->conn, uuids, maxuuids);
+ if (maxuuids < 0) {
+ vshError(ctl, FALSE, "%s", _("Failed to list secrets"));
+ free(uuids);
+ return FALSE;
+ }
+
+ qsort(uuids, maxuuids, sizeof(char *), namesorter);
+
+ vshPrintExtra(ctl, "%s\n", _("UUID"));
+ vshPrintExtra(ctl, "-----------------------------------------\n");
+
+ for (i = 0; i < maxuuids; i++) {
+ vshPrint(ctl, "%-36s\n", uuids[i]);
+ free(uuids[i]);
+ }
+ free(uuids);
+ return TRUE;
+}
eg, i defined 6 secrets, and now the listing shows.
# ./src/virsh secret-list
UUID
-----------------------------------------
1b4fde6f-0929-3bb5-c2aa-0f62ef79e52a
3174ee25-1be0-ba8f-1c99-d0b929226d7e
71d068f3-354e-1a51-241c-5bf6d5f68f8d
7c2c8591-eb89-d373-3bcf-0957b84210fc
a67c94ac-7db6-b661-b04c-058c1eac2512
de96f05d-ca6a-2fa9-8c65-4e13f2a399d7
which isn't very user friendly. I think we need to try and get info
about the usage of the secret included in the output,
eg consider if we allowed use of the secrets API for managing per
guest secrets for the VNC server too, then I could imagine a
display like
# ./src/virsh secret-list
UUID Usage Object
----------------------------------------------------
1b4fde6f-0929-3bb5-c2aa-0f62ef79e52a volume /var/lib/libvirt/images/demo.img
3174ee25-1be0-ba8f-1c99-d0b929226d7e volume /var/lib/libvirt/images/mail.img
71d068f3-354e-1a51-241c-5bf6d5f68f8d volume /var/lib/libvirt/images/db.img
7c2c8591-eb89-d373-3bcf-0957b84210fc vnc mailguest
a67c94ac-7db6-b661-b04c-058c1eac2512 vnc dbguest
de96f05d-ca6a-2fa9-8c65-4e13f2a399d7 vnc demo
This might suggest that we have 1 or 2 more public APIs,
const char *virSecretGetUsage(virSecretPtr sec);
const char *virSecretGetObject(virSecretPtr sec);
and, probably that we include those 2 attributes in the virSecretPtr
struct defined in src/datatypes.h, so that calling those 2 APis does
not incur further RPC calls. This would also mean that we'd have to
extend
struct remote_nonnull_secret {
remote_nonnull_string uuid;
};
to include
struct remote_nonnull_secret {
remote_nonnull_string uuid;
remote_nonnull_string usage;
remote_nonnull_string object;
};
Daniel
--
|: Red Hat, Engineering, London -o- http://people.redhat.com/berrange/ :|
|: http://libvirt.org -o- http://virt-manager.org -o- http://ovirt.org :|
|: http://autobuild.org -o- http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505 -o- F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|