[ovirt-devel] oVirt 4.0 Nightly repo

Thu Jun 16 14:18:06 UTC 2016

Hi everyone,

I think Sven was referring specifically to oVirt Dashboard component
of oVirt Engine product. Dashboard (UI plugin) has its own repo [1]

[1] https://gerrit.ovirt.org/#/admin/projects/ovirt-engine-dashboard

with dedicated Jenkins job to build its RPM. When Engine is installed,
Dashboard RPM is *automatically* installed & updated as well.

You don't have to worry about tracking Dashboard RPM version installed
on machine running your Engine. Dashboard is technically part of Engine
because it relies on Engine UI plugin infra, it's not "standalone" like
VDSM.

TL;DR the fact that Dashboard has its own RPM shouldn't impact users,
it's a logical part of Engine.

Regards,
Vojtech

----- Original Message -----
> From: "Eyal Edri" <eedri at redhat.com>
> To: "Vinzenz Feenstra" <vfeenstr at redhat.com>
> Cc: "Unname" <devel at ovirt.org>
> Sent: Thursday, June 16, 2016 3:11:51 PM
> Subject: Re: [ovirt-devel] oVirt 4.0 Nightly repo
> 
> I'm not sure what you mean or which versions you're referring to.
> Like every project there is the 'master' branch and nightlies which is latest
> and greatest (and probably the least stable, but still go over heavy CI
> tests).
> The oVirt project reached a point when the next stable major version (4.0) is
> nearing GA, and part of the process is to branch it to create rpms for it,
> in order to continue developing 4.1 (now master) and not to merge new
> features that may risk 4.0 stability the new branch has to be created.
> 
> You as user/developer has the choice to choose which version to use,
> according to you needs:
> for e.g, at this time point, you choices are:
> 
> 1. Use current stable: 3.6 rpms - most stable, only gets specific fixes and
> not major features - recommended for a production usage and if you don't
> need any of the new features [1]
> 2. Use current RC candidate for next major 4.0, which should be the next
> stable version soon and replace 3.6 as the latest stable version [2]
> 3. Use nightlies for every version - either 4.0, master, 3.6 - use at your
> own risk since these are not official releases and not going via extensive
> QA, although the automated tests for each version
> are improving over time and make the nightlies more and more stable. [3]
> 
> 
> Just to help better undertand, if you'll make the same decision in one more
> months for e.g, after 4.0 is GA, you choices will be:
> 
> 1. use current stable 4.0 (unless you really want to use older 3.6)
> 2. use nightlies
> 
> So the extra versions are temp version that are part of the development
> process and actually gives you an oppertunity to check out new features that
> are not available yet in a formal stable version.
> I hope it gives some info on the diff between all the versions.
> 
> [1]. http://resources.ovirt.org/pub/ovirt-3.6/
> [2] http://resources.ovirt.org/pub/ovirt-4.0-pre/
> [3] http://resources.ovirt.org/pub/ovirt-4.0-snapshot(+-static) ,
> http://resources.ovirt.org/pub/ovirt-master-snapshot(+static)
> 
> 
> 
> 
> 
> 
> 
> On Thu, Jun 16, 2016 at 12:16 PM, Vinzenz Feenstra < vfeenstr at redhat.com >
> wrote:
> 
> 
> 
> > On Jun 16, 2016, at 11:06 AM, Sven Kieske < S.Kieske at mittwald.de > wrote:
> > 
> > On 14/06/16 17:34, Vojtech Szocs wrote:
> >> Hi,
> >> 
> >> ovirt-engine-dashboard is currently built from master as well.
> >> 
> >> We should probably create a stable branch, e.g.
> >> ovirt-engine-dashboard-1.0.
> > 
> > Hi,
> > 
> > speaking as an end user (mostly):
> > 
> > please not yet-another-versioning in the great ovirt project.
> > 
> > I'm already having severe issues tracking which engine versions works
> > with which vdsm version, let alone track which datacenter and cluster
> > version within each engine version works with which vdsm version and
> > which features are (un)supported.
> > 
> > Please don't add another different version to the already far to complex
> > equation.
> +1 :-)
> > 
> > I'd suggest you take the same version number as the supported
> > ovirt-engine, you also should adjust release cycles of all the
> > subprojects where possible (I know that doesn't work always).
> > 
> > this would make every users life make so much less painful.
> > 
> > keep up the great work!
> > 
> > --
> > Mit freundlichen Grüßen / Regards
> > 
> > Sven Kieske
> > 
> > Systemadministrator
> > Mittwald CM Service GmbH & Co. KG
> > Königsberger Straße 6
> > 32339 Espelkamp
> > T: +495772 293100
> > F: +495772 293333
> > https://www.mittwald.de
> > Geschäftsführer: Robert Meyer
> > St.Nr.: 331/5721/1033, USt-IdNr.: DE814773217, HRA 6640, AG Bad Oeynhausen
> > Komplementärin: Robert Meyer Verwaltungs GmbH, HRB 13260, AG Bad Oeynhausen
> > 
> > _______________________________________________
> > 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
> 
> 
> 
> 
> 
> --
> Eyal Edri
> Associate Manager
> RHEV DevOps
> EMEA ENG Virtualization R&D
> Red Hat Israel
> 
> phone: +972-9-7692018
> irc: eedri (on #tlv #rhev-dev #rhev-integ)
> 
> _______________________________________________
> Devel mailing list
> Devel at ovirt.org
> http://lists.ovirt.org/mailman/listinfo/devel