[ovirt-devel] Firewalld migration.

Wed Mar 29 08:28:12 UTC 2017

On Tue, Mar 28, 2017 at 6:58 PM, Martin Sivak <msivak at redhat.com> wrote:
>> 2. There are better tools to do it than via engine-config -> database ->
>> host-deploy, which are also easier for both us to support as well as our
>> users to work with.
>
> I am all in favor of skipping engine-config and database.

This is a "detail", not a radical change. We can easily make
the engine read these from a conf file instead of the db.

Not sure we have clear guidelines re what should be in the db
vs what should be in config files. IIUC the only "tool" we
provide for editing config files is engine-setup, which is
quite restricting, considering it has other missions. Perhaps
we should have another tool for that, or teach engine-config
to do that as well. We hesitate from telling people to directly
edit/write config files (vs using engine-config), because, I
guess, we assume that's considered a bit too technical, and
because there is no protection/validation/syntax-checking/etc
if you only use an editor (vs engine-config, engine-setup or
any other tool).

>
>> 1. We can't configure (and/or possibly customize) everything (NTP?
>> multipath.conf configuration? even vdsm.conf!). We strive to improve and do
>> it well, but there are limits and challenges.
>
> Sure, but we still run the host deploy from the engine side and then
> activate the host immediately. Which means we need give the user a
> chance to execute customizations in the middle of the process.
> Currently it was firewall only and the way it was done was pretty
> awkward, but we can do better instead of removing the option
> completely.
>
> I actually like the radical option Didi mentioned -> using Ansible for
> the whole deploy flow. A simple host-deploy dir with playbooks (and
> builtin roles) is something most people would understand easily.

I didn't even really start to analyze what this will require, but I'd
like to mention that the host-deploy process has two sides - one is
the code of ovirt-host-deploy (+otopi) that's copied to the host and
runs there, and the other side is the engine. If we want to keep the
other side to be the engine, we'll have to somehow teach it to talk
to ansible, or to teach ansible to talk to it. If we want to replace
this with something else, we need to check what the engine currently
does, what info is needed for that, make sure all that info is (made)
available externally (API/DB/config files/whatever) and then start
writing stuff (ansible roles or plugins) to do that.

>
> And it would even remove all the infrastructure burden from us, oVirt
> would not be the host management solution, Ansible would take the role
> and we would just invoke it when deploying a new host much like we do
> with host deploy now (except Ansible manages its own ssh connection
> too).

I think saying the above is like saying that already now we do not have
to carry the burden of deploying hosts, because python+java do that for
us.

>From a shallow and short experience with ansible for ovirt-engine-metrics,
I think you/we should treat ansible as a language, not as a tool. As a
language, it has some nice features/builtins, a nice standard library and
a great user community (providing both support and examples etc.), but
it's just that - a language.

If you have a look at ovirt-engine-metrics, you current find there:
389 lines in yml files
466 lines in all files under templates (some .j2, some plain conf)

I expect the functionality of host-deploy to be at least 10 times
larger. So a reimplementation will require at least several thousand
lines of ansible yml. I do not think this will be much easier to
understand/debug than the current python+java code. At least the
otopi+host-deploy code - I know almost nothing of the java code
in the engine, can't even tell how much of it is purely host-deploy
(i.e. will be removed if we reimlement in ansible).

