-
Notifications
You must be signed in to change notification settings - Fork 3
check the xapi version in the installer #48
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
base: 10.10.29-8.3
Are you sure you want to change the base?
Conversation
backend.py
Outdated
available_xapi_versions = repository.listPackagesFromRepos( | ||
main_repositories, 'xapi-core', '%{evr}') | ||
if not available_xapi_versions: | ||
raise RuntimeError("No xapi package found") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
could be good to be more specific, like "... found in package source" (to avoid confusion with installed package)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To me, the message should be either about XAPI
, as the component name, or xapi-core
, as the package name that we actually looked for.
backend.py
Outdated
if not available_xapi_versions: | ||
raise RuntimeError("No xapi package found") | ||
available_xapi_version = available_xapi_versions[0] | ||
for v in available_xapi_versions[1:]: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This [1:]
leads me to think some comments would be useful here.
Note that listPackagesFromRepos
is written with the assumption that repoquery will return all available versions (as dnf repoquery
does) but quick tests right now show only a single version of each package in CentOS7 (like --latest-limit=1
with dnf
) - that makes me even more puzzled about that slice.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
that's just to select the greatest available version, in case there would be more than one returned by repoquery.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Oh I only now realize that's a "latest version in list" here.
IMO we'll rather want to make sure repoquery
does that on its own, and ensure it returns a single xapi-core
version.
The fact listPackagesFromRepos
only returns a single now today is a bug (assuming the CentOS7 repoquery
was acting more like dnf repoquery
).
I'd go with a flag for to return only the latest, add --show-duplicates
for when it isn't set, and an assert len()==1
when set to make we adjust flags properly when we'll switch to dnf
for v9.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
So you would use repoquery
with latest_only=True
(for example) in the case that we're commenting here, right?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think something is wrong for linstor: with repoquery returning a single value by default, how can we select the exact version for linstor if it's not the last one from the available packages?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The linstor case would use latest_only=False
. But today we only support upgrading it from an ISO, on which the only available version will be the latest one.
backend.py
Outdated
available_xapi_version = available_xapi_versions[0] | ||
for v in available_xapi_versions[1:]: | ||
if rpm.labelCompare(('pkg', 'arch', v), ('pkg', 'arch', available_xapi_version)) >= 0: | ||
available_xapi_version = v |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
behaviour when/if several versions are available is "latest wins", we may prefer to assert that we have a single version and avoid looping
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed: repoquery
needs --show-duplicates
if you want more than one version. At least in the version that we're using.
backend.py
Outdated
if rpm.labelCompare(('pkg', 'arch', available_xapi_version), ('pkg', 'arch', answers['xapi-version'])) < 0: | ||
raise RuntimeError("Cannot upgrade the host: the xapi version on the host (%s) " | ||
"is newer than the xapi version to install (%s). " | ||
"Please make sure to use the latest ISO." % |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
- "latest ISO" may not be sufficient if user has upgraded his XS to a newly-released XAPI
- we likely won't release new ISO for every XAPI update, so we'll likely direct users to installing from HTTP to get the latest version
- even then, the message(s) to use will need to be carefully crafted
Maybe use a list of suggestions like those? @stormi surely has more ideas
- (don't show when already installing from official URL) "try installing package from the network for a more recent version"
- wait for a new xapi package and refrain from updating in on your XS host in the meantime
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regarding the Latest ISO, I agree with Yann.
Regarding installing from HTTP, at the moment, we don't support installing from the base
+updates
repos, and only update netinstall repos at the same time that we release new ISOs. We'd like to do better in the future, but that requires CI improvements, so that the installer is always tested with the latest packages, and possibly installer improvements too (Maybe there's a way to make it work as is, but it's untested).
As there can be various situations in which this message is displayed, let's just state what we know for sure and tell users to refer to the official upgrade documentation.
(Which means that we have a documentation update to prepare so that this error is documented in it...)
"Please make sure to use the latest ISO." % | |
"Please refer to the XCP-ng upgrade documentation." % |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regarding installing from HTTP, at the moment, we don't support installing from the base+updates repos
That would be easily solved by generating self-sufficient repos instead of having them stacked on one another
|
||
prepUpgradeArgs = [] | ||
prepStateChanges = ['installation-uuid', 'control-domain-uuid', 'management-address-type', 'linstor-version'] | ||
prepStateChanges = ['installation-uuid', 'control-domain-uuid', 'management-address-type', 'linstor-version', 'xapi-version'] |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I would rather add xapi-version
(which could be interesting upstream) before linstor-version
(which I'm less sure we'll manage to upstream easily)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
good point, but as we need both on the same line, and for now this PR is based on the version with all the branches merged. I'll take care of that later when I'll make this PR based on upstream only :-)
backend.py
Outdated
available_xapi_versions = repository.listPackagesFromRepos( | ||
main_repositories, 'xapi-core', '%{evr}') | ||
if not available_xapi_versions: | ||
raise RuntimeError("No xapi package found") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
To me, the message should be either about XAPI
, as the component name, or xapi-core
, as the package name that we actually looked for.
backend.py
Outdated
available_xapi_version = available_xapi_versions[0] | ||
for v in available_xapi_versions[1:]: | ||
if rpm.labelCompare(('pkg', 'arch', v), ('pkg', 'arch', available_xapi_version)) >= 0: | ||
available_xapi_version = v |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Indeed: repoquery
needs --show-duplicates
if you want more than one version. At least in the version that we're using.
backend.py
Outdated
if rpm.labelCompare(('pkg', 'arch', v), ('pkg', 'arch', available_xapi_version)) >= 0: | ||
available_xapi_version = v | ||
if rpm.labelCompare(('pkg', 'arch', available_xapi_version), ('pkg', 'arch', answers['xapi-version'])) < 0: | ||
raise RuntimeError("Cannot upgrade the host: the xapi version on the host (%s) " |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
raise RuntimeError("Cannot upgrade the host: the xapi version on the host (%s) " | |
raise RuntimeError("Cannot upgrade the host: the XAPI version on the host (%s) " |
backend.py
Outdated
available_xapi_version = v | ||
if rpm.labelCompare(('pkg', 'arch', available_xapi_version), ('pkg', 'arch', answers['xapi-version'])) < 0: | ||
raise RuntimeError("Cannot upgrade the host: the xapi version on the host (%s) " | ||
"is newer than the xapi version to install (%s). " |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
"is newer than the xapi version to install (%s). " | |
"is newer than the XAPI version to install (%s). " |
backend.py
Outdated
if rpm.labelCompare(('pkg', 'arch', available_xapi_version), ('pkg', 'arch', answers['xapi-version'])) < 0: | ||
raise RuntimeError("Cannot upgrade the host: the xapi version on the host (%s) " | ||
"is newer than the xapi version to install (%s). " | ||
"Please make sure to use the latest ISO." % |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Regarding the Latest ISO, I agree with Yann.
Regarding installing from HTTP, at the moment, we don't support installing from the base
+updates
repos, and only update netinstall repos at the same time that we release new ISOs. We'd like to do better in the future, but that requires CI improvements, so that the installer is always tested with the latest packages, and possibly installer improvements too (Maybe there's a way to make it work as is, but it's untested).
As there can be various situations in which this message is displayed, let's just state what we know for sure and tell users to refer to the official upgrade documentation.
(Which means that we have a documentation update to prepare so that this error is documented in it...)
"Please make sure to use the latest ISO." % | |
"Please refer to the XCP-ng upgrade documentation." % |
Signed-off-by: Gaëtan Lehmann <[email protected]>
Signed-off-by: Gaëtan Lehmann <[email protected]>
2d25a78
to
2b7b38c
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
lgtm
if rpm.labelCompare(('pkg', 'arch', available_xapi_versions[0]), ('pkg', 'arch', answers['xapi-version'])) < 0: | ||
raise RuntimeError("Cannot upgrade the host: the XAPI version on the host (%s) " | ||
"is newer than the XAPI version to install (%s). " | ||
"Please refer to the XCP-ng upgrade documentation." % |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Let's not forget to add said doc. We can discuss what we should tell users. I know it's already covered at least for migration from XS, but I'm thinking about users who'd go check the docs after they saw the error. Something that explicitly gives them the error message their search for and explains their options.
raise RuntimeError("No XAPI package found in package source") | ||
assert len(available_xapi_versions) == 1 | ||
if rpm.labelCompare(('pkg', 'arch', available_xapi_versions[0]), ('pkg', 'arch', answers['xapi-version'])) < 0: | ||
raise RuntimeError("Cannot upgrade the host: the XAPI version on the host (%s) " |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Didn't we just say that it may be better to make it a warning screen rather than a fatal error?
No description provided.