Skip to content
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

Merged
merged 3 commits into from
Jan 24, 2019

Conversation

ekinanp
Copy link
Contributor

@ekinanp ekinanp commented Jan 24, 2019

This commit centralizes the puppet_collection_for_puppet_agent_version
and puppet_collection_for_puppet_version logic into a single
puppet_collection_for helper.

This commit centralizes the puppet_collection_for_puppet_agent_version
and puppet_collection_for_puppet_version logic into a single
puppet_collection_for helper.
@ekinanp ekinanp requested a review from caseywilliams January 24, 2019 00:10
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)
Copy link
Contributor Author

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
Copy link
Contributor

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?

Copy link
Contributor Author

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?

Copy link
Contributor

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

Copy link
Contributor

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

Copy link
Contributor

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.

Copy link
Contributor Author

@ekinanp ekinanp Jan 24, 2019

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.

Copy link
Contributor

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
Copy link
Contributor

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.

http://apt.puppet.com/pool/jessie/puppet6/p/

Copy link
Contributor Author

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.

Copy link
Contributor

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?
Copy link
Contributor

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).

Copy link
Contributor Author

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.

Copy link
Contributor Author

@ekinanp ekinanp Jan 24, 2019

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?
Copy link
Contributor

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

Copy link
Contributor Author

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?

Copy link
Contributor

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?

Copy link
Contributor Author

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.

Copy link
Contributor

@melissa melissa left a 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.
@ekinanp
Copy link
Contributor Author

ekinanp commented Jan 24, 2019

Sorry, I realized there were some dangling references to the old puppet_collection_for_ methods. Pushed up a commit to remove them.

@melissa
Copy link
Contributor

melissa commented Jan 24, 2019

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!

@melissa
Copy link
Contributor

melissa commented Jan 24, 2019

11:08:12 + bundle exec rake test:acceptance
11:08:13 rake aborted!
11:08:13 LoadError: cannot load such file -- rspec/core/rake_task

I'm digging into this locally to see what's up

Copy link
Contributor

@caseywilliams caseywilliams left a 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?

@melissa melissa merged commit 485d33c into puppetlabs:master Jan 24, 2019
@melissa
Copy link
Contributor

melissa commented Jan 24, 2019

Apparently acceptance has always failed

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants