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

Tarball #1244

Merged
merged 9 commits into from
Nov 16, 2021
Merged

Tarball #1244

merged 9 commits into from
Nov 16, 2021

Conversation

reidmv
Copy link
Contributor

@reidmv reidmv commented Nov 8, 2021

Chunk PR in support of (original monster PR) #1159

This pull request DEPENDS ON #1242, #1243. Do not merge until after those PRs are merged.

This PR implements:

  • An R10K::Tarball base class
  • An R10K::Module::Tarball class, providing a "tarball" module type
  • An R10K::Environment::Tarball class, providing a "tarball" environment type

Example usage:

---
production:
  type: tarball
  source: https://example.com/puppet-code-env-v1.0.0.tar.gz
  version: 99a906c99c2f144de43f2ae500509a7474ed11c583fb623efa8e5b377a3157f0 # sha256digest
  modules:
    puppetlabs-peadm:
      type: forge
      version: 2.5.0
    reidmv-xampl:
      type: git
      source: https://github.com/reidmv/reidmv-xampl.git
      version: 62d07f2
    reidmv-mymodule:
      type: tarball
      source: https://example.com/reidmv-mymodule-1.0.0.tar.gz
      version: 6128ada158622cd90f8e1360fb7c2c3830a812d1ec26ddf0db7eb16d61b7293f # sha256digest

Later enhancements built on top of this might include Artifactory types, or S3 types, with options for real versions, depending on how the remote repository works.

Fixes #567
Closes #1159

@reidmv reidmv requested a review from a team November 8, 2021 20:25
@reidmv reidmv mentioned this pull request Nov 8, 2021
It's not just a development dependency; it's an r10k dependency too.
Really it always has been because it's a puppetforge dependency.
Copy link
Collaborator

@Magisus Magisus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think I want to play with this a bit.

lib/r10k/module/tarball.rb Show resolved Hide resolved
lib/r10k/module/tarball.rb Outdated Show resolved Hide resolved
spec/unit/module/tarball_spec.rb Outdated Show resolved Hide resolved
spec/unit/module/tarball_spec.rb Show resolved Hide resolved
spec/unit/module/tarball_spec.rb Show resolved Hide resolved
lib/r10k/environment/tarball.rb Outdated Show resolved Hide resolved
@Magisus
Copy link
Collaborator

Magisus commented Nov 12, 2021

Would you mind adding something to the docs with examples on how to use this?

# @return [Array<String>]
def desired_contents
desired = []
desired += @tarball.paths.map { |entry| File.join(@full_path, entry) }
Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Discovered an interesting edge case here: if you build the tarball a bit wrong, even though it unpacks correctly, it might purge incorrectly. In my case, I created the tarball with .. So the paths inside it look like this:

"/Users/aileen/code/r10k/yaml-envs/tarball/.",
 "/Users/aileen/code/r10k/yaml-envs/tarball/./site-modules",
 "/Users/aileen/code/r10k/yaml-envs/tarball/./hiera.yaml",
...

But r10k's current_contents list looks like this:

"/Users/aileen/code/r10k/yaml-envs/tarball/site-modules",
 "/Users/aileen/code/r10k/yaml-envs/tarball/hiera.yaml",
...

So it purges everything except the modules directory (which is ignored by the environment purge level).

I realize this was my mistake, and I should get better at tarballs 😛 But it seems like something that could trip people up and cause a very confusing bug. Maybe we can add some normalization in Tarball.paths? Adding Pathname.new(path).cleanpath seemed to do the trick for me.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Ha! Excellent catch. Although I do have unbridled confidence that users of software would NEVER imperfectly construct a tarball 😉, this does seem like something we could fix.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Huh. I just snap-pushed what I thought would be the fix in 5a1711e, and then realized I was looking at a completely different part of the code. But, it might actually be a valid fix anyway? Don't have a test for it yet.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

That's the spot I edited when fixing this locally 🤷‍♀️ Seemed to work for my bad tarball.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Were you working on a test for this? I think besides that, I'm happy to merge this.

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, lemme add some thing for that. I might just re-construct the fixture tarball to include the ./ name components, I think that'd make it easy to validate. Will push something shortly.

Copy link
Collaborator

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Yeah that's what I was thinking 🙂

@Magisus
Copy link
Collaborator

Magisus commented Nov 16, 2021

So, are the tarball modules usable from the Puppetfile too? Or just with yaml envs? If they are usable from a Puppetfile, it might be nice to note that here.

@reidmv
Copy link
Contributor Author

reidmv commented Nov 16, 2021

So, are the tarball modules usable from the Puppetfile too? Or just with yaml envs? If they are usable from a Puppetfile, it might be nice to note that here.

Totally, and yeah, they are usable. I believe bc24f6b contains some reference to that. Do you think it should say more or say it differently?

@Magisus
Copy link
Collaborator

Magisus commented Nov 16, 2021

Oh duh, no, I missed which file that got added to, my bad.

reidmv and others added 7 commits November 16, 2021 10:23
This class will serve as a base class for creating tarball environment
and module types.
Trying to make sure the global cachedir option gets respected by tarball
This permits modules of type tarball to be used. Tarball modules will
be extracted with no modification into the modules target directory.
Tarballs should not be packed to include a top-level containing folder.

    modules:
      lwf-remote_file:
        type: tarball
        source: https://forge.puppet.com/v3/files/lwf-remote_file-1.1.3.tar.gz
        version: bce01b849631926b452900eff5dc385c893c4320c95b290f992e3c529f417f0e
This permits core environment content to be sourced from tarballs. The
tarball environment type supports defining modules as well.

    ---
    production:
      type: tarball
      source: https://example.com/puppet-code-env-1.0.0.tar.gz
      version: 99a906c99c2f144de43f2ae500509a7474ed11c583fb623efa8e5b377a3157f0
Co-authored-by: Maggie Dreyer <maggie@puppet.com>
Users might construct a tarball with entries like this:

  ./
  ./foo.txt
  ./foo/bar/

r10k's purging facility needs these to be normalized to work correctly.
This commit makes the R10K::Tarball#paths method normalize the values to
e.g.

  foo.txt
  foo/bar

Co-authored-by: Maggie Dreyer <maggie@puppet.com>
@reidmv
Copy link
Contributor Author

reidmv commented Nov 16, 2021

Two logical changes:

  • Changed the fixture'd tarball to include ./ path prefixes, such as a user might incidentally include in a constructed tarball. Did this in a rebase so as not to leave an extra binary blob in the Git history.
  • Made a new commit that adjusts R10K::Tarball#paths to return clean paths only, with a test

I didn't go so far as adding a purge test specifically. Seems like the most thorough fix would actually be to R10K::Util::Purgable itself, if we really wanted to do that. It seems reasonable enough for Tarball to just make sure paths returned are clean paths.

Copy link
Collaborator

@Magisus Magisus left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Retested this, seems to work well.

def properties
{
:expected => @checksum,
:actual => status,
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This would be something like :insync, :absent, :mismatch, right? I think consumers of this (for existing modules) determine the status of insync/mismatch/absent from whether the actual equals the expected, or if it differs, and if it differs if the actual was nil, respectively. I think we want to continue that behavior.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Better? e783dcc

I'm not actually sure how/where/why #properties is used, or what expectations exist for this method. The YARDoc definition in R10K::Module::Base isn't super helpful on that front.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

They are collected to write the r10k-deploy.json, which is used by Impact Analysis.

When a module is insync, the module's `actual` and `expected` properties
should match. When the module is not in sync, they should differ.
@Magisus Magisus merged commit 8cb3643 into puppetlabs:main Nov 16, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Support for plain tarballs
4 participants