Cockpit dependency on PCP without Avahi

[Stef Walter]

We're working on using PCP to load server resource metrics in Cockpit.

Is it possible to build pcp-libs without libavahi? It seems an odd
feature for such a low level library to have ... as opposed to higher
level PCP tools ... where dynamic discovery is interesting.

cockpit-bridge is the piece of Cockpit proxies requests from the
Cockpit Web a component we want to have as few barriers as possible.
It's part of Cockpit that we want to be able to be installed on as
many servers as possible. So we have to take a hard look at every
single cockpit-bridge dependency, even the ones we currently have...

Can we have /usr/lib64/libpcp.so without an Avahi dependency? Or
should we treat PCP as an optional dependency of Cockpit and structure
our code so that PCP is more of an add-on, used when available?

What do you think?

Stef

[Frank Ch. Eigler]

Hi, Stef -

>  We're working on using PCP to load server resource metrics in
> Cockpit. 
Nice.

>  Is it possible to build pcp-libs without libavahi? It seems an odd
>  feature for such a low level library to have ... as opposed to higher
>  level PCP tools ... where dynamic discovery is interesting. 
The discovery functionality is within libpcp because that is a
convenient place for present and future pcp clients to share code.


>  [...]  Can we have /usr/lib64/libpcp.so without an Avahi dependency?
>  Or should we treat PCP as an optional dependency of Cockpit and
>  structure our code so that PCP is more of an add-on, used when
>  available? 
Can we dig a little deeper?  avahi-libs by itself is tiny (<200K); is
its "Require: avahi" part the only problematic aspect?  In Fedora20+
that's already gone (BZ913168); maybe that simply needs to be
backported to RHEL*.


- FChE

[Stef Walter]

On 04.12.2014 16:22, Frank Ch. Eigler wrote:
> > [...]  Can we have /usr/lib64/libpcp.so without an Avahi
> dependency?
> > Or should we treat PCP as an optional dependency of Cockpit and
> > structure our code so that PCP is more of an add-on, used when
> > available?
>  
>  Can we dig a little deeper?  avahi-libs by itself is tiny (<200K); is
>  its "Require: avahi" part the only problematic aspect?  In Fedora20+
>  that's already gone (BZ913168); maybe that simply needs to be
>  backported to RHEL*. 
For starters, you can see the reaction of a system administrator to
Avahi in that bug. I make no comment on whether such a reaction is
justified or not.

https://bugzilla.redhat.com/show_bug.cgi?id=913168

So there are two reasons here:

 * We don't want a hard dep on "Avahi" to be a mental barrier to having
   Cockpit on someone's server ... even if might have an optional
   dependency on avahi in the standard Cockpit Fedora install.

 * Platforms like Atomic try very very very hard to get their bundled
   software stack down to a minimum. I would like the cockpit-bridge
   part of Cockpit to be usable anywhere. Even very lean environments.
   We're working hard to get there.

Having cockpit-bridge pull in an unused hard dependency on avahi-libs is
counter to both of the above goals. It seems that such a dependency
would need to be optional, which would make PCP be optional too.

The pcp-libs dependencies on cyrus-sasl and nss are less problematic,
despite the fact that they'd be unused by Cockpit, since those are
software more typically installed on a server.

Stef

[Markus Larsson]

I can attest that the reaction is justified. I would not like to have any
Avahi in my datacenter. It can cause a myriad of issues in enterprise
scaled enviroments (read thousands of servers).

Br
Markus
On 4 Dec 2014 17:35, "Stef Walter" <stefw(a)redhat.com&gt; wrote:

>  On 04.12.2014 16:22, Frank Ch. Eigler wrote:
>  >> [...]  Can we have /usr/lib64/libpcp.so without an Avahi dependency?
>  >> Or should we treat PCP as an optional dependency of Cockpit and
>  >> structure our code so that PCP is more of an add-on, used when
>  >> available?
>  >
>  > Can we dig a little deeper?  avahi-libs by itself is tiny (<200K); is
>  > its "Require: avahi" part the only problematic aspect?  In Fedora20+
>  > that's already gone (BZ913168); maybe that simply needs to be
>  > backported to RHEL*.
>
>  For starters, you can see the reaction of a system administrator to
>  Avahi in that bug. I make no comment on whether such a reaction is
>  justified or not.
>
>  https://bugzilla.redhat.com/show_bug.cgi?id=913168
>
>  So there are two reasons here:
>
>   * We don't want a hard dep on "Avahi" to be a mental barrier to having
>     Cockpit on someone's server ... even if might have an optional
>     dependency on avahi in the standard Cockpit Fedora install.
>
>   * Platforms like Atomic try very very very hard to get their bundled
>     software stack down to a minimum. I would like the cockpit-bridge
>     part of Cockpit to be usable anywhere. Even very lean environments.
>     We're working hard to get there.
>
>  Having cockpit-bridge pull in an unused hard dependency on avahi-libs is
>  counter to both of the above goals. It seems that such a dependency
>  would need to be optional, which would make PCP be optional too.
>
>  The pcp-libs dependencies on cyrus-sasl and nss are less problematic,
>  despite the fact that they'd be unused by Cockpit, since those are
>  software more typically installed on a server.
>
>  Stef
>
>
>  _______________________________________________
>  cockpit-devel mailing list
>  cockpit-devel(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/cockpit-devel
>
>

[Stef Walter]

On 04.12.2014 19:01, Markus Larsson wrote:
>  I can attest that the reaction is justified. I would not like to
> have
>  any Avahi in my datacenter. It can cause a myriad of issues in
>  enterprise scaled enviroments (read thousands of servers). 
True. However this is about avahi-libs. Without the daemon it is
impotent ... but seems to still cause concern among some admins.

Stef

[Markus Larsson]

Of course, the track record of the libs being available without a
dependency for the deamon has been so and so though. That's probably the
real concern and Avahi is sneaky in that way.

Br
M
On 4 Dec 2014 19:10, "Stef Walter" <stefw(a)redhat.com&gt; wrote:

>  On 04.12.2014 19:01, Markus Larsson wrote:
>  > I can attest that the reaction is justified. I would not like to have
>  > any Avahi in my datacenter. It can cause a myriad of issues in
>  > enterprise scaled enviroments (read thousands of servers).
>
>  True. However this is about avahi-libs. Without the daemon it is
>  impotent ... but seems to still cause concern among some admins.
>
>  Stef
>
>
>
>
>  _______________________________________________
>  cockpit-devel mailing list
>  cockpit-devel(a)lists.fedorahosted.org
>  https://lists.fedorahosted.org/mailman/listinfo/cockpit-devel
>
>

[Frank Ch. Eigler]

Hi -

>  Of course, the track record of the libs being available without a
>  dependency for the deamon has been so and so though. That's probably
>  the real concern and Avahi is sneaky in that way. 
Now that I'm aware of the issue, I plan to monitor it and keep the
avahi-libs dependency 200kB lean.

- FChE