Yedidyah Bar David has posted comments on this change. Change subject: packaging: setup: log setup events - add otopi upgrade ......................................................................
Patch Set 1: (2 inline comments) .................................................... File packaging/setup/ovirt_engine_setup/constants.py Line 538: Line 539: ACTION_SETUP = 'setup' Line 540: ACTION_REMOVE = 'cleanup' Line 541: ACTION_UPGRADE_FROM_LEGACY = 'upgrade (from monolithic setup)' Line 542: ACTION_UPGRADE_FROM_OTOPI = 'upgrade (from otopi setup)' Not sure what you mean, but otopi is not slang. People will install a package called otopi, will have dependencies on it, etc. I agree it has nothing to do with features (in principal, not in practice) and users. It's meant for support - this file is meant for support. If a user cares enough to look at it, they will probably know also what otopi is. Anyway, as I said above, you are welcome to suggest other names if not the ones I picked. Names I do not want, because they are unstable and will change: 'engine-setup', 'engine-setup-2', 'current', 'legacy', etc. Names I can live with: 'setup2011' and 'setup2013' (or whatever), 'setup30' and 'setup33' (or whatever), 'setup cool' and 'setup cooller' (but you'll have a hard time inventing more than a few for the next ones), etc. Anything that will not change its meaning over time. Line 543: Line 544: Line 545: @util.export Line 546: @util.codegen .................................................... File packaging/setup/plugins/ovirt-engine-setup/core/misc.py Line 64: osetupcons.FileLocations.OVIRT_SETUP_POST_INSTALL_CONFIG Line 65: ): Line 66: self.environment[ Line 67: osetupcons.CoreEnv.ACTION Line 68: ] = osetupcons.Const.ACTION_UPGRADE_FROM_OTOPI So what you now say is that we actually need two variables. One will be 'setup/upgrade/cleanup' and one will somehow contain the information that is kept here (new install vs upgrade for legacy vs upgrade from otopi setup). Or I did not understand you. Some days ago you commented (actually about something very related) that you do not want add code that is not used immediately. Now you do? I do not object. Just give clear definitions of what you want. And, BTW, I think that setup-engine-2 does need some testing of its 'upgrade from setup-engine-2' functionality which I am not sure was done enough. I, for one, was under the impression that we'll soon have a engine-upgrade-2 script, and only very recently understood from Sandro that this will done by the same engine-setup-2 script. Line 69: else: Line 70: self.environment[ Line 71: osetupcons.CoreEnv.ACTION Line 72: ] = osetupcons.Const.ACTION_SETUP -- To view, visit http://gerrit.ovirt.org/16245 To unsubscribe, visit http://gerrit.ovirt.org/settings Gerrit-MessageType: comment Gerrit-Change-Id: I0805134c602f37a646065a8794feb3721587d601 Gerrit-PatchSet: 1 Gerrit-Project: ovirt-engine Gerrit-Branch: master Gerrit-Owner: Yedidyah Bar David <d...@redhat.com> Gerrit-Reviewer: Alex Lourie <alou...@redhat.com> Gerrit-Reviewer: Alon Bar-Lev <alo...@redhat.com> Gerrit-Reviewer: Lev Veyde <lve...@gmail.com> Gerrit-Reviewer: Moran Goldboim <mgold...@redhat.com> Gerrit-Reviewer: Ofer Schreiber <oschr...@redhat.com> Gerrit-Reviewer: Sandro Bonazzola <sbona...@redhat.com> Gerrit-Reviewer: Yedidyah Bar David <d...@redhat.com> _______________________________________________ Engine-patches mailing list Engine-patches@ovirt.org http://lists.ovirt.org/mailman/listinfo/engine-patches
