OpenLMI Firewall Model

Russell Doty rdoty at redhat.com
Fri Jan 31 14:54:23 UTC 2014


On Fri, 2014-01-31 at 13:21 +0100, Tomáš Smetana wrote:
> On Thu, 30 Jan 2014 15:41:47 +0100
> Jan Safranek <jsafrane at redhat.com> wrote:
> 
> > On 01/30/2014 03:26 PM, Radek Novacek wrote:
> 
> <...>
> 
> > > 1) Model FirewallD API closely
> > > 
> > > Using same model as underlying service has one big advantage - it doesn't 
> > > disrupt local configuration - one can use both remote and local API
> > > (command line, GUI) simultaneously, and one big disadvantage - model
> > > won't be compatible with other firewall implementations.
> 
> <...>
> 
> > > Personally, I would go with 1). There is no model that would bring 
> > > compatibility with other systems, so IMHO it would be best to create
> > > model that will be simple and understandable and it's usage won't disrupt
> > > other usage (cmdline, gui, ...).
> > 
> > Yes, 1) is my favorite too. IMHO there is no CIM firewall management
> > implementation we know about and we want to be compatible with. So let's
> > model it around _our_ firewall mgmt tools, which is currently firewalld.
> 
> Firewalld is (still) very Fedora-specific tool, whereas a firewall management
> is quite universally demanded feature.  Even though it's probably a bit
> premature consideration: we may make it harder for OpenLMI to become part of
> other distributions.
Anything preventing other distros from adopting firewalld? We've already
got dependencies on underlying tools, such as Network Manager and
Blivet, which are at least somewhat distro dependent.

I recognize that firewall is different in that this is the first time we
have to write our own model, rather than use a CIM model. Can we make
the firewall model "similar" to the rest of the models? Hopefully not as
complex as the DMTF models, but follow the general conventions, look and
feel, and behavior as the rest of the system?

This might make the firewall model a bit more complex than it would
otherwise be, but having it cleanly integrate with the rest of the
system (from a design perspective) would be good.

> 
> But since the firewall provider is going to be difficult enough anyway I
> don't have that strong opinion on reflecting the firewalld API in the
> model.
> 
> Regards,




More information about the openlmi-devel mailing list