Re: RFC for enablement of slpd on openbmc

[Patrick Williams <patrick@stwcx.xyz>]

[-- Attachment #1: Type: text/plain, Size: 3434 bytes --]

On Thu, Oct 20, 2016 at 07:25:32PM +0530, Ratan Gupta wrote:
> > What is the anticipated size footprint of using openSLP?  The RFC
> > doesn't seem that significant, so if we do not need the directory aspect
> > might it be more beneficial to write a small daemon ourself to give SLP
> > responses rather than trying to mold openSLP to fit our needs?
>     runtime foot print TOP Command shows
>     214     1 daemon   S *3620*   3%   0% slpd -l /tmp/slpd.log  >>>3.5K
>     file size which will take in flash
>     slpd:- 100.4K
>     libslp:-69.7K

Not horrible then.

> > I'm certainly not advocating avoiding using existing open source.  But,
> > with there not being an update to openSLP since 2013 and all the aspects
> > we are going to have to work around below, I'm wondering on the benefit.
>    I think we are not doing any workaround here,It is slp (as per the 
> RFC)which expects
>    IP in their reg url as the slp needs ip in the reg url,we are 
> catering that need via de

What I mean by a "workaround" is that for localhost reasons it would be
much more convenient to have the daemon do this work of automatically
updating the URL when the IP changes.  The non-local IP case isn't
especially interesting for the BMC. 

> > Do we need to ensure the application is running (or available to run via
> > socket activation) before we do the registration?  If the application is
> > being restarted should we remove the registration and add it back after
> > it comes back?
> I believe that is not needed as the application(SA) would be dependent 
> on the conf
>       and out policy suggest that network services should restart always 
> so it would be unnecessary
>       to do reg and unreg

We currently do it this way for Avahi so I am fine doing the same for
SLP.  Someone ambitious could enhance this aspect in the future.

> > We also can then keep off of something in systemd / networkd to run
> > 'slp-register ip-change' whenever the IP changes.  This could either
> > restart *-slp-register.service or it could extract all of the SLP
> > registrations and update them with new IP addresses.  Putting all of the
> > *-slp-register.service into a 'target' might make restarting them very
> > simple.
> >
> > With this approach we do not need a long running application.
> I agree but do we really need to dereg and reg in the case when the 
> service is going down as.
>      Our service policy is restart always whenever the network service 
> goes down. so service would be down for a moment
>      Long running application i was asking for the IP change event,I am 
> not aware if systemd-networkd send some event
>      whenever the ip change occurs.

Correct.  I don't feel it is needed now.

> >> 2) Application(new DBUS app) will register the configured services to
> >> the slpd on startup.
> > I am not understanding what the 'dbus app' aspect of this would be.
> > What would be the dbus interfaces?
>    I thought of if some other app(netman.py) wants to do the reg and 
> unreg. so thought of exposing the
>        Register Service
>        unregister Service
>        Raising the DBUS signal in case of IP change.

I don't think we need to dynamically do these, other than the IP change.
We can handle that through a service restart rather than a long running
dbus process for an infrequent operation?

-- 
Patrick Williams

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 819 bytes --]