Add UDP transport for rsyslog

Patrick Williams patrick at stwcx.xyz
Wed Jan 18 23:23:55 AEDT 2023


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.

>  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.

>  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?

>  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.

> Regards!
> 
> Gleb

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

-- 
Patrick Williams
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: not available
URL: <http://lists.ozlabs.org/pipermail/openbmc/attachments/20230118/9e48fa6c/attachment-0001.sig>


More information about the openbmc mailing list