-
Notifications
You must be signed in to change notification settings - Fork 66
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
(maint) Centralize puppet_collection_for logic #100
Conversation
This commit centralizes the puppet_collection_for_puppet_agent_version and puppet_collection_for_puppet_version logic into a single puppet_collection_for helper.
def puppet_collection_for_puppet_agent_version(agent_version) | ||
agent_version = agent_version.to_s | ||
return 'puppet' if agent_version.strip == 'latest' | ||
def puppet_collection_for(package, 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.
Chose this instead of puppet_collection_for(agent_version: <version>)
because a single entry hash parameter doesn't really make sense.
|
||
return 'pc1' if x == 4 | ||
return 'pc1' if x == 4 |
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.
do we need to keep pc1 around since we aren't doing anything with 1.x or 4.x in foss anymore?
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 so because we're still supporting upgrades from Puppet 4/Agent 1.x in the puppet_agent module. @caseywilliams can you confirm?
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 beaker-puppet used int he puppet_agent module? That's a little scary
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 wait, I shouldn't be surprised by this. The beaker puppet install helper uses beaker-puppet
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.
However, wouldn't this only be needed if we were installing new package? This should be verified, but I'm not convinced we need this for packages that already exist on the system we are upgrading. Just a thought. It would be nice to start removing all the pc1
references in this code. It's totes something we can save for later.
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.
We do need PC1 in the :puppet_agent
package case because the puppet_agent module tests calculate the collection from the agent version. I don't know about PC1 in the :puppet
package case though. @caseywilliams ?
EDIT: Nevermind. With the "reduce redundancy" commit, I think it's cleaner to keep the PC1 reference for Puppet 4.
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.
👍 sounds good :) Safest to keep it
def puppet_collection_for(package, version) | ||
valid_packages = [ | ||
:puppet_agent, | ||
:puppet |
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.
Shouldn't we have a longer list of valid packages here? Puppetserver, puppetdb, puppetdb-termini are all versioned on the same scheme as puppet and puppet_agent, so there is a case to be made that we might need to find the release stream for those 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.
I was thinking this could be something that'd be extended on a per-need case? So if a puppetserver person finds out that they need to calculate the collection from their package version, then they can extend this method with that code (and they'd figure out they need the collection from the raised exception). If you think it is a good idea to do as much as we can in the current implementation, however, I'm happy to update it. I'm not sure what the collection should be for legacy server/puppetdb versions (like Server 2.x, since agent 1.x uses it). Maybe we don't need to worry about those.
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 suppose it depends on where this method is used? But generally since this repo is so ad hoc, I'm fine waiting to add those other packages until we need them. As long as that's a conscious decision
"puppet#{x}" if x > 4 | ||
end | ||
x, y, z = agent_version.to_s.split('.').map(&:to_i) | ||
return nil if x.nil? || y.nil? || z.nil? |
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 there a way we can reduce the redundancies here? The only real difference between :puppet_agent
and :puppet
that I can tell is the pc1 logic (return 'pc1' if x == 1
vs return 'pc1' if x == 4
).
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.
Yeah, I can go ahead and do that.
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.
Updated the PR with a new commit.
x, y, z = puppet_version.to_s.split('.').map(&:to_i) | ||
return nil if x.nil? || y.nil? || z.nil? | ||
x, y, z = puppet_version.to_s.split('.').map(&:to_i) | ||
return nil if x.nil? || y.nil? || z.nil? |
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.
Hmm, I feel like we have enough information to return a valid result if the only thing we have is x
, since it's only the major version that defines the release stream. Though, I suppose if y
and z
are nil that might indicate a malformed version string.... I'm not sure my hang up on this is worth any follow up work
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.
We'll still need y
to handle weird cases like the 5.99
tag (I forgot why we did that in the first place -- maybe @caseywilliams can clarify ?).
It might be worth raising an exception for a malformed version string?
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 feel like raising an error isn't a bad idea if we can't figure out what's happening with the version string. Do we have existing utilities available to help parse version strings?
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.
There is Beaker::Shared::Semvar, but that doesn't raise any errors if the versions are malformed strings and it isn't specific to semver parsing.
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 travis failure isn't specific to this PR
18:09:14 An error occurred while installing i18n (1.5.3), and Bundler cannot continue.
18:09:14 Make sure that `gem install i18n -v '1.5.3' --source
18:09:14 'https://artifactory.delivery.puppetlabs.net/artifactory/api/gems/rubygems/'`
18:09:14 succeeds before bundling.
18:09:14
18:09:14 In Gemfile:
18:09:14 markdown was resolved to 1.2.0, which depends on
18:09:14 textutils was resolved to 1.4.0, which depends on
18:09:14 activesupport was resolved to 5.2.2, which depends on
18:09:14 i18n
I'm going to dig into that now and hopefully fix it.
But this looks good to me! Thanks for answering all my questions!
There were some dangling references to the previous puppet_collection_for_<package> methods that should be removed.
Sorry, I realized there were some dangling references to the old puppet_collection_for_ methods. Pushed up a commit to remove them. |
I manually edited the PR Tests job for this PR so I could test https://github.com/puppetlabs/ci-job-configs/pull/5530, but at least we know that's passing! |
I'm digging into this locally to see what's up |
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 is fine with me. Can I merge? Do we need to wait on acceptance?
Apparently acceptance has always failed |
This commit centralizes the puppet_collection_for_puppet_agent_version
and puppet_collection_for_puppet_version logic into a single
puppet_collection_for helper.