removed fqdn of the server together with the version from the name of candlepin-cert-consumer package.
This makes scripting of the package downloads much, much simpler, as the package name doesn't need to be generated at runtime. This would also simplify development and testing, as in those environments fqdn of the katello host doesn't always equal the host in the url used to access katello.
- 点赞 评论 复制链接分享
I disagree. I think having version in file name is very good habit. Yes, you can still gather the version using rpm command. But not if you (e.g. support) only have log file, where is only file name. And candlepin_consumer_name is not only used to construct file name, but even the name of package (as stored in package header). Therefore you could not have two independent instances of candlepin (or katello) and both have managed by Katello, because both will have the same rpm with the same version.点赞 评论 复制链接分享
I'd agree with if we were talking about a normal package. This is purely a configuration rpm, built during the install of katello, that will never show up in public repositories.
How often would the support need versioning information for candlepin_consumer_cert package??? Moreover, there are other means to retrieve versioning information besides log files.
I don't understand your comment regarding package name: a host can't be managed by multiple instances of Katello/Candlepin. Having fqdn in the name is actually a deal-breaker: this breaks some setups.点赞 评论 复制链接分享
I don't understand your comment regarding package name: a host can't be managed by multiple instances of Katello/Candlepin
In reverse. Imagine one Katello server in Europe, one in US and one in Japan. This is actually very common setup. And of course users use management software because they are punctilious about package managing. Therefore they manage all three Katello server using one of those server or using another one, which stands as master (again, this is example of real setup). And they manage all package. Those which are in rhel repos, those which created themself and of course even cert package. Now how can they manage cert-package on all those server when they will have same NEVRA, but different content?
Having fqdn in the name is actually a deal-breaker: this breaks some setups.
Actually I just learn another counter-case: https://fedorahosted.org/katello/wiki/MultiHomeDesign In this example you will need two packages. Each of them will have different bootstrap script, because the server will have different names when accessed from different networks. Therefore you have to distinguish those packages even on one server.点赞 评论 复制链接分享
The idea is that the cert package is not going to be managed via normal means: it's not going to be promoted through environments/CVs, it's not going to be served from yum repositories. Instead it's going to be downloaded by the client from the appropriate Katello server directly.
With the above in mind: fqdn is not always resolvable, especially in test setups (when you don't have dedicated dns for a given zone, or have no access to the server authoritative for the zone). In joint foreman-katello setups katello url used by the Foreman is oftentimes the ip address of the server, which is most certainly differs from fqdn by which Katello identifies itself.
In other words: we have two independent systems which may use different fqdns for the Katello server. This makes the current naming convention for the cert package unusable, as one of the systems may not be able to resolve the package name at runtime.点赞 评论 复制链接分享
I may be missing something here, but how does a package that is generated during katello install get managed externally? And how could there ever be multiple versions on that katello install of that rpm?
Your multi-home example explicitly has instructions for building RPMs, as far as I can tell, so wouldn't the registering client system need to know the correct name anyway (and it would be different than default one)?
As it stands right now, we generate the rpm on every install with the same name and unchanging version every time. Thus there is no value in including neither the fqdn nor the version, right? Including them leads at least to users confusion, and perhaps to more complicated issues when trying to figure out what the correct fqdn is.点赞 评论 复制链接分享
ACK to symlink, very nice solution点赞 评论 复制链接分享
ACK as well.点赞 评论 复制链接分享
re-created the PR in katello-installer repository; closing here.点赞 评论 复制链接分享