[ovirt-devel] Firewalld migration.
Yaniv Dary
ydary at redhat.com
Wed Mar 29 08:23:29 UTC 2017
Ok, so I guess I misread.
VDSM should have that responsibility and engine should not be evolved.
I like the suggestion from other in the thread on managing the admin custom
rules via Ansible and the inventory playbook we have already created.
Yaniv Dary
Technical Product Manager
Red Hat Israel Ltd.
34 Jerusalem Road
Building A, 4th floor
Ra'anana, Israel 4350109
Tel : +972 (9) 7692306
8272306
Email: ydary at redhat.com
IRC : ydary
On Wed, Mar 29, 2017 at 9:53 AM, Dan Kenigsberg <danken at redhat.com> wrote:
> On Mon, Mar 27, 2017 at 2:38 PM, Yaniv Dary <ydary at redhat.com> wrote:
> > Hi,
> > I like option number 3 the most from reading the comments.
> > We are not a configuration management system, so custom rules should not
> be
> > a main consideration.
> > VDSM should probably enable the firewalld rules it needs to work and
> engine
> > should not care about firewall at all.
> > A user wanting to add more rules then this should probably use the ones
> > planned in:
> > https://github.com/cockpit-project/system-api-roles
>
>
> I, too, like the idea of shedding off the attempt to configure custom
> iptables rules. Moving to firewalld makes it much easier to manage
> such customization out of oVirt. (Anybody who's ever edited iptables
> chains by hand would know what I mean)
>
> Please note that what you describe is Leon's alternative (2.). Where
> Vdsm, as oVirt host agent, has complete responsibility on configuring
> the services needed by oVirt. There is no Engine/Vdsm interaction in
> alternative (2.). Option (3.) requires Engine to provide a list of
> services to the host.
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.ovirt.org/pipermail/devel/attachments/20170329/a33c630d/attachment.html>
More information about the Devel
mailing list