On Thu, May 18, 2017 at 4:47 PM, Marcin Mirecki <[email protected]> wrote:
> The size of the required components: > > Name : openvswitch Size : 11 M > Name : openvswitch-ovn-common Size : 2.8 M > Name : openvswitch-ovn-host Size : 1.9 M > Name : ovirt-provider-ovn Size : 224 k > Name : python-openvswitch Size : 821 k > > about 17M total > Latest nightly built appliance from master [1] is 751MB so we are talking about a 2% increment. If OVN if something that could interest a great part of our users, and personally I absolutely think so, I'd suggest to simply include it. [1] http://resources.ovirt.org/pub/ovirt-master-snapshot/rpm/el7/noarch/ovirt-engine-appliance-4.2-20170517.1.el7.centos.noarch.rpm > > On Thu, May 18, 2017 at 3:26 PM, Simone Tiraboschi <[email protected]> > wrote: > >> >> >> On Wed, May 17, 2017 at 2:35 PM, Yedidyah Bar David <[email protected]> >> wrote: >> >>> On Wed, May 17, 2017 at 2:54 PM, Dan Kenigsberg <[email protected]> >>> wrote: >>> > On Wed, May 17, 2017 at 12:23 PM, Yedidyah Bar David <[email protected]> >>> wrote: >>> >> On Wed, May 17, 2017 at 11:42 AM, Dan Kenigsberg <[email protected]> >>> wrote: >>> >>> On Wed, May 17, 2017 at 10:44 AM, Yedidyah Bar David < >>> [email protected]> wrote: >>> >>>> On Wed, May 17, 2017 at 9:38 AM, Dan Kenigsberg <[email protected]> >>> wrote: >>> >>>>> On Tue, May 16, 2017 at 6:56 PM, Sandro Bonazzola < >>> [email protected]> wrote: >>> >>>>>> >>> >>>>>> Hi, >>> >>>>>> with https://gerrit.ovirt.org/76855 it's requested to increase >>> the appliance size by adding ovirt-provider-ovn and its dependencies. >>> >>>>>> >>> >>>>>> This raise a few questions. >>> >>>>>> The support for ovirt-provider-ovn is enabled by default in >>> engine-setup and going to be installed by default in the appliance so we're >>> pushing to use it. >>> >>>>>> Why not requiring it at ovirt-engine spec file level? >>> >>>>>> Answer given in the commit message of above patch is: >>> >>>>>> >>> >>>>>> We do not want to have a hard dependency in the >>> >>>>>> form of an rpm require. >>> >>>>>> OVN and openvswitch are relatively heavy and complex, >>> >>>>>> and are still experimental. We would not want to >>> >>>>>> force everybody to pull them onto any Engine host. >>> >>>>>> >>> >>>>>> So why adding it to the appliance, which is the default for >>> hosted engine which is our recommeded way to deploy oVirt, and enable it by >>> default? >>> >>>>>> >>> >>>>>> How this differs from DWH? ovirt-engine requires >>> ovirt-engine-setup which requires ovirt-engine-dwh setup which requires >>> ovirt-engine-dwh. >>> >>>>>> Why can't we just require ovirt-provider-ovn in ovirt-engine >>> instead of tweaking the appliance? >>> >>>>>> >>> >>>>>> If we decide it's not mandatory, why not make the default to not >>> enabling it in engine-setup and avoid to add it to the appliance? >>> >>>>>> Being optional, adding it collides with Bug 1401931 - [RFE] >>> reduce the size of the appliance >>> >>>>> >>> >>>>> Much like with DWH, I can envisage a use case where >>> ovirt-provider-ovn >>> >>>>> sits on a remote host, rather than on Engine's. However, the >>> default >>> >>>>> use case is to place them on the same host. >>> >>>>> >>> >>>>> I thought that it would be a good idea to include OVN on the >>> >>>>> appliance, as a means to showcase this new and exciting feature of >>> >>>>> oVirt. However, it is not a must. We can say that we'd like to keep >>> >>>>> the appliance small; if someone wants to use OVN with it, let them >>> run >>> >>>>> ovirt-engine-setup manually, and pull in the dependencies. >>> >>>> >>> >>>> The appliance is assumed to (soon?) be our standard installation >>> flow, >>> >>>> not a way to showcase things. For the latter, you might want to add >>> ovn >>> >>>> to ovirt-live or to the ovirt demo tool [1] (not yet released IIUC). >>> >>>> >>> >>>> [1] https://trello.com/b/wocfflzf/sales-demo-tool-lago-based >>> >>>> >>> >>>>> >>> >>>>> For this we'd need to flip the default, and not install OVN when >>> the >>> >>>>> appliance is created, and skip OVN test in the offline test suite. >>> >>>> >>> >>>> +1 >>> >>> >>> >>> Could you point us to the answer file used for appliance creation? >>> >> >>> >> Do you want to keep the default True for non-appliance? My +1 above >>> >> was also for reverting the default, not only in appliance. >>> > >>> > Oh. I still want to have OVN by default for non-appliance. I like this >>> > feature, and I want to entice people to use it. >>> >>> I think that Sandro's question above applies equally well to the >>> non-appliance usecase. If it's good enough to be the default for >>> non-appliance, might as well be so for the appliance as well. If >>> it's not good enough for the appliance, perhaps default to No also >>> for non-appliance. >>> >>> > >>> > For appliance I understand that we have a size limitation, so ok, let >>> > us not bloat it up. >>> >>> What's the impact on size? For the appliance image and for the >>> eventually-installed machine? >>> >>> I do not think the impact on appliance size is the major question here, >>> but whether we really expect most users to use OVN. But I might be >>> surprised... >>> >>> >> Now we have a bug to track it: >> https://bugzilla.redhat.com/show_bug.cgi?id=1452131 >> >> >>> > >>> > I hope you are also fine with disabling ovn in the following answer >>> file. >>> > >>> >> >>> >> The appliance-supplied answer file seems is: >>> >> >>> >> https://gerrit.ovirt.org/gitweb?p=ovirt-appliance.git;a=blob >>> ;f=engine-appliance/data/ovirt-engine-answers;h=2881af656329 >>> 7a7a3d220dfe479d39f88c12ca46;hb=HEAD >>> >> >>> >> When hosted-engine --deploy is using the appliance, and if the user >>> >> asks to run engine-setup automatically, it uses above file, >>> >> but also adds another file, auto-generated, see here: >>> >> >>> >> https://gerrit.ovirt.org/gitweb?p=ovirt-hosted-engine-setup. >>> git;a=blob;f=src/plugins/gr-he-common/vm/cloud_init.py;h=0a2 >>> 0f946d65199423c99769ab51e4fe092465e96;hb=HEAD#l1018 >>> >> >>> >> None of them has the answer for OVN. Latter has: >>> >> >>> >> DIALOG/autoAcceptDefault=bool:True >>> >> >>> >> For this, see: >>> >> >>> >> https://bugzilla.redhat.com/show_bug.cgi?id=1270719 >>> >>> >>> >>> -- >>> Didi >>> _______________________________________________ >>> Devel mailing list >>> [email protected] >>> http://lists.ovirt.org/mailman/listinfo/devel >>> >> >> >> _______________________________________________ >> Devel mailing list >> [email protected] >> http://lists.ovirt.org/mailman/listinfo/devel >> > > > > -- > > MARCIN mIRECKI > > Red Hat > > <https://www.redhat.com> > <https://red.ht/sig> >
_______________________________________________ Devel mailing list [email protected] http://lists.ovirt.org/mailman/listinfo/devel
