<div dir="ltr"><div><div><div>My 2 cent on this: Whatever option you choose, do not couple OVN to Engine, it may cost you less now, but you will find it expensive later.<br></div><div>On the other hand, if the solution is phased into 2 stages, the first just pushes it in and immediately later does the needed changes to decouple things, then it may make sense (to the sake of having the feature).<br></div></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 13, 2017 at 10:33 AM, Martin Perina <span dir="ltr"><<a href="mailto:mperina@redhat.com" target="_blank">mperina@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Will OVN provider be mandatory for all engine 4.2 installation? Can OVN provider be installed on different host than engine? If not mandatory or "may be on different host", then it should be handled similar way as DWH, so it should be in separate package and it's engine-setup part should also be in separate package. And even if we don't support OVN on different host in 4.2, we can prepare for the future ...<span class="HOEnZb"><font color="#888888"><br><br></font></span></div><span class="HOEnZb"><font color="#888888"><div class="gmail_default" style="font-family:arial,helvetica,sans-serif">Martin<br></div></font></span></div><div class="HOEnZb"><div class="h5"><div class="gmail_extra"><br><div class="gmail_quote">On Tue, Jun 13, 2017 at 7:36 AM, Yedidyah Bar David <span dir="ltr"><<a href="mailto:didi@redhat.com" target="_blank">didi@redhat.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Mon, Jun 12, 2017 at 5:50 PM, Leon Goldberg <<a href="mailto:lgoldber@redhat.com" target="_blank">lgoldber@redhat.com</a>> wrote:<br>
> Hey,<br>
><br>
> We're trying to come up with a way to deploy OVN provider's firewalld<br>
> services during engine setup. The naive solution of querying the user during<br>
> customization and then installing during STAGE_PACKAGES fails as firewalld<br>
> configuration happens prior to it.<br>
><br>
> We thought of a couple of possible solutions we'd like your opinions on<br>
> (ordered in perceived level of difficulty):<br>
><br>
> 1) Ship/require the packages with ovirt-engine without requiring user input.<br>
> This essentially couples engine with OVN and disregards a future where OVN<br>
> doesn't run alongside Engine.<br>
<br>
How much space will this add? RPMs/Installed-size?<br>
<br>
This is also what we do today with dwh. It can run in the engine machine or<br>
on a different one, but the engine still (indirectly) requires it. So it's<br>
always shipped, and if user chooses to not configure it, it still takes<br>
space, and user has to set it up elsewhere.<br>
<br>
><br>
> 2) Install the packages immediately following user input during<br>
> customization. A bit hacky and doesn't conceptually fit the stage of<br>
> customization.<br>
><br>
> 3) Move user input to STAGE_INTERNAL_PACKAGES. Feels more disruptive than #1<br>
> to the current otopi flow as STAGE_INTERNAL_PACKAGES is dedicated for<br>
> packages that are required for otopi itself to operate. Not only this<br>
> doesn't fit conceptually, it introduces user input to a stage that shouldn't<br>
> have any.<br>
><br>
> 4) Move firewalld configuration to happen after STAGE_PACKAGES.<br>
<br>
This is a rather big change to how things are done, and breaks iptables<br>
support. If we want to keep iptables support, and allow prompting the user<br>
with the changes that will be done to iptables [1], we must know beforehand<br>
which ports will need to be opened, so we need the firewalld service files<br>
during customization.<br>
<br>
Thinking about this, another option is to package the service files<br>
separately (in ovn itself, one day, or in the provider, for now) -<br>
and require by the engine only this sub-package, which should be tiny<br>
and have no dependencies (except for firewalld perhaps).<br>
<br>
[1] <a href="https://bugzilla.redhat.com/1109326" rel="noreferrer" target="_blank">https://bugzilla.redhat.com/11<wbr>09326</a><br>
<br>
><br>
> 5) Refactor to prepare the grounds for OVN/Engine separation. At this point<br>
> this feels very ambiguous. We don't yet know how will containers be accessed<br>
> (is ssh guaranteed?) in the future or generally how should a remote<br>
> installation look like.<br>
<br>
Agreed. While "this is the future", I do not think we can do anything worthy<br>
for 4.2.<br>
<br>
Best,<br>
<br>
><br>
> Any input/questions are appreciated.<br>
><br>
> Thanks,<br>
> Leon<br>
<span class="m_-9082150733636355262HOEnZb"><font color="#888888"><br>
<br>
<br>
--<br>
Didi<br>
______________________________<wbr>_________________<br>
Devel mailing list<br>
<a href="mailto:Devel@ovirt.org" target="_blank">Devel@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/mailman<wbr>/listinfo/devel</a><br>
</font></span></blockquote></div><br></div>
</div></div><br>______________________________<wbr>_________________<br>
Devel mailing list<br>
<a href="mailto:Devel@ovirt.org">Devel@ovirt.org</a><br>
<a href="http://lists.ovirt.org/mailman/listinfo/devel" rel="noreferrer" target="_blank">http://lists.ovirt.org/<wbr>mailman/listinfo/devel</a><br></blockquote></div><br></div>