>
> Martin
>
> On Tue, Mar 28, 2017 at 5:29 PM, Yaniv Kaul <ykaul at redhat.com> wrote:
>>
>>
>> On Tue, Mar 28, 2017 at 4:00 PM, Martin Sivak <msivak at redhat.com> wrote:
>>>
>>> > But we do not want to support custom firewall rules, we are not a
>>> > firewall
>>> > manager.
>>> > IMO, oVirt should support the hardening of its services and co-exist
>>> > with
>>> > other rules.
>>> > Custom firewall settings imply one of these:
>>> > - We need to extend current firewall options.
>>> > - It needs to be implemented outside oVirt.
>>> >
>>> > But if the need to support back doors is proven to be a must, then
>>> > implement
>>> > them
>>> > outside the main core solution, these edge cases should not block the
>>> > main
>>> > business
>>> > logic.
>>>
>>> I seem to remember that the one feature that sets us apart from
>>> everybody else is that we know how to manage the bare metal. And the
>>> current standing decision I know about is that we want to keep that
>>> capability.
>>>
>>> Yaniv? Is that still so?
>>
>>
>> It is, but we also need to acknowledge that:
>> 1. We can't configure (and/or possibly customize) everything (NTP?
>> multipath.conf configuration? even vdsm.conf!). We strive to improve and do
>> it well, but there are limits and challenges.
>> 2. There are better tools to do it than via engine-config -> database ->
>> host-deploy, which are also easier for both us to support as well as our
>> users to work with.
>> Y.
>>
>>
>>>
>>> All other solutions (OpenStack, OpenShift, ..) require you to
>>> configure the bare metal first and then deploy virtualization. We
>>> simplify this for the sysadmin and that makes us special (for good and
>>> bad as Sven pointed out).
>>>
>>> So, if we do not want to support custom rules in the engine, then the
>>> whole host deploy script (not just firewall) needs to work very
>>> differently, because the end goal is to have properly deployed node
>>> for virtualization. And the "properly" word is defined both by us and
>>> the owner sysadmin.
>>>
>>> But deploy has to all or nothing operation, otherwise the engine will
>>> start using half configured host and you risk someone forgetting to
>>> run an extra script.
>>>
>>> Martin
>>>
>>> On Mon, Mar 27, 2017 at 7:47 PM, Edward Haas <ehaas at redhat.com> wrote:
>>> >
>>> >
>>> > On Mon, Mar 27, 2017 at 7:07 PM, Martin Sivak <msivak at redhat.com> wrote:
>>> >>
>>> >> > Clients should be made aware their custom rules are going to be
>>> >> > obsolete
>>> >> > and
>>> >> > that they should reapply them once they reinstall.
>>> >>
>>> >> Would you want to manually fix every reinstalled host? I would
>>> >> consider that very annoying. This has to be somewhat automatic if we
>>> >> want to support custom firewall rules. And although I agree the engine
>>> >> is not the right place for that, it is the only central place we have
>>> >> and from which we are starting the reinstall task.
>>> >
>>> >
>>> > But we do not want to support custom firewall rules, we are not a
>>> > firewall
>>> > manager.
>>> > IMO, oVirt should support the hardening of its services and co-exist
>>> > with
>>> > other rules.
>>> > Custom firewall settings imply one of these:
>>> > - We need to extend current firewall options.
>>> > - It needs to be implemented outside oVirt.
>>> >
>>> > But if the need to support back doors is proven to be a must, then
>>> > implement
>>> > them
>>> > outside the main core solution, these edge cases should not block the
>>> > main
>>> > business
>>> > logic.
>>> >
>>> >
>>> >>
>>> >>
>>> >> Martin
>>> >>
>>> >> On Mon, Mar 27, 2017 at 4:16 PM, Leon Goldberg <lgoldber at redhat.com>
>>> >> wrote:
>>> >> > You're right, but I don't think it matters; hosts will remain
>>> >> > unaffected
>>> >> > until they're reinstalled via an upgraded Engine.
>>> >> >
>>> >> > Clients should be made aware their custom rules are going to be
>>> >> > obsolete
>>> >> > and
>>> >> > that they should reapply them once they reinstall.
>>> >> >
>>> >> > On Mon, Mar 27, 2017 at 9:01 AM, Yedidyah Bar David <didi at redhat.com>
>>> >> > wrote:
>>> >> >>
>>> >> >> On Sun, Mar 26, 2017 at 6:01 PM, Leon Goldberg <lgoldber at redhat.com>
>>> >> >> wrote:
>>> >> >> > Effectively, upgrading will leave lingering (but nonetheless
>>> >> >> > operational)
>>> >> >> > iptables rules on the hosts. I'm not even sure there needs to be
>>> >> >> > special
>>> >> >> > upgrade treatment?
>>> >> >>
>>> >> >> Please describe the expected flow.
>>> >> >>
>>> >> >> Please note that at least when I tried, 'systemctl start firewalld'
>>> >> >> stops
>>> >> >> iptables.
>>> >> >>
>>> >> >> Thanks,
>>> >> >>
>>> >> >> >
>>> >> >> > On Sun, Mar 26, 2017 at 4:59 PM, Yedidyah Bar David
>>> >> >> > <didi at redhat.com>
>>> >> >> > wrote:
>>> >> >> >>
>>> >> >> >> On Sun, Mar 26, 2017 at 4:49 PM, Leon Goldberg
>>> >> >> >> <lgoldber at redhat.com>
>>> >> >> >> wrote:
>>> >> >> >> > 1) Do we actually need iptables for any reason that isn't a
>>> >> >> >> > legacy
>>> >> >> >> > consideration?
>>> >> >> >>
>>> >> >> >> No idea personally.
>>> >> >> >>
>>> >> >> >> Perhaps some users prefer that, and/or need that for integration
>>> >> >> >> with
>>> >> >> >> other
>>> >> >> >> systems/solutions/whatever.
>>> >> >> >>
>>> >> >> >> If we drop iptables, how do you suggest to treat upgrades?
>>> >> >> >>
>>> >> >> >> >
>>> >> >> >> > 2 & 3) I am in favor of treating custom services as a
>>> >> >> >> > requirement
>>> >> >> >> > and
>>> >> >> >> > plan
>>> >> >> >> > accordingly. Many (most, even) of the services are already
>>> >> >> >> > provided
>>> >> >> >> > by
>>> >> >> >> > either firewalld itself (e.g. vdsm, libvirt) or the 3rd party
>>> >> >> >> > packages
>>> >> >> >> > (e.g.
>>> >> >> >> > gluster). Some are missing (I've recently created a pull
>>> >> >> >> > request
>>> >> >> >> > for
>>> >> >> >> > ovirt-imageio to firewalld, for example) and I hope we'll be
>>> >> >> >> > able
>>> >> >> >> > to
>>> >> >> >> > get
>>> >> >> >> > all
>>> >> >> >> > the services to be statically provided (by either firewalld or
>>> >> >> >> > the
>>> >> >> >> > relevant
>>> >> >> >> > 3rd party packages).
>>> >> >> >> >
>>> >> >> >> > Ideally I think we'd like use statically provided services, and
>>> >> >> >> > provide
>>> >> >> >> > the
>>> >> >> >> > capability to provide additional services (I'm not a fan of the
>>> >> >> >> > current
>>> >> >> >> > methodology of converting strings into xmls). I don't think
>>> >> >> >> > we'd
>>> >> >> >> > want
>>> >> >> >> > to
>>> >> >> >> > limit usage to just statically provided services. (2)
>>> >> >> >> >
>>> >> >> >> > As previously stated, I don't see a technical reason to keep
>>> >> >> >> > iptables
>>> >> >> >> > under
>>> >> >> >> > consideration. (3)
>>> >> >> >> >
>>> >> >> >> >
>>> >> >> >> > On Sun, Mar 26, 2017 at 2:57 PM, Yedidyah Bar David
>>> >> >> >> > <didi at redhat.com>
>>> >> >> >> > wrote:
>>> >> >> >> >>
>>> >> >> >> >>
>>> >> >> >> >> 1. Do we want to support in some version X both iptables and
>>> >> >> >> >> firewalld,
>>> >> >> >> >> or
>>> >> >> >> >> is it ok to stop support for iptables and support only
>>> >> >> >> >> firewalld
>>> >> >> >> >> without
>>> >> >> >> >> overlap? If so, do we handle upgrades, and how?
>>> >> >> >> >>
>>> >> >> >> >> 2. Do we want to support custom firewalld xml to be configured
>>> >> >> >> >> on
>>> >> >> >> >> the
>>> >> >> >> >> host by us? Or is it ok to only support choosing among
>>> >> >> >> >> existing
>>> >> >> >> >> services,
>>> >> >> >> >> which will need to be added to the host using other means
>>> >> >> >> >> (packaged
>>> >> >> >> >> by
>>> >> >> >> >> firewalld, packaged by 3rd parties, added manually by users)?
>>> >> >> >> >>
>>> >> >> >> >> 3. Opposite of (2.): Do we want to support firewalld services
>>> >> >> >> >> that
>>> >> >> >> >> are
>>> >> >> >> >> added to the host using other means (see there)? Obviously we
>>> >> >> >> >> do,
>>> >> >> >> >> but:
>>> >> >> >> >> If we do, do we still want to support also iptables (see
>>> >> >> >> >> (1.))?
>>> >> >> >> >> And
>>> >> >> >> >> if
>>> >> >> >> >> so, what do we want to then happen?
>>> >> >> >> >>
>>> >> >> >> >> (2.) and (3.) are not conflicting, each needs its own answer.
>>> >> >> >> >>
>>> >> >> >> >>
>>> >> >> >> >> --
>>> >> >> >> >> Didi
>>> >> >> >> >
>>> >> >> >> >
>>> >> >> >>
>>> >> >> >>
>>> >> >> >>
>>> >> >> >> --
>>> >> >> >> Didi
>>> >> >> >
>>> >> >> >
>>> >> >>
>>> >> >>
>>> >> >>
>>> >> >> --
>>> >> >> Didi
>>> >> >
>>> >> >
>>> >> >
>>> >> > _______________________________________________
>>> >> > Devel mailing list
>>> >> > Devel at ovirt.org
>>> >> > http://lists.ovirt.org/mailman/listinfo/devel
>>> >> _______________________________________________
>>> >> Devel mailing list
>>> >> Devel at ovirt.org
>>> >> http://lists.ovirt.org/mailman/listinfo/devel
>>> >
>>> >
>>
>>
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel

-- 
Didi