engine-setup allow to upgrade all packages in a group called ovirt-engine-3.4 and fallback to upgrading ovirt-engine if the group doesn't exist. With https://fedorahosted.org/ovirt/ticket/130 we started trying to use the group and failed. We've seen that when ovirt-engine-3.4 group is provided, upgrade fails. After investigation we could reproduce that just using yum: # yum --disableplugin versionlock groupupdate ovirt-engine-3.4 Loaded plugins: langpacks, refresh-packagekit There is no installed groups file. Maybe run: yum groups mark convert (see man yum) Maybe run: yum groups mark install (see man yum) No packages in any requested group available to install or update Executing: # yum groups mark convert Loaded plugins: langpacks, refresh-packagekit, versionlock There is no installed groups file. Maybe run: yum groups mark convert (see man yum) Converted old style groups to objects. Then it works: # yum --disableplugin versionlock groupupdate ovirt-engine-3.4 Loaded plugins: langpacks, refresh-packagekit Resolving Dependencies --> Running transaction check ---> Package ovirt-engine.noarch 0:3.3.4-1.fc19 will be updated --> Processing Dependency: ovirt-engine = 3.3.4-1.fc19 for package: ovirt-engine-restapi-3.3.4-1.fc19.noarch --> Processing Dependency: ovirt-engine = 3.3.4-1.fc19 for package: ovirt-engine-tools-3.3.4-1.fc19.noarch ... We need to add support for the new yum group selection used in Fedora >= 19 and EL >= 7.
Let's consider converting the group mechanism into a separate package. Add ovirt-engine-xxx package with Requires of all optional components that are required. At ovirt-engine add Requires ovirt-engine-xxx. This can be also made available to downstream (distribution specific) only, as I do not think we should have ovirt-engine as meta package at upstream. The mission: Force fetch and update extra misc packages, without re-build ovirt-engine. Previous solution: Hardcode package names within setup, this means building ovirt-engine for every change in group list. Current solution: Use yum group for package selection. New solution: Use separate meta package to pull misc packages. Consider not doing that per default at upstream.
(In reply to Alon Bar-Lev from comment #1) > New solution: > Use separate meta package to pull misc packages. +1 What name do you suggest? How about: ovirt ovirt-engine (and rename the engine package to e.g. ovirt-engine-core - that's a different discussion) ovirt-engine-meta ovirt-engine-all I think I prefer one of the first two. The main problem with the first is that it's not completely clear if vdsm is part of ovirt or not :-) But generally, it's quite common to keep the short names to meta packages instead of adding a special suffix. > Consider not doing that per default at upstream. So what do you suggest upstream? I think it actually should be the same up- and downstream if possible. I might be missing something, though.
(In reply to Yedidyah Bar David from comment #2) > (In reply to Alon Bar-Lev from comment #1) > > New solution: > > Use separate meta package to pull misc packages. > > +1 > > What name do you suggest? How about: > > ovirt > > ovirt-engine (and rename the engine package to e.g. ovirt-engine-core - > that's a different discussion) > > ovirt-engine-meta meta is good, I would like to avoid rename. > > ovirt-engine-all > > I think I prefer one of the first two. The main problem with the first is > that it's not completely clear if vdsm is part of ovirt or not :-) But > generally, it's quite common to keep the short names to meta packages > instead of adding a special suffix. I think that meta package should be explicit. > > > Consider not doing that per default at upstream. > > So what do you suggest upstream? > > I think it actually should be the same up- and downstream if possible. I > might be missing something, though. I think that the support model of upstream differ from downstream. At upstream there is no actual need to provide meta package, nor the log collector etc... So I think pulling additional misc packages should be per downstream need.
(In reply to Alon Bar-Lev from comment #3) > (In reply to Yedidyah Bar David from comment #2) > > (In reply to Alon Bar-Lev from comment #1) > > > New solution: > > > Use separate meta package to pull misc packages. > > > > +1 > > > > What name do you suggest? How about: > > > > ovirt > > > > ovirt-engine (and rename the engine package to e.g. ovirt-engine-core - > > that's a different discussion) > > > > ovirt-engine-meta > > meta is good, I would like to avoid rename. > > > > > ovirt-engine-all > > > > I think I prefer one of the first two. The main problem with the first is > > that it's not completely clear if vdsm is part of ovirt or not :-) But > > generally, it's quite common to keep the short names to meta packages > > instead of adding a special suffix. > > I think that meta package should be explicit. I agree with your reasoning in both, just pointed out that it's very common to do the opposite. Not sure about Fedora, but a quick search in Debian shows many meta pacakges with short names, few with '-all', and none with '-meta'. > > > > > > Consider not doing that per default at upstream. > > > > So what do you suggest upstream? > > > > I think it actually should be the same up- and downstream if possible. I > > might be missing something, though. > > I think that the support model of upstream differ from downstream. At > upstream there is no actual need to provide meta package, nor the log > collector etc... > > So I think pulling additional misc packages should be per downstream need. Of course, I just think we should have the same structure. Same suffix (or other name structure) etc, just the list of dependencies can be different.
(In reply to Yedidyah Bar David from comment #4) > (In reply to Alon Bar-Lev from comment #3) > > (In reply to Yedidyah Bar David from comment #2) > > > (In reply to Alon Bar-Lev from comment #1) > > > > New solution: > > > > Use separate meta package to pull misc packages. > > > > > > +1 > > > > > > What name do you suggest? How about: > > > > > > ovirt > > > > > > ovirt-engine (and rename the engine package to e.g. ovirt-engine-core - > > > that's a different discussion) > > > > > > ovirt-engine-meta > > > > meta is good, I would like to avoid rename. > > > > > > > > ovirt-engine-all > > > > > > I think I prefer one of the first two. The main problem with the first is > > > that it's not completely clear if vdsm is part of ovirt or not :-) But > > > generally, it's quite common to keep the short names to meta packages > > > instead of adding a special suffix. > > > > I think that meta package should be explicit. > > I agree with your reasoning in both, just pointed out that it's very common > to do the opposite. Not sure about Fedora, but a quick search in Debian > shows many meta pacakges with short names, few with '-all', and none with > '-meta'. If the package would have renamed to ovirt-engine-backend then I would have fine with ovirt-engine as meta package. But we cannot rename anything because of the use of versionlock. So for now it is not actually meta package but a package that pulls dependencies. As ovirt-engine will pull that package and not the other way around. > > > > > > > > > > Consider not doing that per default at upstream. > > > > > > So what do you suggest upstream? > > > > > > I think it actually should be the same up- and downstream if possible. I > > > might be missing something, though. > > > > I think that the support model of upstream differ from downstream. At > > upstream there is no actual need to provide meta package, nor the log > > collector etc... > > > > So I think pulling additional misc packages should be per downstream need. > > Of course, I just think we should have the same structure. Same suffix (or > other name structure) etc, just the list of dependencies can be different. If we actually need to pull extra packages at upstream, I question that as a requirement. I do not think we should pull any misc package.
(In reply to Alon Bar-Lev from comment #5) > (In reply to Yedidyah Bar David from comment #4) > > (In reply to Alon Bar-Lev from comment #3) > > > (In reply to Yedidyah Bar David from comment #2) > > > > (In reply to Alon Bar-Lev from comment #1) > > > > > New solution: > > > > > Use separate meta package to pull misc packages. > > > > > > > > +1 > > > > > > > > What name do you suggest? How about: > > > > > > > > ovirt > > > > > > > > ovirt-engine (and rename the engine package to e.g. ovirt-engine-core - > > > > that's a different discussion) > > > > > > > > ovirt-engine-meta > > > > > > meta is good, I would like to avoid rename. > > > > > > > > > > > ovirt-engine-all > > > > > > > > I think I prefer one of the first two. The main problem with the first is > > > > that it's not completely clear if vdsm is part of ovirt or not :-) But > > > > generally, it's quite common to keep the short names to meta packages > > > > instead of adding a special suffix. > > > > > > I think that meta package should be explicit. > > > > I agree with your reasoning in both, just pointed out that it's very common > > to do the opposite. Not sure about Fedora, but a quick search in Debian > > shows many meta pacakges with short names, few with '-all', and none with > > '-meta'. > > If the package would have renamed to ovirt-engine-backend then I would have > fine with ovirt-engine as meta package. > > But we cannot rename anything because of the use of versionlock. OK, makes sense. Not sure we "cannot", but it definitely makes it harder. > > So for now it is not actually meta package but a package that pulls > dependencies. As ovirt-engine will pull that package and not the other way > around. It's still a meta-package... There is no law that you can't depend on a meta-package. What you probably mean is that usually users will not manually install it directly. If you imply by that that the common naming practices do not apply here I guess I agree. In light of this, perhaps '-meta' is not a good name. Perhaps '-extras'? Or '-deps'? > > > > > > > > > > > > > > > Consider not doing that per default at upstream. > > > > > > > > So what do you suggest upstream? > > > > > > > > I think it actually should be the same up- and downstream if possible. I > > > > might be missing something, though. > > > > > > I think that the support model of upstream differ from downstream. At > > > upstream there is no actual need to provide meta package, nor the log > > > collector etc... > > > > > > So I think pulling additional misc packages should be per downstream need. > > > > Of course, I just think we should have the same structure. Same suffix (or > > other name structure) etc, just the list of dependencies can be different. > > If we actually need to pull extra packages at upstream, I question that as a > requirement. I do not think we should pull any misc package.
*** Bug 1093721 has been marked as a duplicate of this bug. ***
Problem is also on F19 so not blocking F20 support.
Recent rpm supports Recommends and Suggests. These might be a solution too - we can have ovirt-engine package recommend and/or suggest others that are not mandatory but are useful, and provide an option in engine-setup to ignore these.
Following the discussion above changed the summary. Also we should rethink other dependencies. Example: engine-backup is currently packaged inside -tools. tools depends on the entire engine. This means that dwh/reports on separate hosts that want to use engine-backup (which should already work for them without the engine) needlessly pull the entire engine (and risk an error on the user's part when running engine-setup the next time - might wrongly reply 'Yes' to 'Configure Engine?'. We might want to open another bug on this one, that's a separate issue). TODO: 1. analyze and document somehow the minimal dependencies we want to have (e.g. do we want to support running engine-config from remote? etc.) 2. Test dropping most/all deps and install each current package separately 3. (From previous discussion) decide what kind of structure we want for meta packages: - Do we want users to be able to install one (or more?) among several meta-packages (say ovirt-engine-full, ovirt-engine-minimal etc)? - Do we want something like a meta package ovirt-engine-core which is depending on some other packages we "always" want and other packages can depend on it? I think the former. Also consider dwh/reports on separate hosts and the current use for the yum group (e.g. installing stuff like the log-collector). 4. Decide what we want engine-setup to do, e.g.: - If user installed ovirt-engine-minimal, we should probably check only for updates for it - Should we also suggest/recommend ovirt-engine-full? will require restating setup - If ovirt-engine-full, check updates for all components
This is an automated message. This Bugzilla report has been opened on a version which is not maintained anymore. Please check if this bug is still relevant in oVirt 3.5.4. If it's not relevant anymore, please close it (you may use EOL or CURRENT RELEASE resolution) If it's an RFE please update the version to 4.0 if still relevant.
Target release should be placed once a package build is known to fix a issue. Since this bug is not modified, the target version has been reset. Please use target milestone to plan a fix for a oVirt release.
(In reply to Yedidyah Bar David from comment #9) > Recent rpm supports Recommends and Suggests. These might be a solution too - > we can have ovirt-engine package recommend and/or suggest others that are > not mandatory but are useful, and provide an option in engine-setup to > ignore these. Now checked again and I see that el7's rpm does not have it, nor does this functionality seem very mature in yum/dnf. Perhaps we should do this ourselves. Something like: 1. Drop the code handling the yum group etc. 2. Things that are mandatory, just add as 'Requires:' to engine spec. We do this already. 3. Things that we need to upgrade to latest version by engine-setup, and which we do not want to bother with updating this latest version in the engine spec file, can be handled by existing code that installs/updates all the packages in osetupcons.RPMDistroEnv.PACKAGES_UPGRADE_LIST (which can be extended also in a plugin if needed). 4. Have in the source (of the engine setup plugin or whatever) a list of recommended and/or suggested optional packages (and setup packages). 5. Ask the user whether to install these recommended/suggested ones. 6. If yes, and if setup packages need to be installed/updated, install them and restart engine-setup. See also bug 1130445. 7. Continue as usual: ask about optional components in the code as is today, install needed packages during relevant stage etc.
Didi, is this still relevant now that we dropped the effort supporting groups?
(In reply to Sandro Bonazzola from comment #14) > Didi, is this still relevant now that we dropped the effort supporting > groups? I'd say many parts of the discussion might be relevant and still not addressed, but the core issue is solved. Optional components might be handled radically differently eventually - there are ideas to provide them as appliances (VMs or containers) etc. Closing as duplicate of bug 1286558 for now. *** This bug has been marked as a duplicate of bug 1286558 ***