Schedule for Monday's FESCo Meeting (2012-06-18)

[Seth Vidal]

On Mon, 18 Jun 2012, Richard Hughes wrote:

> On 18 June 2012 00:38, Reindl Harald <h.reindl at thelounge.net> wrote:
>> the point is that it was perfectly possible in 2005 to make a fedora
>> dist-upgrade at friday night while http, netatalk or samba was
>> fully up and running until saturday sometimes at evening where
>> you rebootet the machine and now EIGHT years later we discuss about
>> making updates at reboot/offline like windows?
>
> Well, if you're running a headless server with just http, netatalk and
> samba then you can of course update now live using yum, restarting
> services when convenient. I'm not going to change that. What I want to
> change is for the case of updating a fully functioning desktop with
> ~30 session processes per user talking to each other over session
> DBus, ~20 doing IPC with system DBus, and ~15 processes in the system
> context, ~3 of which do DBus IPC with each other. That's about as far
> removed from a simple server with three non-connected daemons that do
> one thing each as you can get.
>
>> something must have gone terrible wrong in the meantime
>
> If your goal is to just run three simple daemons, I agree.
>

As dbus is required for various things like networkmanager - does this 
mean that if a server happens to be using nm for network setup that in 
order to apply a security patch to dbus, for example, that the server will require 
a reboot?

Since more and more we're relying on dbus for server-y processes it feels 
like we'll be adding one more component that requires a reboot for updates 
to take effect. That eats up real time and causes real pain later on for 
admins maintaining systems.

Either we need to make dbus something we can sensibly restart or we need 
to rely on it less for server-y tasks (or both).

I understand you're not working on PK for servers but the packaging 
expectations will trickle down to our slower-changing server installations 
and this will cause real pain and irritation. The implications for servers 
are fairly serious.

  -sv