Add UDP transport for rsyslog

[Gleb Semenov]

On 18.01.2023 15:23, Patrick Williams wrote:
> On Wed, Jan 18, 2023 at 02:36:15PM +0300, Gleb Semenov wrote:
>
>>   1. Modification of the
>>      xyz/openbmc_project/Network/Client.interface.yaml interface to add
>>      the protocol attribute.
> You may want either a separate interface or a separate path to identify
> TCP vs UDP (Network.Transport?).  There are enough users of Network.Client that
> you probably don't also want to modify all of them to have "TCP".  Maybe we
> could set TCP as the default on a new property, but I think most protocols only
> have only a single implied protocol, so you're now forcing error paths
> onto all of them if "Transport != TCP".
>
> Make sure this is done as an enumeration.

Seems You are right, The semantics of the "protocol" field may be differ 
for different services. For SNMP, for example, the "protocol" 
specification means a pair (transport, SNMP version), rather than just 
TCP or UDP. So distinct interface and path will be better.

>
>>   2. Handling for the  interface changes in the code of the dbusplus library.
> Not sure what you mean by this.  The phosphor-dbus-interfaces is where
> the YAML is and the result is generated.  I don't think there should be
> any changes to the sdbusplus repository for this proposal.

Yep. If we conclude to implement a distinct interface/path for the 
protocol specification for rsyslog, than to add a proper handler to 
phosphor-logging is enough.

>
>>   3. Corresponding changes to the phosphor-rsyslog-config service.
> (This is phosphor-logging)
>
>>   4. Proper changes to the REST/redfish API.
> Do you have a Redfish schema already to handle this?

It is "under construction".

>
>>   5. Modification of the web interface and command line tools.
> Which CLIs?  I'm not aware of any that are relevant here.
>
>> Also, current DBUS interface to the object implies two independent
>> messages to change network parameters, one to set the IP-address, and
>> the other to set the port number. They are not atomic and configuring
>> just one parameter yields in undesirable state transitions of the
>> service to configure. It is good to send all the parameters in one
>> "atomic" message. But, I'm understand that this may require to persist
>> current network parameters on both sides of transmission (or, at least,
>> to have all of them on sending side upfront).
>>
>> So, it needs to add  DBUS getters/setters for just protocol type, and
>> all parameters at once.
> The "getters/setters" are defined by the dbus specification.  We should
> not add new methods that set the properties.  See
> org.freedesktop.DBus.Properties.Set[1].
>
> If you need to be able to atomically construct a new configuration, you
> should look to the 'Create' pattern found in the rest of the
> phosphor-dbus-interface repository.
>
> ```
> $ find -name Create.interface.yaml
> ./yaml/com/ibm/Dump/Create.interface.yaml
> ./yaml/xyz/openbmc_project/Certs/CSR/Create.interface.yaml
> ./yaml/xyz/openbmc_project/Dump/Create.interface.yaml
> ./yaml/xyz/openbmc_project/HardwareIsolation/Create.interface.yaml
> ./yaml/xyz/openbmc_project/Logging/Syslog/Destination/Mail/Create.interface.yaml
> ./yaml/xyz/openbmc_project/Logging/Create.interface.yaml
> ./yaml/xyz/openbmc_project/Network/Client/Create.interface.yaml
> ./yaml/xyz/openbmc_project/User/Ldap/Create.interface.yaml
> ```
>
> You'll note that Network.Client.Create already exists, which is probably
> what you're looking for.

May be, thanks.

>
>> Regards!
>>
>> Gleb
> 1. https://dbus.freedesktop.org/doc/dbus-specification.html#standard-interfaces-properties
>