OVN provider's firewalld services deployment during engine setup
Hey, We're trying to come up with a way to deploy OVN provider's firewalld services during engine setup. The naive solution of querying the user during customization and then installing during STAGE_PACKAGES fails as firewalld configuration happens prior to it. We thought of a couple of possible solutions we'd like your opinions on (ordered in perceived level of difficulty): 1) Ship/require the packages with ovirt-engine without requiring user input. This essentially couples engine with OVN and disregards a future where OVN doesn't run alongside Engine. 2) Install the packages immediately following user input during customization. A bit hacky and doesn't conceptually fit the stage of customization. 3) Move user input to STAGE_INTERNAL_PACKAGES. Feels more disruptive than #1 to the current otopi flow as STAGE_INTERNAL_PACKAGES is dedicated for packages that are required for otopi itself to operate. Not only this doesn't fit conceptually, it introduces user input to a stage that shouldn't have any. 4) Move firewalld configuration to happen after STAGE_PACKAGES. 5) Refactor to prepare the grounds for OVN/Engine separation. At this point this feels very ambiguous. We don't yet know how will containers be accessed (is ssh guaranteed?) in the future or generally how should a remote installation look like. Any input/questions are appreciated. Thanks, Leon
On Mon, Jun 12, 2017 at 5:50 PM, Leon Goldberg <lgoldber@redhat.com> wrote:
Hey,
We're trying to come up with a way to deploy OVN provider's firewalld services during engine setup. The naive solution of querying the user during customization and then installing during STAGE_PACKAGES fails as firewalld configuration happens prior to it.
We thought of a couple of possible solutions we'd like your opinions on (ordered in perceived level of difficulty):
1) Ship/require the packages with ovirt-engine without requiring user input. This essentially couples engine with OVN and disregards a future where OVN doesn't run alongside Engine.
How much space will this add? RPMs/Installed-size? This is also what we do today with dwh. It can run in the engine machine or on a different one, but the engine still (indirectly) requires it. So it's always shipped, and if user chooses to not configure it, it still takes space, and user has to set it up elsewhere.
2) Install the packages immediately following user input during customization. A bit hacky and doesn't conceptually fit the stage of customization.
3) Move user input to STAGE_INTERNAL_PACKAGES. Feels more disruptive than #1 to the current otopi flow as STAGE_INTERNAL_PACKAGES is dedicated for packages that are required for otopi itself to operate. Not only this doesn't fit conceptually, it introduces user input to a stage that shouldn't have any.
4) Move firewalld configuration to happen after STAGE_PACKAGES.
This is a rather big change to how things are done, and breaks iptables support. If we want to keep iptables support, and allow prompting the user with the changes that will be done to iptables [1], we must know beforehand which ports will need to be opened, so we need the firewalld service files during customization. Thinking about this, another option is to package the service files separately (in ovn itself, one day, or in the provider, for now) - and require by the engine only this sub-package, which should be tiny and have no dependencies (except for firewalld perhaps). [1] https://bugzilla.redhat.com/1109326
5) Refactor to prepare the grounds for OVN/Engine separation. At this point this feels very ambiguous. We don't yet know how will containers be accessed (is ssh guaranteed?) in the future or generally how should a remote installation look like.
Agreed. While "this is the future", I do not think we can do anything worthy for 4.2. Best,
Any input/questions are appreciated.
Thanks, Leon
-- Didi
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 ... Martin On Tue, Jun 13, 2017 at 7:36 AM, Yedidyah Bar David <didi@redhat.com> wrote:
On Mon, Jun 12, 2017 at 5:50 PM, Leon Goldberg <lgoldber@redhat.com> wrote:
Hey,
We're trying to come up with a way to deploy OVN provider's firewalld services during engine setup. The naive solution of querying the user during customization and then installing during STAGE_PACKAGES fails as firewalld configuration happens prior to it.
We thought of a couple of possible solutions we'd like your opinions on (ordered in perceived level of difficulty):
1) Ship/require the packages with ovirt-engine without requiring user input. This essentially couples engine with OVN and disregards a future where OVN doesn't run alongside Engine.
How much space will this add? RPMs/Installed-size?
This is also what we do today with dwh. It can run in the engine machine or on a different one, but the engine still (indirectly) requires it. So it's always shipped, and if user chooses to not configure it, it still takes space, and user has to set it up elsewhere.
2) Install the packages immediately following user input during customization. A bit hacky and doesn't conceptually fit the stage of customization.
3) Move user input to STAGE_INTERNAL_PACKAGES. Feels more disruptive
than #1
to the current otopi flow as STAGE_INTERNAL_PACKAGES is dedicated for packages that are required for otopi itself to operate. Not only this doesn't fit conceptually, it introduces user input to a stage that shouldn't have any.
4) Move firewalld configuration to happen after STAGE_PACKAGES.
This is a rather big change to how things are done, and breaks iptables support. If we want to keep iptables support, and allow prompting the user with the changes that will be done to iptables [1], we must know beforehand which ports will need to be opened, so we need the firewalld service files during customization.
Thinking about this, another option is to package the service files separately (in ovn itself, one day, or in the provider, for now) - and require by the engine only this sub-package, which should be tiny and have no dependencies (except for firewalld perhaps).
[1] https://bugzilla.redhat.com/1109326
5) Refactor to prepare the grounds for OVN/Engine separation. At this
point
this feels very ambiguous. We don't yet know how will containers be accessed (is ssh guaranteed?) in the future or generally how should a remote installation look like.
Agreed. While "this is the future", I do not think we can do anything worthy for 4.2.
Best,
Any input/questions are appreciated.
Thanks, Leon
-- Didi _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
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. 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). On Tue, Jun 13, 2017 at 10:33 AM, Martin Perina <mperina@redhat.com> wrote:
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 ...
Martin
On Tue, Jun 13, 2017 at 7:36 AM, Yedidyah Bar David <didi@redhat.com> wrote:
On Mon, Jun 12, 2017 at 5:50 PM, Leon Goldberg <lgoldber@redhat.com> wrote:
Hey,
We're trying to come up with a way to deploy OVN provider's firewalld services during engine setup. The naive solution of querying the user during customization and then installing during STAGE_PACKAGES fails as firewalld configuration happens prior to it.
We thought of a couple of possible solutions we'd like your opinions on (ordered in perceived level of difficulty):
1) Ship/require the packages with ovirt-engine without requiring user input. This essentially couples engine with OVN and disregards a future where OVN doesn't run alongside Engine.
How much space will this add? RPMs/Installed-size?
This is also what we do today with dwh. It can run in the engine machine or on a different one, but the engine still (indirectly) requires it. So it's always shipped, and if user chooses to not configure it, it still takes space, and user has to set it up elsewhere.
2) Install the packages immediately following user input during customization. A bit hacky and doesn't conceptually fit the stage of customization.
3) Move user input to STAGE_INTERNAL_PACKAGES. Feels more disruptive
than #1
to the current otopi flow as STAGE_INTERNAL_PACKAGES is dedicated for packages that are required for otopi itself to operate. Not only this doesn't fit conceptually, it introduces user input to a stage that shouldn't have any.
4) Move firewalld configuration to happen after STAGE_PACKAGES.
This is a rather big change to how things are done, and breaks iptables support. If we want to keep iptables support, and allow prompting the user with the changes that will be done to iptables [1], we must know beforehand which ports will need to be opened, so we need the firewalld service files during customization.
Thinking about this, another option is to package the service files separately (in ovn itself, one day, or in the provider, for now) - and require by the engine only this sub-package, which should be tiny and have no dependencies (except for firewalld perhaps).
[1] https://bugzilla.redhat.com/1109326
5) Refactor to prepare the grounds for OVN/Engine separation. At this
point
this feels very ambiguous. We don't yet know how will containers be accessed (is ssh guaranteed?) in the future or generally how should a remote installation look like.
Agreed. While "this is the future", I do not think we can do anything worthy for 4.2.
Best,
Any input/questions are appreciated.
Thanks, Leon
-- Didi _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
_______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
On Tue, Jun 13, 2017 at 10:33 AM, Martin Perina <mperina@redhat.com> wrote:
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.
In 4.2, OVN provider is configured by default on the Engine host, but the user can opt to avoid that. He can then configure the provider manually, and add it manually to Engine. We have already limited the automatic configuration of OVN to the case of it running on the same host. When looked from this perspective, adding an explicit rpm-level Requires, does not make things much worse, it only makes reality visible.
And even if we don't support OVN on different host in 4.2, we can prepare for the future ...
A big question is whether that future includes installing things on a remote host (as in DWH), or alternatively spawning a container. Implementing the OVN deployment to the Engine machine took quite a big effort[1]. I worry that extending it to allow remote host would be even more consuming, it's not a minor preparation but a mid-size feature on its own. [1] https://gerrit.ovirt.org/#/q/message:ovn+project:ovirt-engine+message:packag...
On Sun, Jun 18, 2017 at 2:17 PM, Dan Kenigsberg <danken@redhat.com> wrote:
On Tue, Jun 13, 2017 at 10:33 AM, Martin Perina <mperina@redhat.com> wrote:
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.
In 4.2, OVN provider is configured by default on the Engine host, but the user can opt to avoid that. He can then configure the provider manually, and add it manually to Engine. We have already limited the automatic configuration of OVN to the case of it running on the same host.
When looked from this perspective, adding an explicit rpm-level Requires, does not make things much worse, it only makes reality visible.
And even if we don't support OVN on different host in 4.2, we can prepare for the future ...
A big question is whether that future includes installing things on a remote host (as in DWH), or alternatively spawning a container. Implementing the OVN deployment to the Engine machine took quite a big effort[1]. I worry that extending it to allow remote host would be even more consuming, it's not a minor preparation but a mid-size feature on its own.
I'm not sure anyone answered how heavy (CPU, memory, disk size) it is on the Engine. Y.
[1] https://gerrit.ovirt.org/#/q/message:ovn+project:ovirt- engine+message:packaging+status:merged _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
On Sun, Jun 18, 2017 at 5:18 PM, Yaniv Kaul <ykaul@redhat.com> wrote:
On Sun, Jun 18, 2017 at 2:17 PM, Dan Kenigsberg <danken@redhat.com> wrote:
On Tue, Jun 13, 2017 at 10:33 AM, Martin Perina <mperina@redhat.com> wrote:
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.
In 4.2, OVN provider is configured by default on the Engine host, but the user can opt to avoid that. He can then configure the provider manually, and add it manually to Engine. We have already limited the automatic configuration of OVN to the case of it running on the same host.
When looked from this perspective, adding an explicit rpm-level Requires, does not make things much worse, it only makes reality visible.
And even if we don't support OVN on different host in 4.2, we can prepare for the future ...
A big question is whether that future includes installing things on a remote host (as in DWH), or alternatively spawning a container. Implementing the OVN deployment to the Engine machine took quite a big effort[1]. I worry that extending it to allow remote host would be even more consuming, it's not a minor preparation but a mid-size feature on its own.
I'm not sure anyone answered how heavy (CPU, memory, disk size) it is on the Engine.
On another thread, Sandro mentioned the effect on disk size: +17Mb, +2%. CPU and Memory are much harder to estimate, as they depend on the number of networks and hosts controlled by OVN. Mor, can you provide numbers for a small cluster that you tested? Dan.
On Mon, Jun 19, 2017 at 9:45 AM, Dan Kenigsberg <danken@redhat.com> wrote:
On Sun, Jun 18, 2017 at 5:18 PM, Yaniv Kaul <ykaul@redhat.com> wrote:
On Sun, Jun 18, 2017 at 2:17 PM, Dan Kenigsberg <danken@redhat.com> wrote:
On Tue, Jun 13, 2017 at 10:33 AM, Martin Perina <mperina@redhat.com> wrote:
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.
In 4.2, OVN provider is configured by default on the Engine host, but the user can opt to avoid that. He can then configure the provider manually, and add it manually to Engine. We have already limited the automatic configuration of OVN to the case of it running on the same host.
When looked from this perspective, adding an explicit rpm-level Requires, does not make things much worse, it only makes reality visible.
And even if we don't support OVN on different host in 4.2, we can prepare for the future ...
A big question is whether that future includes installing things on a remote host (as in DWH), or alternatively spawning a container. Implementing the OVN deployment to the Engine machine took quite a big effort[1]. I worry that extending it to allow remote host would be even more consuming, it's not a minor preparation but a mid-size feature on its own.
I'm not sure anyone answered how heavy (CPU, memory, disk size) it is on the Engine.
On another thread, Sandro mentioned the effect on disk size: +17Mb, +2%.
CPU and Memory are much harder to estimate, as they depend on the number of networks and hosts controlled by OVN. Mor, can you provide numbers for a small cluster that you tested?
I believe these are irrelevant if the user opts to not configure/run OVN on the engine machine. My (not sure about Yaniv's) question was only about disk space, which iiuc is the only implication of making engine Require: ovn. Still, if possible, it will be useful if someone can provide cpu/memory use, and also the list of dependencies for the ovn package (and the provider package) - especially if there are ones that are not from the base OS.
Dan. _______________________________________________ Devel mailing list Devel@ovirt.org http://lists.ovirt.org/mailman/listinfo/devel
-- Didi
(Re-opening an old thread) On Mon, Jun 19, 2017 at 9:53 AM, Yedidyah Bar David <didi@redhat.com> wrote:
On Mon, Jun 19, 2017 at 9:45 AM, Dan Kenigsberg <danken@redhat.com> wrote:
On Sun, Jun 18, 2017 at 5:18 PM, Yaniv Kaul <ykaul@redhat.com> wrote:
On Sun, Jun 18, 2017 at 2:17 PM, Dan Kenigsberg <danken@redhat.com> wrote:
On Tue, Jun 13, 2017 at 10:33 AM, Martin Perina <mperina@redhat.com> wrote:
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.
In 4.2, OVN provider is configured by default on the Engine host, but the user can opt to avoid that. He can then configure the provider manually, and add it manually to Engine. We have already limited the automatic configuration of OVN to the case of it running on the same host.
When looked from this perspective, adding an explicit rpm-level Requires, does not make things much worse, it only makes reality visible.
And even if we don't support OVN on different host in 4.2, we can prepare for the future ...
A big question is whether that future includes installing things on a remote host (as in DWH), or alternatively spawning a container. Implementing the OVN deployment to the Engine machine took quite a big effort[1]. I worry that extending it to allow remote host would be even more consuming, it's not a minor preparation but a mid-size feature on its own.
I'm not sure anyone answered how heavy (CPU, memory, disk size) it is on the Engine.
On another thread, Sandro mentioned the effect on disk size: +17Mb, +2%.
CPU and Memory are much harder to estimate, as they depend on the number of networks and hosts controlled by OVN. Mor, can you provide numbers for a small cluster that you tested?
I believe these are irrelevant if the user opts to not configure/run OVN on the engine machine. My (not sure about Yaniv's) question was only about disk space, which iiuc is the only implication of making engine Require: ovn. Still, if possible, it will be useful if someone can provide cpu/memory use, and also the list of dependencies for the ovn package (and the provider package) - especially if there are ones that are not from the base OS.
Any update? I still think that we should either make the engine Require: ovn or change the default to 'No'. -- Didi
On Mon, Sep 18, 2017 at 4:16 PM, Yedidyah Bar David <didi@redhat.com> wrote:
(Re-opening an old thread)
On Mon, Jun 19, 2017 at 9:53 AM, Yedidyah Bar David <didi@redhat.com> wrote:
On Mon, Jun 19, 2017 at 9:45 AM, Dan Kenigsberg <danken@redhat.com> wrote:
On Sun, Jun 18, 2017 at 5:18 PM, Yaniv Kaul <ykaul@redhat.com> wrote:
On Sun, Jun 18, 2017 at 2:17 PM, Dan Kenigsberg <danken@redhat.com> wrote:
On Tue, Jun 13, 2017 at 10:33 AM, Martin Perina <mperina@redhat.com> wrote:
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.
In 4.2, OVN provider is configured by default on the Engine host, but the user can opt to avoid that. He can then configure the provider manually, and add it manually to Engine. We have already limited the automatic configuration of OVN to the case of it running on the same host.
When looked from this perspective, adding an explicit rpm-level Requires, does not make things much worse, it only makes reality visible.
And even if we don't support OVN on different host in 4.2, we can prepare for the future ...
A big question is whether that future includes installing things on a remote host (as in DWH), or alternatively spawning a container. Implementing the OVN deployment to the Engine machine took quite a big effort[1]. I worry that extending it to allow remote host would be even more consuming, it's not a minor preparation but a mid-size feature on its own.
I'm not sure anyone answered how heavy (CPU, memory, disk size) it is on the Engine.
On another thread, Sandro mentioned the effect on disk size: +17Mb, +2%.
CPU and Memory are much harder to estimate, as they depend on the number of networks and hosts controlled by OVN. Mor, can you provide numbers for a small cluster that you tested?
I believe these are irrelevant if the user opts to not configure/run OVN on the engine machine. My (not sure about Yaniv's) question was only about disk space, which iiuc is the only implication of making engine Require: ovn. Still, if possible, it will be useful if someone can provide cpu/memory use, and also the list of dependencies for the ovn package (and the provider package) - especially if there are ones that are not from the base OS.
Any update?
I still think that we should either make the engine Require: ovn or change the default to 'No'.
I don't have much to add. It code simplicity vs. deployment flexibility. Recently, my opinion (for flexibility) was overruled when ovn-driver was added as a requirement of ovirt-host. It can be similarly be overruled on Engine. I don't care *that* much about the ability to install ovirt-engine with openvswitch baggage. I won't NACK a "Require: ovn" if you think it's still useful.
On Mon, Sep 18, 2017 at 11:53 PM, Dan Kenigsberg <danken@redhat.com> wrote:
On Mon, Sep 18, 2017 at 4:16 PM, Yedidyah Bar David <didi@redhat.com> wrote:
(Re-opening an old thread)
On Mon, Jun 19, 2017 at 9:53 AM, Yedidyah Bar David <didi@redhat.com> wrote:
On Mon, Jun 19, 2017 at 9:45 AM, Dan Kenigsberg <danken@redhat.com> wrote:
On Sun, Jun 18, 2017 at 5:18 PM, Yaniv Kaul <ykaul@redhat.com> wrote:
On Sun, Jun 18, 2017 at 2:17 PM, Dan Kenigsberg <danken@redhat.com> wrote:
On Tue, Jun 13, 2017 at 10:33 AM, Martin Perina <mperina@redhat.com> wrote: > 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.
In 4.2, OVN provider is configured by default on the Engine host, but the user can opt to avoid that. He can then configure the provider manually, and add it manually to Engine. We have already limited the automatic configuration of OVN to the case of it running on the same host.
When looked from this perspective, adding an explicit rpm-level Requires, does not make things much worse, it only makes reality visible.
> And even if we don't support OVN on different host in > 4.2, we can prepare for the future ...
A big question is whether that future includes installing things on a remote host (as in DWH), or alternatively spawning a container. Implementing the OVN deployment to the Engine machine took quite a big effort[1]. I worry that extending it to allow remote host would be even more consuming, it's not a minor preparation but a mid-size feature on its own.
I'm not sure anyone answered how heavy (CPU, memory, disk size) it is on the Engine.
On another thread, Sandro mentioned the effect on disk size: +17Mb, +2%.
CPU and Memory are much harder to estimate, as they depend on the number of networks and hosts controlled by OVN. Mor, can you provide numbers for a small cluster that you tested?
I believe these are irrelevant if the user opts to not configure/run OVN on the engine machine. My (not sure about Yaniv's) question was only about disk space, which iiuc is the only implication of making engine Require: ovn. Still, if possible, it will be useful if someone can provide cpu/memory use, and also the list of dependencies for the ovn package (and the provider package) - especially if there are ones that are not from the base OS.
Any update?
I still think that we should either make the engine Require: ovn or change the default to 'No'.
I don't have much to add. It code simplicity vs. deployment flexibility. Recently, my opinion (for flexibility) was overruled when ovn-driver was added as a requirement of ovirt-host. It can be similarly be overruled on Engine. I don't care *that* much about the ability to install ovirt-engine with openvswitch baggage. I won't NACK a "Require: ovn" if you think it's still useful.
Pushed: https://gerrit.ovirt.org/81960 -- Didi
participants (6)
-
Dan Kenigsberg -
Edward Haas -
Leon Goldberg -
Martin Perina -
Yaniv Kaul -
Yedidyah Bar David