Re: [libvirt] [RFCv2 PoCv1 PATCH 00/15] Just Admin API
On Fri, Apr 17, 2015 at 09:31:58AM -0400, Lee Schermerhorn wrote: On Fri, 2015-04-17 at 11:30 +0100, Daniel P. Berrange wrote: On Thu, Apr 16, 2015 at 04:46:10PM +0200, Martin Kletzander wrote: > *** BLURB *** > > ... > > Just kidding :) > > Sooo... After very very VERY long time, here's a draft of an admin > interface that is supposed to open up new possibilities to be done on > a live daemon. The aim here is to create some first inches of that > API in order to open up the possibility of new API function creation > to more people. > > I already spent so much time explaining so much of that that I don't > know what else to point at in here. Maybe the fact that last three > patches are just an example on how this might work. Of course there > won't be any functions like listClientIDs with the need of getting > each client info by another API. There's going to be > e.g. virAdmClientInfo and virAdmGetClients() will return the list of > them, etc. Long story short, let's not repeat past mistakes ;) > > With all that said, feel free to hate, love, comment or just try out > compiling this series and let me know how many things I've missed and > screwed up (hopefully zero). Broadly speaking I think this all looks like pretty good approach to me. We should probably think about exactly which API we want to target for inclusion in the first release. Perhaps the ability to change the logging filters & outputs would be the most useful one, as its something people often want to have in the production deployments where restarting libvirtd is not an option. Logging settings is definitely in the top of the list. My idea is that then we'll design some APIs for the introspection of the virNerServer (i.e. what is virNetSubServer in this series) like services, clients, rpm programs, whatever comes to mind. It would be nice if libvirt-1.3 (2.0 :) ) would have at least logging settings and info about connected clients. I'd say that's enough for the first tryout release. One question came up when we discussed Admin API with Michal. Can we say something in the sense of "this is not stable yet and the API can change"? It would help us speed up some prototyping, but I don't think this is possible simply because we guarantee full backward compatibility. How about reloading the server TLS certificates? virNetTLSContextNew() contains the comment: /* Generate Diffie Hellman parameters - for use with DHE * kx algorithms. These should be discarded and regenerated * once a day, once a week or once a month. Depending on the * security requirements. */ If I understand correctly, currently one must restart libvirtd to pickup new certificates? I wondered whether Martin's patch 4/15 -- multiple NetSubServers -- would allow introduction of a new cert on a new SubServer w/o restarting libvirtd? E.g., to allow long running migration, blockcopy or other jobs to complete on existing connections before destroying them. I haven't checked the internals of this, but it sounds like a good idea. However, the introspection mentioned beforehand must be completed first, otherwise we cannot get to the TLS service. Therefore I'd see this arriving a bit later than in the first trial series. However, others should be encouraged to implement APIs for this ;) If that would be possible, I think would would also be useful for early inclusion for people considering ephemeral certificates. Regards, Lee Regards, Daniel signature.asc Description: PGP signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFCv2 PoCv1 PATCH 00/15] Just Admin API
On Fri, 2015-04-17 at 11:30 +0100, Daniel P. Berrange wrote: > On Thu, Apr 16, 2015 at 04:46:10PM +0200, Martin Kletzander wrote: > > *** BLURB *** > > > > ... > > > > Just kidding :) > > > > Sooo... After very very VERY long time, here's a draft of an admin > > interface that is supposed to open up new possibilities to be done on > > a live daemon. The aim here is to create some first inches of that > > API in order to open up the possibility of new API function creation > > to more people. > > > > I already spent so much time explaining so much of that that I don't > > know what else to point at in here. Maybe the fact that last three > > patches are just an example on how this might work. Of course there > > won't be any functions like listClientIDs with the need of getting > > each client info by another API. There's going to be > > e.g. virAdmClientInfo and virAdmGetClients() will return the list of > > them, etc. Long story short, let's not repeat past mistakes ;) > > > > With all that said, feel free to hate, love, comment or just try out > > compiling this series and let me know how many things I've missed and > > screwed up (hopefully zero). > > Broadly speaking I think this all looks like pretty good approach > to me. We should probably think about exactly which API we want > to target for inclusion in the first release. > > Perhaps the ability to change the logging filters & outputs would > be the most useful one, as its something people often want to have > in the production deployments where restarting libvirtd is not an > option. How about reloading the server TLS certificates? virNetTLSContextNew() contains the comment: /* Generate Diffie Hellman parameters - for use with DHE * kx algorithms. These should be discarded and regenerated * once a day, once a week or once a month. Depending on the * security requirements. */ If I understand correctly, currently one must restart libvirtd to pickup new certificates? I wondered whether Martin's patch 4/15 -- multiple NetSubServers -- would allow introduction of a new cert on a new SubServer w/o restarting libvirtd? E.g., to allow long running migration, blockcopy or other jobs to complete on existing connections before destroying them. If that would be possible, I think would would also be useful for early inclusion for people considering ephemeral certificates. Regards, Lee > > Regards, > Daniel -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFCv2 PoCv1 PATCH 00/15] Just Admin API
On Fri, Apr 17, 2015 at 11:30:54AM +0100, Daniel P. Berrange wrote: On Thu, Apr 16, 2015 at 04:46:10PM +0200, Martin Kletzander wrote: *** BLURB *** ... Just kidding :) Sooo... After very very VERY long time, here's a draft of an admin interface that is supposed to open up new possibilities to be done on a live daemon. The aim here is to create some first inches of that API in order to open up the possibility of new API function creation to more people. I already spent so much time explaining so much of that that I don't know what else to point at in here. Maybe the fact that last three patches are just an example on how this might work. Of course there won't be any functions like listClientIDs with the need of getting each client info by another API. There's going to be e.g. virAdmClientInfo and virAdmGetClients() will return the list of them, etc. Long story short, let's not repeat past mistakes ;) With all that said, feel free to hate, love, comment or just try out compiling this series and let me know how many things I've missed and screwed up (hopefully zero). Broadly speaking I think this all looks like pretty good approach to me. We should probably think about exactly which API we want to target for inclusion in the first release. Perhaps the ability to change the logging filters & outputs would be the most useful one, as its something people often want to have in the production deployments where restarting libvirtd is not an option. Logging settings should be one of the first ones, together with client connection information. We can continue with working with those connections (disconnecting, etc.), similarly to services (e.g. disabling TLS socket listening) adding events for all that, etc. My opinion is that logging stuff and connection listing should be in the first batch and we'll go on from that. Thanks for your input. signature.asc Description: PGP signature -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
Re: [libvirt] [RFCv2 PoCv1 PATCH 00/15] Just Admin API
On Thu, Apr 16, 2015 at 04:46:10PM +0200, Martin Kletzander wrote: > *** BLURB *** > > ... > > Just kidding :) > > Sooo... After very very VERY long time, here's a draft of an admin > interface that is supposed to open up new possibilities to be done on > a live daemon. The aim here is to create some first inches of that > API in order to open up the possibility of new API function creation > to more people. > > I already spent so much time explaining so much of that that I don't > know what else to point at in here. Maybe the fact that last three > patches are just an example on how this might work. Of course there > won't be any functions like listClientIDs with the need of getting > each client info by another API. There's going to be > e.g. virAdmClientInfo and virAdmGetClients() will return the list of > them, etc. Long story short, let's not repeat past mistakes ;) > > With all that said, feel free to hate, love, comment or just try out > compiling this series and let me know how many things I've missed and > screwed up (hopefully zero). Broadly speaking I think this all looks like pretty good approach to me. We should probably think about exactly which API we want to target for inclusion in the first release. Perhaps the ability to change the logging filters & outputs would be the most useful one, as its something people often want to have in the production deployments where restarting libvirtd is not an option. Regards, Daniel -- |: http://berrange.com -o-http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :| -- libvir-list mailing list libvir-list@redhat.com https://www.redhat.com/mailman/listinfo/libvir-list
[libvirt] [RFCv2 PoCv1 PATCH 00/15] Just Admin API
*** BLURB *** ... Just kidding :) Sooo... After very very VERY long time, here's a draft of an admin interface that is supposed to open up new possibilities to be done on a live daemon. The aim here is to create some first inches of that API in order to open up the possibility of new API function creation to more people. I already spent so much time explaining so much of that that I don't know what else to point at in here. Maybe the fact that last three patches are just an example on how this might work. Of course there won't be any functions like listClientIDs with the need of getting each client info by another API. There's going to be e.g. virAdmClientInfo and virAdmGetClients() will return the list of them, etc. Long story short, let's not repeat past mistakes ;) With all that said, feel free to hate, love, comment or just try out compiling this series and let me know how many things I've missed and screwed up (hopefully zero). Martin Kletzander (15): util: add virJSONValueCopy util: Add virabstracts file for keeping abstract classes datatypes: Use abstract connect class in virConnect Break virNetServer into virNetSubServers Teach gendispatch how to handle admin dispatching files Add admin protocol Build client headers for admin protocol Add admin error domain Add libvirt-admin library Add XML files with admin API specification Add configuration options for permissions on daemon's admin socket Add support for admin API in libvirt daemon rpc: Add virNetSubServerGetNClients admin: Add virAdmHello function Example virt-admin .gitignore | 5 + Makefile.am| 4 +- cfg.mk | 11 +- configure.ac | 19 +- daemon/Makefile.am | 33 +- daemon/admin_server.c | 119 + daemon/admin_server.h | 36 ++ daemon/libvirtd-config.c | 5 +- daemon/libvirtd-config.h | 1 + daemon/libvirtd.aug| 1 + daemon/libvirtd.c | 138 -- daemon/libvirtd.conf | 8 + daemon/libvirtd.h | 14 +- daemon/remote.c| 194 - daemon/test_libvirtd.aug.in| 1 + docs/Makefile.am | 23 +- docs/apibuild.py | 10 +- include/libvirt/Makefile.am| 6 +- include/libvirt/libvirt-admin.h| 63 +++ include/libvirt/virterror.h| 3 +- libvirt-admin.pc.in| 13 + libvirt.spec.in| 10 + po/POTFILES.in | 3 + src/Makefile.am| 134 +- src/admin/admin_protocol.x | 73 src/admin_protocol-structs | 17 + src/datatypes.c| 39 +- src/datatypes.h| 45 +- src/internal.h | 1 + src/libvirt-admin.c| 363 src/libvirt-host.c | 3 +- src/libvirt_admin.syms | 19 + src/libvirt_private.syms | 6 + src/libvirt_remote.syms| 17 +- src/locking/lock_daemon.c | 40 +- src/locking/lock_daemon_dispatch.c | 18 +- src/lxc/lxc_controller.c | 18 +- src/rpc/gendispatch.pl | 141 +++--- src/rpc/virnetserver.c | 859 + src/rpc/virnetserver.h | 61 +-- src/rpc/virnetserverprogram.c | 12 +- src/rpc/virnetserverprogram.h | 9 +- src/rpc/virnetsubserver.c | 672 + src/rpc/virnetsubserver.h | 78 src/util/virabstracts.c| 100 + src/util/virabstracts.h| 57 +++ src/util/virerror.c| 95 ++-- src/util/virerror.h| 4 +- src/util/virjson.c | 65 ++- src/util/virjson.h | 4 +- tests/confdata/libvirtd.conf | 6 + tests/confdata/libvirtd.out| 5 + tests/jsontest.c | 111 + tools/virt-admin/Makefile.am | 70 +++ tools/virt-admin/virt-admin.c | 68 +++ tools/virt-admin/virt-admin.pod| 43 ++ 56 files changed, 3092 insertions(+), 881 deletions(-) create mode 100644 daemon/admin_server.c create mode 100644 daemon/admin_server.h create mode 100644 include/libvirt/libvirt-admin.h create mode 100644 libvirt-admin.pc.in create mode 100644 src/admin/admin_protocol.x create mode 100644 src/admin_protocol-structs create mode 100644 src/libvirt-admin.c create mode 100644 src/libvirt_admin.syms create mode 100644 src/rpc/virnetsubserver.c create mode 100644 src/rpc/virnetsubserver.h create mode 100644 src/util/virabstracts.c create mode 100644 src/util/virabstracts.h create mode 100644 tools/virt-admin/Makefile.am create mode 100644 tools/virt-admin/virt-admin.c create mode 100644 tools/virt-admin/virt-admin.pod -- 2.3.5 -- libvir-list mailing list l
