Link phosphor-hostlogger and bmcweb

[Artem Senichev]

On Sat, Jun 12, 2021 at 12:07 AM Nan Zhou <nanzhou at google.com> wrote:
>>
>> >
>> >> > Or did me missing something?
>> >> >
>> >> > Also, we already talked about it: there's a problem that if BMC loses the
>> >> > power before it sends out a signal to hostlogger, data in memory won't be
>> >> > persisted.
>> >> Yes, I agree that this is a problem. But there are ways to fix it without
>> >> breaking the current functionality of Hostlogger.
>> >> We can use rsyslog with external log server, or increase the buffer size
>> >> in obmc-console-server, or use systemd-cat with logrotate.
>> >> We can even add a new mode to Hostlogger that will not use the buffer, but
>> >> as I said earlier, there are not many common parts.
>> >
>> > I guess you are arguing we need a new daemon rather than modify Hostlogger, right? +Ed Tanous here to see what his opinion is.
>> If Nans use case is in fact totally different, and can't be handled in
>> the same application I think that's ok, but I'd like to see the new
>> application put in the hostlogger repo so it can share the routines
>> that are common (things like finding and opening the unix socket,
>> managing the reads, and the zlib integration) and to ensure that users
>> find it when searching for code that solves this problem, as on the
>> outset they're pretty similar, just with seemingly different rules.
>> If we don't put it there, it seems like we'd have to duplicate a lot
>> of code.
>
> Thanks a lot for the previous discussion. Following up on this, is it acceptable if we add a new application (it will be a new binary + a new systemd service config) in the hostlogger repo to support the stream application? We can add options to control whether to turn on this new stream application. In this way, existing applications stay unchanged. As Ed said, we could use codes that deal with unix sockets and reads. It should also make sense that console codes are put together in the same place.
>
> Please let us know what you think. Your confirmation will be very valuable and will unblock our development.

I still don't see a reason to have two different applications in one
repository, but let's try.
I believe that the common part with socket opening/reading (about 100
lines of code) is nothing compared to the complexity of supporting
such sophisticated configuration in meson and bb files.

--
Best regards,
Artem Senichev