Open Stack

On Fri, Aug 02, 2013 at 12:50:08PM +0100, Chris Jones wrote:
> Hi
> 
> On 2 August 2013 11:15, Daniel P. Berrange <berrange at redhat.com> wrote:
> 
> > better is really missing the bigger picture. In Linux, there has been
> > a move away from use of sudo or similar approaches, towards the idea
> > of having privileged separated services. So if you wanted todo stuff
> >
> 
> I think it would be fair to say that this move has happened significantly
> more in the desktop world than the server world?

Alot of the work has been done by people working to satisfy problems
on the desktop space, eg so you don't have to run admin tools as
root from your desktop. The work they done is useful to the development
to server apps too though. In the virtualization world, you already
have this separation present in any mgmt application (like Nova) which
talks to libvirt for the various privileged operations that are needed
for managing VMs. Nova isn't using as much as it could do though. Nova
isn't using any of libvirt's storage or network related APIs currently,
which could obsolete some of its uses of rootwrap.

> > related to storage, you'd have some small daemon running privilegd,
> > which exposed APIs over DBus, which the non-privileged thing would
> >
> 
> There are several things that worry me about this suggestion:
> 
>  * DBus isn't super pleasing to work with as a developer or a sysadmin

No worse than OpenStack's own RPC system

>  * AIUI it doesn't offer very many guarantees about message delivery or
> high availability

As a host-local service only, I'm not sure high availability is really
a relevant issue.

> > Of course this is alot more work than just hacking up some scripts
> > using sudo or rootwrap. That's the price you pay for properly
> > engineering formal APIs todo jobs instead of punting to random
> > shell scripts.
> >
> 
> Given the sorts of things that OpenStack components need to run with
> privileges, I strongly suspect that even if you wedge DBus in the middle of
> things, you'll still be "punting to random shell scripts" on the backend,
> unless the tools on Linux servers are about to grow a heck of a lot of
> APIs. At that point I'm not really sure you've gained anything other than
> making the whole process more complicated and significantly harder to debug.

There's certainly alot of stuff in Linux mgmt which is lacking any kind
of reasonable API. We have felt that pain in providing APIs in libvirt,
but I still think it is better to have your root/non-root barrier defined
in terms of APIs. It is much simpler to validate well defined parameters
to API calls, than to parse & validate shell command lines. Shell commands
have a nasty habit of changing over time, or being inconsistent across
distros, or have ill defined error handling / reporting behaviour.

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 :|